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

‫یکی از مواردی که کمتر مورد بحث قرار گرفته، اما به هرحال بسیار مهم است، ارتقای ZK-EVM ها است که باعث اعتبارسنجی زنجیره اتریوم می شود. SNARK هایی که اجرای EVM را ثابت می کنند سال هاست که در دست توسعه هستند و این فناوری به طور فعال توسط پروتکل های لایه 2 به نام ZK rollups استفاده می شود. برخی از این ZK rollups در حال حاضر در شبکه اصلی فعال هستند و به زودی موارد بیشتری نیز ارائه می‌شوند. اما در بلند مدت، ZK-EVM ها نه تنها برای rollups خواهند بود، بلکه ما می خواهیم آنها را برای تأیید اجرای لایه 1 نیز استفاده کنیم (مراجعه کنید به : Verge)

‫هنگامی که این اتفاق بیفتد، ZK-EVM ها عملاً به نوع سوم کلاینت های اتریوم تبدیل می شوند، به همان اندازه که کلاینت های اجرایی و کلاینت های اجماع امروزی برای امنیت شبکه مهم هستند. و این به طور طبیعی یک سوال را ایجاد می کند: چگونه ZK-EVM ها با فلسفه مالتی کلاینت تعامل خواهند داشت؟ یکی از بخش های سخت در حال حاضر انجام شده است: ما در حال حاضر چندین پیاده سازی ZK-EVM داریم که به طور فعال در حال توسعه هستند. اما بخش‌های سخت دیگر باقی می‌ماند: چگونه می‌توانیم یک اکوسیستم «مالتی کلاینت» برای اثبات صحت بلاک‌های اتریوم با ZK بسازیم؟ این سوال چالش‌های فنی جالبی را به وجود می‌آورد — و البته این سوال پیش روی این است که آیا این معاوضه ارزشش را دارد یا نه.

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

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

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

‫البته من با این تحلیل مخالفم. نکته اصلی اختلاف نظر من این است که (1) اشکالات فاجعه بار به سبک 2010 نیز مهم هستند، و (2) شما هرگز در واقع فقط یک کلاینت ندارید. نکته آخر در فورک بیت کوین در سال 2013 آشکارتر شده است: شکاف زنجیره ای به دلیل اختلاف نظر بین دو نسخه مختلف کلاینت بیت کوین رخ داد، کهمشخص شد که یکی از آنها محدودیت تصادفی و غیرمستندی در تعداد آبجکت‌هایی دارد که می‌توان آن‌ها را در یک بلاک تغییر داد. از این رو، یک کلاینت در تئوری اغلب در عمل دو کلاینت است، و پنج کلاینت در تئوری ممکن است در عمل شش یا هفت کلاینت باشند — بنابراین ما فقط باید به سمت راست منحنی ریسک حرکت کنیم و حداقل چند کلاینت مختلف داشته باشیم.

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

‫نگرانی در مورد سیاست های پروتکل، به‌ویژه در زمینه 2013–14 Bitcoin OP_RETURN wars که در آن برخی از شرکت‌کنندگان آشکارا از تبعیض علیه استفاده‌های خاص از زنجیره حمایت می‌کردند، عامل مهمی در پذیرش اولیه فلسفه چند مشتری توسط اتریوم بود. هدف این بود که گرفتن این نوع تصمیمات را برای گروه کوچکی دشوارتر کند. نگرانی های خاص اکوسیستم اتریوم — یعنی اجتناب از تمرکز قدرت در خود بنیاد اتریوم — پشتیبانی بیشتری از این جهت فراهم کرد. در سال 2018، تصمیمی گرفته شد که بنیاد به طور عمدی پروتکل Ethereum PoS را اجرا نکند (یعنی چیزی که اکنون “کلاینت اجماع” نامیده می شود) و این کار را کاملاً به تیم های خارجی واگذار می کند.

