Smart Contracts – Wo ist Vertrag drin?

Ich bin neu bei Smart Contracts. Als ich ein Beispiel für Smart Contracts sah, wurde mir klar, dass es sich nur um ein Stück Code handelt, nicht genau um Verträge.

Zum Beispiel function sendCoin(address receiver, uint amount)ist eine in Smart Contract definierte Methode, die die Empfängeradresse und den Betrag nimmt, um Coins an den Empfänger zu senden.

Aber im Vertrag geht es nicht darum, wie man Coins versendet, sondern wie viel man versendet. Wenn das Material beispielsweise pünktlich geliefert wird, leisten Sie die vollständige Zahlung, andernfalls berechnen Sie eine Strafe von 10 % für jede Woche Verspätung.

Nach meinem Verständnis befindet sich der Aufruf – wo diese Wenn-dann-Regeln geschrieben sind (Darstellung des Vertrags) – außerhalb des Smart Contract.

Ist mein Verständnis richtig? Ist der Begriff „Smart Contract“ irreführend?

Werden in der Anwendung, die diese Funktionen auslöst, immer noch echte Verträge außerhalb der Blockchain codiert? Wenn ja, warum Smart Contracts dann nicht manipuliert werden können, können die Anwendungen den Vertrag immer noch kompromittieren – zum Beispiel. durch nicht vertragsgemäße Zahlung.

Was kann ein signiertes Stück Papier, was eine signierte Software nicht kann? und was kann ein signiertes Stück Software, was ein signiertes Stück Papier nicht kann?
@siid: Ich stimme teilweise zu, da der Vertragsaufruf außerhalb über eine API wie web3 oder so erfolgt. Obwohl das Stück Code nicht kompromittiert wird, können seine Eingabeparameter kompromittiert werden, wenn sie nicht Teil von Ethereum sind und vorab zum Zeitpunkt des Vertragsschreibens selbst definiert wurden. Vielleicht formuliere ich meine Frage um: "Sind die Smart-Contract-Aufrufregeln (If-Then-Regeln) auch Teil von Ethereum oder können sie zu einem Teil von Ethereum gemacht werden?"

Antworten (2)

Ich glaube, das Wort Vertrag kommt aus der Vertragsprogrammierung . Ist eine Möglichkeit, Software zu entwerfen, die die Anforderungen dieses Paradigmas erfüllt. In der Tat unterstützt Solidity die Vertragsprogrammierung nativ.

pragma solidity ^0.4.0;

contract Sharer {
    function sendHalf(address addr) public payable returns (uint balance) {
        require(msg.value % 2 == 0); // Only allow even numbers
        uint balanceBeforeTransfer = this.balance;
        addr.transfer(msg.value / 2);
        // Since transfer throws an exception on failure and
        // cannot call back here, there should be no way for us to
        // still have half of the money.
        assert(this.balance == balanceBeforeTransfer - msg.value / 2);
        return this.balance;
    } 
}

Anhand dieses Beispiels können Sie sehen, dass requireses sich um die Vorbedingungen handelt, während assetses sich um Nachbedingungen handelt. Die Nebenwirkungen sind Ausnahmen, die den Status in der EVM zurücksetzen.

Geben Sie hier die Bildbeschreibung ein

