مقدمه ای بر قراردادهای هوشمند

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

قرارداد منظم در مقابل قرارداد هوشمند

قبل از اینکه به جزئیات بپردازیم، بیایید نمونه ای از تفاوت های یک قرارداد معمولی که روی کاغذ مشخص شده و یک قرارداد هوشمند که به صورت دیجیتالی نشان داده می شود را مثال بزنیم.

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

در مورد قراردادهای هوشمند چه می توان گفت؟ آنها هم امکان نوشتن شرایط قرارداد و هم مکانیسم اجرای دقیق آنها را با هم ترکیب می کنند. اگر شرایط تعیین شده باشد و معامله یا درخواست مربوطه امضا شده باشد، پس از پذیرش آن درخواست یا معامله، دیگر امکان تغییر شرایط و یا تأثیر بر اجرای آنها وجود ندارد.

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

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

تعریف قرارداد هوشمند

به طور کلی، خود این اصطلاح توسط محقق نیک سابو ابداع شد و اولین بار در سال 1994 مورد استفاده قرار گرفت و در سال 1997 در مقاله ای مستند شد که ایده قراردادهای هوشمند را توصیف می کند.

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

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

یک مثال ساده - سرویس Escrow

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

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

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

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

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

واسطه علاقه مند است که هم خشم خریدار و هم منافع فروشگاه آنلاین را برآورده کند (بعداً مشخص خواهد شد که چرا). این معامله ای است که در آن سکه های یک آدرس چند امضایی به نسبتی بین خریدار، فروشگاه آنلاین و واسطه خرج می شود، زیرا او بخشی را برای خود به عنوان پاداش کارش می گیرد. فرض کنید 90 درصد از کل مبلغ به فروشنده، 5 درصد به واسطه و 5 درصد خسارت به خریدار می رسد. میانجی این معامله را با کلید خود امضا می کند، اما هنوز نمی توان آن را اعمال کرد، زیرا به دو امضا نیاز دارد، اما فقط یکی ارزش آن را دارد. چنین معامله ای را هم برای خریدار و هم برای فروشنده ارسال می کند. اگر حداقل یکی از آنها از این گزینه برای توزیع مجدد سکه راضی باشد، تراکنش از قبل امضا شده و در شبکه توزیع می شود. برای تایید آن کافی است یکی از طرفین معامله با خیار میانجی موافقت کند.

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

مثلا خوابگاه و یخچال

بیایید به یک مثال پیچیده‌تر نگاه کنیم که قابلیت‌های یک قرارداد هوشمند را به طور واضح‌تر نشان می‌دهد.

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

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

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

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

طبقه بندی قراردادهای هوشمند

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

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

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

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

علاوه بر این، قراردادهای هوشمند در سطح حریم خصوصی متفاوت هستند. آنها می توانند کاملاً باز، تا حدی یا کاملاً محرمانه باشند. مورد دوم به این معنی است که ناظران شخص ثالث شرایط قراردادهای هوشمند را نمی بینند. با این حال، موضوع حریم خصوصی بسیار گسترده است و بهتر است آن را جدا از مقاله فعلی در نظر بگیرید.

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

قراردادهای هوشمند بر اساس زمان اجرا

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

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

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

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

قراردادهای هوشمند به روش تنظیم و تحقق شرایط

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

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

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

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

قراردادهای هوشمند با روش شروع

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

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

حساب های اتریوم

انواع حساب اتریوم

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

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

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

نحوه ایجاد حساب ها در اتریوم

در مورد یک حساب کاربری، مالک به طور مستقل یک جفت کلید با استفاده از ECDSA ایجاد می کند. توجه به این نکته ضروری است که اتریوم دقیقاً از الگوریتم مشابه و دقیقاً همان منحنی بیضوی برای امضای الکترونیکی بیت کوین استفاده می کند، اما آدرس به روشی کمی متفاوت محاسبه می شود. در اینجا دیگر مانند بیت کوین از نتیجه هش دوگانه استفاده نمی شود، بلکه هش تک با تابع Keccak در طول 256 بیت ارائه می شود. کمترین بیت های مهم از مقدار به دست آمده جدا می شوند، یعنی کمترین 160 بیت از مقدار هش خروجی. در نتیجه، ما یک آدرس در اتریوم دریافت می کنیم. در واقع 20 بایت اشغال می کند.

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