‫امروزه از ZK-EVM به صورت rollup استفاده می شود. این امر با اجازه دادن به اجرای EVM گران قیمت تنها چند بار خارج از زنجیره ( off-chain) اتفاق می‌افتد، مقیاس‌گذاری را افزایش می‌دهد، و بقیه به سادگی SNARK‌های ارسال شده در زنجیره را تأیید می‌کنند که ثابت می‌کنند اجرای EVM به درستی محاسبه شده است. همچنین اجازه می دهد تا برخی از داده ها (به ویژه امضاها) در زنجیره گنجانده نشوند و در هزینه های گاز صرفه جویی شود. این به ما مزایای مقیاس‌پذیری زیادی می‌دهد، و ترکیب محاسبات مقیاس‌پذیر با ZK-EVM و داده‌های مقیاس‌پذیر با نمونه‌گیری در دسترس بودن داده‌ها می‌تواند به ما اجازه دهد تا مقیاس بسیار زیادی داشته باشیم.

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

‫ما می‌توانیم به مرور زمان هدفِ “گس به ازای هر بلاک” لایه 1 را از 15 میلیون به 1 میلیون کاهش دهیم، به اندازه‌ای که یک بلاک حاوی یک SNARK و چند عملیات واریز و برداشت باشد، اما نه چیزهای دیگر، و در نتیجه تقریباً تمام فعالیت های کاربر را مجبور به انتقال به پروتکل های لایه 2 کنیم. چنین طرحی همچنان می‌تواند از تعداد زیادی rollup در هر بلوک پشتیبانی کند: می‌توانیم از پروتکل‌های تجمیع خارج از زنجیره اجرا شده توسط سازندگان سفارشی برای جمع‌آوری SNARK‌ها از چندین پروتکل لایه ۲ و ترکیب آن‌ها در یک SNARK استفاده کنیم. در چنین دنیایی، تنها عملکرد لایه 1 این است که یک مرکز تسویه پروتکل های لایه 2 باشد، اثبات آنها را تأیید کند و گهگاه انتقال وجوه بزرگ بین آنها را تسهیل کند.

‫این رویکرد می تواند کارساز باشد، اما چندین نقطه ضعف مهم دارد:

‫عملاً ناسازگار با نسخه های قبلی است، به این معنا که بسیاری از برنامه های کاربردی مبتنی بر L1 موجود از نظر اقتصادی غیرقابل دوام هستند. وجوه کاربران تا صدها یا هزاران دلار ممکن است با بالا رفتن کارمزدها به حدی گیر کند که از هزینه تخلیه آن حساب ها بیشتر شود. این می‌تواند با اجازه دادن به کاربران برای امضای پیام‌ها برای انتخاب یک انتقال انبوه درون پروتکل به L2 مورد انتخاب خود برطرف شود (برخی ایده‌های پیاده‌سازی اولیه را در اینجا ببینید)، اما این باعث پیچیدگی در انتقال می‌شود و برای ارزان کردن آن واقعا نیاز به نوعی SNARK در لایه ۱ است. من به طور کلی طرافدار شکست سازگاری با نسخه های قبلی در مواردی مانند آپکد SELFDESTRUCT هستم، اما در این مورد بنظر میرسد که مصالحه ی مطلوبی نیست.

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

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

‫از این رو، تلاش برای یافتن راهی برای استفاده از ZK-SNARKs برای تأیید خود لایه 1 منطقی تر به نظر می رسد.

‫نوع 1 (کاملاً معادل اتریوم) ZK-EVM می تواند برای تأیید اجرای EVM یک بلوک اتریوم (لایه 1) استفاده شود. ما می‌توانیم کد SNARK بیشتری بنویسیم تا طرف اجماع یک بلوک را نیز تأیید کنیم. این یک مشکل مهندسی چالش برانگیز خواهد بود: امروزه، ZK-EVM ها برای تأیید بلوک های اتریوم از چند دقیقه تا چند ساعت طول می کشند، و تولید اثبات در زمان واقعی نیاز به یک یا چند مورد (i) بهبود در خود اتریوم برای حذف مؤلفه های غیردوستانه SNARK دارد، (ii) ) یا افزایش بهره وری بزرگ با سخت افزار تخصصی، و (iii) پیشرفت های معماری با موازی سازی بسیار بیشتر. با این حال، هیچ دلیل فنی اساسی وجود ندارد که چرا نمی توان آن را انجام داد — و بنابراین من انتظار دارم که، حتی اگر سال ها طول بکشد، انجام شود.

