Bereitgestellte Verträge ohne Solidity-Code [geschlossen]

Ich habe viele Verträge auf Etherscan überprüft und festgestellt, dass viele von ihnen keinen Solidity-Code veröffentlicht haben. Meiner Meinung nach macht es keinen Sinn, einen Vertrag ohne den Solidity-Code zu verwenden/veröffentlichen, er bricht das gesamte Konzept von Smart Contracts. Wenn man den Solidity-Code von Smart Contract nicht überprüfen kann, interagiert er damit, was bringt es dann überhaupt, Ethereum zu verwenden? Denken Sie, dass es in irgendeiner Weise obligatorisch sein sollte, den zugehörigen Code zu veröffentlichen? Ich weiß, man kann den Bytecode zu Assembler-ähnlichen Befehlen dekompilieren, aber uhhh, es sollte transparenter sein, oder? Ich glaube, auf etherscan.io ist der veröffentlichte Solidity-Code nicht in der Ethereum-Blockchain gespeichert, sondern nur in einer interlan etherscan.io-Datenbank. Ich weiß, dass es viel Platz in der Ethereum-Blockchain brauchen würde, um den Solidity-Code zu speichern....

Standards sind aus diesem Grund sehr wichtig, aber auch, warum viele Menschen Smart Contracts nicht mögen; sie können unordentlich werden. Theoretisch könnte ein Programmierer hingehen und einen Teil des Vertragscodes ändern, ohne dass der Benutzer davon erfährt (vorausgesetzt, der Vertrag ist änderbar). Benutzer brauchen einen Anreiz, überhaupt mit dem Vertrag zu interagieren, und eine etablierte und vertrauenswürdige Partnerschaft. Ich würde hoffen, dass der Interagierende zumindest Zugriff auf abi hat. Dann sollte diese Partei zumindest jede Interaktion verstehen. Eine Vertrags-Blockchain klingt schwer.

Antworten (4)

Nun ... konzeptionell sollten Sie, genau wie im wirklichen Leben, keinen Vertrag akzeptieren oder mit ihm interagieren, den Sie nicht lesen können.

Abgesehen davon gibt es viele Verträge, die nicht für die breite Öffentlichkeit bestimmt sind. Wenn ich zum Beispiel einen Vertrag speziell zwischen Ihnen und mir schreiben wollte, sollte keine Verpflichtung bestehen, den dazugehörigen Code öffentlich zu veröffentlichen. Ich würde Ihnen den Code direkt zur Überprüfung senden, und es wäre Ihre Sache, eine Art Überprüfungstool zu verwenden, um den Code zu überprüfen.

Der einzige Zweck des intelligenten Vertrags besteht darin, sicherzustellen, dass jede Interaktion/Transaktion mit ihm eingehalten wird ... nicht die im Vertrag festgelegten Parameter zu überprüfen.

Ich stimme @reyHaynes zu.

Außerdem würde ich Anstoß an der Idee nehmen, dass es keinen Sinn macht, wenn es keinen Quellcode gibt.

Die harte Realität ist, dass das EVM Bytecode gemäß seiner Maschinenlogik-Idee davon, wie "richtig" aussieht, ausführen wird. Der Compiler selbst kann eine Fehlerquelle sein. Unabhängig davon, woher er kommt, der Bytecode ist das, was zählt. Nicht alle Verträge sind für alle Beobachter gedacht.

Stimmt, wenn jemand das Vertrauen anderer gewinnen möchte, dann ist eine Möglichkeit, den Quellcode zu veröffentlichen, damit wir ihn leichter verstehen können.

Wenn wir nicht sehen und verstehen sollen, ist es wirkungslos, die Quelle zu verbergen. Es belästigt lediglich einen entschlossenen Gegner.

Ich hoffe es hilft.

Während die anderen Antworten darin richtig sind, dass im Allgemeinen nicht unbedingt eine Verpflichtung zur Veröffentlichung des Quellcodes für einen Vertrag besteht, der nicht für die Verwendung durch die breite Öffentlichkeit bestimmt ist, ist der grundlegendere Grund, warum es keine Anforderung auf Protokollebene gibt, den Quellcode zu veröffentlichen dass dies eine Spezifikation auf Protokollebene für die Hochsprache erfordern würde.

Die EVM ist eine sprachagnostische Maschine. Ich kann Code in Solidity, Serpent, LLL, reinem Assembler usw. schreiben und alles wird gut funktionieren. Das Erfordernis des Quellcodes bedeutet, dass jeder nicht nur die gleiche Sprache, sondern auch die gleiche Compiler-Version verwenden muss, was Aktualisierungen der Hochsprache sehr schwierig macht.

Im Wesentlichen ändert sich Solidity als Sprache sehr häufig, EVM ändert sich sehr selten, und daher ist es weitaus sinnvoller, einfach den Maschinencode zu veröffentlichen und den Entwickler den Quellcode out-of-band veröffentlichen zu lassen.

Es gibt viele Smart-Contract-Anwendungen, deren Code definitiv NICHT der Öffentlichkeit zugänglich gemacht werden sollte (dh denjenigen, die nicht mit dem Vertrag in Verbindung stehen). Stellen Sie sich zum Beispiel einen Vertrag vor, an den Sie Ihre ERC20-Token senden können und diese Token nur mit einem Passwort abheben können, aber dies kann von jeder Adresse aus erfolgen. Auf diese Weise müssten Sie sich keine Sorgen machen, Ihren privaten Schlüssel oder ähnliches zu verlieren, da Ihre Token in einem Vertrag eingeschlossen sind. Möchten Sie, dass der Code öffentlich ist, damit Hacker versuchen können, potenzielle Schwachstellen im Code auszunutzen, um Ihre Token zu stehlen? Diese Frage muss nicht beantwortet werden, da sie rhetorisch ist, und ich bin sicher, dass Sie den Sinn dieser Antwort auf Ihre Frage verstehen.

Trotzdem halte ich es für wichtig, dass Smart Contracts, an denen Gemeinschaften von Menschen teilnehmen, wie ICOs, ERC20-Token, Glücksspielanwendungen und Spiele, öffentlich gemacht werden sollten.

Wenn ein Hacker wirklich etwas Ether aus dem Vertrag stehlen möchte, könnte er den Vertrag dekompilieren, analysieren und trotzdem Ihr Geld stehlen. Ohne den Solidity-Code wäre es zeitaufwändiger, aber es ist immer noch machbar. Es wäre nur eine Frage der Zeit, es anzugreifen, das ist kein Sicherheitsschild. Es ist wie die Verwendung von http anstelle von https, aber man würde den Datenverkehr zum Beispiel mit base64 verschlüsseln ... Keinen Solidity-Code mit einem bestimmten bereitgestellten Vertrag zu veröffentlichen, ist KEIN zusätzlicher Sicherheitsschild, es verlängert nur die Unterbrechung dieses Vertrags ...