یک ویژگی مهم وجود دارد و آن این است که یک حساب کاربری در سطح پایگاه داده عمومی در لحظه ای ایجاد می شود که اولین پرداخت دریافتی را می پذیرد.

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

هر قرارداد هوشمند لزوماً شامل سازنده خود (این قرارداد) است. ممکن است خالی باشد یا محتوایی داشته باشد. پس از اجرای سازنده، یک شناسه حساب قرارداد هوشمند ایجاد می شود که با استفاده از آن می توانید سکه ارسال کنید، روش های قرارداد هوشمند خاص و غیره را فراخوانی کنید.

ساختار تراکنش اتریوم

برای روشن تر شدن موضوع، ما شروع به بررسی ساختار تراکنش اتریوم و نمونه کد قرارداد هوشمند خواهیم کرد.

یک تراکنش اتریوم از چندین فیلد تشکیل شده است. اولین مورد، nonce، یک شماره سریال معین تراکنش نسبت به خود حسابی است که آن را توزیع می کند و نویسنده آن است. این امر برای تشخیص معاملات مضاعف ضروری است، یعنی استثناء موردی که یک معامله دو بار پذیرفته شود. با استفاده از یک شناسه، هر تراکنش دارای یک مقدار هش منحصر به فرد است.

بعد یک فیلد مانند می آید قیمت بنزین. این نشان دهنده قیمتی است که ارز پایه اتریوم با آن به گاز تبدیل می شود که برای پرداخت هزینه اجرای قرارداد هوشمند و تخصیص منبع ماشین مجازی استفاده می شود. چه مفهومی داره؟

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

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

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

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

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

و آخرین فیلد نامیده می شود امضا. این به طور همزمان شامل امضای الکترونیکی نویسنده این معامله و کلید عمومی است که با آن این امضا تأیید می شود. از کلید عمومی می توانید شناسه حساب فرستنده این تراکنش را بدست آورید، یعنی حساب فرستنده را به صورت منحصر به فرد در خود سیستم شناسایی کنید. ما به نکته اصلی در مورد ساختار معامله پی بردیم.

نمونه کد قرارداد هوشمند برای Solidity

بیایید اکنون با استفاده از یک مثال به ساده‌ترین قرارداد هوشمند نگاهی دقیق‌تر بیندازیم.

