Всім привіт!
Зовсім недавно Waves Labs
Ми вибрали кейс DAO, оскільки
Ми почали роботу з простого прикладу в
Давайте розберемо цей приклад, перевіримо гіпотези і розглянемо деякі дивацтва:
Нехай у нас є Alice - dApp Owner
Boob і Cooper - партнери Alice, співзасновники Alice-BC DAO
Neli — власник бізнесу, якому потрібне фінансування
Bank - банк, що роздає токени
Етап 1. Ініціалізація балансів
Для того, що в тестовій мережі waves отримати токени, потрібно звернутися до
Адреса можна дізнатися в IDE, розкривши дані облікового запису.
Виділяємо Bank 10 WAVES. Після того перевіряємо, що вони надійшли через оглядач блоків і транзакцій:
Тепер давайте роздамо токени з банку решті учасників. (Notes: Усі транзакції в мережі waves не безкоштовні, тому необхідний мінімальний позитивний баланс для всіх учасників, щоб здійснювати транзакції).
1 WAVES = 100000000 одиниць (wavelets), тому що amounts можуть бути тільки integer
0.01 WAVES (Transaction Fee) = 1000000
Bank -> [3 WAVES] -> Alice, через TransferTransaction (Type: 4).
Перевіряємо, що env.SEED, від якого підписуються транзакції, відповідає нашому Bank:

Якщо у вас немає відповідності seed фраз, просто перейдіть до нього у вкладці Accounts і перевірте ще раз.
Після цього створюємо, анонсуємо та підписуємо транзакцію про передачу 3 WAVES Alice.
Дізнатися дані Аліси також можна через змінну env.accounts. Нумерація починається з 0, відповідно, Аліса це env.accounts[1].
broadcast(transfer({recipient:address(env.accounts[1]), amount: 300000000, fee: 1000000}))
Результат можна також спостерігати в браузері, посилання на нього нам повернеться відразу після виконання
Переконуємось, що баланс Alice поповнений на 3 WAVES, а на балансі банку залишилося 10 – 3 – 0.01 = 0.699.
Відправляємо Boob та Cooper по 3 WAVES, а Neli, Xena та Mark по 0.2 WAVES тим же способом.
(Notes: Ми припустилися помилки на один знак і відправили Neli 0.02 WAVES. Будьте уважні!)
broadcast(transfer({recipient:address(env.accounts[4]), amount: 20000000, fee: 1000000}))
Після поповнення балансів усіх учасників ми бачимо:
Етап 2. Створення облікового запису dApp
Ми домовилися, що творцем та оунером децентралізованої програми буде Alice.
У Accounts переходимо встановлюємо її, як SEED і перевіряємо env.SEED відповідає Alice.
Спробуємо встановити на обліковий запис Alice найпростіший скрипт (контракт) із можливих.
Смарт-контакти в Waves - це предикати, які забороняють або дозволяють виконатися якомусь типу вихідної транзакції за певних умов. У цьому випадку ця умова – ALWAYS. Код контракту – true. Викликаємо deploy().
Fee за setScript транзакцію 1400000/100000000 = 0.014 WAVES. У Аліси на балансі залишилося 2.986 WAVES.
Спробуємо зараз встановити на обліковий запис Alice складнішу логіку смарт-контракту, описану в
Ride4Dapps тепер включає 2 нових типи анотацій:
- @Callable(i) — приймає як параметр i дані про те, який акаунт викликав/підписав транзакцію. Саме результат цієї функції визначає зміну стану dApp облікового запису. Інші облікові записи можуть створювати транзакції та виконувати функції з цією анотацією та змінювати стан облікового запису dApp.
- @Verifier(tx) — Верифікатор транзакції із параметром tx транзакції. Відповідає логіки предикатів із RIDE. Саме в цьому виразі можна дозволити або заборонити подальші зміни логіки смарт-контрактів на обліковому записі dApp.
Давайте зробимо dApp обліковий запис як загальний гаманець для всіх учасників.
Щоб перевірити те, який зараз контракт активний на акаунті, можна в браузері блоків скопіювати base64 код смарт-контракту і розпізнати його через декомпілятор (
Переконуємось, що логіка смарт-контракту відповідає тому, що ми очікуємо.
У Аліси на балансі залишилося 2.972 WAVES.
Даний dApp веде облік того, скільки вносять кожен із учасників до загального фонду через механізм data transaction - DataEntry(currentKey, newAmount), де currentKey - це обліковий запис, який викликає функцію deposit, а newAmount - це значення поповненого балансу.
Boob та Cooper вносять свої депозити на dApp account по 1 WAVES.
Припустимося помилки і транзакція не проходить. Оскільки ми незважаючи на те, що переконалися в тому, що робимо транзакцію від імені Bob, помилилися в індексі і вказали обліковий запис Bank, на якому немає смарт-контракту. Тут варто наголосити на важливому моменті — за невдалі спроби ініціювати транзакції комісія. не знімається! У Аліси на балансі залишилося 2.972 WAVES. У Bob 3 WAVES.
Bob відправив 1 WAVES на dApp Account.
broadcast(invokeScript({dappAddress: address(env.accounts[1]), call:{function:"deposit",args:[]}, payment: [{amount: 100000000, asset:null }]}))
У Bob залишилося 1.99 WAVES. Тобто Bob заплатив 0.01 WAVES комісії
Аліса на балансі мала 2.972 WAVES, стала 3.972. На обліковому записі Alice також зареєстрована транзакція, проте з dApp Account (Alice) жодної комісії не було списано.
Після того, як Cooper також поповнив рахунок у Аліси, на балансі стало 4.972 WAVES.
Про те, кому скільки WAVES в загальному гаманці належить, можна дізнатися в браузері блоків у вкладці Data.
Cooper передумав залишати суму у 1 WAVES на загальному гаманці та вирішив вивести половину спорідненостей. Для цього він повинен викликати функцію звипадком.
Однак, ми знову помилилися, так як у функції звиведенням зовсім інші параметри, інша сигнатура. Коли проектуватимете смарт-контракти на RIDE4DAPPS слід звернути увагу на цей момент
У Cooper на балансі стало 2.48 WAVES. Відповідно 3 WAVES - 1 - 0.01, а потім + 0.5 - 0.01. Відповідно кожен виклик deposit і withdraw обходиться в 0.01 WAVES. У результаті, в таблиці власників dApps записи змінилися в такий спосіб.
Bob також вирішив вилучити деяку суму із загального гаманця, але помилився та спробував витягти 1.5 WAVES.
Проте у смарт-контракті була перевірка на таку ситуацію.
Xena - шахрайка, спробувала вивести 1 WAVES із загального рахунку.
У неї також нічого не вийшло.
У наступній частині розглянемо складніші моменти пов'язані з недосконалістю Alice dApp Account.
Джерело: habr.com