Modul #3 Web 3.0 mit Waves

Modul #3 Einführung in Smart Contracts und Smart Accounts

Herzlich Willkommen zum 3. Modul des Online-Kurs “Mastering Web3 with Waves”. In diesem Modul sprechen wir über Smart Contracts, wie sie funktionieren und wie man sie zur Implementierung unserer dezentralen Web3-Anwendung — Coupon Bazaar — einsetzt.

3.1 Übersicht;

3.2 Einführung in Smart Contracts;

3.3 Smart Contracts in Waves und Smart Accounts;

3.4 Sicherheitsprobleme und Smart Accounts mit mehreren Signaturen;

3.5 Smart Accounts und dezentrale Anwendungen (dApps);

3.6 Praxis: “ Gutschein Basar”

Legen wir los!

Traditionelle Verträge stellen Vereinbarungen zwischen Teilnehmern (Parteien) dar, diese Vereinbarungen werden von einer offiziellen Stelle, einer Regierung oder eines dritten validiert und durchgesetzt. Drittanbieter sind wichtige Teilnehmer bei der Überprüfung der Vertragsbedingungen, der Umgebungsbedingungen und der Ereignisse, die die Vertragsabwicklung des Kontakts beeinflussen könnten.

Trotz ähnlicher Bedingungen sind Smart Contracts keine Verträge per Definition von “Vereinbarung zwischen Parteien”. Der Smart Contract ist ein Computer-Quellcode oder -Programm, das in einer verteilten Umgebung wie einem Blockchain-Netzwerk ausgeführt werden kann. Alle Operationen und Ausführungsergebnisse werden in einer Blockchain gespeichert.

In dieser Definition ist der Smart Contract kein Vertrag zwischen den Parteien, sondern ein Protokoll über die Zusammenarbeit zwischen den Nutzern, aber auch zwischen Nutzer und Computer oder sogar Computer und Computer gemäß den im Smart Contract Source Code beschriebenen Regeln.

Der Smart Contract ist ein Programmcode für den Computer. Es handelt sich um eine Reihe von Anweisungen, die verschiedene Prüfungen und Validierungen, Datenoperationen zum Lesen und Schreiben, Operationen mit digitalen Assets (wie Transfers, Ausgabe, Brennen, Einfrieren usw.) beinhalten. Denken Sie daran, dass die Haupttechnologie für Web3 die Blockchain oder allgemein DLT (Distributed Ledger Technology) ist. Smart Contracts werden auf Hunderten von Maschinen gleichzeitig ausgeführt. Aus diesem Grund haben Smart Contracts mehrere schöne Funktionen:

• Sie benötigen keinen Mittelsmann
• Sichere Speicherung von digitalen Assets
• Der Programmcode ist das Gesetz
• Backups standardmäßig
• Sie verhindern manuelle Fehler
• Zuverlässige Ausführung
• Autonome Ausführung

Einige von Ihnen werden vielleicht von Ricardian-Verträgen gehört — eine Innovation aus den 90er Jahren.

Es ist eine digitale Form von Traditionsverträgen. Der Ricardian-Vertrag besteht aus zwei Teilen: menschenlesbaren Begriffen und maschinenlesbaren Komponenten. Hier kommen digitale Signaturen und Betriebsautomatisierung zum Einsatz. Aber trotz der digitalen Natur sind Ricardian-Verträge keine intelligenten Verträge, sondern immer noch traditionelle Verträge. Sie haben die rechtliche Macht, aber intelligente Verträge nicht. Ricardian Smart Contracts sind die beste Kombination.

Verschiedene DLT-Plattformen haben unterschiedliche Ansätze für die Realisierung intelligenter Verträge.

Waves Smart Contracts werden durch zwei verschiedene Typen dargestellt: Smart Accounts und Smart Assets. Wir werden später in diesem Kurs intensiver auf Smart Assets eingehen.

Jedes Waves-Konto kann mit einem speziellen Konto-Skript in einen Smart-Account umgewandelt werden. Das Kontoskript ist ein Programmcode in der Sprache RIDE, der eine Reihe von Bedingungen für die Zulassung und Ablehnung verschiedener Arten von ausgehenden Transaktionen enthält.

Technisch gesehen besteht die Erstellung und Bereitstellung von Waves Smart Contract aus mehreren Phasen:

RIDE-Code, Kompilierung, Generierung der SetSkriptTransaktion, Validierung durch einen Knoten, UTX-Pool zwischen allen Knoten und dann Einfügen der Transaktion mit dem Skript in den neuen Block.

In einer genaueren Übersicht gibt es tatsächlich mehr Schritte:

