خوش آمدید!
اخیراً، آزمایشگاه امواج
ما مورد DAO را انتخاب کردیم زیرا
ما با یک مثال ساده شروع کردیم
بیایید به این مثال نگاه کنیم، فرضیه ها را آزمایش کنیم و به برخی موارد عجیب و غریب نگاه کنیم:
اجازه دهید آلیس - مالک dApp را داشته باشیم
بوب و کوپر شرکای آلیس و از بنیانگذاران Alice-BC DAO هستند
نلی یک صاحب کسب و کار است که نیاز به تامین مالی دارد
بانک - بانکی که توکن ها را توزیع می کند
مرحله 1. راه اندازی تعادل
برای دریافت توکن در شبکه تست امواج، باید تماس بگیرید
با باز کردن جزئیات حساب خود می توانید آدرس را در IDE پیدا کنید.
ما بانک 10 WAVES را برجسته می کنیم. سپس بررسی می کنیم که آنها از طریق مرورگر بلوک و تراکنش وارد شده اند:
حالا بیایید توکن ها را از بانک بین بقیه شرکت کنندگان توزیع کنیم. (نکته: تمام تراکنشهای شبکه امواج رایگان نیستند، بنابراین حداقل تراز مثبت برای همه شرکتکنندگان برای انجام معاملات لازم است).
1 WAVES = 100000000 واحد (موجک)، زیرا مقادیر فقط می توانند عدد صحیح باشند
0.01 WAVES (کارمزد معامله) = 1000000
بانک -> [3 WAVES] -> آلیس، از طریق TransferTransaction (نوع: 4).
بررسی میکنیم که env.SEED که تراکنشها از آن امضا میشوند با بانک ما مطابقت داشته باشد:

