In diesem Artikel werden wir erörtern, was Smart Contracts sind, welche Arten es gibt, verschiedene Smart-Contract-Plattformen kennenlernen, ihre Merkmale untersuchen und besprechen, wie sie funktionieren und welche Vorteile sie bieten können. Dieses Material wird für Leser sehr nützlich sein, die nicht ausreichend mit dem Thema Smart Contracts vertraut sind, aber ein besseres Verständnis erlangen möchten.
Traditioneller Vertrag vs. Smart Contract
Bevor wir in die Einzelheiten eintauchen, lassen Sie uns anhand eines Beispiels die Unterschiede zwischen einem traditionellen Vertrag, der auf Papier erstellt wird, und einem Smart Contract, der digital vorliegt, erläutern.
Wie funktionierte es vor der Einführung von Smart Contracts? Stellen Sie sich eine Gruppe von Personen vor, die bestimmte Regeln und Bedingungen für die Verteilung von Werten festlegen möchten und einen Mechanismus haben, um die Einhaltung dieser Regeln und Bedingungen zu gewährleisten. Früher trafen sie sich, erstellten ein Dokument, auf dem sie ihre Identifikationsdaten, Bedingungen und die beteiligten Werte festhielten, setzten ein Datum und unterschrieben. Dieser Vertrag wurde auch von einer vertrauenswürdigen Partei, wie einem Notar, beglaubigt. Anschließend gingen diese Personen mit ihrer Papierkopie des Vertrags auseinander und begannen, Handlungen vorzunehmen, die möglicherweise nicht mit dem Vertrag übereinstimmten, das heißt, sie machten das eine, während auf dem Papier etwas anderes festgehalten war. Wie kann man aus dieser Situation herauskommen? Tatsächlich musste eines der Gruppenmitglieder dieses Dokument herausholen, Beweise sammeln, vor Gericht gehen und die Einhaltung zwischen dem Vertrag und den tatsächlichen Handlungen einfordern. Oft ist es schwierig, die gerechte Durchführung dieses Vertrags zu erreichen, was zu unangenehmen Konsequenzen führen kann.
Was kann man über Smart Contracts sagen? Sie vereinen die Möglichkeit, Vertragsbedingungen zu formulieren, und einen Mechanismus für deren strikte Einhaltung. Wenn die Bedingungen festgelegt und die entsprechende Transaktion oder Anfrage unterzeichnet wurde, ist es nach Annahme dieser Anfrage oder Transaktion nicht mehr möglich, die Bedingungen zu ändern oder deren Ausführung zu beeinflussen.
Es gibt einen Validator oder ein ganzes Netzwerk sowie eine Datenbank, die alle Smart Contracts speichert, die zur Ausführung in strenger chronologischer Reihenfolge eingereicht wurden. Es ist auch wichtig, dass diese Datenbank alle Triggerbedingungen für die Ausführung des Smart Contracts enthält. Darüber hinaus muss sie den Wert berücksichtigen, dessen Verteilung im Vertrag beschrieben ist. Wenn es sich um eine digitale Währung handelt, muss diese Datenbank auch diese berücksichtigen.
Mit anderen Worten, Validierer von Smart Contracts müssen Zugriff auf alle Daten haben, mit denen der Smart Contract arbeitet. Zum Beispiel sollte eine Datenbank gleichzeitig für die Erfassung digitaler Währungen, Benutzerkonten, Benutzertransaktionen und Zeitstempel verwendet werden. In diesem Fall könnte eine Bedingung im Smart Contract das Guthaben des Benutzers in einer bestimmten Währung, das Erreichen eines bestimmten Zeitpunkts oder die Durchführung einer bestimmten Transaktion sein, aber nicht mehr.
Definition des Smart Contracts
Die Terminologie wurde ursprünglich von dem Forscher Nick Szabo erfunden und erstmals 1994 verwendet, dokumentiert wurde sie 1997 in einem Artikel, der die Idee der Smart Contracts beschreibt.
Smart Contracts implizieren, dass eine Automatisierung der Verteilung von Wert erfolgt, die ausschließlich von den zuvor festgelegten Bedingungen abhängt. Im einfachsten Fall sieht dies aus wie ein Vertrag mit genau festgelegten Bedingungen, der von bestimmten Parteien unterzeichnet wurde.
Smart Contracts sollen das Vertrauen in dritte Parteien minimieren. Manchmal wird das Entscheidungszentrum, von dem alles abhängt, vollständig ausgeschlossen. Außerdem ist es einfacher, solche Verträge einem Audit zu unterziehen. Dies ist eine Folge gewisser Designmerkmale eines solchen Systems, aber meist verstehen wir unter einem Smart Contract eine dezentralisierte Umgebung mit Funktionen, die es jedem ermöglichen, die Datenbank zu analysieren und eine vollständige Überprüfung der Vertragserfüllung durchzuführen. Dadurch wird der Schutz vor nachträglichen Änderungen der Daten gewährleistet, die Änderungen bei der Ausführung des Vertrags zur Folge hätten. Die Digitalisierung der meisten Prozesse bei der Erstellung und Implementierung eines Smart Contracts vereinfacht oft die Technologie und die Kosten ihrer Umsetzung.
Ein einfaches Beispiel – Escrow-Service
Lassen Sie uns ein sehr einfaches Beispiel betrachten. Es wird helfen, das Verständnis der Funktionalitäten von Smart Contracts zu vertiefen und besser zu erkennen, in welchen Fällen sie angewendet werden sollten.
Es kann auch mit Bitcoin umgesetzt werden, obwohl Bitcoin derzeit noch schwer als vollständige Plattform für Smart Contracts bezeichnet werden kann. Nehmen wir an, wir haben einen Käufer und einen Online-Shop. Der Käufer möchte in diesem Shop einen Monitor kaufen. Im einfachsten Fall gibt der Käufer die Zahlung auf und sendet sie ab, während der Online-Shop diese entgegennimmt, bestätigt und anschließend die Ware versendet. Allerdings gibt es in dieser Situation eine erhebliche Vertrauensnotwendigkeit – der Käufer muss dem Online-Shop das gesamte Geld für den Monitor anvertrauen. Da der Online-Shop möglicherweise einen niedrigen Ruf in den Augen des Käufers hat, besteht das Risiko, dass der Shop aus irgendwelchen Gründen nach Erhalt der Zahlung den Service verweigert und die Ware nicht an den Käufer versendet. Daher fragt sich der Käufer (und daher auch der Online-Shop fragt sich), was in diesem Fall angewendet werden kann, um solche Risiken zu minimieren und ähnliche Transaktionen zuverlässiger zu machen.
Im Falle von Bitcoin kann dem Käufer und Verkäufer die Möglichkeit gegeben werden, jeweils unabhängig einen Vermittler auszuwählen. Es gibt viele Leute, die sich mit der Lösung von Streitfragen befassen. Unsere Teilnehmer können aus einer gemeinsamen Liste von Vermittlern denjenigen auswählen, dem sie gleichzeitig vertrauen. Gemeinsam erstellen sie eine Multisignatur-Adresse 2 aus 3, auf der drei Schlüssel liegen, wobei zwei Signaturen von beliebigen zwei Schlüsseln erforderlich sind, um die Münzen von dieser Adresse auszugeben. Ein Schlüssel gehört dem Käufer, der zweite dem Online-Shop und der dritte dem Vermittler. Und an diese Multisignatur-Adresse wird der Käufer den Betrag senden, der für den Kauf des Monitors erforderlich ist. Jetzt, da der Verkäufer sieht, dass das Geld für eine gewisse Zeit auf der Multisignatur-Adresse, die von ihm abhängt, gesperrt ist, kann er sicher den Monitor per Post versenden.
Anschließend erhält der Käufer das Paket, prüft die Ware und trifft eine endgültige Kaufentscheidung. Er kann mit dem bereitgestellten Service vollkommen zufrieden sein und die Transaktion mit seinem Schlüssel unterzeichnen, wodurch er Münzen von der Multisignature-Adresse des Verkäufers überträgt, oder er kann unzufrieden sein. Im zweiten Fall kontaktiert er den Mediator, um eine alternative Transaktion zu erstellen, die die Münzen anders verteilt.
Angenommen, der Monitor kam mit ein paar Kratzern an und das Kabel zum Anschluss an den Computer lag nicht bei, obwohl auf der Website des Online-Shops angegeben war, dass das Kabel im Lieferumfang enthalten sein sollte. Dann sammelt der Käufer Beweise, die notwendig sind, um dem Mediator zu beweisen, dass er in dieser Situation betrogen wurde: er macht Screenshots der Website, fotografiert die Quittung von der Post, macht ein Foto von den Kratzern auf dem Monitor und zeigt, dass das Siegel gebrochen wurde und das Kabel entfernt wurde. Der Online-Shop sammelt seinerseits seine Beweise und reicht sie dem Mediator weiter.
Der Mediator hat ein Interesse daran, sowohl den Unmut des Käufers als auch die Interessen des Online-Shops zufrieden zu stellen (was später verständlich sein wird). Er erstellt eine Transaktion, bei der die Münzen von der Multisignature-Adresse in einem bestimmten Verhältnis zwischen dem Käufer, dem Online-Shop und dem Mediator verteilt werden, da er sich einen Teil als Belohnung für seine Arbeit nimmt. Angenommen, 90 % des gesamten Betrags gehen an den Verkäufer, 5 % an den Mediator und 5 % als Entschädigung an den Käufer. Diese Transaktion unterzeichnet der Mediator mit seinem Schlüssel, doch sie kann noch nicht angewendet werden, da dafür zwei Unterschriften erforderlich sind, aber nur eine vorliegt. Er sendet diese Transaktion sowohl an den Käufer als auch an den Verkäufer. Wenn wenigstens einer von ihnen mit dieser Art der Umverteilung der Münzen einverstanden ist, wird die Transaktion nachunterzeichnet und im Netzwerk verbreitet. Für die Validierung reicht es aus, dass einer der Teilnehmer der Transaktion mit dem Vorschlag des Mediators einverstanden ist.
Es ist wichtig, von Anfang an einen Mediator auszuwählen, dem beide Parteien vertrauen. In diesem Fall wird er unabhängig von den Interessen des einen oder anderen handeln und die Situation objektiv bewerten. Wenn der Mediator jedoch keine Verteilung der Münzen anbietet, die zumindest einen der Beteiligten zufriedenstellt, können Käufer und Online-Shop gemeinsam die Münzen auf eine neue Multisignatur-Adresse transferieren, indem sie ihre beiden Unterschriften leisten. Die neue Multisignatur-Adresse wird bereits mit einem anderen Mediator erstellt, der möglicherweise kompetenter in der Angelegenheit ist und eine bessere Lösung anbietet.
Beispiel mit einem Wohnheim und einem Kühlschrank
Betrachten wir ein komplexeres Beispiel, das die Möglichkeiten eines Smart Contracts deutlicher darstellt.
Angenommen, es gibt drei Jungs, die sich gerade in ein Zimmer in einem Wohnheim eingelebt haben. Sie sind gemeinsam daran interessiert, einen Kühlschrank für ihr Zimmer zu kaufen, den sie gemeinsam nutzen werden. Einer von ihnen hat sich bereit erklärt, den notwendigen Betrag für den Kauf des Kühlschranks zu sammeln und mit dem Verkäufer zu verhandeln. Da sie sich jedoch erst vor kurzem kennengelernt haben, gibt es nicht genug Vertrauen zwischen ihnen. Offensichtlich gehen zwei von ihnen das Risiko ein, ihr Geld an den dritten zu geben. Außerdem müssen sie sich auf den Verkäufer einigen.
Sie können einen Escrow-Service in Anspruch nehmen, das heißt, einen Mediator auswählen, der die Ausführung der Transaktion überwacht und Streitfragen klärt, falls solche auftreten. Dann erstellen sie gemeinsam einen Smart Contract und legen darin bestimmte Bedingungen fest.
Die erste Bedingung besteht darin, dass bis zu einem bestimmten Zeitpunkt, zum Beispiel innerhalb einer Woche, drei Zahlungen von bestimmten Adressen in einer bestimmten Höhe auf das entsprechende Smart-Contract-Konto eingehen müssen. Erfolgt dies nicht, wird der Smart Contract gestoppt und die Coins werden an alle Teilnehmer zurückgegeben. Wird die Bedingung jedoch erfüllt, werden die Werte für die Identifikatoren des Verkäufers und des Mediators festgelegt, und es wird überprüft, ob alle Teilnehmer mit der Wahl des Verkäufers und des Mediators einverstanden sind. Wenn alle Bedingungen erfüllt sind, werden die Mittel an die angegebenen Adressen übertragen. Dieser Ansatz kann die Teilnehmer vor Betrug von jeder Seite schützen und eliminiert im Allgemeinen die Notwendigkeit des Vertrauens.
Wir sehen an diesem Beispiel das grundlegende Prinzip, dass die Möglichkeit, schrittweise Parameter für die Erfüllung jeder Bedingung festzulegen, die Erstellung von Systemen jeder Komplexität und Tiefe von Verschachtelungsstufen ermöglicht. Darüber hinaus kann im Smart Contract zunächst die erste Bedingung definiert werden, und erst nach deren Erfüllung können die Parameter für die nächste Bedingung festgelegt werden. Anders ausgedrückt, wird die Bedingung formal festgelegt, während die Parameter dafür bereits während ihrer Ausführung festgelegt werden können.
Klassifikation von Smart Contracts
Für die Klassifikation können verschiedene Gruppen von Kriterien herangezogen werden. Im Moment der technologischen Entwicklung sind jedoch vier davon relevant.
Smart Contracts können nach der Ausführungsumgebung unterschieden werden, die entweder zentralisiert oder dezentralisiert sein kann. Im Falle der Dezentralisierung haben wir bei der Ausführung von Smart Contracts eine viel größere Unabhängigkeit und Ausfallsicherheit.
Sie können auch nach dem Prozess der Festlegung und Ausführung von Bedingungen unterschieden werden: Sie können beliebig programmierbar, eingeschränkt oder vorkonfiguriert, d. h. strikt typisiert sein. Wenn es auf der Smart Contract-Plattform nur 4 bestimmte Smart Contracts gibt, können die Parameter für diese beliebig festgelegt werden. Folglich ist es viel einfacher, sie festzulegen: Wir wählen den Vertrag aus der Liste aus und übergeben die Parameter.
Es gibt automatisierte Smart Contracts, die sich bei Erfüllung bestimmter Bedingungen selbst ausführen. Es gibt jedoch auch Verträge, bei denen Bedingungen festgelegt sind, aber die Plattform überprüft deren Erfüllung nicht automatisch; diese müssen separat initiiert werden.
Zusätzlich unterscheiden sich Smart Contracts im Hinblick auf das Maß an Privatsphäre. Sie können entweder vollständig offen, teilweise oder vollständig vertraulich sein. Letzteres bedeutet, dass externe Beobachter die Bedingungen der Smart Contracts nicht einsehen können. Das Thema Privatsphäre ist jedoch sehr umfassend und sollte getrennt von diesem Artikel betrachtet werden.
Nachfolgend werden wir näher auf die ersten drei Kriterien eingehen, um das Verständnis des aktuellen Themas zu vertiefen.
Smart Contracts nach Ausführungsumgebung
Es werden zentralisierte und dezentralisierte Platforms für Smart Contracts unterschieden. Bei zentralisierten digitalen Verträgen wird ein einziger Dienst genutzt, der nur einen Validator hat und möglicherweise eine zentral verwaltete Backup- und Wiederherstellungsdienstleistung anbietet. Es gibt eine Datenbank, die alle erforderlichen Informationen zur Festlegung der Bedingungen des Smart Contracts und zur Verteilung des Werts, der in dieser Datenbank gespeichert ist, enthält. Ein solcher zentralisierter Dienst hat einen Kunden, der durch bestimmte Anfragen Bedingungen festlegt und diese Verträge nutzt. Da die Plattform zentralisiert ist, können Authentifizierungsmechanismen weniger zuverlässig sein als bei Kryptowährungen.
Als Beispiel können Mobilfunkanbieter (verschiedene Mobilfunkbetreiber) genannt werden. Angenommen, ein bestimmter Anbieter verwaltet den Datenverkehr auf seinen Servern zentral, der in verschiedenen Formaten wie Sprachgesprächen, SMS-Übertragungen, mobilem Internetdatenverkehr und nach verschiedenen Standards übertragen werden kann, und führt eine Buchhaltung über die Guthaben der Nutzer. Dementsprechend kann der Mobilfunkanbieter Verträge zur Abrechnung der bereitgestellten Dienste und deren Bezahlung mit unterschiedlichen Bedingungen erstellen. In einem solchen Fall können Bedingungen wie 'Sende eine SMS mit einem bestimmten Code an eine bestimmte Nummer, und du erhältst diese Bedingungen für die Verteilung des Datenverkehrs' leicht erstellt werden.
Ein weiteres Beispiel: traditionelle Banken mit erweiterten Funktionen des Online-Bankings und sehr einfache Verträge wie regelmäßige Zahlungen, automatische Umwandlung eingehender Zahlungen, automatische Überweisung von Zinsen auf ein angegebenes Konto usw.
Wenn es um Smart Contracts in einer dezentralen Ausführungsumgebung geht, haben wir eine Gruppe von Validatoren. Im Idealfall kann praktisch jeder Validator werden. Dank des Protokolls zur Synchronisierung der Datenbank und zur Erreichung des Konsenses verfügen wir über eine gemeinsame Datenbank, die jetzt alle Transaktionen mit streng beschriebenen Verträgen speichert, und nicht über irgendwelche bedingten Anfragen, deren Formate sich häufig ändern und für die es keine offene Spezifikation gibt. Hier werden die Transaktionen Anweisungen zur Ausführung des Vertrags gemäß der strengen Spezifikation enthalten. Diese Spezifikation ist offen, und daher können die Benutzer der Plattform Smart Contracts auditieren und validieren. Hier sehen wir, dass dezentrale Plattformen in Bezug auf Unabhängigkeit und Fehlertoleranz überlegen sind, ihr Design und ihre Wartung jedoch viel komplexer sind.
Smart Contracts nach der Art der Bedingungsermittlung und -ausführung
Lassen Sie uns nun genauer untersuchen, wie Smart Contracts sich in der Art der Festlegung und Ausführung von Bedingungen unterscheiden können. Hier konzentrieren wir uns auf Smart Contracts, die beliebig und Turing-vollständig programmiert werden. Ein Turing-vollständiger Smart Contract erlaubt es, praktisch beliebige Algorithmen als Bedingungen für die Ausführung des Vertrags festzulegen: Schleifen, Funktionen zur Wahrscheinlichkeitsberechnung usw. bis hin zu eigenen Algorithmen für digitale Signaturen. In diesem Fall ist wirklich die beliebige Programmierung der Logik gemeint.
Es werden auch willkürliche Smart Contracts unterschieden, die jedoch nicht Turing-vollständig sind. Dazu zählen Bitcoin und Litecoin mit ihrem Skript. Es bedeutet, dass nur bestimmte Operationen in beliebiger Reihenfolge verwendet werden können, aber Schleifen und eigene Algorithmen können nicht erstellt werden.
Darüber hinaus gibt es Plattformen für Smart Contracts, die vordefinierte Smart Contracts implementieren. Dazu gehören Bitshares und Steemit. Bitshares verfügt über eine Vielzahl von Smart Contracts für den Handel, die Verwaltung von Accounts und die Konfiguration der Plattform und ihrer Parameter. Steemit ist eine ähnliche Plattform, jedoch nicht auf die Ausgabe von Token und den Handel wie Bitshares ausgerichtet, sondern auf das Bloggen, also speichert und verarbeitet sie Inhalte dezentral.
Zu den voll Turing-vollständigen Smart Contracts gehört die Plattform Ethereum und RootStock, die sich noch in der Entwicklungsphase befindet. Daher werden wir im Folgenden etwas detaillierter auf die Smart Contract-Plattform Ethereum eingehen.
Smart Contracts nach Art der Initiierung
Smart Contracts können auch nach der Art der Initiierung in mindestens zwei Gruppen unterteilt werden: automatisierte und manuelle (nicht automatisierte). Bei automatisierten Smart Contracts wird in allen bekannten Parametern und eingetretenen Bedingungen der Smart Contract vollständig automatisch ausgeführt, das heißt, es sind keine zusätzlichen Transaktionen erforderlich, und es fallen keine zusätzlichen Gebühren bei jeder weiteren Ausführung an. Die Plattform verfügt über alle Daten, um zu berechnen, wie der Smart Contract abgeschlossen wird. Die Logik ist nicht willkürlich, sondern vorab festgelegt und alles ist vorhersehbar. Man kann im Voraus die Komplexität der Ausführung eines Smart Contracts einschätzen, eine konstante Gebühr dafür verwenden, und alle Prozesse seiner Ausführung erfolgen effizienter.
Für Smart Contracts, die beliebig programmiert werden, ist die Ausführung nicht automatisiert. Um einen solchen Smart Contract zu initiieren, muss bei jedem Schritt eine neue Transaktion erstellt werden, die die nächste Phase der Ausführung oder die nächste Methode des Smart Contracts aufruft. Es müssen die entsprechenden Gebühren bezahlt werden, und man muss auf die Bestätigung der Transaktion warten. Die Ausführung kann erfolgreich oder nicht erfolgreich abgeschlossen werden, da der Code des Smart Contracts beliebig ist und unvorhersehbare Momente auftreten können, wie z.B. Endlosschleifen, Mangel an bestimmten Parametern und Argumenten, nicht behandelte Ausnahmen usw.
Accounts in Ethereum
Arten von Ethereum-Accounts
Lass uns betrachten, welche Konten auf der Ethereum-Plattform existieren können. Es gibt hier nur zwei Typen von Konten, und keine weiteren Optionen. Der erste Typ wird Benutzerkonto genannt, der zweite - Smart-Contract-Konto. Lassen Sie uns klären, inwiefern sie sich unterscheiden.
Das Benutzerkonto wird ausschließlich durch den privaten Schlüssel einer digitalen Signatur verwaltet. Der Eigentümer des Kontos generiert sein Schlüsselpaar für die digitale Signatur nach dem ECDSA-Algorithmus (Elliptic Curve Digital Signature Algorithm). Der Zustand dieses Kontos kann nur durch Transaktionen geändert werden, die mit diesem Schlüssel signiert wurden.
Für das Smart-Contract-Konto ist eine separate Logik vorgesehen. Es kann nur durch im Voraus festgelegten Programmcode gesteuert werden, der das Verhalten des Smart Contracts vollständig definiert: wie es seine Münzen unter bestimmten Umständen verwalten wird, auf Initiative welches Benutzers und unter welchen zusätzlichen Bedingungen diese Münzen verteilt werden. Wenn bestimmte Aspekte von den Entwicklern im Programmcode nicht berücksichtigt werden, können Probleme auftreten. Zum Beispiel kann ein Smart Contract einen bestimmten Zustand erreichen, in dem er keine weitere Ausführung mehr von keinem Benutzer akzeptiert. In einem solchen Fall werden die Münzen praktisch eingefroren, da der Smart Contract keinen Ausgang aus diesem Zustand vorsieht.
Wie Konten in Ethereum erstellt werden
Im Fall des Benutzerkontos generiert der Eigentümer selbst ein Schlüsselpaar nach ECDSA. Es ist wichtig zu beachten, dass Ethereum für digitale Signaturen exakt denselben Algorithmus und dieselbe elliptische Kurve wie Bitcoin verwendet, jedoch wird die Adresse auf leicht andere Weise berechnet. Hier wird nicht das Ergebnis der doppelten Hash-Berechnung wie bei Bitcoin verwendet, sondern eine einmalige Hash-Berechnung mit der Keccak-Funktion mit einer Länge von 256 Bit. Von dem erhaltenen Wert werden die niedrigsten Bits, also die 160 niedrigsten Bits des Ausgangswertes der Hash-Funktion, abgeschnitten. Letztendlich erhalten wir die Adresse in Ethereum. Tatsächlich belegt sie 20 Byte.
Beachten Sie, dass die Kontoinformation in Ethereum in Hex ohne Anwendung einer Prüfziffer kodiert wird, im Gegensatz zu Bitcoin und vielen anderen Systemen, bei denen die Adresse in einem 58er Zahlensystem kodiert wird und eine Prüfziffer hinzugefügt wird. Das bedeutet, dass man beim Arbeiten mit Kontoinformationen in Ethereum vorsichtig sein muss: selbst ein einziger Fehler in der Kontoinformation führt garantiert zum Verlust von Coins.
Es gibt eine wichtige Besonderheit, und zwar, dass das Benutzerkonto auf der Ebene der gemeinsamen Datenbank in dem Moment erstellt wird, wenn der Benutzer die erste eingehende Zahlung annimmt.
Für die Erstellung eines Smart Contracts wird ein völlig anderer Ansatz angewendet. Zunächst schreibt einer der Benutzer den Quellcode des Smart Contracts, danach wird der Code durch einen speziellen Compiler für die Ethereum-Plattform geleitet, um Bytecode für die eigene Ethereum-virtuelle Maschine zu erhalten. Der erhaltene Bytecode wird in ein spezielles Feld der Transaktion eingefügt. Diese wird im Namen des initiierenden Kontos signiert. Anschließend wird diese Transaktion im Netzwerk verbreitet und der Code des Smart Contracts veröffentlicht. Die Gebühr für die Durchführung der Transaktion und folglich für die Ausführung des Vertrags wird vom Guthaben des initiierenden Kontos abgezogen.
Jeder Smart Contract enthält unbedingt seinen eigenen Konstruktor (dieses Vertrags). Er kann leer sein oder Inhalt haben. Nachdem der Konstruktor ausgeführt wurde, wird eine Kontoinformation des Smart Contracts erstellt, mit der man Coins senden, bestimmte Methoden des Smart Contracts aufrufen usw. kann.
Struktur der Ethereum-Transaktion
Um es verständlicher zu machen, werden wir uns der Struktur der Ethereum-Transaktion und einem Beispiel für den Code eines Smart Contracts zuwenden.
Eine Ethereum-Transaktion besteht aus mehreren Feldern. Das erste davon ist nonce - eine bestimmte fortlaufende Nummer der Transaktion im Verhältnis zu dem Konto, das sie verbreitet und der Autor ist. Dies ist notwendig, um Doppeltransaktionen zu unterscheiden, also um den Fall auszuschließen, dass dieselbe Transaktion zweimal akzeptiert wird. Durch die Anwendung des Identifikators hat jede Transaktion einen einzigartigen Hash-Wert.
Darauf folgt ein Feld namens gas priceHier wird der Preis angegeben, zu dem die Basiswährung Ethereum in Gas umgerechnet wird, mit dem die Ausführung von Smart Contracts und die Zuweisung von Ressourcen für die virtuelle Maschine bezahlt werden. Was bedeutet das?
Bei Bitcoin werden die Gebühren direkt in der Basiswährung — Bitcoin selbst — bezahlt. Dies ist möglich dank eines einfachen Berechnungsmechanismus: Wir zahlen genau für das Datenvolumen, das in der Transaktion enthalten ist. Bei Ethereum ist die Situation komplexer, da es schwierig ist, sich allein auf das Datenvolumen der Transaktion zu stützen. Hier kann die Transaktion auch Programmcode enthalten, der auf der virtuellen Maschine ausgeführt wird, und jede Operation der virtuellen Maschine kann unterschiedliche Komplexitäten aufweisen. Es gibt auch Operationen, die Speicher für Variablen zuweisen. Diese haben ihre eigene Komplexität, von der die Zahlung für jede Operation abhängt.
Die Kosten jeder Operation im Äquivalent von Gas werden konstant sein. Dies wurde speziell eingeführt, um die konstante Kostenstruktur jeder Operation zu bestimmen. Je nach Auslastung des Netzwerks ändert sich der Gaspreis, also der Koeffizient, nach dem die Basiswährung in diese Hilfseinheit zur Zahlung der Gebühr umgerechnet wird.
Es gibt ein weiteres Merkmal von Transaktionen in Ethereum: Der Bytecode, den sie für die Ausführung in der virtuellen Maschine enthält, wird so lange ausgeführt, bis er mit einem Ergebnis (Erfolg oder Misserfolg) abgeschlossen ist oder bis eine bestimmte Menge an Coins, die zur Zahlung der Gebühr zugewiesen ist, aufgebraucht ist. Um zu vermeiden, dass im Falle eines Fehlers alle Coins des Absenders für die Gebühr ausgegeben werden (z.B. ein ewiger Zyklus in der virtuellen Maschine gestartet wird), gibt es das folgende Feld — start gas (es wird oft als Gaslimit bezeichnet) — es definiert den maximalen Betrag an Coins, den der Absender bereit ist, für die Ausführung einer bestimmten Transaktion auszugeben.
Das nächste Feld heißt destination address. Hier wird die Adresse des Empfängers der Coins oder die Adresse eines bestimmten Smart Contracts, dessen Methoden aufgerufen werden, eingetragen. Danach folgt das Feld value, in das der Betrag der Coins eingetragen wird, die an die Zieladresse gesendet werden.
Darüber hinaus befindet sich ein interessantes Feld mit dem Namen data, in die eine gesamte Struktur passt. Es ist kein einzelnes Feld, sondern eine ganze Struktur, in der der Code für die virtuelle Maschine definiert wird. Hier können beliebige Daten abgelegt werden – dafür gibt es spezielle Regeln.
Das letzte Feld nennt sich signature. Es enthält sowohl die elektronische Signatur des Autors dieser Transaktion als auch den öffentlichen Schlüssel, mit dem diese Signatur überprüft wird. Aus dem öffentlichen Schlüssel kann die Identifikation des Kontos des Absenders dieser Transaktion abgeleitet werden, d.h. das Konto des Absenders wird im System eindeutig identifiziert. Die Struktur der Transaktion haben wir geklärt.
Beispiel für einen Smart Contract in Solidity
Lassen Sie uns nun den einfachsten Smart Contract näher betrachten.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Oben ist der vereinfachte Quellcode dargestellt, der die Münzen der Benutzer halten und auf Anfrage zurückgeben kann.
Es gibt also den Smart Contract Bank, der folgende Funktionen erfüllt: Er sammelt Münzen auf seinem Konto, d.h. bei der Bestätigung der Transaktion und der Bereitstellung dieses Smart Contracts wird ein neues Konto erstellt, das Münzen auf seinem Konto enthalten kann; er speichert die Benutzer und die Verteilung der Münzen zwischen ihnen; er hat mehrere Methoden zur Verwaltung der Guthaben, d.h. es ist möglich, Guthaben aufzufüllen, abzuheben und den Kontostand des Benutzers zu überprüfen.
Lassen Sie uns jede Zeile des Quellcodes durchgehen. In diesem Vertrag gibt es konstante Felder. Eines davon, vom Typ address, heißt owner. Hier erinnert sich der Vertrag an die Adresse des Benutzers, der diesen Smart Contract erstellt hat. Danach gibt es eine dynamische Struktur, die die Entsprechungen zwischen den Adressen der Benutzer und deren Guthaben speichert.
Darauf folgt die Methode Bank – sie trägt denselben Namen wie der Vertrag. Entsprechend ist dies sein Konstruktor. Hier wird der Variable owner die Adresse desjenigen zugewiesen, der diesen Smart Contract im Netzwerk platziert hat. Das ist das einzige, was in diesem Konstruktor geschieht. Das heißt, msg ist in diesem Fall genau die Information, die zusammen mit der Transaktion, die den gesamten Code dieses Vertrags enthält, an die virtuelle Maschine übergeben wurde. Entsprechend ist msg.sender der Autor dieser Transaktion, die diesen Code platziert. Er wird der Eigentümer des Smart Contracts sein.
Die Methode deposit ermöglicht es, eine bestimmte Menge an Münzen durch eine Transaktion auf das Konto des Vertrags zu übertragen. In diesem Fall behält der Smart Contract die Münzen in seinem Guthaben, vermerkt jedoch in der Struktur balances, wer der Absender dieser Münzen ist, um zu wissen, wem sie gehören.
Die nächste Methode heißt withdraw und nimmt einen Parameter — den Betrag an Münzen, den jemand aus dieser Bank abheben möchte. Hier wird überprüft, ob genügend Münzen im Guthaben des Benutzers vorhanden sind, der diese Methode aufruft, um sie zu senden. Wenn genügend vorhanden sind, gibt der Smart Contract die angeforderte Menge an Münzen zurück.
Als Nächstes folgt die Methode zur Überprüfung des aktuellen Guthabens des Benutzers. Derjenige, der diese Methode aufruft, wird verwendet, um dieses Guthaben im Smart Contract zu erhalten. Es ist erwähnenswert, dass der Modifier dieser Methode — view ist. Das bedeutet, dass die Methode keine Variablen seiner Klasse ändert und tatsächlich nur eine Leseoperation ist. Es wird keine separate Transaktion für den Aufruf dieser Methode erstellt, es wird keine Gebühr bezahlt, und alle Berechnungen erfolgen lokal, wonach der Benutzer das Ergebnis erhält.
Die Methode kill dient dazu, den Zustand des Smart Contracts zu zerstören. Hier wird eine zusätzliche Überprüfung vorgenommen, ob der Aufrufer dieser Methode der Eigentümer des Vertrags ist. Falls ja, wird der Vertrag selbst zerstört, und die Zerstörungsfunktion nimmt einen Parameter — die ID des Kontos, auf das der Vertrag alle verbleibenden Münzen in seinem Guthaben sendet. In diesem Fall werden die verbleibenden Münzen automatisch an die Adresse des Eigentümers des Vertrags gesendet.
Wie funktioniert ein vollständiger Knoten im Ethereum-Netzwerk?
Lassen Sie uns schematisch betrachten, wie die Ausführung solcher Smart Contracts auf der Ethereum-Plattform erfolgt und wie ein vollständiger Knoten im Netzwerk funktioniert.
Ein vollständiger Knoten im Ethereum-Netzwerk muss mindestens vier Module haben.
Das erste Modul ist, wie für jedes dezentrale Protokoll, das P2P Networking Module — das Modul für die Netzwerkverbindung und die Interaktion mit anderen Knoten, wo Blöcke, Transaktionen und Informationen über andere Knoten ausgetauscht werden. Dies ist ein traditionelles Element für alle dezentralen Kryptowährungen.
Weiterhin haben wir ein Modul für die Speicherung von Blockchain-Daten, Verarbeitung, Auswahl des bevorzugten Zweigs, Hinzufügen von Blöcken, Abtrennung von Blöcken, Überprüfung dieser Blöcke usw.
Das dritte Modul heißt EVM (Ethereum Virtual Machine) — das ist es, eine virtuelle Maschine, das Bytecode aus Ethereum-Transaktionen akzeptiert. Dieses Modul verfolgt den aktuellen Zustand eines bestimmten Kontos und führt Zustandsänderungen auf der Grundlage des empfangenen Bytecodes durch. Die Version der virtuellen Maschine muss auf jedem Knoten im Netzwerk gleich sein. Die Berechnungen auf jedem Knoten im Ethereum-Netzwerk sind absolut identisch, erfolgen jedoch asynchron: Jemand überprüft und akzeptiert diese Transaktion früher, d. h. führt den gesamten enthaltenen Code aus, während jemand später dies tut. Dementsprechend wird bei der Erstellung einer Transaktion diese im Netzwerk verbreitet, Knoten nehmen sie an, und zum Zeitpunkt der Verifizierung wird sie genau so behandelt, wie im Bitcoin das Bitcoin-Skript ausgeführt wird, hier wird der Bytecode der virtuellen Maschine ausgeführt.
Eine Transaktion gilt als überprüft, wenn der gesamte enthaltene Code ausgeführt wurde, und ein neuer Zustand eines bestimmten Kontos generiert wurde, der bis zu dem Zeitpunkt gespeichert bleibt, bis klar ist, ob diese Transaktion angewendet wurde oder nicht. Wenn die Transaktion angewendet wurde, wird dieser Zustand nicht nur als ausgeführt, sondern auch als aktuell betrachtet. Es gibt eine Datenbank, die den Zustand jedes Kontos für jeden Knoten im Netzwerk speichert. Da alle Berechnungen gleich durchgeführt werden und der Blockchain-Zustand identisch ist, ist auch die Datenbank, die die Zustände aller Konten enthält, für jeden Knoten gleich.
Mythen und Einschränkungen von Smart Contracts
Was die Einschränkungen betrifft, die für Plattformen ähnlich wie Ethereum im Bereich von Smart Contracts existieren, können folgende genannt werden:
- Code-Ausführung;
- Speicher zuweisen;
- Blockchain-Daten;
- Zahlungen senden;
- Neuen Vertrag erstellen;
- Andere Verträge aufrufen.
Lassen Sie uns die Einschränkungen betrachten, die für die virtuelle Maschine gelten, und dementsprechend einige Mythen über Smart Contracts entkräften. Auf einer virtuellen Maschine, die nicht nur in Ethereum, sondern auch in ähnlichen Plattformen vorhanden sein kann, können tatsächlich beliebige logische Operationen ausgeführt werden, das heißt, Sie können Code schreiben und dieser wird dort ausgeführt, es kann zusätzlich Speicher zugewiesen werden. Allerdings wird eine Gebühr separat für jede Operation und für jede zusätzlich zugewiesene Einheit des Speicherplatzes erhoben.
Darüber hinaus kann die virtuelle Maschine Daten aus der Blockchain-Datenbank lesen, um diese Daten als Trigger für die Ausführung bestimmter Logiken von Smart Contracts zu verwenden. Die virtuelle Maschine kann Transaktionen erstellen und senden, neue Verträge erschaffen und Methoden anderer bereits im Netzwerk veröffentlichter Smart Contracts aufrufen: diese existieren, sind zugänglich usw.
Der am häufigsten verbreitete Mythos besagt, dass Ethereum Smart Contracts Informationen aus beliebigen Internetressourcen in ihren Bedingungen verwenden können. Die Wahrheit ist, dass die virtuelle Maschine keine Netzwerkabfrage an eine externe Informationsquelle im Internet senden kann, das heißt, es ist nicht möglich, einen solchen Smart Contract zu schreiben, der den Wert zwischen Benutzern verteilt, basierend auf beispielsweise dem Wetter draußen, oder wer in einem bestimmten Turnier gewonnen hat, oder auf der Grundlage von anderen Ereignissen, die in der Außenwelt passiert sind, weil Informationen über diese Ereignisse einfach nicht in der Datenbank der Plattform selbst vorhanden sind. Im Blockchain gibt es dazu nichts. Wenn es dort nicht erscheint, kann die virtuelle Maschine diese Daten nicht als Trigger verwenden.
Nachteile von Ethereum
Lassen Sie uns die wichtigsten davon aufzählen. Der erste Nachteil besteht darin, dass es einige Schwierigkeiten bei der Gestaltung, Entwicklung und Testung von Smart Contracts in Ethereum gibt (in Ethereum wird zur Erstellung von Smart Contracts die Sprache Solidity verwendet). Tatsächlich zeigt die Praxis, dass ein sehr hoher Prozentsatz aller Fehler dem menschlichen Faktor zuzuschreiben ist. Dies gilt auch für bereits geschriebene Ethereum-Smart Contracts, die einen durchschnittlichen oder höheren Schwierigkeitsgrad haben. Während die Wahrscheinlichkeit eines Fehlers bei einfachen Smart Contracts gering ist, treten bei komplexen Smart Contracts häufig Fehler auf, die zu Diebstahl von Mitteln, deren Einfrierung und zur unbeabsichtigten Zerstörung von Smart Contracts führen können. Es gibt bereits viele solcher Fälle.
Der zweite Nachteil liegt darin, dass die virtuelle Maschine nicht perfekt ist, da sie ebenfalls von Menschen geschrieben wurde. Sie kann willkürliche Befehle ausführen, was eine Schwachstelle birgt: Man kann eine Reihe von Befehlen auf eine Art und Weise konfigurieren, die zu unvorhergesehenen Folgen führt. Dies ist ein sehr komplexer Bereich, aber es gibt bereits mehrere Studien, die zeigen, dass es diese Schwachstellen in der aktuellen Version des Ethereum-Netzwerks gibt, und sie können zu einem Ausfall vieler Smart Contracts führen.
Eine weitere große Schwierigkeit, die man als Nachteil betrachten kann, besteht darin, dass man praktisch oder technisch dazu kommen kann, dass, wenn der Bytecode des Vertrags, der auf der virtuellen Maschine ausgeführt werden soll, kompiliert wird, eine bestimmte spezifische Reihenfolge von Operationen bestimmt werden kann. Bei der Ausführung belasten diese Operationen die virtuelle Maschine sehr stark und verlangsamen sie im Verhältnis zu den Gebühren, die für die Ausführung dieser Operationen gezahlt wurden, unverhältnismäßig.
In der Vergangenheit gab es bereits eine Phase in der Entwicklung von Ethereum, in der viele Leute, die sich detailliert mit der Funktionsweise der virtuellen Maschine auskannten, solche Schwachstellen fanden. Tatsächlich zahlten Transaktionen eine sehr geringe Gebühr, verlangsamten aber praktisch die gesamte Netzwerkleistung erheblich. Diese Probleme sind sehr schwierig zu lösen, da sie erstens deterministisch gemacht werden müssen, zweitens der Preis für die Durchführung dieser Operationen korrigiert werden muss, und drittens ein Hardfork durchgeführt werden muss, was bedeutet, dass alle Knoten im Netzwerk auf die neue Softwareversion aktualisiert werden müssen, gefolgt von der gleichzeitigen Aktivierung dieser Änderungen.
Was Ethereum betrifft, so wurden sehr viele Untersuchungen durchgeführt und es wurde eine sehr große praktische Erfahrung gesammelt: sowohl positive als auch negative, doch es bleiben weiterhin Schwierigkeiten und Schwachstellen, mit denen man sich noch auseinandersetzen muss.
So, der thematische Teil des Artikels ist abgeschlossen, kommen wir zu häufig auftretenden Fragen.
Häufig gestellte Fragen
— Wenn alle Parteien des aktiven Smart Contracts die Bedingungen ändern möchten, können sie diesen Smart Contract dann mit einer Multi-Signatur aufheben und danach einen neuen Smart Contract mit den aktualisierten Bedingungen für dessen Ausführung erstellen?
Hier wird die Antwort zwiespältig sein. Warum? Denn einerseits wird der Smart Contract einmal festgelegt und sieht keine Änderungen vor, andererseits kann er eine im Voraus festgelegte Logik haben, die vollständige oder teilweise Veränderungen gewisser Bedingungen vorsieht. Das heißt, wenn Sie etwas in Ihrem Smart Contract ändern möchten, müssen Sie im Voraus die Bedingungen festlegen, unter denen Sie diese Änderungen vornehmen können. Dementsprechend lässt sich nur auf diese vorausschauende Weise ein Vertragsupdate organisieren. Aber auch hier kann man auf Probleme stoßen: einen Fehler machen und eine entsprechende Schwachstelle erhalten. Daher müssen solche Dinge sehr detailliert und sorgfältig entworfen und getestet werden.
— Und wenn der Mediator sich mit einer der an dem Smart Contract beteiligten Parteien: dem Escrow oder dem Smart Contract, abspricht? Ist ein Mediator im Smart Contract erforderlich?
Ein Mediator ist im Smart Contract nicht obligatorisch. Er kann fehlen. Wenn der Mediator jedoch bei einer Treuhandtransaktion mit einer der Parteien einen Komplott eingeht, verlieren diese Mechanismen sofort ihren gesamten Wert. Daher werden Mediatoren so ausgewählt, dass ihnen alle beteiligten Parteien gleichzeitig vertrauen. Dementsprechend werden Sie einfach keine Münzen an die Multisignatur-Adresse mit dem Mediator übertragen, dem Sie nicht vertrauen.
— Ist es möglich, mit einer Ethereum-Transaktion viele verschiedene Token von Ihrer Adresse auf verschiedene Zieladressen, zum Beispiel die Adressen von Börsen, auf denen diese Token gehandelt werden, zu übertragen?
Das ist eine gute Frage und betrifft das Transaktionsmodell von Ethereum und dessen Unterschiede zum Bitcoin-Modell. Und dieser Unterschied ist entscheidend. Im Transaktionsmodell von Ethereum übertragen Sie einfach Münzen, diese werden nur von einer Adresse auf eine andere übertragen, ohne Rückgaben, nur der spezifische Betrag, den Sie angegeben haben. Mit anderen Worten, es handelt sich nicht um ein Modell von nicht ausgegebenen Transaktionen (UTXO), sondern um ein Modell von Konten und entsprechenden Bilanzen. Es ist theoretisch möglich, mit einer Transaktion mehrere verschiedene Token auf einmal zu senden, wenn man einen cleveren Smart Contract erstellt, aber man muss immer noch viele Transaktionen durchführen, den Vertrag erstellen, dann ihm Token und Münzen übergeben und dann die entsprechende Methode aufrufen. Das erfordert Aufwand und Zeit, weshalb es in der Praxis nicht so funktioniert und alle Zahlungen in Ethereum in separaten Transaktionen durchgeführt werden.
— Einer der Mythen über die Ethereum-Plattform ist, dass es unmöglich ist, Bedingungen zu beschreiben, die von Daten einer externen Internetressource abhängen. Was tun wir dann?
Die Lösung besteht darin, dass der Smart Contract einen oder mehrere sogenannte vertrauenswürdige Orakel vorsehen kann, die Daten über den Zustand der Dinge in der Außenwelt sammeln und diese über spezielle Methoden an die Smart Contracts übermitteln. Der Vertrag betrachtet die Daten, die er von diesen vertrauenswürdigen Quellen erhalten hat, als wahr. Um die Zuverlässigkeit zu erhöhen, wählt man einfach eine größere Gruppe von Orakeln und minimiert das Risiko eines Komplotts. Der Vertrag kann Daten von Orakeln ignorieren, die im Widerspruch zu den meisten stehen.
Dieses Thema ist Bestandteil einer der Lektionen des Online-Kurses über Blockchain — “”.
Quelle: habr.com