• Die Waves IDE validiert RIDE-Code
• Der RIDE-Code wird in der Reihenfolge der Symbole im base64-Format kompiliert.
• Die SetScriptTransaktion wird verwendet, um den kompilierten Code an den Blockchain-Knoten zu senden.
• Deserialisierung und Syntaxprüfung, Namen und Variablen
• Kostenkalkulation, Typenprüfung und Prüfen der Signatur
• Nach der Prüfung und Validierung vom ersten Knoten aus geht die SetSkriptTransaktion in den UTX-Pool zwischen den Knoten.
• Alle anderen Knoten machen Deserialisierungs- und Kostenberechnungsschritte.
• Miner-Knoten machen Deserialisierungs- und Kostenberechnungsschritte, bevor neue Blockvalidierungen und das Einfügen in die Blockchain erfolgen.
• Nach Erhalt des neuen Blocks führen alle Knoten Deserialisierungs- und Kostenberechnungsschritte durch.
• Jetzt wird das Skript auf allen Knoten ausgeführt und validiert alle ausgehenden Transaktionen des Smart Account.

Das intelligente Skript erlaubt oder verweigert einige ausgehende Transaktionen, abhängig von bestimmten Bedingungen. Diese Logik hängt von mehreren Datenquellen ab: Kontodaten, Transaktionsdaten, Blockchain-Status und Daten die in der Blockchain gespeichert sind.

Worin besteht der Unterschied zwischen dem Standardkonto und dem Smart Account?

Das Standardkonto hat nur einen Unterzeichner, der mit seinem privaten Schlüssel und Seed alle ausgehenden Transaktionen signieren kann. Jeder andere Benutzer kann seine digitale Signatur nicht verwenden, um Transaktionen von Standardkonten zu signieren, die nicht zu diesem Benutzer gehören. Einfach ausgedrückt: Bob kann keine Transaktion von Alice’s Konto unterschreiben und umgekehrt.

Aber Alice kann ein Skript auf ihrem eigenen Konto einstellen, indem sie ein Smart Account vom Standardkonto aus erstellt. Um dies zu tun, sollte Alice zuerst die SetSkriptTransaktion signieren.

Wenn das Standardkonto zu einem Smart Account wird, kann jeder bestimmte ausgehende Transaktionen in Abhängigkeit von der Smart Script-Logik signieren.

Lassen Sie uns in diesem Zusammenhang über Sicherheitsprobleme sprechen!

Das Kontoskript muss die Bedingungen überprüfen, die Art der ausgehenden Transaktionen und die Benutzer, die diese Transaktionen signieren können, zulassen. Dies ist ein sehr kritischer Moment! Es ist der kritischste Ort für Sicherheitsschwachstellen.

Denken Sie daran: Wir bauen einen dezentralen Web3-Couponmarktplatz — “Coupon Bazaar”.

Die Nutzer suchen nach Rabatten für Waren und Dienstleistungen und können diese zu einem kleinen Preis auf dem Marktplatz kaufen.

Jeder Coupon — ist ein digitales Asset, welches einen speziellen Rabatt des Lieferanten darstellt.

“Coupon Bazaar” ist ein Marktplatz. Er bietet Matching, Zahlungsvorgänge und Lieferservice zwischen Lieferanten und Kunden an.

Funktionalität für Kunden:

• Gutschein finden
• Gutschein kaufen

Funktionalität für Lieferanten:

• Registrierung
• Hinzufügen/Entfernen/Aktualisieren von Elementen
• Kaufbestätigung

Um mit der dezentralen Datenspeicherung mit Hilfe von Datentransaktionen zu arbeiten, erlauben wir Datentransaktionen für Lieferanten und verweigern alle anderen Transaktionen mit Ausnahme von Set-Script-Transaktionen. Die SetSkriptTransaktion ist erforderlich, damit wir die intelligente Kontenlogik in Zukunft aktualisieren können. Bitte achten Sie auf die Schwachstelle: nun kann jeder Benutzer die ausgehende Transaktion signieren.

Jeder ist in der Lage, das Kontoskript auf diesem Konto zu ändern und danach alle Gelder abzuheben.

Um die SetScriptTransaktion nur für dApp-Besitzer zuzulassen, sollten wir die Funktion sigVerify verwenden. Mit dieser Funktion können wir überprüfen, ob die Signatur aus einer Reihe von Signaturen, den sogenannten Proofs (welche in jeder Transaktion enthalten sind), dem dApp-Besitzer gehört.

Wir können die Funktion sigVerify im Matcher innerhalb der verify()-Funktion verwenden. sigVerify gibt ein TRUE zurück, wenn falls die übergebene Signatur von dem privaten Schlüssel erstellt wurde, die zu dem öffentlichen Schlüssel passt, der ebenfalls als Paremter an die Methode übergeben wird und FALSE andernfalls.

Betrachten wir das klassische Beispiel der Nutzung von Smart Accounts zur Erhöhung der Sicherheit bei der Speicherung digitaler Assets — Multi-Signatur-Konten (Multi-Sig).

Unsere Lieferanten sind beispielsweise kleine Unternehmen, die aus mehreren Gründern oder Verwaltern bestehen (in unserem Fall drei). Um Geld vom Multisigkonto abzuheben, sind für die ausgehende Überweisungstransaktion mindestens zwei von drei Unterschriften erforderlich.

Dieser Multisig-Account schützt den Online-Shop auch vor Hacks, wenn der private Schlüssel oder Seed eines Besitzers kompromittiert oder gestohlen wurde.