Danke für die Erklärung. Aber wie wird der Code ausgelöst? Soweit ich weiß, wird jemand web3 oder eine ähnliche API verwenden, um den Code mit einer "Adresse" und einem "Wert" aufzurufen. Sicherlich wird nur die Hälfte des Wertes gemäß der Implementierung übertragen. Aber technisch gesehen sollte die Bestimmung des genauen Werts für „Wert“ auch Teil des Vertrags sein. Like Senden Sie die Hälfte von 10 an 'mirg', wenn er die Frage beantwortet. Aber mit aktuellem Setup. man kann den Wert von „Wert“ manipulieren und indirekt den Vertrag kompromittieren.
Das Wort Objekt kommt also aus der objektorientierten Programmierung oder vielleicht umgekehrt, oop hat seine Wurzeln in der Art und Weise, wie Menschen die Realität wahrnehmen
@Abhinav wie kann jemand den 'Wert' manipulieren? Wenn ja ist das ein Bug. Ich verstehe deinen Punkt nicht. Wenn Ihr Vertrag immer einen genauen Eth-Betrag senden muss, ist dies ein statischer Wert. Wenn der Vertrag die Hälfte des Wertes senden muss, dann ist der bereitgestellte Code richtig, wenn Vor- und Nachbedingungen angegeben werden.
@siid Ich verstehe es nicht, vielleicht verwende ich ein Wort falsch, aber es geht um Programmierung, nicht um Grammatik.
@mirg: Im Allgemeinen sieht der Vertrag so aus: Wenn die Lieferung pünktlich ist, senden Sie den vollen Rechnungsbetrag. Andernfalls ziehen Sie 10 USD für jede Woche Verspätung ab. Wenn wir in einem solchen Fall nur eine 'Transfer'-Funktion haben, die den zu übertragenden Wert als Parameter übernimmt, kann er vom Aufrufer manipuliert werden. (Weil der eigentliche Vertrag nur die Funktion zum Übertragen des Betrags hat und nicht die Logik, um zu bestimmen, wie viel zu überweisen ist.) In solchen Fällen wird empfohlen, die Funktion so zu schreiben, dass sie das Datum als Eingabe verwendet und dann die Zahlung und nicht den zu verarbeitenden Wert verarbeitet übertragen?
Die meisten Beispiele, die ich gesehen habe, zeigen technische Funktionen wie "Überweisung (Adresse, Betrag)" ohne Vertragsbedingungen, und diese Vertragsbedingungen sind in einer externen Anwendung codiert, die den zu überweisenden Betrag berechnet und dann diese Funktionen aufruft (z . überweisen)
Hängt von der Art des Vertrages und dem Ziel des Autors ab. Wenn man nur einen Weg schaffen will, Wert zu transferieren, muss man nur die Funktion für Transfers gestalten. Vertragsbedingungen können auf Wunsch in den Vertrag aufgenommen werden. Das bedeutet nicht, dass Sie keine Betrüger finden werden, die versuchen, Sie zu täuschen. Deshalb sind Open-Source-Code und eine formale Sprache, die nur eine logische Interpretation hat, bequemer als...
@Abhinav Wenn Ihre geschäftlichen Anforderungen bestimmte Anforderungen erfüllen müssen, hindert Sie niemand daran, die Informationen in der Blockchain zu speichern. z.B. Sie speichern Ihre Produktinformationen, den Preis und so weiter. Wenn Sie einen bestimmten Artikel kaufen, beziehen Sie sich einfach auf seinen Code und der Vertrag speichert den Preis dafür und sendet ihn an den Käufer. Generell ist die Transferfunktion, die man immer in den Verträgen sieht, der Token-Standard ERC20 oder einige Wallets, die einige Spezifikationen erfüllen müssen.

Ihr Verständnis ist genau richtig. Smart Contracts sind weder Smart noch Contracts. Es ist ein irreführendes Wort.

Es ist nur Software, die auf dem EVM läuft. Es gibt nichts, was sie durchsetzt, außer der Tatsache, dass der Code selbst niemals geändert werden kann.

Ich denke, es ist die Unveränderlichkeit des Codes und die Tatsache, dass der Code Open Source ist (und daher von allen Parteien vereinbart wurde), die die Leute dazu bringt, sie als Verträge zu betrachten. Sie können sie nach der Bereitstellung nicht mehr ändern.

Was ist also ein Vertrag?
Ich betrachte den Smart Contract nur als das, was auf dem EVM läuft. Das heißt, der Teil, der auf „Ethereum“ läuft. Ich denke, die Leute nennen es nur deshalb einen Vertrag, weil beide Seiten damit einverstanden sind (weil sie beide den Quellcode lesen können) und es nicht geändert werden kann (weil Code, der auf dem EVM ausgeführt wird, unveränderlich ist). Es gibt überhaupt keinen Rechtsvertrag. „Vertrag“ ist nur ein schlecht gewähltes Wort.
@ThomasJayRush: Danke! Aber für mich ist Code nur Metadaten (es sei denn, er ist nicht von einer externen Variable abhängig), wie das, was er tun wird. Das eigentliche passiert, wenn es aufgerufen wird - wenn der eigentliche Parameter übergeben wird. Diese Möglichkeit, intelligente Verträge von web3 oder anderen APIs aufzurufen, sieht wenig gegen Verträge aus, die zum Zeitpunkt des Schreibens bereits gut definiert sind.
Wenn der Vertrag von einer Behörde unterzeichnet wird, wird er zu einem rechtsgültigen Vertrag. Auch wenn ein Vertrag nicht von einem Dritten unterzeichnet werden muss, garantiert die Blockchain ihre Unveränderlichkeit und Vertrauenswürdigkeit
Smart Contracts – Wo ist Vertrag drin?
AntwortenHierDatenschutz-Bestimmungen1y, 0v