contract Bank {
    address owner;
    mapping(address => uint) balances;
    
    function Bank() {
        owner = msg.sender;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public {
        if (balances[msg.sender] >= amount) {
            balances[msg.sender] -= amount;
            msg.sender.transfer(amount);
        }
    }

    function getMyBalance() public view returns(uint) {
        return balances[msg.sender];
    }

    function kill() public {
        if (msg.sender == owner)
            selfdestruct(owner);
    }
}

در بالا یک کد منبع ساده وجود دارد که می‌تواند سکه‌های کاربران را در خود نگه دارد و آن‌ها را در صورت درخواست بازگرداند.

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

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

این با روش بانک دنبال می شود - نامی مشابه با قرارداد دارد. بر این اساس، این سازنده آن است. در اینجا به متغیر مالک آدرس شخصی که این قرارداد هوشمند را در شبکه قرار داده است، اختصاص می یابد. این تنها چیزی است که در این سازنده اتفاق می افتد. یعنی msg در این حالت دقیقا همان داده ای است که به همراه تراکنش حاوی کل کد این قرارداد به ماشین مجازی منتقل شده است. بر این اساس، msg.sender نویسنده این تراکنش است که میزبان این کد است. او مالک قرارداد هوشمند خواهد بود.

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

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

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

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

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

بیایید به طور شماتیک به نحوه اجرای چنین قراردادهای هوشمند در پلتفرم اتریوم و نحوه عملکرد یک گره شبکه کامل نگاه کنیم.

یک گره کامل در شبکه اتریوم باید حداقل چهار ماژول داشته باشد.
اولین مورد، مانند هر پروتکل غیرمتمرکز، ماژول شبکه P2P است - ماژولی برای اتصال به شبکه و کار با گره های دیگر، که در آن بلوک ها، تراکنش ها و اطلاعات مربوط به گره های دیگر رد و بدل می شوند. این یک جزء سنتی برای همه ارزهای دیجیتال غیرمتمرکز است.

در مرحله بعد، ما یک ماژول برای ذخیره داده های بلاک چین، پردازش، انتخاب شاخه اولویت، الحاق بلوک ها، جدا کردن بلوک ها، اعتبارسنجی این بلوک ها و غیره داریم.

ماژول سوم EVM (ماشین مجازی اتریوم) نام دارد - این یک ماشین مجازی است که بایت کد را از تراکنش های اتریوم دریافت می کند. این ماژول وضعیت فعلی یک حساب خاص را می گیرد و بر اساس بایت کد دریافتی، تغییراتی در وضعیت آن ایجاد می کند. نسخه ماشین مجازی در هر گره شبکه باید یکسان باشد. محاسباتی که روی هر گره اتریوم انجام می‌شود دقیقاً یکسان است، اما به‌صورت ناهمزمان انجام می‌شود: کسی زودتر این تراکنش را بررسی می‌کند و می‌پذیرد، یعنی تمام کدهای موجود در آن را اجرا می‌کند و کسی بعداً. بر این اساس، زمانی که تراکنش ایجاد می‌شود، در شبکه توزیع می‌شود، گره‌ها آن را می‌پذیرند و در زمان تأیید، به همان روشی که بیت‌کوین اسکریپت در بیت‌کوین اجرا می‌شود، بایت کد ماشین مجازی در اینجا اجرا می‌شود.

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

افسانه ها و محدودیت های قراردادهای هوشمند

در مورد محدودیت هایی که برای پلتفرم های قرارداد هوشمند مشابه اتریوم وجود دارد، می توان به موارد زیر اشاره کرد:

• اجرای کد؛
• تخصیص حافظه؛
• داده های بلاک چین؛
• ارسال پرداخت ها؛
• ایجاد قرارداد جدید؛
• با قراردادهای دیگر تماس بگیرید.

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

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

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

معایب اتریوم

بیایید موارد اصلی را فهرست کنیم. اولین عیب این است که در طراحی، توسعه و آزمایش قراردادهای هوشمند در اتریوم مشکلاتی وجود دارد (اتریوم از زبان Solidity برای نوشتن قراردادهای هوشمند استفاده می کند). در واقع، عمل نشان می دهد که درصد بسیار زیادی از همه خطاها مربوط به عامل انسانی است. این در واقع برای قراردادهای هوشمند اتریوم که دارای پیچیدگی متوسط ​​یا بالاتر هستند، صادق است. اگر برای قراردادهای هوشمند ساده احتمال خطا کم است، در قراردادهای هوشمند پیچیده اغلب خطاهایی وجود دارد که منجر به سرقت وجوه، مسدود شدن آنها، از بین رفتن قراردادهای هوشمند به روشی غیرمنتظره و غیره می شود. بسیاری از این موارد قبلاً وجود دارد. شناخته شده.

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

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

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

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

بنابراین، بخش موضوعی مقاله تکمیل شد، بیایید به سوالاتی که اغلب مطرح می شوند برویم.

پرسش های متداول

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

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

— اگر میانجی با یکی از طرفین شرکت کننده به توافق برسد چه می شود: امانت یا قرارداد هوشمند؟ آیا در قرارداد هوشمند به واسطه نیاز است؟

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

— آیا می توان با یک تراکنش اتریوم توکن های مختلف زیادی را از آدرس خود به آدرس های هدف مختلف منتقل کرد، به عنوان مثال، آدرس های مبادله ای که این توکن ها در آن معامله می شوند؟

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

- یکی از افسانه ها در مورد پلتفرم اتریوم این است که توصیف شرایطی که به داده های یک منبع اینترنتی خارجی بستگی دارد غیرممکن است، پس چه باید کرد؟

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

یکی از سخنرانی های دوره آنلاین بلاک چین به این موضوع اختصاص دارد - "مقدمه ای بر قراردادهای هوشمند".

منبع: www.habr.com