🥇Hoe schrijf je een slim contract in WebAssembly op het Ontology-netwerk? Deel 1: Rust

De Ontology Wasm-technologie verlaagt de kosten van het migreren van smart contracts van dApps met complexe zakelijke logica naar de blockchain, waardoor het ecosysteem van dApps aanzienlijk wordt verrijkt.

Momenteel Ontology Wasm ondersteunt tegelijkertijd ontwikkeling in zowel Rust als C++. Rust ondersteunt Wasm beter, en de gegenereerde bytecode is eenvoudiger, wat de kosten van contractaanroepen nog verder kan verlagen. Dus, hoe Rust te gebruiken voor contractontwikkeling in het Ontology-netwerk?

Ontwikkeling van WASM-contracten met Rust

Contractcreatie

Cargo is een goede tool voor projectcreatie en pakketbeheer bij de ontwikkeling van Rust-programma's, die ontwikkelaars helpt om de interactie tussen code en externe bibliotheken beter te organiseren. Om een nieuw Ontology Wasm-contract te maken, voert u eenvoudig de volgende opdracht uit:

De projectstructuur die het genereert:

Het Cargo.toml-bestand wordt gebruikt om basisinformatie over het project en informatie over afhankelijkheidbibliotheken in te stellen. De sectie [lib] in het bestand moet worden ingesteld op crate-type = ["cdylib"]. Het lib.rs-bestand wordt gebruikt voor het schrijven van de logica van het contract. Daarnaast moet u afhankelijkheidsparameters toevoegen aan de sectie [dependencies] van het Cargo.toml-configuratiebestand:

Met deze afhankelijkheid kunnen ontwikkelaars interfaces aanroepen die communiceren met de Ontology-blockchain, en tools zoals serializeerparameters.

De invoerfunctie van het contract

Elke programma heeft een invoerfunctie, zoals de main-functie die we vaak zien, maar een contract heeft geen main-functie. Bij het ontwikkelen van een Wasm-contract met Rust, wordt de invoke-functie standaard gebruikt als invoerfunctie voor het gebruik van het contract. De naam van de functie in Rust zal onduidelijk zijn bij het compileren van de broncode van Rust naar bytecode die kan worden uitgevoerd door de virtuele machine. Om de compiler te waarschuwen om overbodige code te genereren en de grootte van het contract te verkleinen, voegt de invoke-functie de annotatie #[no_mangle] toe.

Hoe ontvangt de functie invoke parameters om de transactie uit te voeren?

De ontio_std bibliotheek biedt de functie runtime::input() om parameters voor het uitvoeren van transacties te verkrijgen. Ontwikkelaars kunnen ZeroCopySource gebruiken voor het deserialiseren van de verkregen byte-array. De eerste gelezen byte-array is de naam van de invoke-methode, gevolgd door de parameters van de methode.

Hoe wordt het resultaat van de contractuitvoering teruggegeven?

De functie runtime::ret die door de ontio_std bibliotheek wordt aangeboden, geeft het resultaat van de methode-uitvoering terug.

De voltooide invoke-functie ziet er als volgt uit:

Serialisatie en deserialisatie van contractgegevens

Bij het ontwikkelen van contracten stuiten ontwikkelaars altijd op problemen met serialisatie en deserialisatie, met name hoe een struct-type gegevens in de database op te slaan en hoe een byte-array die uit de database is gelezen, te deserialiseren om een struct-type gegevens te verkrijgen.

De ontio_std bibliotheek biedt decoder- en encoderinterfaces voor het serialiseren en deserialiseren van gegevens. De velden van de struct implementeren ook decoder- en encoderinterfaces, zodat de struct geserialiseerd en gedeserializeerd kan worden. Instanties van de Sink-klasse zijn nodig bij het serialiseren van verschillende datatypes. Een instantie van de Sink-klasse heeft een set-type veld buf dat byte-gegevens opslaat, terwijl alle geserialiseerde gegevens in buf worden opgeslagen.

Voor gegevens met een vaste lengte (bijvoorbeeld: byte, u16, u32, u64, enz.) worden de gegevens rechtstreeks omgezet in een byte-array en vervolgens opgeslagen in buf; voor gegevens met een onbepaalde lengte moet eerst de lengte worden geserialiseerd en daarna de gegevens (bijvoorbeeld ongetekende gehele getallen van onbekende grootte, inclusief u16, u32 of u64, enz.).

Deserialisatie is het directe tegenovergestelde. Voor elke serialisatiemethode is er een overeenkomstige deserialisatiemethode. Deserialisatie vereist het gebruik van instanties van de Source-klasse. Deze instantie heeft twee velden, buf en pos. Buf wordt gebruikt om de gegevens op te slaan die gedeserialized moeten worden, en pos wordt gebruikt om de huidige leespositie op te slaan. Wanneer een specifiek datatype wordt gelezen, kun je het rechtstreeks lezen als je de lengte kent; voor gegevens met onbekende lengte moet je eerst de lengte lezen en dan de inhoud.

Toegang tot en bijwerken van gegevens in de keten

Ontology-wasm-cdt-rust — heeft de operationele methode voor het werken met gegevens in de keten ingekapseld, wat handig is voor ontwikkelaars om operaties uit te voeren zoals het toevoegen, verwijderen, wijzigen en opvragen van gegevens in de keten als volgt:

database::get(key) — wordt gebruikt om gegevens uit de keten op te vragen, en key vraagt om de implementatie van de interface AsRef;
database::put(key, value) — wordt gebruikt om gegevens in het netwerk op te slaan. Key vraagt om de uitvoering van de interface AsRef, en value vraagt om de implementatie van de interface Encoder;
database::delete(key) — wordt gebruikt om gegevens uit de keten te verwijderen, en key vraagt om de implementatie van de interface AsRef.

Contracttesten

Wanneer contractmethoden worden geïmplementeerd, hebben we toegang nodig tot de gegevens in de keten en hebben we een bijbehorende virtuele machine nodig om de bytecode van het contract uit te voeren, daarom is het doorgaans noodzakelijk om het contract in de keten uit te rollen voor testing. Maar deze testmethode is problematisch. Om het testen van contracten gemakkelijker te maken voor ontwikkelaars, biedt de bibliotheek ontio_std een mock-module voor het testen. Deze module simuleert gegevens in de keten, waardoor het voor ontwikkelaars eenvoudiger wordt om unit tests uit te voeren op methoden in het contract. Specifieke voorbeelden zijn te vinden hier.

Contractdebugging

console::debug(msg) geeft debug-informatie weer tijdens de debugging van het contract. De informatie msg zal in het logbestand van de node worden opgenomen. Een vereiste is dat het logniveau is ingesteld op debugmode wanneer de lokale testnode van Ontology draait.

runtime::notify(msg) geeft relevante debug-informatie weer tijdens de debugging van het contract. Deze methode zal de ingevoerde informatie in de keten opslaan en kan uit de keten worden opgevraagd met behulp van de methode getSmartCodeEvent.

Dit artikel is vertaald door de redactie van Hashrate&Shares speciaal voor OntologyRussia. klik

Bent u een ontwikkelaar? Sluit u aan bij onze technische gemeenschap op Discord. Bekijk ook ons Ontwikkelaarscentrum op onze website, waar u ontwikkelaarstools, documentatie en meer kunt vinden.