Um ein Multi-Signatur-Konto mit mindestens zwei Signaturen zu implementieren, sollten wir öffentliche Schlüssel gültiger Kontounterzeichner deklarieren. Die Teilnehmer können die Transaktion in einer beliebigen Reihenfolge unterschreiben, daher sollten wir entsprechend alle möglichen Kombinationen überprüfen.

Um eine Transaktion mehrmals zu signieren, sollten wir die die Transaktion mehermals an die JavaScript Methode zum signieren von Transaktionen übergeben. Zum Beispiel in unserem Fall an die Methode die einfache Übertragungen.

Lassen Sie uns über dezentrale Anwendungen sprechen!

In unserer Web3-Anwendung sollte der Lieferant Käufe bestätigen. Mal sehen, wie man das automatisiert und welche Use-Cases man hierzu benötigt:

1. Lieferanten:

• Registrierung
• Hinzufügen/Entfernen/Aktualisieren von Elementen
• Kaufbestätigung

2. Kunden:

• Suche
• Kaufen

Mit Hilfe von Smart Contracts konnten dezentrale Web3-Anwendungen erstellt werden.

“Dezentrale Anwendungen (dApps) sind Anwendungen, die auf einem P2P-Netzwerk von Computern und nicht nur auf einem einzelnen Computer ausgeführt werden. dApps gibt es seit der Einführung von P2P-Netzwerken. Es handelt sich um eine Art von Softwareprogramm, welches so konzipiert ist, dass es im Internet in einer Weise existiert, die nicht von einer einzigen Einheit kontrolliert wird. Dezentrale Anwendungen müssen nicht unbedingt auf einem Blockchain-Netzwerk laufen. BitTorrent, Popcorn Time, BitMessage, Tor, sind allesamt traditionelle dApps, die in einem P2P-Netzwerk laufen, aber nicht in einer Blockchain (die eine bestimmte Art von P2P-Netzwerk darstellt).”

Für diesen Kurs definieren wir dApps wie folgt: dApps sind eine “blockchainfähige” Webseiten, bei der der Smart Contract die Verbindung zur Blockchain ermöglicht. Der einfachste Weg, dies zu verstehen, ist zu verstehen, wie traditionelle Websites wie unser “Coupon Bazaar” dApp funktionieren, integriert in die Waves Blockchain und die Waves Keeper Browser-Erweiterung.

Um Entwicklern einen dApp-Entwicklungsprozess zu erleichtern, bietet RIDE- Waves Smart Contract Language zwei Arten von Funktionen:

@Verifier und @Callable.

Wir sind bereits mit @Verifier vertraut.

@Callable-Funktionen können von Benutzern von außerhalb aufgerufen werden. Als Ergebnis der Ausführung können neue Informationen in den Datenspeicher der dApp gespeichert oder aktualisiert werden, in Form von Key-Value-Paaren und / oder Mittel können je nach dApp-Logik vom dApp-Guthaben an den Anrufer oder andere Adressen übertragen werden.

In unserem Fall sind dApp und Smart Account die gleiche Einheit.

Benutzer können @Calable-Funktionen aufrufen. Die entsprechend generierte Transaktion wird InvokeTransaktion genannt. Wir können einige Informationen über die Parameter der InvokeTransaktion-Parameter im Smart Contract Script verwenden, z.B. Zahlungsinformationen: Betrag und Währung (Token).

In Coupon Bazaar werden wir die Kauffunktion für Einkäufe von Kunden und die Gutscheinkaufsbestätigung des Lieferanten nutzen.

Der Preis für den Artikel sollte im dApp Key-Value-Pair gespeichert werden (Schlüssel: item_A_coupon_price). Wir können den Preis mit der getInteger() Funktion extrahieren.

Der Kunde sollte den genauen Betrag bezahlen, um den Gutschein zu kaufen, da sonst ein Smart Contract eine Ausnahme mit Fehlerbeschreibung erzeugt. Wie Sie sehen können, wird der Kauf nach Ausführung der Kauffunktion automatisch bestätigt.

Alle Datensätze werden im dApp Key-Value-Speicher gespeichert. Diese Daten wurden mit der WriteSet-Funktion geschrieben. Der Smart Contract kann diese Daten während der Ausführung lesen und neu schreiben.

Um die @Callable-Funktion “purchase()” aufzurufen, sollten wir eine neue Art von Transaktion und deren Wrapper in JavaScript verwenden “invokeScript()”.

Wir können alle Key-Value-Parameter im Args-Array und Zahlungsdetails definieren. Um festzulegen, welche Funktion ausgeführt wird, sollten wir den Namen der @Callable-Funktion angeben und eine öffentliche Adresse (oder einen Alias) für ein dApp-Konto für den Aufruf angeben.

Dies sind also grundlegende Aspekte von Smart Contracts und deren Umsetzung in Waves.

Wir wünschen Ihnen viel Erfolg bei der “Code Challenge”!

Viel Spaß!

Dieses Modul umfasste die folgenden Themen:

• Einführung in Smart Contracts
• Intelligente Verträge in Waves und Smart Accounts
• Sicherheitsprobleme und Smart Accounts mit mehreren Signaturen
• Smart Accounts und dezentrale Anwendungen (dApps)