چگونه از نابودی سرمایه در قراردادهای هوشمند جلوگیری کنیم؟ (بخش دوم)

در بخش اول این مجموعه ما درباره زبان برنامه‌‌نویسی سالیدیتی و مبانی قراردادهای هوشمند نکاتی را یاد گرفتیم و به برخی از هک‌‌ها و آسیب‌‌پذیری‌‌های اساسی در قراردادهای هوشمند که سبب از بین رفتن پول‌‌های زیادی شده، نگاهی انداختیم. در این مقاله این آشنایی را یک مرحله جلوتر می‌‌بریم و هک‌‌های اساسی و واقعی را بررسی می‌‌کنیم.

0 115

برای مطالعه بخش اول اینجا کلیک کنید.

مثال 1: هک Parity 1

  • TL;DR؛ یکی از آسیب‌‌پذیری‌‌هایی که در نسخه 1.5 پلاس کیف چندامضایی( Parity (Parity Multisig Wallet پیدا شد و به مهاجم اجازه داد بیش از 150 هزار اتر (بیش از 30 میلیون دلار در آن زمان و 105 میلیون دلار با ارزش فعلی، ETH/USD 700) را بدزدد!
  • گاوین وودز یکی از توسعه‌‌دهندگان اصلی سالیدیتی، مدیر فنی Parity بود. در واقع او کدی که ما می‌‌خواهیم بررسی کنیم را نوشت.
  • یکی از مسائلی که Parity برای کاربرانش فراهم کرد، چند امضایی بود. چند امضایی یک کیف با صاحبان M می‌‌باشد و برای انجام فعالیت با سرمایه‌‌ها، نیازمند N از M امضا (تایید) خواهد بود. Parity اساسا نگهبان‌‌ها را از بیرون وارد می‌‌کند.
  • یک هکر خطرناک می‌‌توانست کیف چند امضایی به خصوصی را هدف قرار دهد و میزانی که بالاتر ذکر شد را بدزدد. اگر این هکر جزو یک گروه سفید نبود، می‌‌توانست مبلغ بیشتری را هم سرقت کند. هکرهای سفید تمام کیف‌‌ها را خالی کردند تا هکرها خطرناک نتواند سرمایه بیشتری به جیب بزند. چند هفته بعد هکرهای سفید تمام سرمایه‌‌ای که کسب کرده بودند را بازگرداندند. هکرهای سفید به پول امروز، 264 میلیون دلار را نجات دادند!

حالا چه اتفاقی افتاده بود؟!

PARITY

Parity یک کتابخانه با عنوان WalletLibrary داشت. این کتابخانه در شبکه اتریوم به کار گرفته می‌‌شد و دوباره توسط قراردادهای هوشمند کیف‌‌های چند امضایی مورد استفاده قرار می‌‌گرفت تا افراد برای به کارگیری دوباره کتابخانه، هر بار مجبور به پرداخت gas باشند. این کتابخانه کیف، تعدیل‌‌کننده‌‌های خوبی شامل onlyOwner و onlyManyOwners داشت. نکته مهم این است که تمام این تعدیل‌‌کننده‌‌ها برای تعیین وضعیت متغیرها به کار می‌‌روند تا ببینند چه کسی صاحب است و چه تعداد تاییدیه وجود دارد و موارد دیگر. به این دو تصویر پایین نگاه کنید.

PARITY

PARITY

سپس این کاربرد جذاب و مشکوک با عنوان initWallet را داشتیم که برای آغاز کیف‌‌ها در تولیدکننده به کار می‌‌رفت. بحث درباره این کاربرد در واقع درباره این است که نیاز صاحبان، بیانگر تعداد نیازهای صاحبان برای تایید تراکنش می‌‌باشد. این به چه معنا است؟! این کاربرد هیچ شفافیتی ندارد!

PARITY

صبر کنید، اما شاید initDayLimit یا initMultiOwned نوعی محافظت یا تعدیل‌‌کننده داشته باشد؟

PARITY

PARITY

خیر، آن‌‌ها حتی تعریف شفافیت را هم ندارند! بنابراین initWallet می‌‌تواند توسط هر کسی فراخوانده شود!!!

اما صبر کنید… تا به اینجا ما WalletLibrary را بررسی کرده‌‌ایم. این کتابخانه به وسیله قرارداد کیف مورد استفاده قرار می‌‌گیرد اما در واقع بخشی از آن نیست. بنابراین اگر قرارداد کیف بدون ایراد باشد، این مسئله هم مشکلی نخواهد داشت؟ بیایید به قرارداد کیف نگاهی بیاندازیم.

PARITY

همانطور که در تصویر قابل مشاهده است، درون کیف ما یک متغیر کتابخانه کیف و delegateCalls را داریم.

جدا از این موضوع: delegateCalls پارامترهایی که داده‌‌های msg، نام‌‌های عملکرد و params رمزگذاری‌‌شده را قبول می‌‌کند.

این دقیقا همان اتفاقی است که افتاده است.

با تمرکز بر عملکرد عقب‌‌نشینی با یک تعدیل‌‌کننده قابل‌‌پرداخت، ما می‌‌بینیم که این مسئله عمومی است. می‌‌توانیم بفهمیم که 3 تماس محوله بالا، همگی روش‌‌های عمومی هستند! این مسئله منطقی به نظر می‌‌رسد، زیرا ما می‌‌خواهیم همه بتوانند با آن تماس بگیرند (آن را فرا بخوانند). اما از آنجایی که باقی عملکردها هم عمومی بودند، مهاجم می‌‌توانست delegateCall را همراه با داده‌‌های رمزگذاری‌‌شده‌‌ای که بیانگر نام آغازین کیف، داده‌‌ها و پارامتر‌‌های مورد انتظار می‌‌باشد، را درخواست کند و خودش را به عنوان صاحب تغییر دهد! این دقیقا همان اتفاقی است که افتاده. مهاجم از این وضعیت استفاده کرده و به سادگی متغیر وضعیت m_owners قرارداد را به فهرستی از آدرس‌‌ها تغییر داده و برای اجرای تراکنش‌‌ها، به یک تاییدیه نیاز داشته‌‌است.

Mitigation‌‌

  • پیچیدگی یک آسیب‌‌پذیری است. ساده گرفتن همه چیز هم احمقانه خواهد بود. خوش‌‌بینی بیش از حد و پیچیدگی ریشه تمام حرکات شیطانی است!
  • همیشه شفافیت را به طور واضح تعریف کنید.
  • منطق سازنده را به درون قرارداد کتابخانه وارد نکنید. از خوش‌‌بینی زودهنگام هم دوری کنید!
  • از delegateCall به عنوان یک مکانیسم تماما رو به جلو استفاده نکنید.

Mitigation‌‌: فیکس کردن توسعه‌‌دهندگان Parity

توسعه‌‌دهندگان Parity دو کار انجام دادند.

1- اعلام کردند که initDayLimit و initMultiowned داخلی است.

2- یک تعدیل‌‌کننده با عنوان فقط شروع‌‌نشده (only_uninitialiszed ) اضافه کردند که می‌‌گفت من از قبل صاحبان را دارم و سپس آن را برعکس کردند. آن‌‌ها این تعدیل‌‌کننده را به initWallet اضافه کردند تا نتواند دو بار فراخوانده شود. خوب به نظر می‌‌رسد، اما هنوز هم باگ بسیار بزرگی دارد! به این مسئله بعدا خواهیم پرداخت!

اینجا لینکی برای پچ اصلاح‌‌کننده این هک وجود دارد. بخش کامنت‌‌ها بسیار جذاب است!

مثال 2: روبیکسی

  • روبیکسی (Rubixi) قراردادی است که به‌‌کارگیری آن یادآور طرح‌‌های هرمی می‌‌باشد (اگرچه طرح هرمی نیست!)
  • سرمایه‌‌گذاران می‌‌توانند سپرده‌‌گذاری کنند.
  • صاحب می‌‌توانند تمام سرمایه‌‌ها را جمع‌‌آوری کند.
  • اگر افراد بیشتری را وارد قرارداد هوشمند کنید، بخشی از کارمزد آن‌‌ها را دریافت می‌‌کنید.

Rubixi

به عضوی خالق می‌‌گویند که در سازنده آغاز شده‌‌باشد. ما تعدیل‌‌کننده onlyOwner را داریم که فقط در صورتی کد را اجرا می‌‌کند که شما صاحب مناسب و حقیقی آن باشید. به علاوه ما راه‌‌هایی برای جمع‌‌آوری سرمایه‌‌ها بر اساس این تعدیل‌‌کننده داریم.

پس مشکل اینجا کجاست؟!

نام اصلی قرارداد و سازنده آن DynamicPyramid بود.

Rubixi

سازندگان تغییری در قلب ماجر ایجاد کردند و تصمیم گرفتند که شاید مفهومی از کلمه هرم به ذهن برسد که چندان بازاری نباشد. آن‌‌ها برای همین نام را به روبیکسی تغییر دادند و یادشان رفت که نام روش سازنده را هم تغییر دهند. از آنجایی که عملکرد DynamicPyramid عمومی بود، همه می‌‌توانستند آن را فرابخوانند و خود را سازنده قرارداد بنامند. قراردادی وجود داشت که در آن 100 اتر گم شد و در یک قرارداد دیگر هم ~0.1 اتر از بین رفت.

Mitigation‌‌

  • خوب، برای تازه‌‌کاران، سعی کنید که عملکردها را با نام اشتباه ثبت نکنید…
  • هوشیار بمانید! کلاهبرداران بهتر و بهتر می‌‌شوند.
  • با شروع از 0.4.22 می‌‌توانید از روش سازنده ایمن استفاده کنید. این به آن معنا است که می‌‌توانید چنین کاری انجام دهید.

Rubixi

مثال 3: بانک، قرارداد هوشمند (نفوذ مجدد)

Bank

ما قرارداد هوشمند‌‌ی با نام بانک داریم. هر کاربر ترازهایی دارد و کاربران می‌‌توانند سرمایه‌‌ها را سپرده‌‌گذاری کنند که فورا وضعیت متغیر را با تعداد سرمایه‌‌های موجود، به روز خواهد کرد. ما می‌‌توانیم از عملکرد برداشت استفاده کنیم تا سرمایه‌‌ها را خارج کنیم و سپس این سرمایه‌‌ها به ما ارسال می‌‌شوند.

مشکل کجاست؟

ابتدا باید توجه کرد که دفاع یک درخواست همزمان ممانعتی است. بنابراین تراز تا هنگام تکمیل وضعیت دفاع، به روز رسانی نخواهد شد.

Bank

این مسئله در صورتی به خوبی عمل می‌‌کند که نهاد سپرده‌‌گذاری یک کاربر باشد، اما اگر شرایط برای یک قرارداد هوشمند باشد چه اتفاقی خواهد افتاد؟! اگر نهادی که سرمایه‌‌ها را سپرده‌‌گذاری می‌‌کند، یک قرارداد هوشمند و نه یک کاربر باشد، سپس ارسال این سرمایه‌‌ها به قرارداد هوشمند، یک عملکرد عقب‌‌نشینی قابل پرداخت را آغاز خواهد کرد (چه وجود داشته باشد و چه دچار خطا شده باشد). عملکرد عقب‌‌نشینی به عقب و به سوی بانک باز خواهد گشت و پیش از تکمیل تراکنش اصلی، یک برداشت دیگر هم انجام می‌‌دهد. قرارداد بانک ضد این موضوع عمل و تراز را به روز رسانی می‌‌کند اما این مسئله فقط بعد از حمله بالقوه مهاجم و انجام 2 برداشت او صورت می‌‌گیرد. به این نوع حمله (باگ؟) نفوذ مجدد می‌‌گویند.

بیایید به مثالی درباره قرارداد هوشمند مخربی که به آن دزد (Robber ) می‌‌گویند، نگاهی بیاندازیم. این قرارداد با یک باگ نفوذ مجدد به قرارداد هوشمند بانک نفوذ می‌‌کند.

Bank

برای هر قرارداد می‌‌توانیم این کار را فقط 2 بار انجام دهیم. اما اگر عملی شود می‌‌توانیم قراردادهای هوشمند بسیار زیادی به کار بگیریم و این کار را به طور مرتبط تا هنگامی که بانک را خالی کنیم، انجام دهیم!

  • Mitigation‌‌ 1: الگوی بررسی تعاملات تغییرات
  • بررسی‌‌هایی انجام دهید (چه کسی عملکرد را فراخوانده، چه بحث‌‌هایی وجود دارد، آیا اتر کافی ارسال کرده‌‌اند، آیا فرد توکن دارد و غیره).
  • اگر تمام بررسی‌‌ها درست بود، تاثیرات روی متغیرهای وضعیت قرارداد فعلی را باید انجام داد.
  • در نهایت تمام تعاملات با دیگر حساب‌‌ها یا قرارداد‌‌ها را انجام دهید. فقط برای واضح‌‌تر کردن این مثال، این مسئله هنگامی رخ می‌‌دهد که قرارداد ما با شکست مواجه شود. در قضیه دزدی قرارداد هوشمند، همه چیز پیش از تکمیل تاثیر روی تمام متغیرها صورت گرفت.

با استفاده از این الگو می‌‌توانیم مطمئن شویم که آیا مشکل نفوذ مجدد داریم یا نه و این بررسی با خطا مواجه خواهد شد. بنابراین پس از این الگو، اصلاح قراردادهای بانک ما روی این متغیرهای وضعیت تاثیر خواهد گذاشت. در این حالت، تراز و سپس فراخواندن قرارداد هوشمند یا کاربر:

Bank

Mitigation‌‌ 2: از ()()call.value دوری کنید

در اتریوم ما 3 راه برای تعامل با قراردادهای هوشمند داریم. هنگام ارسال اتر، باید از خرید و فروش نسبی بین استفاده از آن‌‌ها آگاه باشیم:

1- ()address.call.value : اتر فراهم‌‌شده را ارسال خواهد کرد و کد اجرا را با توجه به gasهای در دسترس آغاز می‌‌کند. بنابراین در مثال دزد و بانک اگر کاربر یا قرارداد هوشمند gas کافی ارسال کند، می‌‌تواند اجرای نفوذ مجدد را تکمیل کند.

2- ()address.send : اتر فراهم شده را ارسال خواهد کرد و کد اجرا را با مبلغ ناچیز 2300 gas آغاز می‌‌کند. این مسئله شبیه به مورد قبل است و اساسا برای دریافت سرمایه‌‌ها، کافی خواهد بود. هر مورد پیچیده‌‌تر از این موضوع با شکست و یک استثنای خارج از gas مواجه می‌‌شود.

3- ()address.transfer : معادل نیاز قبلی است. به صورت خود به خودی در صورتی که ارسال با شکست مواجه شود، باز خواهد گشت.

  1. address.transfer(): is equivalent to require(address.send()). It will automatically revert if the Bank

مثال 4: DAO

  • DAO نام یک DAO به خصوص (سازمان غیر متمرکز) است و از سوی تیم پشتیبان آلمانی Slock.it حمایت می‌‌شود. این شرکت قفل‌‌های هوشمند را می‌‌سازد و به مردم اجازه می‌‌دهد تا وسایل خود (ماشین‌‌ها، قایق‌‌ها و آپارتمان‌‌ها) را در یک نسخه غیر متمرکز از Airbnb به اشتراک بگذارند.
  • این موضوع همانند یک صندوق سرمایه‌‌گذاری غیر متمرکز برای تامین مالی Dappها عمل می‌‌کند که در آن شرکت‌‌کنندگان می‌‌توانند تعیین کنند کدام DAppها سرمایه را دریافت کرده‌‌است.
  • آن‌‌ها در 30 آوریل 2016 با یک پنجره سرمایه‌‌گذاری 28 روزه آغاز به کار کردند. این بزرگترین جذب سرمایه انبوه در تاریخ بود و بیش از 150 میلیون دلار (با قیمت فعلی که به چند میلیارد هم می‌‌رسد) از بیش از 11 هزار عضو عاشق به دست آورد.
  • در 18 ژوئن 2016 مهاجم شروع به تخلیله DAO با استفاده از یک حمله نفوذ مجدد کرد.
  • مهاجم موفق شد بیش از 3.600.000 اترر (در آن زمان 72 میلیون دلار، با ارزش فعلی 2.520 میلیارد دلار) به جیب بزند.
  • اجتماع اتریوم چگونه پاسخ داد؟

اجتماع با یک انشعاب به قضیه واکنش داد، یک انشعاب سخت! افرادی که معتقد بودن هک قانونی بوده (کد قانو است) در شبکه باقی ماندند و اتریوم کلاسیک را تشکیل دادند. انشعاب‌‌کنندگان هم یک شبکه جدید ایجاد کردند و تمام پول میزبان را در آن قرار دادند و به آن اتریوم (ساده و قدیمی) گفتند.

مثال 5: هانی‌‌پات

اینجا ما یک قرارداد هوشمند مدافع (Assert) داریم. این یک مثال کوچک برای نمایش مفهوم کلی‌‌تر است. در اصل سازنده قرارداد هوشمند مدافع، صاحب این دارایی است. هر کس می‌‌تواند سرمایه‌‌ها را به این قرارداد ارسال کند. اگر کسی بیشتر از مبلغ موجود در قرارداد هوشمند پیشنهاد دهد، صاحب این دارایی می‌‌شود و تمام سرمایه‌‌های دارایی را دریافت می‌‌کند.

Asset

مواردی که در آن بیانیه می‌‌تواند صحیح باقی بماند چه هستند؟

این مسئله هرگز صحیح نخواهد بود! به این خاطر چنین می‌‌شود که تراز پیش از این که این کد محقق شود، به روز رسانی می‌‌شود. این نوع قرارداد 2 نسخه داشت، که اولین نسخه 20 اتر و نسخه دوم 5 اتر از افراد پیشنهاد دهنده، تخلیه کرد.

انتقالات اتر جایگزین

تا به حال ما روش‌‌های صریح برای انتقال اتر را بررسی کرده‌‌ایم. بیایید به چند گزینه برای انتقال که کمتر مشهور و شناخته‌‌شده هستند نگاه بیاندازیم.

  • به جز ابزار معمولی ارسال اتر (مثل تماس، ارسال یا انتقال)، 2 روش دیگر برای عبور از عملکرد عقب‌‌نشینی وجود دارد:
  • خودتخریبی: تنها احتمالی که کد از بلاک‌‌چین حذف شود هنگامی است که قرارداد در یک آدرس، عملکرد خودتخریبی داشته باشد (قبلا به آن خودکشی می‌‌گفتند). این همان انگیزه به کارگیری یک درخواست خودتخریبی برای حذف قراردادهای هوشمندانه بی‌‌فایده از شبکه است. خودتخربی یک پارامتر آدرسی دریافت می‌‌کند که مشخص می‌‌کند سرمایه‌‌های قرارداد آماده تخریب را باید به کجا منتقل کند.
  • اگر آدرس دریافتی یک قرارداد باشد، عملکرد عقب نشینی اجرا نمی‌‌شود. این یک گزینه طراحی عجیب در سالیدیتی است.
  • به عنوان استخراج‌‌کننده، آدرس هدف را روی آدرس کوین‌‌بیس تنظیم کنید تا بتوانید پاداش‌‌های استخراج بلاک را دریافت کنید.

بیایید یک مثال را با هم بررسی کنیم. هر بار کسی سرمایه‌‌هایی را به قرارداد GenerousAttacker ارسال می‌‌کند، ما خودتخریبی خواهیم داشت و سرمایه‌‌ها را به آدرسی که در سازنده GenerousAttacker مشخص شده، ارسال می‌‌کنیم.

Asset

پس هر بار که یک کاربر پول را به این قرارداد ارسال می‌‌کند، ارزش ذخیره‌‌شده در این قرارداد به یک هدف از پیش مشخص شده منتقل می‌‌شود اما انتقالی صورت نمی‌‌گیرد. توجه کنید! بدون دانستن کامل زبان، نمی‌‌توانید این بحث را مطالعه کنید و فکر کنید همه چیز صادقانه است!

Mitigation‌‌: از فرضیات آگاه باشید

  • هرگز از تراز یک قرارداد به عنوان یک محافظ استفاده نکنید.
  • به طور کلی، از ویژگی‌‌ها و بروز رسانی‌‌های بخصوص زبان و فرم‌‌ورک مطلع باشید.

1- از بهبودها و باگ‌‌های مولف آگاه باشید و آزمون‌‌های لازم را انجام دهید.

2- از باگ‌‌های بخصوص مولف آگاه باشید و همیشه از نسخه مطمئن او استفاده کنید.

3- از مداخلات استخراج‌‌کنندگان بالقوه آگاه باشید (مثل front-running، chain re-org و غیره).

مثال 6: هک Parity 2

TL:DR:

فردی یک صدور Github همراه با کیفParity باز کرده و می‌‌گوید، “من به طور تصادفی عالی کار کردم”. او الزاما راهی برای حذف قراردادهای هوشمند پیدا کرده‌‌است. ناگهان کیف‌‌های زیادی مشخص شدند که از کتابخانه‌‌ای استفاده می‌‌کردند که برای بقا شروع به حذف می‌‌کرد!

Parity 2

  • حدود 513 هزار اتر در قراردادهای هوشمندانه تحت‌‌تاثیر قرار گرفته قفل شده بود.
  • هیچ سرمایه‌‌ای دزدیده نشد؛ فقط تصادفا چند مورد غیرقابل دسترسی شدند.
  • پروپزال‌‌های کمی برای روش‌‌هایی وجود داشت که قرار بود سرمایه‌‌های از بین رفته را باز گرداند و حتی برای یک مدل قانونی جدید این چنین بود، اما بعید است چنین اتفاقی به زودی رخ دهد.

واقعا اینجا چه اتفاقی افتاد؟

Parity 2

اگر به یاد بیاورید، ما فقط این تعدیل‌‌کننده آغازنشده را داشتیم. می‌‌توانید ببینید که کتابخانه از متغیرهای حالت زیادی استفاده می‌‌کند. اما این متغیرهای حالت اعلام‌‌شده و آغاز‌‌شده کجا هستند؟

Parity 2

ما تمام قراردادهای هوشمند مورد استفاده برای ساخت کیفParity را جستجو کردیم و این متغیرهای حالت که در قرارداد کیف تعریف شده بودند را یافتیم.

Parity 2

قرارداد WalletLibrary دارای متغیرهای حالتی است که انتظار می‌‌رود توسط وضعیت خود قرارداد تحت تاثیر قرار بگیرد.

وقتی که قراداد WalletLibrary گسترش یافت، آغاز‌‌نشده می‌‌شود پس m_numOwners صفر خواهد بود.

Parity 2

  • اگر WalletLibrary در زمینه قرارداد کیف اجرا نشود، m_numOwners صفر خواهد بود و به همه اجازه می‌‌دهد تا روش‌‌هایی را فرا بخوانند که این محافظ تعدیل‌‌کننده در آن، initWallet باشد.

این مسئله چگونه به کار گرفته می‌‌شود؟

توسعه‌‌دهنده‌‌ای initWallet را طلب می‌‌کند و خود را به عنوان صاحب قرار می‌‌دهد، سپس سعی می‌‌کند با استفاده از عملکرد کشتن (عملکرد عالی)، آن را به بهترین نحو تغییر دهد. توسعه‌‌دهنده‌‌ای که این باگ را پیدا کرد یک هندل Github از 199 توسعه داشت و سپس این را توییت کرد.

مثال 7: قرارداد مزایده

Action

پس کاربر یک پیشنهاد مزایده می‌‌دهد و اگر بالاترین پیشنهاد را داده باشد، به او سرمایه‌‌ داده می‌‌شود. اما اگر این روش انتقالی شکست بخورد چه اتفاقی خواهد افتاد؟

Action

فرض کنید با شروع مزایده ما یک پیشنهاد ارزان دادیم و صاحب لقب گرفتیم. سپس اگر فردی پیشنهاد بالاتری از پیشنهاد ما ارائه کند و ما با شکست انتقال مواجه شویم، تا ابد برندگان مزایده خواهیم بود اما همچنان بالاترین پیشنهاد جدید را خواهیم داشت! پس بیایید نگاهی به نحوه عمل این مسئله بیاندازیم. بیایید یک قرارداد بسازیم که از عملکرد عقب‌‌نشینی قابل پرداخت استفاده نکند و ارسال پول برای ما را غیر ممکن سازد.

Attacker

Mitigation‌‌ 1: هل‌‌دادن را نسبت به کشیدن در اولویت قرار دهید (Favor Pull over Push)

  • همیشه در ذهن داشته باشید که شما فقط با انسان‌‌ها تعامل نمی‌‌کنید و با باقی قراردادها هم در ارتباط هستید.

ما می‌‌توانیم این مسئله را با استفاده از یک مکانیسم بازگشت هم کاهش دهیم. ما الزاما مسیری از سرمایه‌‌ها را در اختیار خواهیم داشت که تمام کاربران از عملکرد برداشت که به همه اجازه می‌‌دهد درخواست بازگشت سرمایه را داشته باشند، استفاده می‌‌کنند.

Action

Mitigation‌‌ 2: قراردادها را انکار کنید

  • این روش معمولا توصیه نمی‌‌شود و مطلوب نیست اما می‌‌توان با تعامل با قرارداد با استفاده از روش زیر، این کار را انجام داد:

Action

نتیجه‌‌گیری

قرارداد هوشمند واژه است که معمولا به جای محیط‌‌های مطمئن به کار می‌‌رود. اگرچه قراردادهای هوشمند می‌‌توانند اشخاص واسطه و افراد حاضر در قراردادهای متمرکز را حذف کنند، این هک‌‌ها نشان می‌‌دهد که نیاز بالایی به اطمینان وجود دارد. به جای اطمینان به یک شرکت یا وکیل‌‌ها، ما به کد و توسعه‌‌دهندگانی که این قراردادها را می‌‌نویسند و بررسی می‌‌کنند، اعتماد می‌‌کنیم.

اگرچه کد بدون اشتباه نیست، من فکر می‌‌کنم اجتماع قرارداد هوشمند به بهبود اثربخشی خود در قراردادهای هوشمندانه ادامه خواهد داد. توسعه‌‌دهندگان با تجربه‌‌تر می‌‌شوند، از اشتباهات قبلی خود درس می‌‌گیرند و ابزار بهتری برای توسعه و کمک به تحلیل و آزمون قراردادها به کار می‌‌برند. من نسبت به آینده قراردادهای هوشمندانه هیجان‌‌زده هستم و باور دارم آن‌‌ها از نظر محبوبیت در سال‌‌های پیش رو رشد خواهند داشت.

شاید از این مطالب هم خوشتان بیاید.

ارسال پاسخ

آدرس ایمیل شما منتشر نخواهد شد.