‫اینجا جایی است که تلاقی با الگوی مولتی کلاینت را مشاهده می‌کنیم: اگر از ZK-EVM برای تأیید لایه 1 استفاده کنیم، از کدام ZK-EVM استفاده می کنیم؟

‫من سه گزینه می بینم:

‫1- Single ZK-EVM: الگوی مولتی کلاینت را رها کنید و یک ZK-EVM را انتخاب کنید که برای تأیید بلوک ها استفاده میکنیم.

‫2- مالتی ZK-EVM بسته: روی مجموعه خاصی از چند ZK-EVM توافق کنید و در اجماع آن را ثبت کنید، و یک قانون پروتکل لایه اجماع دارید که یک بلاک برای معتبر تلقی شدن نیاز به اثبات بیش از نیمی از ZK-EVM در آن مجموعه دارد.

‫3- مالتی ZK-EVM باز: کلاینت‌های مختلف پیاده‌سازی‌های ZK-EVM متفاوتی دارند و هر کلاینت قبل از پذیرش یک بلاک به‌عنوان معتبر منتظر اثباتی است که با پیاده‌سازی خودش سازگار باشد.

‫از نظر من، (3) ایده‌آل به نظر می‌رسد، حداقل تا زمانی که فناوری ما به حدی ارتقا یابد که بتوانیم به طور رسمی ثابت کنیم که همه پیاده‌سازی‌های ZK-EVM با یکدیگر معادل هستند. در آن مرحله ما فقط می توانیم هر کدام را که کارآمدتر است را انتخاب کنیم. (1) مزایای الگوی مولتی کلاینت را قربانی می کند و (2) امکان توسعه کلاینت جدید را مسدود می کند و منجر به بروز یک اکوسیستم متمرکزتر می شود. (3) چالش هایی دارد، اما این چالش ها حداقل در حال حاضر کوچکتر از چالش های دو گزینه دیگر به نظر می رسند.

‫پیاده‌سازی (3) خیلی سخت نخواهد بود: ممکن است برای هر نوع اثبات، یک شبکه فرعی p2p داشته باشیم، و کلاینتی که از یک نوع اثبات استفاده می‌کند، به شبکه فرعی مربوطه گوش می‌دهد و منتظر می‌ماند تا مدرکی مبنی بر اینکه تایید کننده معتبر تشخیص داده میشود دریافت کند.

‫دو چالش اصلی (3) احتمالا به شرح زیر خواهند بود:

‫چالش تأخیر: یک مهاجم مخرب می تواند یک بلاک را با تأخیر منتشر کند، همراه با یک مدرک معتبر برای یک کلاینت. به طور واقع بینانه زمان زیادی طول می کشد (حتی اگر مثلاً 15 ثانیه) برای سایر کلاینت ها اثبات معتبر ایجاد کند. این زمان به اندازه کافی طولانی خواهد بود تا به طور بالقوه یک فورک موقت ایجاد کند و زنجیره را با چند شکاف مختل کند.

‫ناکارآمدی داده: یکی از مزایای ZK-SNARK ها این است که داده هایی که فقط مربوط به تأیید هستند (که گاهی اوقات “داده های شاهد” نامیده می شود) را می توان از یک بلاک حذف کرد. به عنوان مثال، هنگامی که یک امضا را تأیید کردید، نیازی به نگه داشتن امضا در یک بلاک ندارید، فقط می توانید یک بیت را ذخیره کنید که امضا معتبر است، همراه با یک مدرک در بلاک که تأیید می کند همه موارد امضاهای معتبر وجود دارد با این حال، اگر بخواهیم امکان تولید چندین نوع اثبات برای یک بلاک وجود داشته باشد، امضاهای اصلی باید واقعاً منتشر شوند.

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

