Die Ontology Wasm-Technologie senkt die Kosten für die Migration von dApp-Smart-Verträgen mit komplexer Geschäftslogik auf die Blockchain und bereichert somit erheblich das dApp-Ökosystem.
Derzeit unterstützt die Entwicklung sowohl in Rust als auch in C++. Rust bietet eine bessere Unterstützung für Wasm, und der generierte Bytecode ist einfacher, was die Kosten für Vertragsaufrufe weiter senken kann. Also, wie verwendet man Rust zur Entwicklung eines Vertrags im Ontology-Netzwerk?
Entwicklung eines WASM-Vertrags mit Rust
Vertragserstellung
ist ein nützliches Werkzeug zur Erstellung von Projekten und zur Paketverwaltung bei der Entwicklung von Programmen in Rust, das Entwicklern hilft, die Interaktion von Code und Bibliotheken besser zu organisieren. Um einen neuen Ontology Wasm-Vertrag zu erstellen, führen Sie einfach den folgenden Befehl aus:
Die Projektstruktur, die sie generiert:
Die Datei Cargo.toml wird verwendet, um die grundlegenden Informationen des Projekts sowie die Informationen über abhängige Bibliotheken zu konfigurieren. Der Abschnitt [lib] in der Datei muss auf crate-type = ["cdylib"] gesetzt werden. Die Datei lib.rs dient dazu, den Logikcode des Vertrags zu schreiben. Darüber hinaus müssen Sie die Abhängigkeitsparameter im Abschnitt [dependencies] der Konfigurationsdatei Cargo.toml hinzufügen:
Mit dieser Abhängigkeit können Entwickler Schnittstellen aufrufen, die mit der Ontology-Blockchain interagieren, sowie Werkzeuge wie den Serialisierungsparameter.
Eingabefunktion des Vertrags
Jedes Programm hat eine Eingabefunktion, wie beispielsweise die main-Funktion, die wir normalerweise sehen, aber ein Vertrag hat keine main-Funktion. Wenn ein Wasm-Vertrag mit Rust entwickelt wird, wird die Funktion invoke standardmäßig als Eingabefunktion zur Verwendung des Vertrags verwendet. Der Funktionsname in Rust ist beim Kompilieren des Rust-Quellcodes in Bytecode, der von der virtuellen Maschine ausgeführt werden kann, nicht klar. Um den Compiler davon abzuhalten, überflüssigen Code zu generieren und die Größe des Vertrags zu reduzieren, fügt die Funktion invoke die Annotation #[no_mangle] hinzu.
Wie erhält die Funktion invoke Parameter zur Ausführung einer Transaktion?
Die Bibliothek ontio_std bietet die Funktion runtime::input(), um Parameter für die Ausführung einer Transaktion zu erhalten. Entwickler können ZeroCopySource verwenden, um das erhaltene Byte-Array zu deserialisieren. Das erste gelesene Byte-Array ist der Name der invoke-Methode, gefolgt von den Methodenparametern.
Wie wird das Ergebnis der Vertragsausführung zurückgegeben?
Die Funktion runtime::ret, die von der Bibliothek ontio_std bereitgestellt wird, gibt das Ergebnis der Methodenausführung zurück.
Die vollständige invoke-Funktion sieht wie folgt aus:
Serialisierung und Deserialisierung von Vertragsdaten
Bei der Entwicklung von Verträgen stoßen Entwickler immer wieder auf Probleme mit der Serialisierung und Deserialisierung, insbesondere wie man einen struct-Datentyp in einer Datenbank speichert und wie man ein aus der Datenbank gelesenes Byte-Array deserialisiert, um den struct-Datentyp zu erhalten.
Die Bibliothek ontio_std bietet Decoder- und Encoder-Schnittstellen für die Serialisierung und Deserialisierung von Daten. Die Felder der Struktur struct implementieren ebenfalls Decoder- und Encoder-Schnittstellen, sodass die Struktur serialisiert und deserialisiert werden kann. Instanzen der Klasse Sink sind erforderlich, wenn verschiedene Datentypen serialisiert werden. Eine Instanz der Klasse Sink hat ein set-typ Feld buf, das die Daten vom Typ Byte speichert, während alle serialisierten Daten in buf gespeichert werden.
Für Daten mit fester Länge (zum Beispiel: byte, u16, u32, u64 usw.) werden die Daten direkt in ein Byte-Array umgewandelt und dann in buf gespeichert; für Daten mit variabler Länge muss zunächst die Länge serialisiert und dann Ddata gespeichert werden (zum Beispiel Ganzzahlen ohne Vorzeichen unbekannter Größe, einschließlich u16, u32 oder u64 usw.).
Die Deserialisierung ist das direkte Gegenstück zur Serialisierung. Für jede Methode der Serialisierung gibt es eine entsprechende Methode der Deserialisierung. Die Deserialisierung erfordert die Verwendung von Instanzen der Klasse Source. Diese Instanz der Klasse hat zwei Felder: buf und pos. Buf dient zur Speicherung der Daten, die deserialisiert werden sollen, während pos die aktuelle Leseposition speichert. Wenn ein bestimmter Datentyp gelesen wird und dessen Länge bekannt ist, können Sie ihn direkt lesen. Bei Daten unbekannter Länge wird zuerst die Länge gelesen, gefolgt vom Inhalt.
Zugriff und Aktualisierung von Daten in der Kette
Ontology-wasm-cdt-rust — kapselt die operationale Methode zur Bearbeitung von Daten in der Kette, die für Entwickler praktisch ist, um Operationen wie Hinzufügen, Löschen, Ändern und Abfragen von Daten in der Kette wie folgt zu implementieren:
- database::get(key) — wird verwendet, um Daten aus der Kette abzufragen, wobei key die Implementierung des Interfaces AsRef anfordert;
- database::put(key, value) — wird verwendet, um Daten im Netzwerk zu speichern. Key fordert die Implementierung des Interfaces AsRef an, während value die Implementierung des Interfaces Encoder anfragt;
- database::delete(key) — wird verwendet, um Daten aus der Blockchain zu löschen, während der Schlüssel die Implementierung des AsRef-Interfaces anfordert.
Vertragstest
Um die Methoden des Vertrags zu implementieren, benötigen wir Zugriff auf die Daten in der Blockchain und die entsprechende virtuelle Maschine, um den Bytecode des Vertrags auszuführen. Daher ist es in der Regel erforderlich, den Vertrag in der Blockchain bereitzustellen, um Tests durchzuführen. Doch diese Testmethode ist problematisch. Um Entwicklern das Testen von Verträgen zu erleichtern, bietet die Bibliothek ontio_std ein Mock-Modul für Tests an. Dieses Modul simuliert Daten in der Blockchain und erleichtert Entwicklern das Unit-Testing der Methoden im Vertrag. Konkrete Beispiele finden Sie .
Vertragsdebugging
console::debug(msg) gibt während des Debugging-Prozesses des Vertrags Debugging-Informationen aus. Die msg-Information wird im Logfile des Knotens erfasst. Ein Muss ist es, die Logging-Ebene beim Starten des lokalen Testknotens von Ontology auf Debugging zu setzen.
runtime::notify(msg) gibt während der Debugging-Phase des Vertrags die entsprechenden Debug-Informationen aus. Diese Methode speichert die bereitgestellten Informationen in der Blockchain und kann über die Methode getSmartCodeEvent aus der Blockchain abgerufen werden.
Der Artikel wurde von der Redaktion Hashrate & Shares speziell für OntologyRussia übersetzt.
Sind Sie Entwickler? Treten Sie unserer technischen Gemeinschaft auf . Außerdem schauen Sie in das auf unserer Website, wo Sie Entwicklerwerkzeuge, Dokumentationen und vieles mehr finden können.
Ontology
- /
- Telegram /
- /
Quelle: habr.com
