Mehrere Ethereum (ETH)-Entwickler haben Bedenken hinsichtlich einer potenziellen Sicherheitslücke in einer neuen Smart Contract-Funktion geäußert, die bei dem bevorstehenden Constantinople Hard Fork in die Codebasis von Ethereum integriert werden soll.
Als Reaktion auf diese Bedenken erklärte Ethereum-Mitbegründer Vitalik Buterin bei einem Entwicklertreffen am 15. Februar, dass die geplanten Änderungen der Codebasis keine Schwachstellen in der Ethereum-Blockkette verursachen werden. Nach Aussagen anderer Ethereum-Entwickler könnte das Feature “Skinny CREATE2”, das Teil des Ethereum Verbesserungsvorschlags (EIP) 1014 ist, möglicherweise eine Sicherheitsbedrohung für das Ethereum-Netzwerk darstellen.
“Skinny CREATE2” ermöglicht den Benutzern die Interaktion mit einem Smart Contract, der noch nicht auf der Ethereum-Blockchain ausgestellt wurde. Wie von den Entwicklern von Ethereum erläutert, ermöglicht “Skinny CREATE2” Interaktionen mit “Adressen, die noch nicht on-chain existieren, aber darauf vertrauen können, dass sie nur eventuell Code enthalten”. Diese Funktion könnte laut den Bedenken ausgenutzt werden, weil Smart Contracts so programmiert werden könnten, dass sie ihre Adresse nach der Ausgabe ändern.
Insbesondere Jeff Coleman äußerte Bedenken hinsichtlich der Möglichkeit, Adressverpflichtungen gemäß dem neuen Vorschlag zu manipulieren,
Eines der Dinge, die bei Create2 kontraintuitiv sind, ist, dass theoretisch Redeployments den Vertragsbytecode ändern können, da die Adresse nur eine Bindung an den Initcode ist. Die Leute müssen sich bewusst sein, dass init-Codes Teil des Audits sind, [….] dass nicht-deterministische init-Codes ein Problem sind.
Coleman führte weiter aus, wie das Problem behoben werden könnte, um Adressänderungen oder Selbstzerstörung nach der ersten Festlegung des Vertragscodes zu verhindern,
Wenn wir uns darauf freuen, wo wir landen wollen, dann wäre es, alle Adressen [….] über den Initcode vertraglich binden zu lassen. Wir brauchen eine inhaltsbasierte Adressierung von Verträgen und nicht nur eine auftragsbezogene Adressierung, was Create1 ist. Wenn wir also an den Ort gelangen, an dem Create2 Standard ist, werden wir uns von der Selbstzerstörung ganz befreien [….], könnten wir diese Vorstellung von einem Vertragsbruch verwerfen.
Vitalik Buterin’s Kommentar zu CREATE2
Buterin wies die Behauptungen als “Industriegeschwätz” zurück, dass das Feature, das ursprünglich von Buterin selbst vorgeschlagen wurde, die Sicherheit der Blockchain gefährden würde und erklärte die Auswirkungen von CREATE2 auf die langfristige Roadmap von Ethereum:
Das Einzige, was wir beachten müssen, ist mehr für die Zukunft, wenn wir über Mieten und Löschung nachdenken; das ist ein Weg, der dazu führen kann, dass Verträge in einem Zustand sind, in dem sie sich nicht in einem Zustand ohne Selbstzerstörungsbetrieb befinden [….]. Es ist nichts, was wir in den nächsten Wochen herausfinden müssen, aber es ist trotzdem nützlich, daran zu denken, wenn wir das ETH 2.0 Sharding sehr bald auf eine VM-Spezifikation umstellen.
Featured Image: Ponderful Pictures | Shutterstock