مقدمه
بسیاری از برنامه هایی که از آن ها استفاده می کنیم مثل تلگرام ، اینیستاگرام یا واتس اپ و … به صورت متمرکز اداره می شوند . اطلاعات کاربران در این برنامه ها روی سرور اصلی ذخیره می شود . این گونه برنامه ها می توانند از اطلاعات کاربران در جهات مختلف استفاده کنند . با مطالبی که راجع به اپلیکیشن های متمرکز دانستیم به سراغ برنامه های غیر متمرکز یا همان (dapp) ها می رویم .
Dapp مخفف عبارت Decentralized Application می باشد و به معنای برنامه های غیر متمرکز است .
Dapp چیست؟
برنامه هایی در بستر بلاک چین ساخته می شوند که غیر متمرکزاند یعنی خارج از حوزه نظارت و کنترل یک مرجع واحد هستند ، به این برنامه ها dapp یا همان برنامه های غیر متمرکز می گویند . یکی از دلایلی که باعث شده تا بلاک چین یک سیستم غیر متمرکز باشد این است که اطلاعات بین همه ی اعضا به اشتراک گذاشته می شود و یک شخص خاص نمی تواند اطلاعات را تغییر دهد . برای انجام هر تراکنش در بستر بلاک چین باید یک گروه آنلاین آن را تایید کنند .
در ادامه به خصوصیات مهم برنامه های غیر متمرکز یا dapp ها می پردازیم .
خصوصیات dapp :
مهم ترین خصوصیت dapp ها غیر متمرکز بودن آن ها است یعنی در این گونه برنامه ها سرور مرکزی وجود ندارد و تمام فعالیت ها و تراکنش ها در دفتر مرکزی عمومی ذخیره می شود .
برنامه های غیر متمرکز حریم خصوصی کاربران را حفظ میکنند و فکر میکنم این مهم ترین مزیت dapp ها است .
برنامه های غیر متمرکز در جهت توسعه پذیری منعطف هستند .
Dapp ها برای کاربران شفاف هستند چون به صورت متن باز فعالیت می کنند و تمام فعالیت ها با جزئیات برای کاربران قابل مشاهده است . در صورت لزوم کاربران با شرکت در نظر سنجی در تغییرات برنامه شریک هستند و تغییرات در دسترس کاربران می باشد .
کاربران باید پروتکلی را که گروه برنامه نویس برای تحقق درست برنامه می نویسند بپذیرند تا بتوانند از برنامه های غیر متمرکز استفاده کنند .
برنامه های غیر متمرکز امنیت بالایی دارند چون روی سیستم بلاک چین کسی نمی تواند آن ها را دستکاری کند .
برنامه های غیر متمرکز قابلیت این را دارند که به افرادی که امنیت و فعالیت بلاک چین را انجام می دهند پاداش دهد پس انگیزه کاربران را بالا می برد .
ساختار برنا مه های غیر متمرکز:
ساختار dapp ها مثل تمام برنامه های تحت وب دارای دو قسمت است : فرانت اند (FrontEnd) و بک اند (BackEnd)
- فرانت اند بخشی است که با کاربر ارتباط مستقیم دارد .برنامه های غیر متمرکز در قسمت فرانت اند تفاوت چندانی با برنامه های معمولی تحت وب ندارند اما بخش بک اند برنامه های غیر متمرکز متفاوت است . این بخش در این گونه برنامه ها در بستر بلک چین قرار دارد و عملیات خود را در آنجا انجام می دهد . تغییرات برنامه های غیر متمرکز برای کاربران آشکار است و با تایید اکثریت کاربران انجام می شود .
نمونه اپلیکیشن های غیر متمرکز
برنامه های غیر متمرکز تنوع زیادی دارند از جمله آنها می توان موارد زیر را نام برد : صرافی های غیر متمرکز ( دکس DEX-) ، تسهیلات استقراض و وام دهی با ارز دیجیتال ، بازار های پیش بینی ( prediction markets) ، پلتفرم های رسانه های اجتماعی – پلتفرم های بازی غیر متمرکز ، بازارچه های خرید و فروش دارایی های دیجیتال DEX ها از مهم ترین انواع برنامه های غیر متمرکز هستند .
مرورگر dapp
dapp های بسیار زیادی وجود دارند اما به روز بودن و نوآورانه بودن پروتکل ها بین ان ها رقابت ایجاد می کند . برای دسترسی به اپلیکیشن های غیر متمرکز مرورگرهایdapp ساخته شده اند تا بتوانید تمام اپلیکیشن های غیر متمرکز را در انجا ببینید و دانلود کنید ، نسخه های جدید را اپدیت کنید . همان طور که از اپ استور و گوگل پلی برای اپلیکیشن های متمرکز استفاده می کنید . مرور گرهای محبوب dapp عبارت اند از : ( Dapp Redar ) دپ ریدار ( Defi plus) ، دپ تراست والت
یونی سواپ (UniSwap) , پنکیک سواپ pancakSap )) , سوشی سواپ (SushiSwap) و تریدرجو(Trader Joe) از نمونه های دکس های محبوب هستند . شاید کنجکاو باشید که بازی های غیر متمرکز چیست ؟ این بازی ها هم از محبوب ترین انواع dapp ها هستند . پلتفرم های بازی غیر متمرکز کسب درآمد برای کاربران را فراهم می کند و چون مدل ذخیره سازی نا متمرکز در بستر بلاک چین است به طور قابل توجهی منصفانه می باشد .
نکاتی درباره استفاده از dapp
درست است که همگان می توانند از dapp ها استفاده کنند اما باید به نکاتی توجه داشته باشیم . به دلیل جدید بودن و نو پا بودن dapp ها خطر هک شدن و از دست دادن سرمایه وجود دارد چون هنوز مقررات کاملی درباره dapp ها وجود ندارد . اگر سرما یه تان را از دست دادید نهادی وجود ندارد تا بتوانید آن را پس بگیرید . هنگام سرمایه گذاری مراقب ضرر و زیان های جبران ناپذیر باشید و به این نکته توجه داشته باشید رمز ارزها پر نوسان است . مساله ای که در ارتباط با یک dapp باید در نظر بگیرید تراکم شبکه ، کیفیت رابط کاربری و قابلیتی که ان dapp برای استفاده دارد است .
گفتار پایانی
سعی کردیم در این مقاله dapp ها یا همان برنامه های غیر متمرکز ویژگی ، انواع و ساختار آن ها را بررسی کنیم . با تمام این اوصاف امید وار هستیم که این برنامه ها باعث پیشرفت زندگی انسان و بهبود فناوری در زندگی انسان ها شوند اما به طور قطع و یقین نمی نوان گفت اینده این فناوری چه خواهد شد .
قرارداد هوشمند و سالیدیتی
قراردادهای هوشمند بخش‌های کدی هستند که در یک شبکه بلاک چین اجرا می‌شوند و داده‌ها را ذخیره میکنند. بنابراین ساختاری است که هم شامل کدها و هم داده ها است. Solidity یک زبان برنامه نویسی است که ما را قادر می سازد قرارداد بنویسیم.
یک مثال ممکن است به شما در درک بهتر قراردادهای هوشمند کمک کند. من فکر می کنم همه ما پس از خرید آنلاین با روند حمل و نقل مشکلاتی داشته ایم. ما می توانیم تاریخ تحویل را در توضیحات محصول مشاهده کنیم. بنابراین ما با توجه به آن اطلاعات سفارش می دهیم. اما در اینجا ممکن است با دو مشکل نیز مواجه شویم. فروشندگان ممکن است سفارشات ما را دیر به شرکت های حمل و نقل بدهند. همچنین ممکن است سفارشات ما با تاخیر توسط شرکت های حمل و نقل تحویل داده شود. در این مواقع بازارها مسئول هستند. زیرا خریداران محصولات خود را از طریق بازارها خریداری می کنند. وقتی چنین تاخیرهایی اتفاق می افتد، باید بتوانیم سفارش را لغو کنیم. اما نمی توان در این زمینه به بازارها اعتماد کرد. این وضعیت باعث می شود به این فکر کنیم که چگونه می توانیم از فناوری برای ایجاد این اعتماد استفاده کنیم. قراردادهای هوشمند راه حل خوبی در اینجا ارائه می دهند. ما چنین فرآیندهای تجاری را بر اساس قراردادهای هوشمند می سازیم و آن قراردادها را به صورت شفاف ارائه می کنیم. به این ترتیب مطمئن می شویم که فرآیند دقیقا طبق قراردادها اجرا می شود. باید به یاد داشته باشید که قرارداد منتشر شده را نمی توان بعداً تغییر داد.
سپس، بیایید شروع به توسعه چنین قراردادی کنیم. این فرآیند شامل مراحل زیر خواهد بود.
مالک قرارداد (بازار) سفارش را در قرارداد می نویسد.
خریدار هزینه سفارش خود را پرداخت خواهد کرد.
اگر سفارش در تاریخ مشخص شده نرسد، خریدار می‌تواند سفارش را لغو کرده و پول خود را پس بگیرد.
آماده سازی محیط توسعه
بیایید Truffle را نصب کنیم. Truffle ما را قادر می سازد تا قراردادهای هوشمند را جمع آوری، آزمایش و منتشر کنیم. بنابراین یک محیط توسعه را فراهم می کند.
npm install -g truffle
ما اکنون در حال نصب Ganache برای ایجاد یک شبکه بلاک چین محلی در دستگاه خود هستیم. Ganache یک شبکه بلاک چین محلی ایجاد می کند که در پورت 7545 قابل دسترسی است. این شبکه شامل 10 حساب با موجودی 100ETH است. ما از آنها برای آزمایشات خود استفاده خواهیم کرد. برای نصب بر اساس سیستم عامل خود می توانید از لینک زیر استفاده کنید.
https://www.trufflesuite.com/ganache
ایجاد قرارداد هوشمند
بیایید خط فرمان زیر را اجرا کنیم.
cd order-dapp-sample
mkdir backend
cd backend
truffle init
code.
سه پوشه در دایرکتوری Application وجود دارد. اینها قراردادها، مهاجرت ها و آزمایش ها هستند. ما قراردادی به نام Orders.sol در دایرکتوری “contracts” ایجاد می کنیم.
ما یک مایگریشن به نام 2_deploy_contracts.js را در زیر پوشه migrations اضافه می کنیم.
ما یک تست به نام order.js را در زیر پوشه تست اضافه می کنیم.
ما قسمت شبکه را در فایل truffle-config.js ویرایش می کنیم.
توسعه توابع “Adding Order” و “Order Fetching” بازار شناسه سفارش، قیمت سفارش و تاریخ تحویل را روی قرارداد می نویسد. بنابراین، ساختاری به نام Order ایجاد می کنیم. شبیه ساختار سی شارپ است.
از آنجایی که هیچ نوع داده Guid در Solidity وجود ندارد، شناسه را به عنوان نوع رشته ذخیره می کنیم. در solidity، انواع داده وجود دارد که به ما اجازه می دهد داده های عددی را از uint8 تا uint256 ذخیره کنیم.
ما از نوع داده uint256 برای totalPrice استفاده می کنیم. Solidity نوع داده DateTime ندارد. ما باید آن را در قالب timestamp یونیکس ذخیره کنیم. بنابراین از نوع داده uint256 برای deliveryDate استفاده می کنیم.
همچنین createDate را برای تاریخ ایجاد سفارش، deliveredDate را برای تاریخ تحویل سفارش و وضعیت را برای وضعیت سفارش اضافه می‌کنیم.
وضعیت را به عنوان نوع enum ذخیره می کنیم. شبیه enum در سی شارپ است. اما ما نمی توانیم هیچ شماره ای را اختصاص دهیم.
یک متغیر نوع نگاشت به نام orders ایجاد می کنیم تا اطلاعات سفارش را ذخیره کنیم و سفارش را مطابق شناسه جستجو کنیم. مانند دیکشنری در سی شارپ است.
در بلاک چین، هر حساب یا قرارداد دارای آدرس 160 بیتی است. ما باید آدرس مالک قرارداد را ذخیره کنیم. به این ترتیب این آدرس را برای ایجاد سفارش مجاز می کنیم.
بنابراین فقط بازار می تواند سفارشات را اضافه کند.
از msg.sender به آدرس حساب دسترسی داریم. این اطلاعات را از تابع سازنده دریافت می کنیم و در متغیر نوع آدرس به نام مالک ذخیره می کنیم. در Solidity از نوع داده آدرس برای اطلاعات آدرس استفاده می شود.
تابع “افزودن” را اضافه می کنیم که اطلاعات سفارش را در اختیار ما قرار می دهد.
این اطلاعات را در متغیر سفارشات ذخیره می کنیم. به مجوز نیاز داریم فقط صاحب قرارداد باید بتواند این تابع را فراخوانی کند. به همین دلیل، یک اصلاح کننده به نام onlyOwner ایجاد می کنیم. در این اصلاح کننده، آدرس حسابی که تابع را فراخوانی می کند با آدرس حسابی که قرارداد را ایجاد می کند، مقایسه می کنیم.
اگر مطابقت نداشته باشد، خطای “فرستنده مجاز نیست” را می اندازیم. در نهایت این اصلاح کننده را به تابع “add” اضافه می کنیم.
می توانیم بسیاری از اصلاح کننده ها را در اینجا اضافه کنیم. این اصلاح کننده ها به صورت منظم اجرا می شوند و در صورت عدم وجود خطا، تابع اجرا می شود.
تابع “get” را اضافه می کنیم تا جزئیات سفارش را برگردانیم. این تابع شناسه سفارش را به عنوان پارامتر می گیرد. سفارش را بررسی می کنیم و اگر دستوری وجود نداشته باشد خطا می دهیم.
ما باید قراردادها را قبل از انتشار آزمایش کنیم، زیرا قراردادهای هوشمند پس از انتشار دوباره قابل ویرایش نیستند. به همین دلیل TDD مهم است. ما تست هایی را برای تابع “add” در orders.js زیر پوشه تست می نویسیم.
10 اکانت توسط Ganache با شروع تست تعریف می شود. ما می توانیم از پارامتر “accounts” در خط 3 به این حساب ها دسترسی داشته باشیم.
سه واحد در شبکه اتریوم به نام های اتر، گوئی و وی وجود دارد. اتر بزرگترین واحد است اما تمام تراکنش ها با کوچکترین واحد یعنی Wei انجام می شود. به همین دلیل در خط 8 2.5 اتر را به Wei تبدیل می کنیم.
قرارداد همیشه در حساب اول ایجاد می شود. در خط 16، حساب دوم را “از پارامتر” می دهیم. به این ترتیب انتظار خطا داریم.
ما برنامه Ganache را اجرا می کنیم و روی دکمه QuickStart Ethereum کلیک می کنیم تا شبکه بلاک چین محلی را فعال کنیم.
تست را با خط فرمان زیر اجرا می کنیم.
truffle test ./test/orders.js
توسعه عملکرد “پرداخت سفارش”
ما یک ساختار پرداخت ایجاد می کنیم تا اطلاعات پرداخت را ذخیره کنیم. شناسه سفارش، buyerAddress، payDate، و refundedDate را اضافه می کنیم.
آدرس خریدار را به عنوانpayable علامت گذاری می کنیم تا بتوانیم وجه را به آن آدرس بازپرداخت کنیم. متغیر «payments» را اضافه می کنیم.
بیایید یک رویداد پس از پرداخت منتشر کنیم. رویداد “OrderPaid” را ایجاد می کنیم. آرگومان های رویداد عبارتند از id، payAddress، payAmount و date.
تابع “payment” را برای دریافت پرداخت اضافه می کنیم. این تابع شناسه سفارش را به عنوان پارامتر می گیرد. این تابع می تواند پرداخت دریافت کند، اما تابع “add” نمی تواند. برای آن، کلمه کلیدی قابل پرداخت را اضافه می کنیم. ما بررسی می کنیم که آیا سفارش وجود دارد یا خیر. اگر نه، خطا می دهیم. اگر پرداخت قبلاً انجام شده باشد، خطا می دهیم. سپس بررسی می کنیم که آیا مبلغ پرداختی با قیمت سفارش مطابقت دارد یا خیر و در صورت عدم تطابق با خطا مواجه می شویم. ما به مبلغ پرداختی از msg.value دسترسی داریم.
وضعیت سفارش را به روز می کنیم و آن را به عنوان پرداخت شده تعریف می کنیم. ما آدرس حساب پرداخت و تاریخ پرداخت را ذخیره می کنیم. هنگامی که پرداختی توسط این تابع انجام می شود، مبلغ در قرارداد ذخیره می شود. در نهایت، رویداد “OrderPaid” را منتشر می کنیم.
block.timestamp زمان بلاک فعلی را بر حسب میلی ثانیه برمی گرداند.
msg.value مقدار وارد شده را هنگام اجرای تابع برمی گرداند.
msg.sender آدرس حسابی را که تابع را فراخوانی می کند برمی گرداند.
ما تست هایی را برای تابع “pay” در orders.js زیر پوشه تست می نویسیم.
روش پرداخت می تواند پرداخت را دریافت کند، زیرا به عنوان قابل پرداخت علامت گذاری شده است. در خطوط 16 و 27، ما 200 Wei را به پارامتر “value” می دهیم، بنابراین انتظار خطا داریم زیرا مقدار سفارش (2.5 اتر) با 200 Wei مطابقت ندارد.
ما به تازگی رویدادی را منتشر کرده‌ایم که پرداخت با موفقیت انجام شد. در خط 37 بررسی می کنیم که آیا رویداد منتشر شده است یا خیر.
تست را با خط فرمان زیر اجرا می کنیم.
truffle test ./test/orders.js
