🥇Hur skriver man ett smart kontrakt på WebAssembly i Ontology-nätverket? Del 1: Rust

Ontology Wasm-teknologin sänker kostnaden för att överföra smarta kontrakt för dApps med komplex affärslogik till blockchain, vilket på så sätt berikar dApp-ekosystemet avsevärt.

För närvarande Ontology Wasm stöder samtidigt utveckling på både Rust och C++. Rust ger bättre stöd för Wasm och den genererade bytekoden är enklare, vilket kan ytterligare sänka kostnaden för kontraktsanrop. Så, hur använder man Rust för att utveckla kontrakt i Ontology-nätverket?

Utveckling av WASM-kontrakt med Rust

Skapa kontrakt

Cargo är ett bra verktyg för projektuppbyggnad och paketledning vid utveckling av program med Rust, som hjälper utvecklare att bättre organisera interaktionen mellan kod och tredjepartsbibliotek. För att skapa ett nytt Ontology Wasm-kontrakt, kör helt enkelt följande kommando:

Projektstrukturen som den genererar:

Filen Cargo.toml används för att konfigurera grundläggande projektinformation och information om beroende bibliotek. Sektionen [lib] i filen måste sättas till värdet crate-type = [“cdylib”]. Filen lib.rs används för att skriva logiken i kontraktskoden. Dessutom måste du lägga till beroendeparameterar i sektionen [dependencies] i konfigurationsfilen Cargo.toml:

Med detta beroende kan utvecklare anropa gränssnitt som interagerar med Ontology-blockchainen samt verktyg som parameterserilisering.

Kontraktsinmatningsfunktion

Ett program har en inmatningsfunktion, som till exempel main-funktionen, som vi vanligtvis ser, men ett kontrakt har ingen main-funktion. När man utvecklar ett Wasm-kontrakt med Rust används invocefuktionen som standard som inmatningsfunktion för att använda kontraktet. Funktionsnamnet i Rust blir oklart vid kompilering av Rust-källkoden till bytekod som kan köras av en virtuell maskin. För att förhindra kompilatorn från att generera överflödig kod och minska storleken på kontraktet, lägger funktionen invoke till annoteringen #[no_mangle].

Hur får funktionen invoke parametrar för att utföra transaktionen?

Biblioteket ontio_std tillhandahåller funktionen runtime::input() för att hämta parametrar för transaktionsutförande. Utvecklare kan använda ZeroCopySource för att deserialisera den mottagna byte-arrayen. Den första lästa byte-arrayen är namnet på invoke-metoden, följt av metodens parametrar.

Hur returneras resultatet av kontraktsutförande?

Funktionen runtime::ret, som tillhandahålls av biblioteket ontio_std, returnerar resultatet av metodens utförande.

Den avslutade invoke-funktionen ser ut som följer:

Serialisering och deserialisering av kontraktsdata

Under utvecklingen av kontrakt stöter utvecklare alltid på problem med serialisering och deserialisering, specifikt hur man sparar struct-datatypen i databasen och hur man deserialiserar en byte-array som lästs från databasen för att få struct-datatypen.

Biblioteket ontio_std tillhandahåller gränssnitt för dekodare och kodare för serialisering och deserialisering av data. Fälten i struct-strukturen implementerar också gränssnitt för dekodare och kodare så att strukturen kan serialiseras och deserialiseras. Instanser av klassen Sink är nödvändiga när olika datatyper serialiseras. En instans av klassen Sink har ett set-typ fält buf som lagrar byte-typ data, och all serialiserad data lagras i buf.

För data med fast längd (t.ex.: byte, u16, u32, u64 osv.) transformeras data direkt till en byte-array och sparas sedan i buf; för data med ofast längd måste längden först serialiseras och sedan Ddata (t.ex. osignerade heltal av okänd storlek, inklusive u16, u32 eller u64 osv.).

Deserialisering är motsatsen. För varje serialiseringsmetod finns en motsvarande deserialiseringsmetod. Deserialisering kräver användning av instanser av klassen Source. Denna instans har två fält buf och pos. Buf används för att lagra de data som ska deserialiseras, och pos används för att lagra den aktuella läspositionen. När ett specifikt datatyp läses, om längden är känd, kan den läsas direkt; för data med okänd längd— läs först längden och sedan innehållet.

Åtkomst och uppdatering av data i kedjan

Ontology-wasm-cdt-rust — kapslar in driftsmetoden för att arbeta med data i kedjan, vilket är bekvämt för utvecklare att utföra operationer såsom att lägga till, ta bort, ändra och begära data i kedjan på följande sätt:

database::get(key) — används för att begära data från kedjan, och key begär implementeringen av gränssnittet AsRef;
database::put(key, value) — används för att lagra data i nätverket. Key begär utförandet av gränssnittet AsRef, och value begär implementeringen av gränssnittet Encoder;
database::delete(key) — används för att ta bort data från kedjan, och key begär implementeringen av gränssnittet AsRef.

Kontraktstestning

När kontraktsmetoder implementeras behöver vi tillgång till data i kedjan och vi behöver en motsvarande virtuell maskin för att exekvera kontraktets bytekod, så det är vanligtvis nödvändigt att distribuera kontraktet i kedjan för testning. Men denna testmetod är problematisk. För att underlätta testningen av kontrakt erbjuder ontio_std-biblioteket en mocking-modul för testning. Denna modul simulerar data i kedjan, vilket gör det lättare för utvecklare att enhetstesta metoder i kontraktet. Specifika exempel kan hittas här.

Kontraktsfelsökning

console::debug(msg) skriver ut debug-information under felsökning av kontraktet. Informationen msg kommer att registreras i nodens loggfil. En nödvändig förutsättning är att loggfilens nivå sätts till debug när den lokala testnoden för Ontology körs.

runtime::notify(msg) skriver ut relevant debug-information under felsökning av kontraktet. Denna metod kommer att spara den inskickade informationen i kedjan och kan begäras från kedjan med metoden getSmartCodeEvent.

Artikeln översattes av Hashrate&Shares speciellt för OntologyRussia. klicka

Är du utvecklare? Gå med i vårt tekniska samhälle på Discord. Dessutom, kolla in Utvecklarcentrum på vår webbplats, där du kan hitta utvecklarverktyg, dokumentation och mycket mer.