Ich habe angenommen, „DuskEVM unterstützt Solidity“ würde bedeuten, dass Entwickler mit bestehendem Ethereum-Tooling einfach loslegen und fertig wären. Die eigenen Quickstart-Dokumente von Dusk fügen allerdings stillschweigend einen Schritt hinzu, den die meisten Leute übersehen: die Verifizierung der Quelle.
Das Bereitstellen ist der leichte Teil. DuskEVM nutzt Blockscout als Explorer, und dort bedeutet „Verify & Publish“, dass die relevanten Build-Einstellungen, die Compiler-Version, die Optimizer-Konfiguration, die Quell-Dateien, die Konstruktor-Argumente so nachzustellen sind, dass sie den Bytecode reproduzieren, der tatsächlich bereitgestellt wurde.
Das ist eine andere Messlatte als EVM-Kompatibilität. Die Bereitstellung beweist, dass der Code laufen kann. Die Verifizierung ermöglicht es jemand anderem zu prüfen, was tatsächlich ausgeführt wird. Ein Vertrag kann bereitgestellt und funktionsfähig sein, obwohl er noch nicht verifiziert ist—und dadurch ist es für alle anderen nicht möglich, unabhängig nachzuvollziehen, ob die veröffentlichte Quelle wirklich mit dem übereinstimmt, was live ist.
Das heißt: „EVM-kompatibel“ und „entwicklerbereit“ sind nicht ganz dieselbe Aussage. Die eine Frage lautet, ob dein Code hier läuft. Die andere lautet, ob ein Auditor, eine Institution oder ein Nutzer tatsächlich bestätigen kann, dass das, was läuft, mit dem übereinstimmt, was behauptet wird.
„Eine Kette kann deinen Solidity-Vertrag ausführen und dich trotzdem im Unklaren lassen, nicht beweisen zu können, was dieser Vertrag tatsächlich ist.“
Was ich als Nächstes sehen möchte: ob ein Vertrag, der über den standardmäßigen Solidity/Hardhat-Pfad bereitgestellt wird, zuverlässig anhand seines bereitgestellten Bytecodes verifiziert werden kann—nicht nur, dass die Bereitstellung erfolgreich war.
#dusk $DUSK @Dusk
Das Bereitstellen ist der leichte Teil. DuskEVM nutzt Blockscout als Explorer, und dort bedeutet „Verify & Publish“, dass die relevanten Build-Einstellungen, die Compiler-Version, die Optimizer-Konfiguration, die Quell-Dateien, die Konstruktor-Argumente so nachzustellen sind, dass sie den Bytecode reproduzieren, der tatsächlich bereitgestellt wurde.
Das ist eine andere Messlatte als EVM-Kompatibilität. Die Bereitstellung beweist, dass der Code laufen kann. Die Verifizierung ermöglicht es jemand anderem zu prüfen, was tatsächlich ausgeführt wird. Ein Vertrag kann bereitgestellt und funktionsfähig sein, obwohl er noch nicht verifiziert ist—und dadurch ist es für alle anderen nicht möglich, unabhängig nachzuvollziehen, ob die veröffentlichte Quelle wirklich mit dem übereinstimmt, was live ist.
Das heißt: „EVM-kompatibel“ und „entwicklerbereit“ sind nicht ganz dieselbe Aussage. Die eine Frage lautet, ob dein Code hier läuft. Die andere lautet, ob ein Auditor, eine Institution oder ein Nutzer tatsächlich bestätigen kann, dass das, was läuft, mit dem übereinstimmt, was behauptet wird.
„Eine Kette kann deinen Solidity-Vertrag ausführen und dich trotzdem im Unklaren lassen, nicht beweisen zu können, was dieser Vertrag tatsächlich ist.“
Was ich als Nächstes sehen möchte: ob ein Vertrag, der über den standardmäßigen Solidity/Hardhat-Pfad bereitgestellt wird, zuverlässig anhand seines bereitgestellten Bytecodes verifiziert werden kann—nicht nur, dass die Bereitstellung erfolgreich war.
#dusk $DUSK @Dusk
