In diesem Artikel werden wir uns mit Smart Contracts befassen: was sie sind, welche Arten es gibt, wir lernen verschiedene Smart Contract-Plattformen und deren Besonderheiten kennen. Zudem besprechen wir, wie sie funktionieren und welche Vorteile sie bieten können. Dieser Stoff ist besonders nützlich für Leser, die mit dem Thema Smart Contracts nicht vertraut sind, aber ein besseres Verständnis entwickeln möchten.
Traditioneller Vertrag vs. Smart Contract
Bevor wir ins Detail gehen, lassen Sie uns anhand eines Beispiels die Unterschiede zwischen einem traditionellen Vertrag auf Papier und einem Smart Contract in digitaler Form erläutern.
Wie lief es vor der Einführung von Smart Contracts? Stellen Sie sich eine Gruppe von Personen vor, die einige Regeln und Bedingungen für die Verteilung von Werten festlegen möchte und einen bestimmten Mechanismus benötigt, um die Einhaltung dieser Regeln und Bedingungen zu gewährleisten. Früher kamen sie zusammen, verfassten ein Dokument, in dem sie ihre Identifikationsdaten, Bedingungen und die beteiligten Werte festhielten, datierten es und unterschrieben es. Dieses Vertragsdokument wurde auch von einer vertrauenswürdigen Instanz, wie einem Notar, beglaubigt. Anschließend trennten sich diese Personen mit ihrer Papierkopie des Vertrags und begannen, Handlungen auszuführen, die möglicherweise nicht dem Vertrag entsprachen, das heißt, sie taten eines, während auf dem Papier festgehalten war, dass sie etwas ganz anderes tun sollten. Wie löst man diese Situation? Tatsächlich musste jemand aus der Gruppe dieses Papier nehmen, irgendwelche Beweise sammeln, vor Gericht gehen und die Einhaltung zwischen dem Vertrag und den tatsächlichen Handlungen einfordern. Oft ist es schwierig, eine faire Umsetzung dieses Vertrags zu erreichen, was zu unangenehmen Konsequenzen führt.
Was kann man über Smart Contracts sagen? Sie vereinen die Möglichkeit, Vertragsbedingungen zu formulieren, und den Mechanismus ihrer strikten Ausführung. Wenn die Bedingungen festgelegt wurden und die entsprechende Transaktion oder Anfrage unterzeichnet wurde, können die Bedingungen nach Annahme dieser Anfrage oder Transaktion nicht mehr geändert oder deren Ausführung beeinflusst werden.
Es gibt entweder einen Validator oder ein ganzes Netzwerk sowie eine Datenbank, die alle Smart Contracts speichert, die in strikter zeitlicher Reihenfolge zur Ausführung eingegangen sind. Ebenso wichtig ist, dass diese Datenbank alle Triggerbedingungen für die Ausführung des Smart Contracts enthalten muss. Außerdem muss sie den Wert berücksichtigen, dessen Verteilung im Vertrag beschrieben wird. Bezieht es sich auf eine digitale Währung, muss diese Datenbank diese ebenfalls berücksichtigen.
Mit anderen Worten, Validatoren von Smart Contracts müssen Zugang zu allen Daten haben, mit denen der Smart Contract arbeitet. Beispielsweise sollte eine Datenbank gleichzeitig zur Verwaltung digitaler Währungen, Benutzerkontostände, Benutzertransaktionen und Zeitstempel verwendet werden. In diesem Fall könnte eine Bedingung im Smart Contract der Kontostand eines Benutzers in einer bestimmten Währung, das Eintreten eines bestimmten Zeitpunkts oder das Vorliegen einer bestimmten Transaktion sein, aber nicht mehr.
Definition von Smart Contracts
Die Terminologie wurde ursprünglich von dem Forscher Nick Szabo entwickelt und 1994 erstmals angewendet. Dokumentiert wurde sie 1997 in einem Artikel, der die Idee der Smart Contracts beschreibt.
Smart Contracts bedeuten, dass eine automatisierte Verteilung von Werten erfolgt, die ausschließlich von den zuvor festgelegten Bedingungen abhängt. Im einfachsten Fall sieht dies aus wie ein Vertrag mit genau definierten Bedingungen, der von bestimmten Parteien unterzeichnet wurde.
Smart Contracts sollen das Vertrauen in Dritte minimieren. Manchmal wird das Zentrum der Entscheidungsfindung vollständig ausgeschlossen. Außerdem ist es für solche Verträge einfacher, eine Prüfung durchzuführen. Dies ergibt sich aus bestimmten Designmerkmalen solcher Systeme, doch meistens verstehen wir unter einem Smart Contract eine dezentrale Umgebung und Funktionen, die es jedem ermöglichen, die Datenbank zu analysieren und eine vollständige Prüfung der Vertragserfüllung durchzuführen. So wird der Schutz vor nachträglichen Änderungen der Daten gewährleistet, die Veränderungen in der Vertragserfüllung zur Folge hätten. Die Digitalisierung der meisten Prozesse bei der Erstellung und Implementierung eines Smart Contracts vereinfacht häufig die Technologie und die Kosten ihrer Umsetzung.
Ein einfaches Beispiel ist der Escrow-Service.
Lassen Sie uns ein sehr einfaches Beispiel betrachten. Es wird helfen, die funktionalen Möglichkeiten von Smart Contracts besser zu verstehen und zu erkennen, in welchen Fällen sie eingesetzt werden sollten.
Es ist auch möglich, dies mit Bitcoin zu realisieren, obwohl Bitcoin derzeit noch schwer als vollwertige Plattform für Smart Contracts zu bezeichnen ist. Wir haben also einen Käufer und einen Online-Shop. Der Käufer möchte einen Monitor in diesem Shop erwerben. Im einfachsten Fall gibt der Käufer die Zahlung auf und der Online-Shop akzeptiert sie, bestätigt sie und versendet die Ware. In dieser Situation besteht jedoch eine große Notwendigkeit nach Vertrauen — der Käufer muss dem Online-Shop den gesamten Betrag für den Monitor anvertrauen. Da der Online-Shop in den Augen des Käufers eine schlechte Reputation haben könnte, besteht das Risiko, dass der Shop aus irgendeinem Grund nach Annahme der Zahlung den Service verweigert und die Ware nicht an den Käufer liefert. Daher fragt sich der Käufer (und entsprechend fragt sich auch der Online-Shop), welche Maßnahmen ergriffen werden können, um solche Risiken zu minimieren und solche Transaktionen zuverlässiger zu gestalten.
Im Falle von Bitcoin kann sowohl der Käufer als auch der Verkäufer unabhängig einen Vermittler auswählen. Es gibt viele Personen, die sich mit der Lösung von Streitfragen beschäftigen. Unsere Teilnehmer können aus einer Liste von Vermittlern denjenigen auswählen, dem sie gleichzeitig vertrauen. Gemeinsam erstellen sie eine Multisignaturadresse im Format 2 aus 3, wobei drei Schlüssel existieren und zwei Unterschriften von beliebigen zwei Schlüsseln erforderlich sind, um die Coins von dieser Adresse auszugeben. Ein Schlüssel gehört dem Käufer, der zweite dem Online-Shop und der dritte dem Vermittler. Auf diese Multisignaturadresse wird der Betrag gesendet, der zur Bezahlung des Monitors erforderlich ist. Jetzt, da der Verkäufer sieht, dass das Geld für eine gewisse Zeit auf der Multisignaturadresse blockiert ist, die von ihm abhängt, kann er den Monitor problemlos per Post versenden.
Der Käufer erhält das Paket, betrachtet die Ware und trifft eine Entscheidung über den endgültigen Kauf. Er kann mit dem bereitgestellten Service vollkommen zufrieden sein und die Transaktion mit seinem Schlüssel unterzeichnen, wobei er die Coins von der Multisignatur-Adresse des Verkäufers überträgt. Er kann jedoch auch mit etwas unzufrieden sein. In diesem Fall kontaktiert er den Vermittler, um eine alternative Transaktion zu erstellen, die diese Coins anders verteilt.
Angenommen, der Monitor ist leicht zerkratzt angekommen, und es lag kein Kabel für den Anschluss an den Computer bei, obwohl auf der Website des Online-Shops angegeben war, dass das Kabel im Lieferumfang enthalten sein sollte. In diesem Fall sammelt der Käufer Beweise, die notwendig sind, um dem Vermittler nachzuweisen, dass er in dieser Situation betrogen wurde: Er macht Screenshots von der Website, fotografiert den Beleg von der Post, fotografiert die Kratzer auf dem Monitor und zeigt, dass das Siegel entfernt wurde und das Kabel entnommen wurde. Der Online-Shop wiederum sammelt seine Beweise und übergibt diese dem Vermittler.
Der Mediator hat das Ziel, sowohl die Unzufriedenheit des Käufers als auch die Interessen des Online-Shops gleichzeitig zu berücksichtigen (das wird gleich klarer). Er erstellt eine Transaktion, in der die Coins von einer Multisignatur-Adresse in einem bestimmten Verhältnis zwischen Käufer, Online-Shop und Mediator verteilt werden, da er sich einen Teil als Vergütung für seine Arbeit einbehält. Angenommen, 90 % des Gesamtbetrags gehen an den Verkäufer, 5 % an den Mediator und 5 % als Entschädigung an den Käufer. Diese Transaktion signiert der Mediator mit seinem Schlüssel, aber sie kann noch nicht ausgeführt werden, da dafür zwei Signaturen erforderlich sind, er hat jedoch nur eine. Diese Transaktion sendet er sowohl an den Käufer als auch an den Verkäufer. Wenn einer von ihnen mit dieser Verteilung der Coins einverstanden ist, wird die Transaktion nachsigniert und im Netzwerk verbreitet. Für die Validierung genügt es, wenn einer der Beteiligten dem Vorschlag des Mediators zustimmt.
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 Coins anbieten kann, die zumindest einen der Teilnehmer zufriedenstellt, können Käufer und Online-Shop gemeinsam beschließen, die Coins auf eine neue Multisignaturadresse zu übertragen, indem sie ihre beiden Unterschriften setzen. Die neue Multisignaturadresse wird dann mit einem anderen Mediator erstellt, der möglicherweise kompetenter ist und eine bessere Option anbieten kann.
Beispiel mit einem Wohnheim und einem Kühlschrank
Betrachten wir ein komplexeres Beispiel, das die Möglichkeiten eines Smart Contracts deutlicher aufzeigt.
Stellen Sie sich vor, drei Jugendliche haben sich kürzlich ein Zimmer in einem Wohnheim geteilt. Sie sind alle daran interessiert, einen Kühlschrank für ihr Zimmer zu kaufen, den sie gemeinsam nutzen können. 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 kürzlich kennengelernt haben, besteht nicht genügend Vertrauen zwischen ihnen. Offensichtlich riskieren zwei von ihnen, ihr Geld an den Dritten zu geben. Außerdem müssen sie sich über den Verkäufer einigen.
Sie können einen Escrow-Service nutzen, also einen Mediator wählen, der die Durchführung des Geschäfts überwacht und strittige Fragen klärt, falls solche auftreten. Nachdem sie sich geeinigt haben, erstellen sie einen Smart Contract und legen bestimmte Bedingungen fest.
Das erste Bedingung besteht darin, dass bis zu einem bestimmten Zeitpunkt, beispielsweise innerhalb einer Woche, drei Zahlungen von bestimmten Adressen in einer festgelegten Höhe auf das entsprechende Konto des Smart Contracts eingehen müssen. Wenn dies nicht geschieht, wird der Smart Contract nicht weiter ausgeführt und die Coins werden an alle Teilnehmer zurückgegeben. Erfüllt sich jedoch die Bedingung, werden die Identifikatoren des Verkäufers und des Vermittlers festgelegt und es wird überprüft, ob alle Teilnehmer mit der Wahl des Verkäufers und des Vermittlers einverstanden sind. Sobald alle Bedingungen erfüllt sind, werden die Mittel auf die angegebenen Adressen überwiesen. Ein solcher Ansatz kann die Teilnehmer vor Betrug jeglicher Art schützen und eliminiert die Notwendigkeit des Vertrauens.
Wir erkennen an diesem Beispiel das Prinzip, dass die Möglichkeit, Schritt für Schritt Parameter für die Ausführung jeder Bedingung zu definieren, es erlaubt, Systeme jeder Komplexität und Tiefe von Verschachtelungen zu schaffen. Darüber hinaus kann im Smart Contract zuerst die erste Bedingung festgelegt werden, und erst nach deren Erfüllung können die Parameter für die nächste Bedingung definiert werden. Anders ausgedrückt: formell wird die Bedingung festgelegt, die Parameter dafür können jedoch während ihrer Ausführung bestimmt werden.
Klassifizierung von Smart Contracts
Für die Klassifizierung können unterschiedliche Gruppen von Kriterien festgelegt werden. Derzeit sind jedoch vier davon besonders relevant.
Smart Contracts lassen sich nach der Ausführungsumgebung unterscheiden, die entweder zentralisiert oder dezentralisiert sein kann. Im Falle der Dezentralisierung haben wir unabhängigere und ausfallsichere Smart Contracts.
Sie können auch nach dem Prozess der Festlegung und Ausführung der Bedingungen unterschieden werden: Sie können willkürlich programmierbar, eingeschränkt oder vordefiniert, d.h. strikt typisiert, sein. Wenn auf der Plattform der Smart Contracts nur 4 bestimmte Smart Contracts existieren, können die Parameter für sie beliebig festgelegt werden. Dementsprechend ist es viel einfacher, sie zu definieren: Wir wählen einen Vertrag aus der Liste aus und übergeben die Parameter.
In Bezug auf die Initiierung gibt es automatisierte Smart Contracts, das heißt, sie werden bei Eintritt bestimmter Bedingungen automatisch ausgeführt. Es gibt aber auch solche Verträge, bei denen die Bedingungen festgelegt sind, die Plattform jedoch ihre Ausführung nicht automatisch überprüft; hierfür müssen sie separat initiiert werden.
Darüber hinaus unterscheiden sich Smart Contracts im Hinblick auf die 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 umfangreich und sollte besser getrennt von diesem Artikel behandelt werden.
Im Folgenden betrachten wir die ersten drei Kriterien näher, um mehr Klarheit über das aktuelle Thema zu schaffen.
Smart Contracts nach Ausführungsumgebung
Es gibt zentralisierte und dezentralisierte Plattformen für Smart Contracts. Bei zentralisierten digitalen Verträgen wird ein einzelner Service verwendet, in dem es nur einen Validator gibt; auch ein Backup- und Wiederherstellungsdienst kann zentral verwaltet werden. Eine einzige Datenbank speichert alle notwendigen Informationen zur Festlegung der Bedingungen des Smart Contracts und zur Verteilung des Wertes, der in dieser Datenbank des Services erfasst wird. Ein solcher zentralisierter Dienst hat einen Client, der durch bestimmte Anfragen die Bedingungen festlegt und diese Verträge nutzt. Da die Plattform zentralisiert ist, können die Authentifizierungsmechanismen weniger zuverlässig sein als bei Kryptowährungen.
Ein Beispiel könnten Mobilfunkanbieter (verschiedene Mobilfunkbetreiber) sein. Angenommen, ein bestimmter Anbieter erfasst zentralisiert den Verkehr auf seinen Servern, der in verschiedenen Formaten übertragen wird, wie beispielsweise Sprachtelefonaten, SMS-Versand, mobilen Internet-Traffic und verschiedener Standards. Außerdem verwaltet er die Guthaben auf den Konten der Nutzer. Folglich kann der Mobilfunkanbieter Verträge zur Abrechnung der erbrachten Dienste und deren Bezahlung mit unterschiedlichen Bedingungen aufsetzen. In einem solchen Fall lassen sich Bedingungen wie "Sende eine SMS mit diesem Code an diese Nummer und erhalte diese Bedingungen für die Verkehrsumverteilung" leicht formulieren.
Ein weiteres Beispiel sind traditionelle Banken mit erweiterten Internetbanking-Funktionen und sehr einfachen Verträgen, wie regelmäßig wiederkehrende Zahlungen, automatische Umwandlung eingehender Zahlungen, automatische Gutschrift von Zinsen auf ein bestimmtes Konto usw.
Wenn es um Smart Contracts in einer dezentralen Ausführungsumgebung geht, haben wir eine Gruppe von Validierern. Idealerweise kann jeder Validierer werden. Durch das Protokoll zur Synchronisierung der Datenbank und das Erreichen eines Konsenses verfügen wir über eine gemeinsame Datenbasis, die nun alle Transaktionen mit klar definierten Verträgen speichert, anstatt irgendwelche hypothetischen Anfragen, deren Formate sich häufig ändern und für die es keine offene Spezifikation gibt. Hier enthalten die Transaktionen Anweisungen zur Ausführung des Vertrags gemäß einer strengen Spezifikation. Diese Spezifikation ist öffentlich zugänglich, und daher können die Nutzer der Plattform die Smart Contracts überprüfen und validieren. Hier sehen wir, dass dezentrale Plattformen in Bezug auf Unabhängigkeit und Fehlertoleranz zentralisierten Lösungen überlegen sind, aber ihre Planung und Wartung zugleich viel komplizierter ist.
Smart Contracts in Bezug auf die Festlegung und Ausführung von Bedingungen
Lassen Sie uns nun genauer betrachten, wie Smart Contracts in Bezug auf die Definition und Ausführung von Bedingungen variieren können. Hierbei konzentrieren wir uns auf Smart Contracts, die willkürlich und Turing-vollständig programmiert sind. Ein Turing-vollständiger Smart Contract ermöglicht es, nahezu beliebige Algorithmen als Bedingungen für die Vertragserfüllung festzulegen: dazu gehören das Schreiben von Schleifen, das Berechnen von Wahrscheinlichkeiten und sogar eigene Algorithmen zur elektronischen Unterzeichnung. In diesem Fall ist tatsächlich die willkürliche Logik gemeint.
Es gibt auch willkürliche Smart Contracts, die jedoch nicht Turing-vollständig sind. Hierzu zählen Bitcoin und Litecoin mit ihrem Skript. Dies bedeutet, dass nur bestimmte Operationen in beliebiger Reihenfolge verwendet werden können, beispielsweise lassen sich jedoch keine Schleifen oder eigenen Algorithmen schreiben.
Außerdem gibt es Plattformen für Smart Contracts, die vorab festgelegte Smart Contracts implementieren. Dazu gehören Bitshares und Steemit. Bitshares bietet eine Vielzahl von Smart Contracts für den Handel, das Management von Konten sowie die Verwaltung der Plattform und ihrer Parameter. Steemit hingegen ist eine ähnliche Plattform, die sich nicht auf die Ausgabe von Tokens und Handel wie Bitshares konzentriert, sondern auf das Blogging, d. h. sie speichert und verarbeitet Inhalte dezentral.
Zu den allgemeinen vollständigen Turing-verfügbaren Verträgen zählen die Plattform Ethereum und RootStock, die sich noch in der Entwicklungsphase befindet. Daher werden wir uns im Folgenden etwas ausführlicher mit der Smart-Contract-Plattform Ethereum beschäftigen.
Smart Contracts nach ihrer Initiierungsmethode
Smart Contracts können mindestens in zwei Gruppen eingeteilt werden: automatisierte und manuelle (nicht automatisierte) Verträge. Bei automatisierten Verträgen erfolgt die vollständige Ausführung automatisch, sobald alle bekannten Parameter erfüllt sind und die Bedingungen eintreten. Das bedeutet, dass keine zusätzlichen Transaktionen erforderlich sind und somit keine zusätzlichen Gebühren bei jedem einzelnen Ausführungsprozess anfallen. Die Plattform hat alle notwendigen Daten, um zu berechnen, wie der Smart Contract abgeschlossen wird. Die Logik ist nicht willkürlich, sondern im Voraus festgelegt, was alles vorhersehbar macht. Das heißt, die Komplexität der Ausführung eines Smart Contracts kann im Voraus eingeschätzt werden, und es kann eine konstante Gebühr dafür verwendet werden, sodass alle Abläufe effizienter abgewickelt werden.
Bei Smart Contracts, die beliebig programmiert werden, ist die Ausführung nicht automatisiert. Um einen solchen Smart Contract zu initiieren, muss tatsächlich bei jedem Schritt eine neue Transaktion erstellt werden, die die nächste Ausführungsstufe oder die nächste Methode des Smart Contracts aufruft, die entsprechende Gebühr bezahlt und auf die Bestätigung der Transaktion wartet. Die Ausführung kann erfolgreich abgeschlossen werden oder nicht, da der Code des Smart Contracts beliebig ist und unvorhersehbare Probleme auftreten können, wie z. B. eine Endlosschleife, das Fehlen bestimmter Parameter und Argumente oder nicht behandelte Ausnahmesituationen.
Ethereum-Konten
Arten von Ethereum-Konten
Betrachten wir, welche Arten von Konten auf der Ethereum-Plattform existieren können. Es gibt hier nur zwei Arten von Konten und keine weiteren Optionen. Der erste Typ wird Benutzerkonto genannt, der zweite – Vertragkonto. Lassen Sie uns klären, worin genau der Unterschied besteht.
Das Benutzerkonto wird ausschließlich durch den persönlichen elektronischen Signaturschlüssel verwaltet. Der Kontoinhaber generiert sein eigenes Schlüsselpaar zur elektronischen Signatur nach dem ECDSA-Algorithmus (Elliptic Curve Digital Signature Algorithm). Der Status dieses Kontos kann nur durch Transaktionen, die mit diesem Schlüssel signiert sind, geändert werden.
Für das Smart-Contract-Konto gibt es eine separate Logik. Es kann nur über einen vordefinierten Programmcode gesteuert werden, der das Verhalten des Smart Contracts vollständig bestimmt: wie es seine Coins unter bestimmten Umständen verwaltet, auf Initiative welches Benutzers und unter welchen zusätzlichen Bedingungen diese Coins verteilt werden. Wenn bestimmte Punkte im Programmcode von den Entwicklern nicht berücksichtigt werden, können Probleme auftreten. Zum Beispiel kann der Smart Contract einen bestimmten Zustand erreichen, in dem er die Initiierung weiterer Ausführungen von keinem Benutzer akzeptiert. In diesem Fall wären die Coins faktisch eingefroren, da der Smart Contract keinen Ausweg aus diesem Zustand vorsieht.
Wie werden Konten in Ethereum erstellt?
Bei Benutzerkonten generiert der Eigentümer selbst ein Schlüsselpaar mit ECDSA. Es ist wichtig zu beachten, dass Ethereum für digitale Signaturen denselben Algorithmus und dieselbe elliptische Kurve verwendet wie Bitcoin, aber die Adresse wird etwas anders berechnet. Hier kommt das Ergebnis der doppelten Hashbildung, wie bei Bitcoin, nicht mehr zum Einsatz; stattdessen erfolgt eine einfache Hashbildung mit der Keccak-Funktion mit einer Länge von 256 Bit. Von dem erhaltenen Wert werden die unteren Bits abgeschnitten, genauer gesagt, die 160 untersten Bits des Hash-Wertes. Am Ende erhalten wir die Adresse in Ethereum. Tatsächlich nimmt sie 20 Byte ein.
Es ist zu beachten, dass die Konten-ID in Ethereum hexadezimal kodiert ist, ohne eine Prüfziffer hinzuzufügen, im Gegensatz zu Bitcoin und vielen anderen Systemen, bei denen die Adresse in ein 58er-Zahlensystem mit einer Prüfziffer kodiert wird. Das bedeutet, dass man vorsichtig mit Konten-IDs in Ethereum umgehen sollte: Bereits ein einziger Fehler in der ID führt zwangsläufig zum Verlust von Münzen.
Eine wichtige Besonderheit besteht darin, dass das Benutzerkonto auf der allgemeinen Datenbankebene in dem Moment erstellt wird, in dem der Nutzer die erste eingehende Zahlung akzeptiert.
Für die Erstellung eines Smart Contracts wird ein völlig anderer Ansatz gewählt. Zuerst schreibt einer der Nutzer den Quellcode des Smart Contracts, der dann durch einen speziellen Compiler für die Ethereum-Plattform verarbeitet wird, um den Bytecode für die eigene Ethereum-virtuelle Maschine zu erhalten. Der erzeugte Bytecode wird in ein spezielles Transaktionsfeld eingefügt. Diese Transaktion wird im Namen des Initiator-Kontos signiert. Anschließend wird die Transaktion im Netzwerk verbreitet und der Code des Smart Contracts wird veröffentlicht. Die Gebühr für die Durchführung der Transaktion und somit für die Ausführung des Vertrags wird vom Kontostand des Initiators abgebucht.
Jeder Smart Contract enthält immer seinen eigenen Konstruktor (dieses Vertrags). Dieser kann leer sein oder Inhalte haben. Nach der Ausführung des Konstruktors wird eine Identifikationsnummer des Smart Contract-Kontos erstellt, mit der man Münzen senden, bestimmte Methoden des Smart Contracts aufrufen usw. kann.
Die Struktur einer Ethereum-Transaktion
Um es klarer zu machen, werden wir die Struktur einer Ethereum-Transaktion und ein Beispiel für einen Smart Contract betrachten.
Eine Ethereum-Transaktion besteht aus mehreren Feldern. Das erste ist der nonce – eine Art Ordnungsnummer der Transaktion in Bezug auf das Konto, das sie sendet und autorisiert. Dies ist notwendig, um doppelte Transaktionen zu unterscheiden und sicherzustellen, dass eine Transaktion nicht versehentlich zweimal angenommen wird. Durch die Verwendung dieser Kennung hat jede Transaktion einen einzigartigen Hash-Wert.
Als nächstes folgt das Feld Gaspreis. Hier wird der Preis angegeben, zu dem die Basiswährung Ethereum in Gas umgewandelt wird, welches die Ausführung des Smart Contracts und die Bereitstellung von Ressourcen der virtuellen Maschine bezahlt. Was bedeutet das?
Bei Bitcoin werden die Gebühren direkt in der Basiswährung – also in Bitcoin – bezahlt. Dies ist durch einen einfachen Berechnungsmechanismus möglich: Wir zahlen strikt für das Volumen der Daten, die in der Transaktion enthalten sind. Bei Ethereum ist die Situation komplexer, da es schwierig ist, sich an das Volumen der Transaktionsdaten zu orientieren. Hier kann die Transaktion zusätzlich Programmcode enthalten, der auf einer virtuellen Maschine ausgeführt wird, und jede Operation auf dieser virtuellen Maschine kann von unterschiedlicher Komplexität sein. Es gibt auch Operationen, die Speicher für Variablen reservieren, und die Schwierigkeit dieser Operationen beeinflusst die Zahlung für jede einzelne Operation.
Die Kosten jeder Operation in Gas-Äquivalent werden konstant sein. Dieser wird eingeführt, um die konstante Kostenstruktur jeder Operation festzulegen. Je nach Auslastung des Netzwerks kann sich der Gaspreis ändern, also der Faktor, nach dem die Basiswährung in diese Hilfseinheit zur Zahlung der Gebühren umgerechnet wird.
Es gibt noch eine weitere Besonderheit von Transaktionen in Ethereum: Der Bytecode, der für die Ausführung in der virtuellen Maschine enthalten ist, wird so lange ausgeführt, bis er mit einem Ergebnis (Erfolg-Misserfolg) endet oder bis ein gewisser Betrag an Münzen, der für die Gebühren vorgesehen ist, aufgebraucht ist. Um zu vermeiden, dass im Falle eines Fehlers alle Münzen auf dem Konto des Absenders für Gebühren verwendet werden (zum Beispiel wenn eine Endlosschleife in der virtuellen Maschine gestartet wurde), gibt es das folgende Feld — start gas (häufig als Gaslimit bezeichnet) — es definiert den maximalen Betrag an Münzen, 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 Münzen oder die Adresse eines bestimmten Smart Contracts, dessen Methoden aufgerufen werden, eingetragen. Nach diesem folgt das Feld value, in das der Betrag an Münzen eingetragen wird, der an die destination address gesendet wird.
Weiter folgt ein interessantes Feld mit dem Namen data, in das eine gesamte Struktur integriert ist. Dies ist kein separates Feld, sondern eine vollständige Struktur, in der der Code für die virtuelle Maschine definiert wird. Hier können beliebige Daten eingegeben werden – dafür gibt es spezifische Regeln.
Und das letzte Feld heißt 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 ID des Kontos des Absenders dieser Transaktion abgeleitet werden, das heißt, das Konto des Absenders kann eindeutig im System identifiziert werden. Die grundlegende Struktur der Transaktion haben wir klargestellt.
Beispiel für einen Smart Contract in Solidity
Lassen Sie uns jetzt näher auf den einfachsten Smart Contract anhand eines Beispiels eingehen.
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 finden Sie den vereinfachten Quellcode, der die Münzen der Benutzer verwalten und auf Anfrage zurückgeben kann.
Es gibt also einen Smart Contract namens Bank, der folgende Funktionen erfüllt: Er speichert Münzen auf seinem Konto, das heißt, bei Bestätigung einer Transaktion und der Bereitstellung dieses Smart Contracts wird ein neues Konto erstellt, das Münzen enthalten kann; er merkt sich die Benutzer und die Verteilung der Münzen zwischen ihnen; er verfügt über mehrere Methoden zur Verwaltung der Kontostände, das heißt, es besteht die Möglichkeit, Einzahlungen, Abhebungen und die Überprüfung des Benutzerkontos vorzunehmen.
Lassen Sie uns jede Zeile des Quellcodes durchgehen. In diesem Vertrag gibt es konstante Felder. Eines davon, vom Typ Address, heißt owner. Hier merkt sich der Vertrag die Adresse des Benutzers, der diesen Smart Contract erstellt hat. Darüber hinaus gibt es eine dynamische Struktur, die die Zuordnungen zwischen den Benutzeradressen und den Kontoständen speichert.
Danach folgt die Methode Bank – sie hat denselben Namen wie der Vertrag. Dies ist folglich der Konstruktor. Hier wird der Variable owner die Adresse desjenigen zugewiesen, der diesen Smart Contract im Netzwerk bereitgestellt hat. Das ist alles, was in diesem Konstruktor geschieht. Das bedeutet, dass msg in diesem Fall genau die Daten sind, die zusammen mit der Transaktion an die virtuelle Maschine übermittelt wurden, die den gesamten Code dieses Vertrags enthält. Folglich ist msg.sender der Autor dieser Transaktion, die diesen Code bereitstellt. Er wird der Eigentümer des Smart Contracts sein.
Die Methode deposit ermöglicht es, eine bestimmte Menge an Coins über eine Transaktion auf das Konto des Vertrags zu übertragen. In diesem Fall behält der Smart Contract diese Coins auf seinem Guthaben, verzeichnet jedoch in der Struktur balances, wer genau der Absender dieser Coins war, um zu wissen, wem sie gehören.
Die nächste Methode heißt withdraw und sie nimmt einen Parameter - den Betrag an Coins, den jemand aus dieser Bank abheben möchte. Hier erfolgt eine Überprüfung, ob ausreichend Coins im Konto 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 Coins zurück.
Dann folgt die Methode zur Überprüfung des aktuellen Kontostands des Benutzers. Derjenige, der diese Methode aufruft, wird verwendet, um diesen Kontostand im Smart Contract abzurufen. Es ist erwähnenswert, dass der Modifikator dieser Methode - view ist. Das bedeutet, dass die Methode keine Variablen ihrer Klasse verändert und tatsächlich nur eine Lesemethode ist. Es wird keine separate Transaktion für den Aufruf dieser Methode erstellt, keine Gebühr entfällt und alle Berechnungen erfolgen lokal, woraufhin der Benutzer das Ergebnis erhält.
Die Methode kill dient dazu, den Zustand eines Smart Contracts zu zerstören. Hierbei wird zusätzlich überprüft, ob der Aufrufer dieser Methode der Eigentümer des Vertrags ist. Ist dies der Fall, wird der Vertrag selbstzerstört, und die Zerstörungsfunktion erhält einen Parameter – die Identifikationsnummer des Kontos, auf das der Vertrag alle verbleibenden Münzen auf seinem Guthaben übermitteln wird. In diesem Fall werden die verbleibenden Münzen automatisch an die Adresse des Vertragseigentümers 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 arbeitet.
Ein vollständiger Knoten im Ethereum-Netzwerk muss mindestens vier Module besitzen.
Das erste, wie bei jedem dezentralisierten Protokoll, ist das P2P-Netzwerkmodul – ein Modul für die Netzwerkverbindung und die Interaktion mit anderen Knoten, in dem Blöcke, Transaktionen und Informationen über andere Knoten ausgetauscht werden. Dies ist eine traditionelle Komponente für alle dezentralen Kryptowährungen.
Wir haben ein Modul für die Speicherung von Blockchain-Daten, die Verarbeitung, die Auswahl des bevorzugten Zweigs, das Hinzufügen von Blöcken, das Abkoppeln von Blöcken, die Überprüfung dieser Blöcke usw.
Das dritte Modul wird als EVM (Ethereum Virtual Machine) bezeichnet — dies ist virtuelle Maschine, das Bytecode aus Ethereum-Transaktionen akzeptiert. Dieses Modul nimmt den aktuellen Zustand eines bestimmten Kontos entgegen und führt Änderungen an seinem Zustand basierend auf dem erhaltenen Bytecode durch. Die Version der virtuellen Maschine auf jedem Knotennetzwerk muss identisch sein. Die Berechnungen auf den Knoten des Ethereum-Netzwerks sind absolut identisch, erfolgen jedoch asynchron: Einige Knoten überprüfen und akzeptieren diese Transaktion früher, d.h. führen den darin enthaltenen Code aus, während andere dies später tun. Dementsprechend wird bei der Erstellung einer Transaktion diese im Netzwerk verbreitet, die Knoten nehmen sie entgegen und verifizieren sie genau so, wie im Bitcoin das Bitcoin-Skript ausgeführt wird, hier wird der Bytecode der virtuellen Maschine ausgeführt.
Eine Transaktion wird als überprüft angesehen, wenn der gesamte darin enthaltene Code ausgeführt wurde, ein neuer Zustand eines bestimmten Kontos generiert wurde und dieser 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 identisch ablaufen und der Blockchain-Zustand gleich ist, wird auch die Datenbank, die die Zustände aller Konten enthält, für jeden Knoten gleich sein.
Mythen und Einschränkungen von Smart Contracts
Was die Einschränkungen betrifft, die für Ethereum-ähnliche Smart Contract-Plattformen bestehen, können folgende genannt werden:
- Codeausführung;
- Speicherzuweisung;
- Blockchain-Daten;
- Zahlungen senden;
- Neuen Vertrag erstellen;
- Andere Verträge aufrufen.
Lassen Sie uns die Einschränkungen betrachten, die auf einer virtuellen Maschine liegen, und dabei einige Mythen über Smart Contracts aufklären. Auf einer virtuellen Maschine, die nicht nur in Ethereum, sondern auch in ähnlichen Plattformen existiert, können tatsächlich beliebige logische Operationen durchgeführt werden. Das bedeutet, dass Sie Code schreiben können, der dort ausgeführt wird, und zusätzlich Speicher zugewiesen werden kann. Allerdings wird für jede Operation und jede zusätzlich zugewiesene Speichereinheit eine separate Gebühr 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 Logik von Smart Contracts zu verwenden. Die virtuelle Maschine kann Transaktionen erstellen und senden, neue Verträge aufsetzen und Methoden anderer bereits im Netzwerk veröffentlichter Smart Contracts aufrufen: sie sind vorhanden und zugänglich usw.
Ein weit verbreiteter Mythos besagt, dass Ethereum-Smart Contracts Informationen von beliebigen Online-Ressourcen in ihren Bedingungen verwenden können. Die Wahrheit ist, dass die virtuelle Maschine keinen Netzwerkaufruf an eine externe Informationsquelle im Internet senden kann. Das bedeutet, dass man keinen Smart Contract erstellen kann, der den Wert zwischen Benutzern je nach beispielsweise dem Wetter draußen oder dem Ergebnis eines Wettkampfs verteilt, oder basierend auf Ereignissen, die in der realen Welt geschehen sind. Solche Informationen sind einfach nicht in der Datenbank der Plattform vorhanden. Im Blockchain gibt es keine derartigen Informationen. Wenn sie dort nicht vorhanden sind, kann die virtuelle Maschine diese Daten nicht als Auslöser verwenden.
Nachteile von Ethereum
Lassen Sie uns die wichtigsten Punkte zusammenfassen. Der erste Nachteil besteht darin, dass es einige Herausforderungen bei der Gestaltung, Entwicklung und dem Testen von Smart Contracts in Ethereum gibt (für das Schreiben von Smart Contracts kommt in Ethereum die Sprache Solidity zum Einsatz). In der Praxis zeigt sich, dass ein sehr großer Anteil aller Fehler auf den menschlichen Faktor zurückzuführen ist. Dies gilt insbesondere für bereits implementierte Ethereum-Smart Contracts, die mittlere oder höhere Komplexität aufweisen. Während bei einfachen Smart Contracts die Fehlerrate niedrig ist, treten bei komplexen Smart Contracts häufig Fehler auf, die zu Diebstählen, zur Einfrierung von Geldern oder zur unerwarteten Zerstörung von Smart Contracts führen können und vieles mehr. Es sind bereits zahlreiche solche Fälle bekannt.
Ein weiteres Manko besteht darin, dass die virtuelle Maschine selbst nicht perfekt ist, da sie ebenfalls von Menschen programmiert wurde. Sie kann beliebige Befehle ausführen, was eine Schwachstelle darstellt: Man kann eine Reihe von Befehlen so konfigurieren, dass sie unerwartete Folgen haben. Dies ist ein sehr komplexes Thema, aber es gibt bereits mehrere Studien, die zeigen, dass diese Schwachstellen in der aktuellen Version des Ethereum-Netzwerks existieren und zu Ausfällen vieler Smart Contracts führen können.
Ein weiteres großes Problem, das auch als Nachteil angesehen werden kann, besteht darin, dass man praktisch oder technisch zu dem Punkt kommen kann, dass, wenn man den Bytecode des Vertrags, der auf der virtuellen Maschine ausgeführt wird, kompiliert, eine spezifische Reihenfolge der Operationen bestimmt werden kann. Wenn diese Operationen gemeinsam ausgeführt werden, belasten sie die virtuelle Maschine erheblich und verlangsamen sie unverhältnismäßig zur Gebühr, die für die Ausführung dieser Operationen bezahlt wurde.
In der Vergangenheit gab es bereits einen Entwicklungszeitraum von Ethereum, in dem viele Experten, die sich intensiv mit der Funktionsweise der virtuellen Maschine beschäftigt haben, Schwachstellen entdeckten. Tatsächlich wurden bei Transaktionen nur sehr geringe Gebühren erhoben, was jedoch die gesamte Netzwerkleistung erheblich verlangsamte. Diese Probleme sind nur mit großem Aufwand zu lösen. Zunächst müssen sie determiniert werden, dann müssen die Ausführungskosten dieser Operationen angepasst werden, und schließlich ist ein Hard Fork erforderlich, was bedeutet, dass alle Knoten im Netzwerk auf eine neue Softwareversion aktualisiert werden müssen, gefolgt von einer gleichzeitigen Aktivierung dieser Änderungen.
Was Ethereum betrifft, so wurden zahlreiche Studien durchgeführt und es gibt umfassende praktische Erfahrungen – sowohl positive als auch negative. Dennoch bestehen weiterhin Herausforderungen und Schwachstellen, gegen die noch anzugehen ist.
Damit ist der thematische Teil des Artikels abgeschlossen. Lassen Sie uns nun zu den Fragen übergehen, die häufig auftauchen.
Häufig gestellte Fragen
— Wenn alle Parteien des bestehenden Smart Contracts die Bedingungen ändern möchten, können sie diesen Smart Contract dann mittels Multisignatur widerrufen und anschließend einen neuen Smart Contract mit aktualisierten Ausführungsbedingungen erstellen?
Hier wird die Antwort zwiespältig sein. Warum? Weil einerseits der Smart Contract einmal festgelegt wird und keine Änderungen mehr zulässt, andererseits kann er jedoch eine im Voraus festgelegte Logik enthalten, die vollständige oder teilweise Änderungen bestimmter Bedingungen vorsieht. Das bedeutet, wenn Sie etwas in Ihrem Smart Contract ändern möchten, müssen Sie im Voraus die Bedingungen festlegen, unter denen Sie diese Änderungen durchführen können. Nur auf diese vorausschauende Weise kann die Aktualisierung des Vertrags organisiert werden. Aber auch hier kann es zu Problemen kommen: Fehler können zu einer entsprechenden Schwachstelle führen. Daher müssen solche Aspekte sehr detailliert und sorgfältig entworfen und getestet werden.
— Und was passiert, wenn der Mediator sich mit einer der beteiligten Parteien – Escrow oder Smart Contract – verschwört? Ist der Mediator im Smart Contract erforderlich?
Ein Treuhänder ist im Smart Contract nicht zwingend erforderlich. Er kann fehlen. Wenn der Treuhänder jedoch in einem Escrow-Fall mit einer der Parteien kolludiert, verliert dieses Modell schnell an Wert. Daher werden Treuhänder so ausgewählt, dass ihnen alle beteiligten Parteien gleichzeitig vertrauen. Folglich werden Sie einfach keine Coins auf eine Multisignatur-Adresse mit einem Treuhänder überweisen, dem Sie nicht vertrauen.
— Ist es möglich, mit einer einzigen Ethereum-Transaktion verschiedene Token von Ihrer Adresse auf unterschiedliche Zieladressen, beispielsweise Exchange-Adressen, wo diese Token gehandelt werden, zu übertragen?
Das ist eine gute Frage und betrifft das Transaktionsmodell von Ethereum und dessen Unterschiede zum Bitcoin-Modell. Diese Unterschiede sind grundlegend. Im Transaktionsmodell von Ethereum übertragen Sie Münzen lediglich von einer Adresse zur anderen, ohne Rückgeld – einfach der konkrete Betrag, den Sie angegeben haben. Anders gesagt, es handelt sich nicht um ein Modell ungenutzter Ausgaben (UTXO), sondern um ein Kontenmodell mit entsprechenden Salden. Theoretisch könnte man mit einer einzigen Transaktion mehrere verschiedene Token senden, wenn man einen cleveren Smart Contract erstellt, aber man müsste dennoch viele Transaktionen durchführen, den Contract erstellen, dann die Token und Münzen übergeben und schließlich die entsprechende Methode aufrufen. Dies erfordert Aufwand und Zeit, weshalb es in der Praxis nicht so funktioniert und alle Zahlungen in Ethereum als separate Transaktionen erfolgen.
— Einer der Mythen über die Ethereum-Plattform ist, dass es unmöglich sei, Bedingungen zu beschreiben, die von Daten einer externen Internetressource abhängen. Wie steht es damit?
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 Informationen, die er von vertrauenswürdigen Quellen erhält, als wahr. Um die Zuverlässigkeit zu erhöhen, wählt man einfach eine größere Gruppe von Orakeln aus und minimiert das Risiko einer Kollusion. Der Vertrag kann Informationen von Orakeln ignorieren, die im Widerspruch zur Mehrheitsmeinung stehen.
Dieses Thema wird in einer der Lektionen des Online-Kurses über Blockchain behandelt – “”.
Quelle: habr.com
