در طول سه سال گذشته توسعه قراردادهای هوشمند، جامعه ارزهای رمزنگاری شده شاهد بوده است که قراردادهای هوشمند نوشته شده در Solidity توسط انواع باگ‌ها و اکسپلویت‌ها (سوء بهره‌برداری DAO، اشکال کیف پول چند علامتی Parity و غیره) واژگون شده‌اند. تقصیر غلبه قراردادهای هوشمند ناامن را به زبان قرارداد هوشمند Solidity و بسیاری از ویژگی‌های آن سرزنش کنید. با این حال، ما معتقدیم که برخی از بدترین ایرادات Solidity - فقدان بازرسی و قابلیت ردیابی، کدورت و ناخوانا بودن کد روی زنجیره، و تماس‌های گران قیمت، کند و خطرناک به قراردادهای هوشمند خارجی - مستقیماً از تصمیم‌های طراحی اساسی ناشی می‌شوند. معماری ماشین مجازی اتریوم (EVM).
در حالی که ما می دانیم که گروه کاری EWASM به دنبال پیشرفت وضعیت فناوری قراردادهای هوشمند در اتریوم است، ما نسبت به نادیده گرفتن ایرادات در EVM و اشاره به راه حل جدید براق هشدار می دهیم، زیرا اگر ایرادات طراحی شناسایی نشوند در معرض خطر جدی قرار دارند. در حال تکرار شدندر بحث درباره این ایرادات، ما همچنین آنها را با تصمیماتی که به طراحی Pact، زبان قراردادهای هوشمند منبع باز Kadena که آگاهانه از بسیاری از این دام ها اجتناب می کند، تضاد می کنیم.
ماشین های مجازی و فراتر از آن
یک ماشین مجازی (VM) که به خوبی ساخته شده است به دنبال محافظت از طراحان زبان در برابر اشتباهات خطرناک و پشتیبانی از ساخت کارآمد با ویژگی های مرکزی مانند پشتیبانی ارسال، وضوح نام و غیره است. با این حال، EVM در ارائه ضمانت‌های مشابه، اغلب با توجیه مبهم تجسم اخلاق اصلی اتریوم، برای ارائه «ماشین محاسباتی جهانی» ناکام است. می‌توان یک ماشین کامل تورینگ داشت بدون اینکه توسعه‌دهندگان را در معرض خطراتی قرار داد که ماشین‌های مجازی مدرن برای دهه‌ها از بین برده‌اند. در عوض، EVM این حکمت را نادیده می‌گیرد و انتظار دارد که زبان‌های سطحی که در آن جمع‌آوری می‌شوند به آنها بپردازند.
در واقع، EVM برای ایمن بودن در سختی زبان بایت کد و عملکرد بومی آن بسیار پیچیده است، اما به اندازه کافی ویژگی های یک VM مناسب برای ایمن بودن در ساخت را ندارد. اگر EVM یک مدل محاسباتی سختگیرانه تر و ناقص تورینگ را اتخاذ کند، می تواند به تضمین های ایمنی بایت کد بیت کوین نزدیک شود. از سوی دیگر، اگر EVM ویژگی‌هایی را ارائه می‌کرد که از یک ماشین مجازی مدرن انتظار می‌رفت، آنگاه به ایمنی سطح پایین ارائه شده توسط ماشین‌هایی مانند ماشین مجازی جاوا (JVM) نزدیک می‌شد.
از این رو، هر زبانی که EVM را هدف قرار می دهد، باید با انتخاب های طراحی ناامن و فقدان ویژگی های مدرن VM مقابله کند. ویژگی هایی مانند ارسال و انتزاع باید به طور کامل توسط زبان رو به روی کاربر مدیریت شود، که طراحان زبان، مانند نویسندگان Solidity را با کار بسیار دشواری مواجه می کند و فرصت های بسیار زیادی برای انجام اشتباهات اساسی می گذارد.
بایت کد EVM برای انسان قابل خواندن نیست
بیت کوین یک زبان بایت کد ایمن، ساده و به طور موثر خوانا ارائه می کند که برای تضمین سازگاری و صحت برنامه های اجرا شده بر روی بلاک چین طراحی شده است. این یک مجموعه دستورالعمل حداقلی را ارائه می دهد و از بایت کد در درجه اول برای کوچک نگه داشتن محموله ها استفاده می کند. هرگز قرار نبود هدف کامپایل برای یک زبان همه منظوره باشد. این محدودیت‌های عمدی در سطح زبان، سربار شناختی درک آنچه که یک بار معین واقعاً انجام می‌دهد را به حداقل می‌رساند تا توسعه‌دهندگان بتوانند به طور مؤثرتری در مورد کد خود و همچنین کد دیگران استدلال کنند. در واقع، توسعه دهندگان باتجربه بیت کوین می توانند به طور مستقیم کدهای عملیات بیت کوین را بخوانند و تفسیر کنند.
سازندگان EVM مدل Bytecode را حفظ کردند اما ایده برنامه های کوچک و قابل درک را به هم ریختند. در عوض ، آنها به Bytecode به عنوان "کد ماشین هدف" نگاه کردند که کد قابل خواندن با آن در آن گردآوری می شود. به همین دلیل استحکام خواندن در زنجیره غیرممکن است و باید برای اشکال زدایی یا اعتبارسنجی از آن جدا شود. چندین پروژه در اکوسیستم Ethereum به دنبال ارائه اطمینان بیشتر در مورد کد کامپایل شده ، مانند تلاش برای تأیید رسمی قراردادهای هوشمند اتریوم از طریق زبان اثبات کننده قضیه ، با مشخص کردن یک زبان فرعی نامناسب از استحکام ، هرچند که هنوز هم در آن است. نوزادی به عنوان یک پروژه تحقیقاتی. اما مانند بسیاری از معماری ها با اشتباهات طراحی سطح پایین ، این نشان دهنده تلاش زیادی است که می توان با طراحی مناسب از آن جلوگیری کرد. در عوض ، EVM با استفاده از Bytection Bitcoin Bytecode را گسترش می دهد ، اما باعث می شود که در دستیابی به یک هدف کمپانی حداقل برای کد سطح بالاتر دلخواه ، بیش از حد انجام شود. با انجام این کار ، ویژگی ایمنی مهم در داشتن قراردادهای قابل خواندن انسانی را از دست می دهد.
PACT با ارائه یک زبان تفسیری که مستقیماً اجرا می شود ، به جای تالیف مانند استحکام ، رویکرد متفاوتی را به خود می گیرد. علاوه بر این ، همچنین با اخلاق "کوچکتر بهتر" ساخته شده است که مستقیماً از اسکریپت بیت کوین الهام گرفته شده است. این استدلال مبنی بر اینکه یک زبان کامپایل شده نسبت به یک تفسیر بیشتر اجرا خواهد شد ، توسط پایگاه داده های بی شماری که SQL را با سرعت بسیار زیاد اجرا می کنند ، و همچنین گام های عظیمی در بهبود مترجمان جاوا اسکریپت انجام می شود. همانطور که تاریخ نشان داده است ، اگر یک زبان نتواند بهینه سازی ، ذخیره سازی و "فقط به موقع" را فراهم کند ، یک زبان تفسیری می تواند در حالی که خوانایی برتر را ارائه می دهد ، رقیب کامپایل شده خود را از آن خود کند.
استفاده از مترجم به این معنی است که کد پیمان مستقر ، قراردادهای هوشمند قابل خواندن انسان را مستقیماً در زنجیره قرار می دهد. در مقابل ، هر زبانی که در بالای EVM ساخته شده باشد ، کد بایت تولید می کند که توسط انسان ها غیرقابل توصیف و غیرقابل توصیف خواهد بود ، و بنابراین فقط درک ناقص از عملکرد برنامه های نوشته شده در آن زبان خواهد داشت. سرانجام ، PACT با داشتن یک زبان برنامه نویسی کاربردی با ارزش گرا ، این مفهوم اطمینان را تقویت می کند: یک توسعه دهنده یا خواننده می تواند از استدلال معادل در مورد کد پیمان استفاده کند به گونه ای که EVM Bytecode هرگز نمی تواند اعتراف کند.
EVM به زبانها اجازه می دهد تا کامل شود
کد بیت کوین ، در رابطه با تضمین صحت ، همچنین شامل یکی دیگر از ویژگی های مهم برای اهداف ایمنی است: TURING ناقص بودن. با انجام این کار ، بیت کوین Bytecode از برنامه ها در برابر آسیب پذیری در حملات بازگشتی محافظت می کند ، و خطر ابتلا به ناخواسته در یک حلقه بی نهایت ، که هم در یک رایانه توزیع شده گران است و هم از امنیت سوء استفاده در انتظار اتفاق می افتد.
در آغاز EVM ، توسعه دهندگان Ethereum سعی کردند با ارائه یک مجموعه دستورالعمل که به طور کامل شبیه بیت کوین بود ، با اضافه کردن محدودیت تورینگ ، با افزودن پرش ، فراخوانی و دستورالعمل های مرتبط ، بر روی بایت کد بیت کوین بهبود یابد. اینها امکان بازگشت غیرقانونی و جریان کنترل خودسرانه به مکان های کد و سایر قراردادهای موجود در سیستم را فراهم می کند.
این عواقب قدرتمند و دور از دسترس برای بیان و صحت برنامه هایی که بر روی EVM اجرا می شود ، باز می کند و این برنامه ها را به یک کلاس کامل از اشکالات و رفتارهای غیر قطعی که توسط یک زبان تورینگ نامشخص است ، باز می کند. بهره برداری DAO نمونه ای عالی را ارائه می دهد ، که در آن مهاجم می تواند قبل از حل و فصل تعادل ، به صورت بازگشتی از کیف پول خارج شود و قبل از خاتمه میلیون ها نفر را به حساب خود واریز کند. بهره برداری DAO همچنین از مدل اعزام "روش پیش فرض" استحکام استفاده کرد ، که هر VM مدرن عاقل به طور اصولی ممنوع است ، و خطر ترک چنین عملکردی را به سازه های سطح بالاتر نشان می دهد. با این وجود ، اگر EVM در مورد اول تورینگ را محدود می کرد ، سوء استفاده از DAO نمی توانست رخ دهد.
ما امروز شاهد ظهور بهترین شیوه ها در اکوسیستم توسعه استحکام هستیم که در مواردی که گاز تمام می شود ، به نوعی شرایط خاتمه نیاز دارد ، یا بازگشت به طور واقعی خاتمه می یابد. این یک مورد از کاربران است که مجموعه دستورالعمل های خود را محدود می کنند. وضعیتی که می توان با یک مدل محاسباتی محدودتر از EVM اجتناب کرد.
در مقابل ، پیمان ، با طراحی ، برای جلوگیری از خطاهای برگشت و الگوهای استفاده بد همراه ، کاملاً ناقص است. ما معتقدیم که نسبت موارد استفاده واقعی برای بازگشت در محیط معاملاتی blockchain هم از نظر ناپدید کننده کوچک است و هم برای پشتیبانی از خطر ایمنی برخوردار نیست. بعلاوه ، یک blockchain با تعریف یک محیط محاسباتی محدود است ، به همین دلیل یک مدل گاز مورد نیاز است ، به این معنی که موارد استفاده واقعی بازگشتی منجر به عدم توانایی در پیش بینی استفاده از منابع می شود و باید به درستی از زنجیره ای اجرا شود.
مدل اجرای EVM گران ، آهسته و ناامن است
EVM بسیاری از ویژگی ها و مؤلفه های مهم مدل اجرای خود را بدون استفاده و طراحان زبان را وادار می کند تا آنها را به صورت دستی اجرا کنند. به عنوان مثال ، EVM ویژگی های زیر را به مجری زبان واگذار می کند:
- پشتیبانی واقعی کتابخانه ، به جای اهداف تماس با برکت در آدرس های مشهور
- انواع داده های غنی تر
- پشتیبانی مستقیم و اجرای رابط ها/API ها
به این ترتیب ، EVM بسیاری از ویژگی های تعیین کننده VM های واقعی ، مانند اعزام ، درون نگری کد و تهیه یک کتابخانه استاندارد را رها می کند ، که باعث می شود محیط اعدام گران ، کند و ناامن باشد.
در EVM ، هنگامی که یک قرارداد اجرا می شود ، EVM از یک مدل اجرای مات و "از بالا به پایین" استفاده می کند ، که در آن کل بدنه قرارداد هوشمند به عنوان یک بلوک مبهم کد بارگیری می شود و از اولین دستورالعمل کورکورانه اجرا می شود. تا زمانی که خاتمه یابد ، اجرا کنید. در مقابل ، VM هایی مانند JVM ، درک می کنند که توابع در نام های خاص یا ماژول ها چه کارکردهایی بیان می شوند و به آنها اجازه می دهد تا به صورت جداگانه بارگیری شوند و مستقیماً فراخوانی شوند. مدل "از بالا به پایین" به این معنی است که وقتی یک قرارداد خارجی فراخوانی می شود ، EVM باید کل قرارداد را بارگیری کند تا یک عملکرد واحد پیدا کند.
کتابخانه های استاندارد یکی دیگر از ویژگی های رایج VM است که توسط EVM پشتیبانی نمی شود. به عنوان مثال ، در JVM ، بسیاری از کارکردهای اصلی هسته در یک کتابخانه استاندارد "rt. jar" که با VM توزیع شده است ، ذخیره می شوند. اگر قراردادهای هوشمند به یک کتابخانه استاندارد دسترسی داشته باشند ، آنها می توانند بسیاری از کارهای مشترک را به جای اجرای مستقیم آنها در قرارداد هوشمند به کتابخانه استاندارد واگذار کنند. هزینه اجرای هر دستورالعمل در یک قرارداد هوشمند کاربر هر بار که توسعه دهندگان را مجبور می کند گاز اضافی قابل توجهی را برای این امتیاز برای تنظیم عملکردهای اساسی مورد نیاز برای نوشتن قرارداد بپردازند و قراردادهای هوشمند را در EVM بسیار گرانتر می کنند. قراردادهای داخلی نمایانگر یک راه حل ناخوشایند است که می تواند هزینه گاز را کاهش دهد اما هیچ کاری برای بهبود مدل اجرای ناکارآمد انجام نمی دهد.
علاوه بر کند بودن و گران بودن ، تماس های خارجی با EVM بسیار ناامن است. از آنجا که یک قرارداد فراخوانی توانایی تعیین آنچه منابع درون قرارداد در برخی از قراردادهای دیگر معتبر هستند ، در زمان اجرا از مرجع وجود ندارد که به یک مرجع غایب یا ناقص اشاره دارد. این پدیده باعث ایجاد مسئله کیف پول برابری شد ، جایی که کیف پول ها به نام یک قرارداد اصلی و اصلی که متعاقباً حذف شد ، و بودجه موجود در آن کیف پول را قفل می کرد. در همین حال ، هک DAO نمونه ای از یک مرجع قرارداد ناامن بود که فقط برای حساب های "کاربر" (EOAS یا "حساب های خارج از کشور" طراحی شده است) ، که وقتی توسط یک حساب قرارداد مخرب فراخوانده می شود ، روش پیش فرض را مجاز می کند (غیرقابل توضیح در "ارسال" اجرا می شود"روش پرداخت) برای شروع بهره برداری از بازگشت.
در مقابل ، PACT یک کتابخانه استاندارد را به عنوان یک اصل اول ارائه می دهد ، و کلیه ابزارهای لازم را برای نویسنده پیمان برای نوشتن قراردادهای ایمن و مؤثر ارائه می دهد. علاوه بر این ، PACT هرگز "Opcodes" یا آدرس های قرارداد داخلی را تمام نمی کند و به آن اجازه می دهد ویژگی های جدید را درج کند زیرا تقاضا برای آنها نشان داده شده است. در نتیجه ، مدل گاز برای توابع تعریف شده به خوبی تعریف شده و استاتیک باقی مانده است ، که به کاربر اجازه می دهد کد خود را به روشی مدولار بسازد و در عین حال توانایی استدلال نه تنها در مورد عملکرد کد آنها را حفظ کند ، بلکه هزینه آن درزمان اجرا
علاوه بر این ، هنگامی که یک نویسنده پیمان قرارداد دیگری را در مورد blockchain فراخوانی می کند ، کد عملکرد خاص (با تمام وابستگی های گذرا آن) به طور دائم در سایت تماس کاربر وارد می شود ، به طوری که اجرای نه تنها سریع است (کد در دامنه فوری است) بلکه در محدوده فوری است)همچنین غیرقانونی بودن در زمان بعدی غیرممکن است و تاکنون ایمن تر است.
EVM فاقد پشتیبانی چند جانبه و قراردادهای قابل ارتقا است
قراردادها و حساب های موجود در اتریوم توسط آدرس ارجاع می شوند ، که نمایندگی هشدار دهنده برخی از کلید های عمومی است که به طور ذاتی از حق دسترسی به آدرس با امتیازات بالا برخوردار است. نتیجه این انتخاب طراحی ، اتریوم و EVM را به عدم پشتیبانی از حمایت بومی برای تأیید اعتبار چند امضایی متعهد می کند و تحت تأثیر قرار می دهد که "کد قانون" انتخاب شده است تا قراردادهای هوشمند برای همیشه نتوانند کد را در یک آدرس خاص به روز کنند. این در واقع یکی از دلایلی است که EVM فاقد مکانیسم اعزام مدرن است که این کار را انجام می دهد بدون هیچ نوع وضوح مبتنی بر نام ، یک سیستم حتی مات تر از آنچه امروز با ما روبرو است ، خواهد بود. با این حال ، فقدان اعزام و وضوح مبتنی بر نام اساساً تضمین می کند که کد قابل ارتقا نیست ، زیرا هیچ نمایشی اولیه وجود ندارد که چه کد در یک آدرس (مانند هش محتوا و غیره) وجود داردبدانید که آیا کد به روز شده است یا خیر.
برای بدتر شدن اوضاع ، قالب یک آدرس در واقع تمام قراردادهای موجود در EVM را مجبور می کند تا یک امضاء واحد باشد و از قراردادهای گران قیمت داخلی و/یا تماس های چند معامله برای پشتیبانی از MultiIG استفاده کند. اگر EVM اعزام داشته باشد ، یک قرارداد می تواند با یک نام انتزاعی همراه باشد ، که می تواند امضاها را از یک آدرس قرارداد جدا کند و این امکان را فراهم می آورد که یک قرارداد به طور طبیعی چندگانه باشد.
در نتیجه این نواقص ، یک صنعت کلبه کیف پول های چندگوش ، استانداردهای قرارداد و تکنیک ها به منظور پر کردن این خلاء معرفی شده است. قراردادهای پروکسی ، توابع اعتبار سنجی چندگوش و کیف پول هایی مانند Gnosis یا Parity Multisig برای ارائه این ویژگی مورد نیاز معرفی شده اند ، اما با هزینه هزینه اضافی برای بسیاری از آدرس های حاکم بر معامله. در مقابل ، بیت کوین و متعاقباً پیمان هرگز طرح های خود را در مورد یک رویکرد تک امضا محدود نکردند و انگیزه چنین راه حل ها را از بین بردند. در واقع ، PACT کلیدهایی را به عنوان اعتبار سنجی بدوی ارائه می دهد ، به این معنی که هر معامله می تواند چند یا یک سیگ را انتخاب کند و بدون پیچیدگی اضافه شده برای برنامه نویس باشد. علاوه بر این ، PACT یک مدل اعزام مناسب را ارائه می دهد ، و این امکان را برای قراردادهای هوشمند (و در نتیجه قابل ارتقاء) که توسط یک کلیدهای تک یا چندگوش اداره می شود ، فراهم می کند.
نتیجه
EWASM یک تلاش جدید برای ارائه جایگزین امن تر برای EVM در Ethereum است و تیم EVM طی سالها پیشرفت های افزایشی در EVM داشته است. متأسفانه ، بسیاری از عواملی که به تجربه کاربر ناامن و ناکارآمد در EVM کمک می کنند ، نمی توانند با تکه ها یا رفع سریع برطرف شوند ، زیرا آنها نتیجه ای از مشکلات عمیق معماری در طراحی EVM هستند. EVM سادگی ظریف از بیت کوین بایت کد و کاربران را پرداخت می کند: این یک محیط اجرای ایمن و قابل استفاده را برای توسعه دهندگان زبان فراهم نمی کند.
در حالی که این مقاله برای EVM بسیار مهم است ، ما مایل به انتخاب دعوا با توسعه دهندگان اتریوم نیستیم و به تلاش های انجام شده برای معرفی یک جایگزین ایمن تر با EWASM احترام می گذاریم. اما تا آنجا که EWASM هر یک از این مفاهیم اصلی را در EVM به چالش نمی کشد ، سرنوشت مشابهی را متحمل می شود ، همانطور که مشاغل و توسعه دهندگان که سعی در دستیابی به ایده های نوآورانه و موارد استفاده دارند ، فقط برای از دست دادن پول در سوء استفاده های اجتناب ناپذیر یاهزینه های بیش از حد گازدر کادنا ، ما پیمان را برای مقابله با امنیت و قابلیت استفاده در یک blockchain به روشی کاملاً متفاوت طراحی کردیم. رویکردی که کنترل و ایمنی را در دست توسعه دهنده قرار می دهد. اما ما همچنین امیدواریم که دیدگاه روشنی از کاستی های EVM ، درک جامعه عمومی از EVM و آنچه Ewasm را باید اصلاح کند تا آینده بهتری را اصلاح کند.