اگر یک عبارت اولیه منطبق ندارید، کافی است در تب Accounts به آن بروید و دوباره بررسی کنید.
پس از این، یک تراکنش برای انتقال 3 موج آلیس ایجاد، اعلام و امضا می کنیم.
همچنین می توانید داده های آلیس را از طریق متغیر env.accounts بیابید. شماره گذاری از 0 شروع می شود، بنابراین Alice env.accounts است[1].
broadcast(transfer({recipient:address(env.accounts[1]), amount: 300000000, fee: 1000000}))
نتیجه را می توان در مرورگر نیز مشاهده کرد، لینک آن بلافاصله پس از اجرا به ما بازگردانده می شود
ما مطمئن می شویم که موجودی آلیس با 3 موج پر می شود و موجودی بانک در 10 - 3 - 0.01 = 0.699 باقی می ماند.
ما هر کدام Boob و Cooper 3 WAVES و Neli، Xena و Mark هر کدام 0.2 WAVES را به همین ترتیب ارسال می کنیم.
(توجه: ما یک خطای یک کاراکتری انجام دادیم و Neli 0.02 WAVES را ارسال کردیم. مراقب باشید!)
broadcast(transfer({recipient:address(env.accounts[4]), amount: 20000000, fee: 1000000}))
پس از پر کردن موجودی همه شرکت کنندگان، می بینیم:
مرحله 2. یک حساب کاربری dApp ایجاد کنید
ما توافق کردیم که آلیس خالق و مالک برنامه غیرمتمرکز باشد.
به Accounts بروید، آن را به عنوان SEED تنظیم کنید و env.SEED matches Alice را بررسی کنید.
بیایید سعی کنیم ساده ترین اسکریپت (قرارداد) ممکن را روی حساب آلیس نصب کنیم.
مخاطبین هوشمند در Waves محمولاتی هستند که هر نوع تراکنش خروجی را تحت شرایط خاصی ممنوع یا اجازه می دهند. در این حالت، این شرط همیشه است. کد قرارداد درست است فراخوانی deploy().
کارمزد هر تراکنش setScript 1400000/100000000 = 0.014 WAVES. آلیس 2.986 موج در تعادلش باقی مانده است.
بیایید اکنون سعی کنیم منطق قرارداد هوشمند پیچیده تری را روی حساب آلیس نصب کنیم، که در توضیح داده شده است
Ride4Dapps اکنون شامل 2 نوع حاشیه نویسی جدید است:
- @Callable(i) - به عنوان پارامتر i، اطلاعات مربوط به اینکه کدام حساب تراکنش را فراخوانی/امضا کرده است، می گیرد. نتیجه این تابع است که تغییر در وضعیت حساب dApp را تعیین می کند. حسابهای دیگر میتوانند تراکنشها را ایجاد کنند و عملکردهایی را با این حاشیهنویسی اجرا کنند و وضعیت حساب dApp را تغییر دهند.
- @Verifier(tx) - تأیید کننده تراکنش با پارامتر تراکنش tx. با منطق محمول از RIDE مطابقت دارد. در این عبارت است که می توانید تغییرات بیشتر در منطق قراردادهای هوشمند را در حساب dApp مجاز یا ممنوع کنید.
بیایید انجام دهیم شیک حساب به عنوان یک کیف پول مشترک برای همه شرکت کنندگان.
برای بررسی اینکه کدام قرارداد در حال حاضر روی حساب شما فعال است، می توانید کد base64 قرارداد هوشمند را در بلاک اکسپلورر کپی کنید و با استفاده از یک دیکامپایلر آن را تشخیص دهید (
ما مطمئن می شویم که منطق قرارداد هوشمند با آنچه ما انتظار داریم مطابقت دارد.
آلیس 2.972 موج در تعادلش باقی مانده است.
این dApp میزان کمک هر شرکت کننده به صندوق مشترک را از طریق مکانیسمی پیگیری می کند تراکنش داده - Data Entry (currentKey، newAmount)، که در آن currentKey حسابی است که تابع سپرده را فراخوانی می کند و newAmount مقدار موجودی دوباره پر شده است.
Boob و Cooper سپرده های خود را با 1 WAVES به حساب dApp واریز می کنند.
ما اشتباه می کنیم و معامله انجام نمی شود. از آنجایی که علیرغم اینکه متقاعد شده بودیم از طرف باب تراکنش انجام می دهیم، در شاخص اشتباه کردیم و یک حساب بانکی را نشان دادیم که قرارداد هوشمند ندارد. شایان ذکر است در اینجا به یک نکته مهم توجه کنید - هزینه ای برای تلاش های ناموفق برای شروع معاملات وجود دارد قابل حذف نیست! آلیس 2.972 موج در تعادلش باقی مانده است. باب 3 موج دارد.
باب 1 WAVES به حساب dApp ارسال کرد.
broadcast(invokeScript({dappAddress: address(env.accounts[1]), call:{function:"deposit",args:[]}, payment: [{amount: 100000000, asset:null }]}))
باب 1.99 موج باقی مانده است. یعنی باب 0.01 کمیسیون WAVES پرداخت کرد
آلیس 2.972 موج در تراز خود داشت، اکنون 3.972 است. تراکنش نیز در حساب آلیس ثبت شد، اما هیچ کمیسیونی از حساب dApp (آلیس) دریافت نشد.
پس از اینکه کوپر نیز حساب را پر کرد، موجودی آلیس به 4.972 WAVES تبدیل شد.
میتوانید در تب Data در بلاک اکسپلورر متوجه شوید که چه کسی صاحب چند WAVES در کیف پول رایج است.
کوپر نظر خود را در مورد باقی گذاشتن مقدار 1 WAVES روی کیف پول عمومی تغییر داد و تصمیم گرفت نیمی از وابستگی را پس بگیرد. برای انجام این کار، او باید تابع برداشت را فراخوانی کند.
با این حال، ما دوباره اشتباه کردیم، زیرا تابع برداشت دارای پارامترهای کاملاً متفاوت و امضای متفاوتی است. هنگام طراحی قراردادهای هوشمند در RIDE4DAPPS باید به این نکته توجه کنید
کوپر اکنون 2.48 موج در ترازنامه خود دارد. بر این اساس، 3 موج - 1 - 0.01، و سپس + 0.5 - 0.01. بر این اساس، هر تماس برای واریز و برداشت 0.01 WAVES هزینه دارد. در نتیجه، ورودیهای جدول مالکان dApps به صورت زیر تغییر کردند.
باب همچنین تصمیم گرفت مقداری پول از کیف پول مشترک برداشت کند، اما اشتباه کرد و سعی کرد 1.5 WAVES را برداشت کند.
با این حال، قرارداد هوشمند چکی برای این وضعیت داشت.
Xena یک کلاهبردار است، او سعی کرد 1 WAVES را از کل حساب برداشت کند.
برای او هم درست نشد.
در قسمت بعدی به مسائل پیچیده تری مربوط به ناقص بودن حساب کاربری Alice dApp خواهیم پرداخت.
منبع: www.habr.com