Ist Solidity block.number sicherer als timestamp?

In Solidity sind einige Eigenschaften wie z. B. block.timestampvon Minern angreifbar und nicht (stark) durch das Protokoll geschützt. Wie wäre es block.number, könnte ein Miner eine zufällig hohe Zahl einführen?

BEARBEITEN: Ich denke darüber nach, ein Spiel zu sichern, das Aktionen wie eine Auszahlung nach Ablauf einer bestimmten Zeitspanne erleichtert.

Wenn wir über Stunden oder Tage sprechen und nur wissen möchten, ob die Zeit vergangen ist oder nicht, glaube ich nicht, dass die Verwendung von Blocknummern anstelle von Blockzeitstempeln einen bedeutenden Sicherheitsvorteil bringen würde. Wenn die Zeit jedoch den Menschen die Möglichkeit geben soll, auf etwas zu reagieren, indem sie Transaktionen senden – zum Beispiel, um eine vorgeschlagene Aktion anzufechten – möchten Sie vielleicht auch eine Sperrnummer angeben, nur für den Fall, dass etwas Seltsames im Netzwerk passiert . Ich denke, es ist grenzwertig, ob der Wert davon die Sicherheitskosten der zusätzlichen Komplexität wert ist.
Bitte beachten Sie, dass block.timestampSpekulationen in der Regel unbegründet sind. block.timestampist in realen Szenarien sehr sicher. block.timestampist für 99 % der Anwendungsfälle sicher. Wenn Sie Angst vor dem Frontrunning-Problem haben, dann löst die Verwendung block.numberes nicht wirklich. Wenn Sie befürchten, dass Bergleute Ihre Transaktion durcheinander bringen, dann haben Sie eine Möglichkeit für andere Angriffsvektoren, die die Verwendung block.numbernicht löst.

Antworten (1)

Die Blocknummer ist per Definition immer korrekt: Es ist die Nummer x in der Kette, weil sie über x-1 verkettet ist.

Wie Sie jedoch sagen block.timestamp, kann ein wenig gespielt werden - oder mit der Zusammenarbeit der wirtschaftlichen Mehrheit der validierenden Knoten viel - was auch bedeutet, dass das Verhältnis von block.numberzur tatsächlichen Zeit gespielt werden kann. Wer also nicht darauf vertraut, dass a block.timestampvom 01.01.2017 wirklich ungefähr der 01.01.2017 sein wird, der kann sich auch nicht darauf verlassen, die Blöcke zu zählen, die bis zum 01.01.2017 abgebaut werden sollen.

PS. Die Leute können Ihnen möglicherweise hilfreichere Ratschläge geben, wenn Sie uns mitteilen, für welchen Zweck Sie sicher sein möchten und wovor Sie sicher sein möchten.

Ich verstehe nicht So if you don't trust that a block.timestamp of 2017-01-01 will really be approximately 2017-01-01, you can't rely on counting the blocks that are supposed to be mined between now and 2017-01-01 either.: Wenn mein Spiel bei Blocknummer 1M beginnt und 100 Blöcke bis zur Auszahlung dauern sollte, könnte ich einfach überprüfen, ob wir bereits Block 1'000'100 erreicht haben. Ich vertraue hier dem Konsensalgorithmus, dass die Zeit dazwischen 100 * 14 Sekunden betrug und nicht nur ein einzelner Miner.
Der Konsensalgorithmus verhindert, dass Blöcke rückwärts oder weiter vorwärts als die aktuelle Zeit gehen. Und jeder ehrliche Miner kann es zum richtigen Zeitpunkt vorverlegen. Ohne viel Miner-Zusammenarbeit sollte es also nicht weit sein. Wenn es im Laufe der Zeit viel Unfug der Miner gibt, wirkt sich dies auch auf das Retargeting aus, sodass das Blockintervall nicht zuverlässig 14 Sekunden beträgt.
Lassen Sie mich für maximale Klarheit versuchen, es anders zu formulieren: Ohne signifikante Zusammenarbeit können Bergleute nicht beeinflussen, wann Block Nummer X im Netzwerk erscheint. Daher block.numberist es wesentlich sicherer als block.timestampdas, was (bis zu einem gewissen Grad) von einem einzelnen Miner manipuliert werden kann. Da die Blockzeit nicht konstant ist, ist dies jedoch nur dann eine praktikable Lösung, wenn die genaue Zeit nicht benötigt wird. Richtig?
Das ist nicht ganz richtig. Der Miner kann beeinflussen, wann Block Nummer X im Netzwerk erscheint: Er kann Blöcke, die er geschürft hat, auf später zurückhalten, oder er kann mehr Miner einschalten, um die Dinge für eine Weile schneller zu machen. (z. B. wenn Sie einen Chunk-Mining-ETC haben, ist es fast kostenlos, ihn vorübergehend auf ETH umzustellen.) Es stimmt, dass block.timestamper innerhalb des Blockfensters leicht und kostenlos manipuliert werden kann (dh wenn Sie 15 Sekunden nach dem letzten Block abgebaut haben, könnten Sie es so tun). B. 3 Sekunden nach dem letzten Block), aber die Präzision, die Sie bei diesem Angriff verlieren, geht bereits verloren, wenn Sie Blockhöhe verwenden.
Mein aus dem Hintern gezogener Vorschlag, ohne Mathematik zu begehen, wäre, dass Sie die Blockhöhe (oder beides, wenn Sie menschliche Zeit benötigen) für kleine Zahlen wie 10 Blöcke verwenden möchten, denn wenn weniger Blöcke verstrichen sind, ist nichts verstrichen Die Blockchain kann Ihnen zuverlässig Auskunft über die Zeit geben. Tage und Wochen sollten Sie verwenden, block.timestampwenn es Ihnen um menschliche Zeit geht, um etwas über soziale Kanäle herauszufinden, oder Blockhöhe, wenn Ihnen die Möglichkeit wichtig ist, eine Transaktion durch einen automatisierten Prozess zu senden, oder beides, wenn Sie sich darum kümmern beide. 100 Blocks fühlt sich ein bisschen grenzwertig an.
ok danke für die aufklärung. Um wie viel ein Miner den Zeitstempel wirklich verändern kann, ist ein weiteres Thema, das wir in einem anderen Thread diskutieren sollten. Ich denke, das ist nicht so offensichtlich (weißes vs. gelbes Papier vs. Geth).
@Sebastian Das Protokoll hat keine Begrenzung, wie hoch der Zeitstempel sein kann, aber es ist unwahrscheinlich, dass andere Miner auf einem solchen Block aufbauen: ethereum.stackexchange.com/questions/5927/…
Ist Solidity block.number sicherer als timestamp?
AntwortenHierDatenschutz-Bestimmungen1y, 0v