Angenommen, Peer A erhält einen Vertrag und legt Vertrags-ABI offen. Peer B möchte demselben Netzwerk beitreten. Er hat die ABI bei sich. Aber er möchte den echten Vertragscode sehen, bevor er dem Netzwerk beitritt. Wie Peer B das sehen kann.
Sofern Peer A den Quellcode nicht zur Verfügung gestellt hat, können Sie nur den Bytecode (dh den kompilierten Code) sehen.
Auch wenn Peer A den Quellcode zur Verfügung stellt, sollten Sie dennoch vorsichtig sein. Wenn Peer A böswillig war, hat er/sie möglicherweise Quellcode mit einer identischen ABI veröffentlicht, aber mit unterschiedlichem Code hinter der Schnittstelle.
Aus diesem Grund sollten Sie, wenn Sie wirklich ultrasicher sein wollen, den Quellcode besorgen, ihn lesen, bis Sie sicher sind, dass er tut, was er tun soll, und ihn dann selbst in Bytecode kompilieren. Erst wenn Sie bestätigt haben, dass der von Ihnen selbst kompilierte Bytecode mit dem identisch ist, was an der Adresse des Smart Contracts läuft, können Sie sicher sein, dass Sie vollständig verstehen, was passiert, wenn Sie ETH dorthin senden.
Dies ist beispielsweise der Golem-Fabrikvertrag ( https://etherscan.io/address/0x7da82c7ab4771ff031b66538d2fb9b0b047f6cf9 ). Wie Sie sehen können, wurde der Quellcode „verifiziert“. In diesem Fall hat Etherscan den oben beschriebenen Prozess durchgeführt, und Sie können sicher sein, dass der Quellcode und der Bytecode identisch sind.
Peer A hätte es unter posten sollen GitHub.com/(TheRelevantRepositorySubdirectoryHere).
Ansonsten steht er auf dem betreffenden Block als Bytecode zur Verfügung. Die EVM führt diesen Bytecode aus, wenn der Vertrag verwendet wird: z. B. Speichern/Ändern von Daten oder Verwenden einer constantFunktion. Natürlich gibt es immer Bytecode-zu-Opcode-Konverter.
Verwandte: https://stackoverflow.com/questions/33798205/how-to-get-or-verify-the-source-code-of-a-contract
Ismael
Thomas JayRush
inputDatenfeld enthalten. Ich denke, das OP fragt nach dem Solidity-Quellcode.eth