Wie mache ich mein DAPP „Serenity-Proof“?

Wenn Serenity kommt, wird das Netzwerk viele Änderungen erfahren, von denen einige unerwartete Auswirkungen auf bestehende Smart Contracts haben können. Wie kann ich so planen, dass ich am besten darauf vorbereitet bin, die Vorteile der neuen Funktionen in Serenity zu nutzen und am wenigsten unerwartete Fehler und Sicherheitslücken zu sehen?

Antworten (1)

Noch ist es nicht sicher, aber:

  1. Verlassen Sie sich NICHT auf sehr detaillierte Berechnungen der aktuellen Gaskosten. Gehen Sie davon aus, dass die Gaskosten für Vertragsanrufe bei einem zukünftigen Hard Fork um bis zu eine Größenordnung steigen oder fallen können.
  2. Wenn Sie Verträge in Assembly erstellen (d. h. nicht Serpent, Solidity oder LLL), verwenden Sie KEINE dynamischen JUMP/JUMPI-Operationen (d. h. jedem JUMP/JUMPI sollte unmittelbar ein PUSH-Wert vorangehen, der den genauen Punkt im Code angibt, zu dem gesprungen werden soll) .
  3. Machen Sie KEINE wichtigen Dinge basierend auf dem DIFFICULTY-Opcode.
  4. Verlassen Sie sich NICHT auf die Annahme einer Blockzeit zwischen 12-20 Sekunden.
  5. Gehen Sie NICHT davon aus, dass BLOCKHASHes eine zuverlässige Quelle für Zufälligkeiten sind.
  6. Gehen Sie NICHT davon aus, dass tx.origin weiterhin verwendbar oder sinnvoll ist.
  7. Gehen Sie NICHT davon aus, dass andere Opcodes als 0xfe weiterhin ungültig sind.

Es ist nicht sicher, ob alle diese Schritte erforderlich sind oder ausreichen, aber das sollte Sie zum größten Teil dorthin bringen.

Wenn also tx.origin nicht sinnvoll ist, wird msg.sender es trotzdem sein?
Ja, msg.sender bleibt sinnvoll.
sollten wir hinzufügen: "Geben Sie NICHT weiter, dass 0x0 niemals ein msg.sender sein kann?" - oder ist diese Idee der Tisch?
Es ist wahrscheinlich, dass wir den Einstiegspunkt auf etwas anderes als 0x0 setzen, wenn wir sehen, dass viele Anwendungen 0x0 als Ersatz für „in diesem Slot existiert noch kein Konto“ verwenden, bis zu dem Punkt, an dem 0x0 als Einstiegspunkt die Sicherheit gefährdet.
Warum sind Blockhashes keine verlässliche Quelle für Zufälligkeit?
@VitalikButerin Was ist eine zuverlässige Quelle für den Initiator einer Anrufkette, wenn nicht tx.origin?
@VitalikButerin Wie verhindern wir, dass Verträge zu Empfängern von Wert werden, dh böswillige Fallback-Funktionen werfen Sendemuster ein, ohne dass tx.origin == Absender der Nachricht erforderlich ist?
@VitalikButerin und ein weiterer großer ... verlassen Sie sich NICHT darauf, dass die Blocknummer oder Variablen über Verträge hinweg konsistent sind. Im Moment ist es im Grunde eine globale Blockchain für alle Verträge. Während Ihre Transaktion läuft, kann sie sich darauf verlassen, dass Variablen in anderen Shards konsistent sind. Aber können wir im Sharding-Szenario dann Race Conditions ZWISCHEN den Shards haben, oder verhält es sich im vollen ACID-Modus immer noch so, als gäbe es eine riesige Blockchain und die Blockzahlen werden wie bisher über alle Shards hinweg monoton steigen? Wird es „von innen im EVM gleich aussehen“?
Wie mache ich mein DAPP „Serenity-Proof“?
AntwortenHierDatenschutz-Bestimmungen1y, 0v