انواع پروژه‌ های مبتنی بر دانش صفر و سازگار با ماشین مجازی اتریوم (ZK-EVM)

پروژه­‌های مبتنی بر دانش صفر و سازگار با ماشین مجازی اتریوم¹ زیادی از اواخر سال ۲۰۲۱ بوجود آمده‌اند که با سرو صدای زیادی همراه بوده‌اند. پالیگان پروژه ZK-EVM خود را به صورت منبع باز² ارائه کرده، پروژه ZKSync برنامه­های خود را برای نسخه ZKSync 2.0 منتشر نمود و پروژه تازه تاسیس Scroll نیز در اواخر ۲۰۲۲ از انتشار ZK–EVM خود خبر داد. همچنین تلاش‌های زیادی از سوی تیم­های مختلف از جمله Privacy and Scaling Explorations، Nicolas Liochon و غیره در این رابطه در حال انجام است.

همه این پروژه‌ها، سه هدف کلی را دنبال می­کنند:

استفاده از فناوری ZK-SNARK برای تائید تراکنش‌های مشابه اتریوم

آسان‌تر کردن تأیید تراکنش­های خود بلاکچین اتریوم

ساخت مجموعه‌های ZK-rollup مشابه اتریوم اما با مقیاس‌پذیری بسیار بالاتر
اما تفاوت‌های ظریفی بین این پروژه‌ها ومیزان عملی بودن و سرعت آن‌ها وجود دارد. در این مقاله یک طبقه‌بندی از انواع EVMها و مزایا و معایب هریک ارائه خواهد شد.

نوع ۱: کاملاً مشابه اتریوم

ZK-EVMهای نوع ۱ در تلاش هستند تا به طور کامل مشابه اتریوم شوند. آن‌ها برای ساده کردن فرآیند اثبات³ هیچ بخشی از سیستم اتریوم را تغییر نمی‌دهند و نیز جایگزین هش‌ها، درخت‌های حالت⁴، درخت‌های تراکنش⁵ و یا منطق­های اجماع نمی‌شوند.

نقطه قوت: سازگاری کامل با اتریوم

هدف این است که بتوان بلاک‌های اتریوم را همانطور که هستند، تأیید نمود (یا حداقل، جنبه مربوط به لایه اجرا⁶را تأیید نمود). بنابراین، نیاز به منطق اجماع beacon chain نیست اما  اجرای تراکنش­ها و قراردادهای هوشمند را شامل می‌شود.

این نوع ZK-EVM باعث مقیاس­پذیرتر شدن لایه۱ اتریوم می­شود. ممکن است در آینده، نوع دوم یا سوم ZK-EVM ها باعث بهبود در عملکرد اتریوم شوند، اما باید در نظر داشت که این نوع تغییرات اساسی، باعث افزایش پیچیدگی در ساختاربندی خواهد شد.

ZK-EVMهای نوع اول برای rollupها ایده‌آل هستند، زیرا این امکان را فراهم می‌کنند که از بسیاری از زیرساخت‌هایی که قبلا وجود داشته، استفاده شوند. برای مثال، کلاینت‌⁷های اجرای اتریوم را می‌توان همانطور که هست برای تولید و پردازش بلاک‌های rollup استفاده کرد (یا حداقل، زمانی که برداشت‌ها انجام می‌شوند، این عملکرد می‌تواند دوباره برای پشتیبانی از اتریوم­هایی که در حال واریز شدن به rollupها هستند، استفاده شود). پس با نوع اول ابزارهایی مانند بلاک اکسپلوررها، فرآیند تولید بلاک و بسیاری از زیرساخت­‌های دیگر مجددا قابل استفاده هستند.

نقطه ضعف: زمان زیاد اثبات

اتریوم در ابتدا به نوعی طراحی نشده بود که با اثبات مبتنی بر دانش صفر یا همان zk سازگار باشد، لذا بخش‌های زیادی از پروتکل اتریوم وجود دارد که محاسبات زیادی برای دستیابی به اثبات ZK انجام می‌دهند. هدف نوع اول z-EVMها این است که دقیقا مشابه اتریوم باشند، بنابراین هیچ راهی برای کاهش این ناکارآمدی­ها و اجتناب از این پردازش­های سنگین وجود ندارد. به طور مثال در حال حاضر (نوامبر ۲۰۲۲)، انجام فرآیند اثبات بلاک‌های اتریوم ساعت‌ها طول می‌کشد. این مشکل را می­توان با استفاده از یک ساختاربندی جدید حل کرد که باعث انجام اثبات­‌ها به صورت موازی می‌شود و یا نوع دیگری از zkها ( ZK-SNARK ASIC) در آینده معرفی شوند.

شرکت های در حال ساخت

تیمThe Privacy and Scaling Explorations در حال ساختن این zk-EVMهای نوع اول است.

نوع ۲: کاملاً معادل EVM

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

نقطه قوت: مشابهت کامل در سطح VM