‫مسئله کارایی داده باید با داشتن یک پروتکل جداگانه برای جمع آوری داده های مربوط به راستی آزمایی حل شود. برای امضا، می‌توانیم از تجمیع BLS استفاده کنیم، که ERC-4337 قبلاً از آن پشتیبانی می‌کند. دسته عمده دیگری از داده های مرتبط با تأیید، ZK-SNARK هایی هستند که برای حفظ حریم خصوصی استفاده می شوند. خوشبختانه، اینها معمولاً پروتکل‌های تجمیع خود را دارند.

‫همچنین لازم به ذکر است که تأیید لایه 1 با SNARK یک مزیت مهم دارد: این واقعیت که اجرای EVM روی زنجیره دیگر نیازی به تأیید توسط هر گره ندارد باعث می شود تا میزان اجرای EVM در حال انجام به میزان زیادی افزایش یابد. این امر می تواند با افزایش بسیار زیاد گس لیمیت لایه 1 یا با معرفی enshrined rollups یا هر دو اتفاق بیفتد.

‫ایجاد یک اکوسیستم مالتی کلاینت باز ZK-EVM به خوبی کار خواهد کرد. اما خبر واقعا خوب این است که بسیاری از این کارها در حال انجام است یا به هر حال اتفاق خواهد افتاد:

• ‫ما در حال حاضر چندین پیاده سازی قوی ZK-EVM داریم. این پیاده سازی ها هنوز نوع 1 (کاملاً معادل اتریوم) نیستند، اما بسیاری از آنها به طور فعال در آن جهت حرکت می کنند.

• ‫کار روی لایت کلاینت ها مانند Helios و Succinct ممکن است در نهایت به تأیید کامل‌تر SNARK از طرف اجماع PoS زنجیره اتریوم تبدیل شود.

• ‫کلاینت ها احتمالاً شروع به آزمایش با ZK-EVM خواهند کرد تا اجرای بلاک اتریوم را خود به خود ثابت کنند، به خصوص زمانی که کلاینت های بدون وضعیت داشته باشیم و نیازی فنی به اجرای مجدد مستقیم هر بلاک برای حفظ وضعیت وجود نداشته باشد. احتمالاً با اجرای مجدد بلاک‌های اتریوم توسط کلاینت‌هایی که بلاک‌های اتریوم را تأیید می‌کنند به اکثر کلاینت‌هایی که بلاک‌های اتریوم را با بررسی اثبات‌های SNARK تأیید می‌کنند، انتقال آهسته و تدریجی خواهیم داشت.

• ‫اکوسیستم‌های ERC-4337 و PBS احتمالاً به زودی کار خود را با فناوری‌های تجمیع مانند BLS و تجمع اثباتی آغاز می‌کنند تا در هزینه‌های گس صرفه‌جویی کنند. در تجمیع BLS، کار از قبل شروع شده است.

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

‫در آینده‌ی بلندمدت، البته همه چیز ممکن است. شاید هوش مصنوعی بتواند با استفاده از تأیید رسمی، شرایطی را ایجاد کند که بتواند به راحتی پیاده‌سازی‌های ZK-EVM را به هم نزدیک و تمام باگ‌های موجود را شناسایی و از میان بردارد. این پروژه ممکن است چیزی باشد که حتی در حال حاضر قابل شروع کردن باشد. اگر این روش تأیید رسمی موفق باشد، مکانیزم‌های مختلفی برای تضمین ادامه‌ی تمرکز زدایی سیاسی پروتکل بایستی ایجاد شود؛ شاید در آن نقطه، پروتکل “کامل” در نظر گرفته شود و هنجارهای تغییر ناپذیری قوی تر باشد. با این حال حتی اگر این آینده‌ی بلندمدت باشد، دنیای مالتی کلاینت ZK-EVM باز بمانند یک پله طبیعی به نظر می رسد که به هر حال ممکن است اتفاق بیفتد.

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

