Wird sich die Einführung von Sharding auf die Funktionalität aktuell eingesetzter Smart Contracts oder der EVM auswirken?

Besteht die Gefahr, dass der Hard Fork, der für das Sharding oder Plasma erforderlich ist, um im Ethereum-Netzwerk wirksam zu werden, zu Kompatibilitätsproblemen für bereits bereitgestellte Verträge führt?

Wird das Protokoll, das immer dann eingesetzt wird, wenn Sharding in Kraft tritt, mit aktuellen Verträgen (wie Token usw.) abwärtskompatibel sein?

Danke für jede Hilfe. Ich habe Mühe zu verstehen, wie sich dies auf diesen Aspekt von Ethereum auswirken wird.

Antworten (1)

Phase-1-Sharding hat keine Ausführung oder EVM, sodass es nicht in das Hauptnetz integriert wird. Phase 2 wird ein EVM haben und rückwärtsinkompatible Änderungen auf Smart-Contract-Ebene einführen, wie z. (Siehe https://github.com/ethereum/wiki/wiki/Sharding-FAQ#du-erwähntest-transparentes-sharding-im-12-years-old-and-what-is-this ; siehe auch die Links auf der Speichermietpunkt hier: https://github.com/ethereum/wiki/wiki/Sharding-roadmap#phase-2-evm-state-transition-function .)

Grundlegendes Sharding-Design: https://github.com/ethereum/wiki/wiki/Sharding-FAQ#what-might-a-basic-design-of-a-sharded-blockchain-look-like .

Als L2-Lösung muss Plasma mit allen aktuellen Blockchain-Spezifikationen kompatibel sein.

Danke schön. Gibt es eine Dokumentation darüber, wie dies DX- und UX-freundlicher gemacht werden kann? Wird die aktuelle EVM auch weiterhin auf Ethereum-Knoten ausgeführt oder wird sie als etwas anderes betrachtet (wie Ethereum Classic 2.0), sobald ein Sharding-Hard-Fork stattfindet?
Aktualisierte Links für den ersten und dritten: github.com/ethereum/wiki/wiki/… und github.com/ethereum/wiki/wiki/… . Es muss eine Hard Fork geben, also müssen Knotenbetreiber ihren Client auf die neueste Version aktualisieren, die die Hard Fork unterstützt. Natürlich besteht bei einer Hard Fork immer die Möglichkeit, dass sie nicht sauber ist und einige Betreiber weiterhin eine alte Version wie Ethereum Classic verwenden.