ZK-EVMهای نوع دوم با ایجاد تغییراتی در ساختارهای داده، مواردی مانند حالت اتریوم را حفظ کنند. خوشبختانه خود EVM نمی‌تواند مستقیماً به این ساختارها دسترسی داشته باشد، بنابراین اپلیکیشن هایی که روی اتریوم کار می‌کنند تقریباً همیشه روی یک مجموعه ZK-EVM نوع دوم فعالیت دارند. در نوع دوم نمی­توان از کلاینت‌های اجرایی اتریوم همانطور که هست استفاده نمود (مگر آنکه تغییراتی در آن‌ها ایجاد شود) اما می­توان از ابزارهای رفع باگ در EVM و بسیاری از زیرساخت‌های توسعه‌دهنده­های دیگر استفاده نمود.

نقطه ضعف: زمان زیاد فرآیند اثبات زیاد علیرغم توسعه zk-EVMها

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

شرکت های در حال ساخت

پروژه  Scroll's ZK-EVM در حال ساخت ZK-EVM نوع دوم مانند  Polygon Hermez است. در حال حاضر هیچ یک از پروژه­ها به طور کامل پیاده­سازی نشده­اند و خیلی از پیش‌کامپایل⁹­ها هنوز عملیاتی نیستند. از این رو، در حال حاضر هر دو پروژه بهتر است نوع سوم در نظر گرفته شوند.

نوع ۲.۵: مشابه EVM، به جز هزینه ­های کارمزد

یکی از راه‌های بهبود زمان‌ فرآیند اثبات بسیار کند، افزایش شدید هزینه‌های کارمزد عملیات­های خاصی در EVM است که اثبات آن با ZK بسیار دشوار است. این امر ممکن است شامل پیش‌کامپایل‌ها، کد KECCAK و احتمالاً الگوهای خاصی از فراخوانی قراردادها یا دسترسی به حافظه یا ذخیره‌سازی باشد.

تغییر هزینه‌های کارمزد ممکن است سازگاری با ابزار توسعه‌دهنده را کاهش دهد و تعدادی از اپلیکیشن­ها را از بین ببرد، اما عموماً نسبت به تغییرات اساسی EVM، ریسک کمتری دارد. توسعه‌دهندگان باید مراقب باشند که در یک تراکنش به هزینه بیشتری نسبت به یک بلاک نیاز نداشته باشند.

یک راه جایگزین برای افزایش کارمزدها (مدیریت محدودیت‌های منابع)، تنظیم محدودیت‌ برای تعداد دفعاتی است که هر عملیات می‌تواند فراخوانی شود. پیاده‌سازی این محدودیت در مدارها آسان‌تر است، اما کارایی کمتری دارد و می‌توان این رویکرد را بیشتر  نوع ۳ دانست تا نوع ۲.۵.

نوع ۳: تقریبا مشابه EVM

ZK-EVMهای نوع ۳ تقریباً مشابه EVM هستند، اما برای بهبود بیشتر زمان‌ فرآیند و آسان‌تر کردن توسعه EVM، مقداری از میزان شباهت به EVM را قربانی می‌کنند.

نقطه قوت: بهبود زمان فرآیند اثبات

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

نقطه ضعف: ناسازگاری بیشتر

هدف یک ZK-EVM نوع ۳ سازگاری با بیشتر اپلیکیشن­‌ها است و برای بقیه اپلیکیشن­‌ها (که از  پیش‌ کامپایل‌هایی که نوع سوم ZK-EVM حذف می‌کند، استفاده می­‌کنند) نیاز به حداقل تغییرات دارد.

شرکت های در حال ساخت

Scroll و Polygon هر دو در شکل فعلی خود نوع ۳ هستند، اگرچه انتظار می­رود در طول زمان سازگاری را بهبود بخشند.

تا کنون (نوامبر ۲۰۲۲) هیچ تیم ZK-EVM نمی­خواهد نوع ۳ باشد. نوع ۳ یک مرحله میانی محسوب می­شود تا زمانی که پیش کامپایل­ها اضافه شوند و پروژه­ها بتواند به نوع ۲.۵ منتقل شود. با این حال، در آینده (زمانیکه پیش‌کامپایل­های جدید سازگاربا ZK–SNARK اضافه شوند که عملکردی را برای توسعه­دهندگان با زمان اثبات کم و کارمزدهای پایین فراهم کنند)، ZK-EVMهای نوع ۱ یا نوع ۲ ممکن است به طور داوطلبانه به ZK-EVMهای نوع ۳ تبدیل شوند.

نوع ۴: مشابه زبان­های سطح بالا

یک سیستم نوع ۴، کد منبع قرارداد هوشمند نوشته شده به یک زبان سطح بالا (مثلاً Solidity، Vyper) را گرفته و آن را به زبانی که با ZK–SNARK سازگار است، کامپایل می­کند.

نقطه قوت: زمان پروور¹⁰بسیار سریع

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

نقطه ضعف: ناسازگاری بیشتر