‫یکی از مواردی که کمتر مورد بحث قرار گرفته، اما به هرحال بسیار مهم است، ارتقای ZK-EVM ها است که باعث اعتبارسنجی زنجیره اتریوم می شود. SNARK هایی که اجرای EVM را ثابت می کنند سال هاست که در دست توسعه هستند و این فناوری به طور فعال توسط پروتکل های لایه 2 به نام ZK rollups استفاده می شود. برخی از این ZK rollups در حال حاضر در شبکه اصلی فعال هستند و به زودی موارد بیشتری نیز ارائه می‌شوند. اما در بلند مدت، ZK-EVM ها نه تنها برای rollups خواهند بود، بلکه ما می خواهیم آنها را برای تأیید اجرای لایه 1 نیز استفاده کنیم (مراجعه کنید به : Verge)

‫هنگامی که این اتفاق بیفتد، ZK-EVM ها عملاً به نوع سوم کلاینت های اتریوم تبدیل می شوند، به همان اندازه که کلاینت های اجرایی و کلاینت های اجماع امروزی برای امنیت شبکه مهم هستند. و این به طور طبیعی یک سوال را ایجاد می کند: چگونه ZK-EVM ها با فلسفه مالتی کلاینت تعامل خواهند داشت؟ یکی از بخش های سخت در حال حاضر انجام شده است: ما در حال حاضر چندین پیاده سازی ZK-EVM داریم که به طور فعال در حال توسعه هستند. اما بخش‌های سخت دیگر باقی می‌ماند: چگونه می‌توانیم یک اکوسیستم «مالتی کلاینت» برای اثبات صحت بلاک‌های اتریوم با ZK بسازیم؟ این سوال چالش‌های فنی جالبی را به وجود می‌آورد — و البته این سوال پیش روی این است که آیا این معاوضه ارزشش را دارد یا نه.

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

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

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

‫البته من با این تحلیل مخالفم. نکته اصلی اختلاف نظر من این است که (1) اشکالات فاجعه بار به سبک 2010 نیز مهم هستند، و (2) شما هرگز در واقع فقط یک کلاینت ندارید. نکته آخر در فورک بیت کوین در سال 2013 آشکارتر شده است: شکاف زنجیره ای به دلیل اختلاف نظر بین دو نسخه مختلف کلاینت بیت کوین رخ داد، کهمشخص شد که یکی از آنها محدودیت تصادفی و غیرمستندی در تعداد آبجکت‌هایی دارد که می‌توان آن‌ها را در یک بلاک تغییر داد. از این رو، یک کلاینت در تئوری اغلب در عمل دو کلاینت است، و پنج کلاینت در تئوری ممکن است در عمل شش یا هفت کلاینت باشند — بنابراین ما فقط باید به سمت راست منحنی ریسک حرکت کنیم و حداقل چند کلاینت مختلف داشته باشیم.

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

‫نگرانی در مورد سیاست های پروتکل، به‌ویژه در زمینه 2013–14 Bitcoin OP_RETURN wars که در آن برخی از شرکت‌کنندگان آشکارا از تبعیض علیه استفاده‌های خاص از زنجیره حمایت می‌کردند، عامل مهمی در پذیرش اولیه فلسفه چند مشتری توسط اتریوم بود. هدف این بود که گرفتن این نوع تصمیمات را برای گروه کوچکی دشوارتر کند. نگرانی های خاص اکوسیستم اتریوم — یعنی اجتناب از تمرکز قدرت در خود بنیاد اتریوم — پشتیبانی بیشتری از این جهت فراهم کرد. در سال 2018، تصمیمی گرفته شد که بنیاد به طور عمدی پروتکل Ethereum PoS را اجرا نکند (یعنی چیزی که اکنون “کلاینت اجماع” نامیده می شود) و این کار را کاملاً به تیم های خارجی واگذار می کند.

