Leren Waves smart contracts te schrijven in RIDE en RIDE4DAPPS. Deel 1 (Multiplayer portemonnee)

Hallo allemaal!

Onlangs heeft Waves Labs aangekondigd een wedstrijd voor ontwikkelaars ter gelegenheid van de lancering van het testnet van de uitbreiding van de smart contracttaal RIDE voor gedecentraliseerde applicaties Ride4Dapps!

We hebben gekozen voor de DAO-casus, omdat Ventuary van plan is om een dApp te ontwikkelen met sociale functies: stemmen, fondsenwerving, en vertrouwelijk beheer, enz.
We begonnen met een eenvoudig voorbeeld in Q&A-sessies en in RIDE IDE — voorbeeld met een gezamenlijke portemonnee.

Laten we dit voorbeeld analyseren, de hypotheses testen en enkele eigenaardigheden bekijken:

Laten we Alice hebben — de dApp-eigenaar
Boob en Cooper — partners van Alice, medeoprichters van Alice-BC DAO
Neli — een ondernemer die financiering nodig heeft
Bank — de bank die tokens uitgeeft

Stap 1. Balansen initialiseren

Om tokens in het Waves-testnet te krijgen, moet een verzoek worden ingediend bij de faucet en het adres opgeven waarop de tokens moeten worden verzonden.
Het adres kan worden achterhaald in de IDE door de accountgegevens uit te vouwen.
We wijzen Bank 10 WAVES toe. Daarna controleren we of ze zijn aangekomen via de blokken- en transactie-explorer: explorer

Nu laten we tokens van de bank naar de andere deelnemers distribueren. (Opmerking: alle transacties in het Waves-netwerk zijn niet gratis, dus alle deelnemers moeten een minimale positieve balans hebben om transacties uit te voeren).

1 WAVES = 100000000 eenheden (wavelets), aangezien bedragen alleen gehele getallen kunnen zijn
0.01 WAVES (Transactiekosten) = 1000000

Bank -> [3 WAVES] -> Alice, via TransferTransaction (Type: 4).

We controleren of env.SEED, waarmee de transacties worden ondertekend, overeenkomt met onze Bank:


Als u geen overeenkomende seed-zinnen heeft, schakel dan over naar de tab Accounts en controleer het opnieuw.
Daarna maken we een transactie aan, kondigen deze aan en ondertekenen de overdracht van 3 WAVES naar Alice.
Gegevens van Alice kunnen ook worden achterhaald via de variabele env.accounts. De nummering begint bij 0, wat betekent dat Alice env.accounts[1] is.

broadcast(transfer({recipient:address(env.accounts[1]), amount: 300000000, fee: 1000000}))

Het resultaat kan ook worden bekeken in de explorer, de link naar deze zal onmiddellijk na de uitvoering worden geretourneerd transactie.

We verzekeren ons ervan dat het saldo van Alice is verhoogd met 3 WAVES, terwijl het saldo van de bank 10 — 3 — 0.01 = 0.699 blijft.

We sturen Boob en Cooper elk 3 WAVES, en Neli, Xena en Mark elk 0.2 WAVES op dezelfde manier.
(Opmerking: We hebben een fout gemaakt met één cijfer en hebben Neli 0.02 WAVES gestuurd. Wees voorzichtig!)

broadcast(transfer({recipient:address(env.accounts[4]), amount: 20000000, fee: 1000000}))

Na het aanvullen van de balansen van alle deelnemers zien we:

Stap 2. Aanmaken van een dApp-account

We hebben afgesproken dat de maker en eigenaar van de gedecentraliseerde applicatie Alice zal zijn.
Ga naar Accounts en stel haar in als SEED, en controleer of env.SEED overeenkomt met Alice.

Laten we proberen het eenvoudigste script (contract) op Alice's account te installeren.
Slimme contracten in Waves zijn predikaten die een bepaalde uitgaande transactie toestaan of verbieden onder bepaalde voorwaarden. In dit geval is die voorwaarde — ALWAYS. De contractcode — true. We roepen deploy() aan.

De vergoeding voor de setScript-transactie is 1400000/100000000 = 0.014 WAVES. Alice heeft nog 2.986 WAVES op haar saldo.