یک اپلیکیشن عادی که با Vyper یا Solidity نوشته شده را می‌توان کامپایل کرد و نتیجه­ بخش خواهد بود اما در بسیاری موارد، بسیاری از اپلیکیشن­ ها عادی محسوب نمی­شوند.

شرکت های در حال ساخت

ZKSync یک سیستم نوع ۴ است. برای نمونه، پروژه Warp Nethermind در حال ساخت یک کامپایلر از Solidity به Starkware's Cairo است که StarkNet را به یک سیستم واقعی نوع ۴ تبدیل میکند.

آینده انواع مختلف ZK-EVMها

هیچ یک از انواع مختلف ZK-EVMهایی که در بالا بررسی شد از دیگری بهتر یا بدتر نیستند، بلکه صرفا نقاط ضعف و قوت متفاوتی دارند؛ انواع با شماره کوچک‌تر (نوع۱ و نوع ۲) با زیرساخت­های موجود سازگارتر اما کندتر هستند، در مقابل انواع با شماره بالاتر (نوع۳ و نوع ۴) با زیرساخت­های موجود سازگاری کمتری دارند اما سریعتر می‌باشند.

پروژه‌های ZK-EVM می­توانند به راحتی از انواع با شماره بالاتر شروع شوند و در طول زمان به انواع با شماره کوچک‌تر تغییر کنند (یا برعکس). برای مثال:

یک ZK-EVM می‌تواند به‌ عنوان نوع ۳ شروع به کار کند و تصمیم بگیرد برخی از ویژگی‌هایی را که با اثبات ZK سخت است، شامل نشود. بعداً این پروژه می­تواند آن ویژگی­ها را به مرور زمان اضافه کرده و به نوع ۲ تبدیل گردد.

یک ZK-EVM می­تواند به عنوان نوع ۲ شروع شود و بعداً (با سازگاری کامل با اتریوم یا با یک درخت وضعیت اصلاح شده که می تواند فرآیند اثبات را سریع‌تر انجام دهد) به یک ZK-EVM هیبریدی نوع ۲ / نوع ۱ تبدیل شود. پروژه اسکرول در این جهت در حال فعالیت است.

پروژه­ای که به عنوان یک سیستم نوع ۴ شروع می­شود، می­تواند در طول زمان با افزودن قابلیت پردازش کد EVM، تبدیل به نوع ۳ شود (اگرچه توسعه‌دهندگان همچنان تشویق می­شوند که با هدف کاهش هزینه‌ها و زمان، مستقیماً از زبان‌های سطح بالا کامپایل نمایند).

یک ZK-EVM نوع ۲ یا نوع ۳ می­تواند به ZK-EVM نوع ۱ تبدیل شود اگر اتریوم خود را در جهت سازگاری بیشتر با ZK اصلاح کند.

ویتالیک بوترین، بنیانگذار شبکه اتریوم، شخصا امیدوار است که انواع مختلف اشاره شده در بالا با پیشرفت‌ در ZK-EVMها و توسعه برای سازگاری بیشتر با ZK-SNARK، به مرور زمان به نوع ۱ تبدیل شود. با این فرض، چندین پیاده‌سازی از ZK-EVMها رخ خواهد داد که می‌توانند هم برای-rollup  ZKها و هم برای اثبات خود زنجیره اتریوم استفاده شوند. با این حال، دستیابی به چنین دستاوری مدتی زمان خواهد برد و انتظار می رود روزانه شاهد نوآوری­های زیادی در مسیرهای مختلف برای مقیاس­پذیری اتریوم و Ethereum-based ZK-Rollups باشیم.

منبع

vitalik

¹ Zkمخفف Zero-Knowledge یا اثبات دانش صفر است که به وسیله آن یک طرف (اثبات کننده) می‌تواند به طرف دیگر (تأییدکننده) ثابت کند که یک عبارت درست است در حالی که اثبات‌کننده از انتقال هر گونه اطلاعات اضافی خودداری می‌کند. همچنینevm  مخفف عبارتEthereum virtual machine  یا ماشین مجازی اتریوم است. پروژه‌های zk-evm به مواردی اطلاق می­شود که مبتنی بر اثبات دانش صفر بوده و با ماشین مجازی اتریوم سازگارند.

² Open Source

³ Proof

⁴ State Trees

⁵ Transaction Trees

⁶ Execution-layer

⁷ Client: معادل نودهای مشارکت‌کننده در شبکه

⁸ Data Structures

⁹ Compile به معنای تفسیر و ترجمه کردن است در واقع، کامپایلر (Compiler) نرم افزاری است که کدهای نوشته شده به زبان سطح بالا (نزدیک به زبان انسان) توسط برنامه‌نویسان را به زبان ماشین تبدیل می‌کند؛ زیرا کامپیوترها تنها قادر به اجرای کدهای دودویی هستند و لذا کدهای سطح بالا باید به زبان ماشین ترجمه شوند که به این فرآیند اصطلاحا کامپایل کردن گفته می­شود.

¹⁰ Prover: اثبات‌کننده اجماع