‫امروزه از ZK-EVM به صورت rollup استفاده می شود. این امر با اجازه دادن به اجرای EVM گران قیمت تنها چند بار خارج از زنجیره ( off-chain) اتفاق می‌افتد، مقیاس‌گذاری را افزایش می‌دهد، و بقیه به سادگی SNARK‌های ارسال شده در زنجیره را تأیید می‌کنند که ثابت می‌کنند اجرای EVM به درستی محاسبه شده است. همچنین اجازه می دهد تا برخی از داده ها (به ویژه امضاها) در زنجیره گنجانده نشوند و در هزینه های گاز صرفه جویی شود. این به ما مزایای مقیاس‌پذیری زیادی می‌دهد، و ترکیب محاسبات مقیاس‌پذیر با ZK-EVM و داده‌های مقیاس‌پذیر با نمونه‌گیری در دسترس بودن داده‌ها می‌تواند به ما اجازه دهد تا مقیاس بسیار زیادی داشته باشیم.

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

‫ما می‌توانیم به مرور زمان هدفِ “گس به ازای هر بلاک” لایه 1 را از 15 میلیون به 1 میلیون کاهش دهیم، به اندازه‌ای که یک بلاک حاوی یک SNARK و چند عملیات واریز و برداشت باشد، اما نه چیزهای دیگر، و در نتیجه تقریباً تمام فعالیت های کاربر را مجبور به انتقال به پروتکل های لایه 2 کنیم. چنین طرحی همچنان می‌تواند از تعداد زیادی rollup در هر بلوک پشتیبانی کند: می‌توانیم از پروتکل‌های تجمیع خارج از زنجیره اجرا شده توسط سازندگان سفارشی برای جمع‌آوری SNARK‌ها از چندین پروتکل لایه ۲ و ترکیب آن‌ها در یک SNARK استفاده کنیم. در چنین دنیایی، تنها عملکرد لایه 1 این است که یک مرکز تسویه پروتکل های لایه 2 باشد، اثبات آنها را تأیید کند و گهگاه انتقال وجوه بزرگ بین آنها را تسهیل کند.

‫این رویکرد می تواند کارساز باشد، اما چندین نقطه ضعف مهم دارد:

‫عملاً ناسازگار با نسخه های قبلی است، به این معنا که بسیاری از برنامه های کاربردی مبتنی بر L1 موجود از نظر اقتصادی غیرقابل دوام هستند. وجوه کاربران تا صدها یا هزاران دلار ممکن است با بالا رفتن کارمزدها به حدی گیر کند که از هزینه تخلیه آن حساب ها بیشتر شود. این می‌تواند با اجازه دادن به کاربران برای امضای پیام‌ها برای انتخاب یک انتقال انبوه درون پروتکل به L2 مورد انتخاب خود برطرف شود (برخی ایده‌های پیاده‌سازی اولیه را در اینجا ببینید)، اما این باعث پیچیدگی در انتقال می‌شود و برای ارزان کردن آن واقعا نیاز به نوعی SNARK در لایه ۱ است. من به طور کلی طرافدار شکست سازگاری با نسخه های قبلی در مواردی مانند آپکد SELFDESTRUCT هستم، اما در این مورد بنظر میرسد که مصالحه ی مطلوبی نیست.

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

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

‫از این رو، تلاش برای یافتن راهی برای استفاده از ZK-SNARKs برای تأیید خود لایه 1 منطقی تر به نظر می رسد.

‫نوع 1 (کاملاً معادل اتریوم) ZK-EVM می تواند برای تأیید اجرای EVM یک بلوک اتریوم (لایه 1) استفاده شود. ما می‌توانیم کد SNARK بیشتری بنویسیم تا طرف اجماع یک بلوک را نیز تأیید کنیم. این یک مشکل مهندسی چالش برانگیز خواهد بود: امروزه، ZK-EVM ها برای تأیید بلوک های اتریوم از چند دقیقه تا چند ساعت طول می کشند، و تولید اثبات در زمان واقعی نیاز به یک یا چند مورد (i) بهبود در خود اتریوم برای حذف مؤلفه های غیردوستانه SNARK دارد، (ii) ) یا افزایش بهره وری بزرگ با سخت افزار تخصصی، و (iii) پیشرفت های معماری با موازی سازی بسیار بیشتر. با این حال، هیچ دلیل فنی اساسی وجود ندارد که چرا نمی توان آن را انجام داد — و بنابراین من انتظار دارم که، حتی اگر سال ها طول بکشد، انجام شود.

