Усім прывітанне!
Зусім нядаўна 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 на агульным кашальку і вырашыў вывесці палову сродстваў. Для гэтага ен павінен выклікаць функцыю withdraw.
Аднак, мы зноў памыліліся, так як у функцыі withdraw зусім іншыя параметры, іншая сігнатура. Калі будзеце праектаваць смарт-кантракты на 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