Wie gehen Ethereum-Kunden mit zukünftigen Sperren um?

Gemäß dem Yellow Paper sind die Beschränkungen für Blockzeitstempel, H s ,

  • H s ∈ ℙ 256 (Mathematischer Term #35) ― ①,
  • und H s > P(H) H s (Mathematischer Term #48 und #56) ― ②,

wobei P(H) H s der Zeitstempel des übergeordneten (vorherigen) Blocks ist und ℙ 256 eine Menge natürlicher Zahlen kleiner als 2 256 ist .

Es scheint , dass das Gelbe Papier zukünftige Blöcke (Blöcke mit einem zukünftigen Zeitstempel) zulässt ― ③, da es außer ① und ② keine Beschränkung gibt.

Aber wie gehen Ethereum- Kunden eigentlich damit um? Akzeptieren sie wirklich zukünftige Sperren, wie es das Gelbe Papier erlaubt?

Ich habe einen kurzen Blick auf den Quellcode von geth und cpp-ethereum geworfen , und es scheint ErrFutureBlockund "allowFutureBlocks"ist relevant, aber ich konnte nicht vollständig verstehen, was sie damit machen.

Wenn ich oben etwas übersehen oder falsch gemacht habe, lassen Sie es mich bitte wissen.

Das ist eine ausgezeichnete Frage. Ziemlich Mathe!

Antworten (1)

Ich habe den Quellcode von Eth , Geth , Parity , pyethapp gelesen .

  • Eth behält zukünftige Blöcke (im m_futureKartenobjekt) und verarbeitet sie später zu dem im Zeitstempel angegebenen Zeitpunkt.
  • Geth und Parity akzeptieren zukünftige Blöcke , aber nur maximal 30 Sekunden zukünftige. Andernfalls verwerfen. So klug.

Wenn sie naive Clients wären, also die Block-Zeitstempel-Validierung nur mit den Einschränkungen des Yellow Paper implementiert hätten, hätten sie Integer-Overflow-Schwachstellen, die zu Denial of Service führen können .

Zusamenfassend

Akzeptieren sie wirklich zukünftige Sperren, wie es das Gelbe Papier erlaubt?

NEIN.

Aus Interesse, wenn Geth und Parity einen Block mit einem Zeitstempel 29 Sekunden in der Zukunft erhalten, aktualisieren sie den Zeitstempel des Blocks, den sie abbauen, so dass er später ist als der, den sie gerade akzeptiert haben, oder versuchen sie einfach weiter zu schürfen ein Block, den sie im Erfolgsfall als ungültig betrachten würden, weil der Zeitstempel rückwärts geht?
@EdmundEdgar Guter Fang. Jetzt lese ich den Quellcode von Parity und Geth über das, was Sie gesagt haben. Ich werde kommentieren, wenn meine Untersuchung abgeschlossen ist.
@EdmundEdgar Fertig. Sie aktualisieren den Zeitstempel des Blocks, den sie abbauen, so dass er 1 Sekunde später ist als der zukünftige Block, den sie gerade akzeptiert haben. Geth wartet (schläft) einige Sekunden, um zukünftige Blöcke nicht abzubauen, während Parity dies nicht tut. :)
Wie gehen Ethereum-Kunden mit zukünftigen Sperren um?
AntwortenHierDatenschutz-Bestimmungen1y, 0v