Laten we nu proberen een complexere logica van een slim contract op Alice's account te installeren, zoals beschreven in het voorbeeld

Ride4Dapps bevat nu 2 nieuwe typen annotaties:

1. @Callable(i) — accepteert als parameter i, gegevens over welk account de transactie heeft aangeroepen/ondertekend. De uitkomst van deze functie bepaalt de wijziging van de status van het dApp-account. Andere accounts kunnen transacties aanmaken en functies met deze annotatie uitvoeren en de status van het dApp-account wijzigen.
2. @Verifier(tx) — De verificateur van de transactie met de parameter tx van de transactie. Dit komt overeen met de logica van predikaten uit RIDE. In deze uitdrukking kan men verdere wijzigingen in de logica van slimme contracten op het dApp-account toestaan of verbieden.

Laten we maken dApp account als gemeenschappelijke portemonnee voor alle deelnemers.

Om te controleren welk contract momenteel actief is op het account, kun je in de blokkenverkenner de base64-code van het slimme contract kopiëren en deze met de decompiler herkennen (bijvoorbeeld)

We zorgen ervoor dat de logica van het slimme contract overeenkomt met onze verwachtingen.
Alice heeft nog 2.972 WAVES op haar saldo.

Deze dApp houdt bij hoeveel elke deelnemer bijdraagt aan het gezamenlijke fonds via het mechanisme data transaction — DataEntry(currentKey, newAmount), waarbij currentKey het account is dat de functie deposit aanroept en newAmount de waarde van het bijgevulde saldo is.

Boob en Cooper storten elk 1 WAVES op het dApp-account.

We maken een fout en de transactie gaat niet door. Hoewel we hebben gecontroleerd dat we de transactie namens Bob uitvoeren, hebben we ons vergist in de index en het account Bank opgegeven, waar geen slim contract is. Het is belangrijk om op te merken dat er geen kosten in rekening worden gebracht voor mislukte pogingen om transacties te initiëren. Worden niet in rekening gebracht! Alice heeft nog 2.972 WAVES op haar saldo. Bob heeft 3 WAVES.

Bob heeft 1 WAVES naar het dApp-account gestuurd.

broadcast(invokeScript({dappAddress: address(env.accounts[1]), call:{function:"deposit",args:[]}, payment: [{amount: 100000000, asset:null }]}))

Bob heeft nog 1.99 WAVES over. Dat betekent dat Bob 0.01 WAVES aan kosten heeft betaald.

Alice had 2.972 WAVES op haar saldo, en dat is nu 3.972 geworden. Op het account van Alice is ook een transactie geregistreerd, maar er zijn geen kosten van het dApp-account (Alice) afgeschreven.
Nadat Cooper ook het saldo van Alice had aangevuld, was ze 4.972 WAVES rijker.

Je kunt in de blockchain explorer in het tabblad Data zien hoeveel WAVES er in de gezamenlijke portemonnee toebehoren aan wie.

Cooper heeft besloten de 1 WAVES niet in de gezamenlijke portemonnee te laten staan en heeft besloten de helft van de middelen op te nemen. Hiervoor moet hij de functie withdraw aanroepen.

Echter, we hebben opnieuw een fout gemaakt, omdat de functie withdraw heel andere parameters heeft en een andere handtekening. Wanneer je smart contracts ontwerpt in RIDE4DAPPS, moet je op dit punt letten.

Cooper heeft 2.48 WAVES op zijn saldo. Dus 3 WAVES — 1 — 0.01, en vervolgens + 0.5 — 0.01. Bij elke aanroep van deposit en withdraw zijn de kosten 0.01 WAVES. Uiteindelijk zijn de records in de tabel van dApp-eigenaren als volgt veranderd.

Bob heeft ook besloten om een bedrag uit de gezamenlijke portemonnee op te nemen, maar maakte een fout en probeerde 1.5 WAVES te onttrekken.

In het smart contract was echter een controle voor zo'n situatie.

Xena is een oplichter, ze probeerde 1 WAVES van de gezamenlijke rekening op te nemen.

Ook zij heeft hierin niets bereikt.

In het volgende deel bespreken we de complexere aspecten met betrekking tot de onvolkomenheden van het Alice dApp-account.

Bron: habr.com