‫اینجا جایی است که تلاقی با الگوی مولتی کلاینت را مشاهده می‌کنیم: اگر از ZK-EVM برای تأیید لایه 1 استفاده کنیم، از کدام ZK-EVM استفاده می کنیم؟

‫من سه گزینه می بینم:

‫1- Single ZK-EVM: الگوی مولتی کلاینت را رها کنید و یک ZK-EVM را انتخاب کنید که برای تأیید بلوک ها استفاده میکنیم.

‫2- مالتی ZK-EVM بسته: روی مجموعه خاصی از چند ZK-EVM توافق کنید و در اجماع آن را ثبت کنید، و یک قانون پروتکل لایه اجماع دارید که یک بلاک برای معتبر تلقی شدن نیاز به اثبات بیش از نیمی از ZK-EVM در آن مجموعه دارد.

‫3- مالتی ZK-EVM باز: کلاینت‌های مختلف پیاده‌سازی‌های ZK-EVM متفاوتی دارند و هر کلاینت قبل از پذیرش یک بلاک به‌عنوان معتبر منتظر اثباتی است که با پیاده‌سازی خودش سازگار باشد.

‫از نظر من، (3) ایده‌آل به نظر می‌رسد، حداقل تا زمانی که فناوری ما به حدی ارتقا یابد که بتوانیم به طور رسمی ثابت کنیم که همه پیاده‌سازی‌های ZK-EVM با یکدیگر معادل هستند. در آن مرحله ما فقط می توانیم هر کدام را که کارآمدتر است را انتخاب کنیم. (1) مزایای الگوی مولتی کلاینت را قربانی می کند و (2) امکان توسعه کلاینت جدید را مسدود می کند و منجر به بروز یک اکوسیستم متمرکزتر می شود. (3) چالش هایی دارد، اما این چالش ها حداقل در حال حاضر کوچکتر از چالش های دو گزینه دیگر به نظر می رسند.

‫پیاده‌سازی (3) خیلی سخت نخواهد بود: ممکن است برای هر نوع اثبات، یک شبکه فرعی p2p داشته باشیم، و کلاینتی که از یک نوع اثبات استفاده می‌کند، به شبکه فرعی مربوطه گوش می‌دهد و منتظر می‌ماند تا مدرکی مبنی بر اینکه تایید کننده معتبر تشخیص داده میشود دریافت کند.

‫دو چالش اصلی (3) احتمالا به شرح زیر خواهند بود:

‫چالش تأخیر: یک مهاجم مخرب می تواند یک بلاک را با تأخیر منتشر کند، همراه با یک مدرک معتبر برای یک کلاینت. به طور واقع بینانه زمان زیادی طول می کشد (حتی اگر مثلاً 15 ثانیه) برای سایر کلاینت ها اثبات معتبر ایجاد کند. این زمان به اندازه کافی طولانی خواهد بود تا به طور بالقوه یک فورک موقت ایجاد کند و زنجیره را با چند شکاف مختل کند.

‫ناکارآمدی داده: یکی از مزایای ZK-SNARK ها این است که داده هایی که فقط مربوط به تأیید هستند (که گاهی اوقات “داده های شاهد” نامیده می شود) را می توان از یک بلاک حذف کرد. به عنوان مثال، هنگامی که یک امضا را تأیید کردید، نیازی به نگه داشتن امضا در یک بلاک ندارید، فقط می توانید یک بیت را ذخیره کنید که امضا معتبر است، همراه با یک مدرک در بلاک که تأیید می کند همه موارد امضاهای معتبر وجود دارد با این حال، اگر بخواهیم امکان تولید چندین نوع اثبات برای یک بلاک وجود داشته باشد، امضاهای اصلی باید واقعاً منتشر شوند.

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

