Ich weiß nicht, wann und wie oft ein Skript ausgeführt wird, aber es scheint mir, dass es ein Problem geben würde, wenn ein einzelnes Skript (oder eine Summe aller Skripte in einem Block) die Zeit überschreitet, die benötigt wird, um in einen aufgenommen zu werden Block.
Angesichts der Tatsache, dass der Trend bei Altcoins darin besteht, die Blockzeitdauer zu verkürzen, denke ich, dass dies zu einem Problem oder einer Rennbedingung werden könnte, bei der der TX niemals in einen Block aufgenommen wird.
Wenn man bedenkt, dass mit zunehmender Größe der verschiedenen Alt-Coin-Blöcke ... Vielleicht größer als 1 MB, würde dieses Risiko angesichts der höheren Anzahl von Transaktionen ebenfalls zunehmen.
Also meine Frage ist:
Ich habe gehört, dass bestimmte alte TX-Skripte während der anfänglichen Synchronisierung nicht validiert werden, um den Prozess zu beschleunigen, also gibt es vielleicht andere Fälle, in denen ein TX nicht ausgeführt wird. (Vielleicht ist es ein unbekanntes Skript.)
Vielleicht sind nur Bergleute betroffen.... Ich bin mir nicht sicher.
Sie sollten sich keine Sorgen machen müssen, dass dies jemals passiert.
Es gibt keine Loop-Opcodes in Skripten. Jeder Skript-Opcode kann nur einmal ausgeführt werden, und der langsamste Opcode ist wahrscheinlich die ECDSA-Signaturüberprüfung (weil es um EC_point_multiply geht). Trotzdem dauert die Verarbeitung auf einem einzelnen Kern einer modernen CPU nur etwa 50 bis 100 μs.
Nehmen wir an, ein 1-MB-Block (maximale Größe) enthält 100 % Signaturüberprüfungs-Opcodes, das sind 1 Million Signaturüberprüfungen und benötigen höchstens 100 Sekunden CPU-Zeit eines einzelnen Kerns, dies ist immer noch viel weniger als die Blockzeit. In der Praxis wird jede scriptSig von mindestens 100 Byte Daten (Pubkey + ECDSA-Signatur) begleitet, sodass sie wahrscheinlich weniger als 1 Sekunde CPU-Zeit benötigt.
Dies ist ein potenzielles Problem bei Bitcoin, aber noch viel mehr bei Altcoins. Bitcoin ist sehr konservativ in der Reichhaltigkeit seines Transaktionsskripts. Altcoins mit einer schnelleren Blockzeit und/oder weniger restriktiven Scripting-Engines müssen erhebliche Optimierungen vornehmen, damit dies kein Risiko darstellt.
Dies ist eines der Probleme bei der Erhöhung der Blockgröße auf etwa 8 MB.
Rusty Russell diskutiert in einem Beitrag über die Megatransaktion ( https://rusty.ozlabs.org/?p=522 ).
Laut Rusty
Wenn Blöcke 8 MB groß wären: Eine 8-MB-Transaktion mit 22.500 Eingaben und 3,95 MB Ausgaben benötigt mehr als 11 Minuten zum Hashen. Wenn Sie eine davon abbauen können, können Sie Konkurrenten für immer von Ihren Fersen fernhalten und das Bitcoin-Netzwerk besitzen
Die Bitcoin-Core-Entwickler haben erhebliche Verbesserungen an der Bitcoin-Infrastruktur (wie libsecp256k1) vorgenommen, um zukünftige Erweiterungen zu ermöglichen. Aber dies ist ein Beispiel dafür, wie eine einfache ständige Veränderung weitreichende Auswirkungen haben kann.
Wenn es nur ein einzelner Knoten ist, der hinterherhinkt, könnte jeder seiner generierten Blöcke leicht zu einem verwaisten Block werden, der vom Netzwerk nicht akzeptiert wird. Wenn dies ein Fehler/Bug im Altcoin ist, passt sich die Schwierigkeit nach unten bis zum Minimum an, da keine Knoten Blöcke schnell genug vervollständigen (was unmöglich ist, wenn die Blockverarbeitung immer länger als die Blockzeit dauert).
Wie bereits erwähnt, ist es unwahrscheinlich, dass dieser Fehler auftritt, da die Verarbeitungszeiten für Blöcke vernachlässigbar sind. Es sei denn, Ihre Blockzeit ist so niedrig, aber Sie werden auf größere Probleme stoßen, wenn Ihre Blockzeit unter einer Sekunde liegt.
Macher7
Joe Pineda