‫مسئله کارایی داده باید با داشتن یک پروتکل جداگانه برای جمع آوری داده های مربوط به راستی آزمایی حل شود. برای امضا، می‌توانیم از تجمیع BLS استفاده کنیم، که ERC-4337 قبلاً از آن پشتیبانی می‌کند. دسته عمده دیگری از داده های مرتبط با تأیید، ZK-SNARK هایی هستند که برای حفظ حریم خصوصی استفاده می شوند. خوشبختانه، اینها معمولاً پروتکل‌های تجمیع خود را دارند.

‫همچنین لازم به ذکر است که تأیید لایه 1 با SNARK یک مزیت مهم دارد: این واقعیت که اجرای EVM روی زنجیره دیگر نیازی به تأیید توسط هر گره ندارد باعث می شود تا میزان اجرای EVM در حال انجام به میزان زیادی افزایش یابد. این امر می تواند با افزایش بسیار زیاد گس لیمیت لایه 1 یا با معرفی enshrined rollups یا هر دو اتفاق بیفتد.

‫ایجاد یک اکوسیستم مالتی کلاینت باز ZK-EVM به خوبی کار خواهد کرد. اما خبر واقعا خوب این است که بسیاری از این کارها در حال انجام است یا به هر حال اتفاق خواهد افتاد:

• ‫ما در حال حاضر چندین پیاده سازی قوی ZK-EVM داریم. این پیاده سازی ها هنوز نوع 1 (کاملاً معادل اتریوم) نیستند، اما بسیاری از آنها به طور فعال در آن جهت حرکت می کنند.

• ‫کار روی لایت کلاینت ها مانند Helios و Succinct ممکن است در نهایت به تأیید کامل‌تر SNARK از طرف اجماع PoS زنجیره اتریوم تبدیل شود.

• ‫کلاینت ها احتمالاً شروع به آزمایش با ZK-EVM خواهند کرد تا اجرای بلاک اتریوم را خود به خود ثابت کنند، به خصوص زمانی که کلاینت های بدون وضعیت داشته باشیم و نیازی فنی به اجرای مجدد مستقیم هر بلاک برای حفظ وضعیت وجود نداشته باشد. احتمالاً با اجرای مجدد بلاک‌های اتریوم توسط کلاینت‌هایی که بلاک‌های اتریوم را تأیید می‌کنند به اکثر کلاینت‌هایی که بلاک‌های اتریوم را با بررسی اثبات‌های SNARK تأیید می‌کنند، انتقال آهسته و تدریجی خواهیم داشت.

• ‫اکوسیستم‌های ERC-4337 و PBS احتمالاً به زودی کار خود را با فناوری‌های تجمیع مانند BLS و تجمع اثباتی آغاز می‌کنند تا در هزینه‌های گس صرفه‌جویی کنند. در تجمیع BLS، کار از قبل شروع شده است.

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

‫در آینده‌ی بلندمدت، البته همه چیز ممکن است. شاید هوش مصنوعی بتواند با استفاده از تأیید رسمی، شرایطی را ایجاد کند که بتواند به راحتی پیاده‌سازی‌های ZK-EVM را به هم نزدیک و تمام باگ‌های موجود را شناسایی و از میان بردارد. این پروژه ممکن است چیزی باشد که حتی در حال حاضر قابل شروع کردن باشد. اگر این روش تأیید رسمی موفق باشد، مکانیزم‌های مختلفی برای تضمین ادامه‌ی تمرکز زدایی سیاسی پروتکل بایستی ایجاد شود؛ شاید در آن نقطه، پروتکل “کامل” در نظر گرفته شود و هنجارهای تغییر ناپذیری قوی تر باشد. با این حال حتی اگر این آینده‌ی بلندمدت باشد، دنیای مالتی کلاینت ZK-EVM باز بمانند یک پله طبیعی به نظر می رسد که به هر حال ممکن است اتفاق بیفتد.