آشنایی با لایه سه‌های شبکه اتریوم

مقدمه

شبکه اتریوم اولین شبکه ارائه‌دهنده قراردادهای هوشمند است و بسیاری از اپلیکیشن‌های غیرمتمرکز¹ بر روی این بلاکچین ساخته شده‌ا‌ند. وجود تعداد زیادی DApp بر روی این شبکه، حجم تراکنش‌های انجام شده بر روی شبکه را بسیار بالا می‌برد. این عامل باعث افزایش هزینه کارمزد شبکه شده است. اتریوم برای افزایش مقیاس‌پذیری² از راه‌حل‌های لایه ۱³ و ۲⁴ استفاده می‌کند.

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

لایه دوم‌ها پرتکل­هایی‌اند که از امنیت لایه ۱ (اتریوم) استفاده می­کنند و یک سری از تراکنش­ها را در خارج از زنجیره اصلی اتریوم انجام داده و باعث افزایش مقیاس‌پذیری شبکه اصلی می­شوند. حال با توجه به این موضوع این پرسش مطرح می‌گردد که آیا می­توان یک پروتکل لایه ۳ ساخت که از امنیت لایه ۲ استفاده نماید. و مقیاس‌پذیری بیشتری را به آن اضافه نماید؟ مفهوم لایه سه‌ها⁶ با این پرسش آغاز می‌شود.

به طور ساده، مفهوم لایه سه بیان می­کند که در صورت وجود ساختار لایه­ای که باعث مقیاس‌پذیری درجه دو می­شود، آیا می‌توان آن لایه را مجددا روی خودش قرار داد و مقیاس­پذیری نمایی⁷(مقیاس‌پذیری در حد لایه سه) را ایجاد نمود؟ در جواب باید در نظر گرفت که چنین ایده­های ساده­ای به صورت عملی قابل استفاده نیستند. همیشه اجزایی در یک لایه وجود دارد که قابل انباشته شدن⁸نیستند و تنها یک مرتبه باعث افزایش مقیاس­پذیری خواهد شد (به عبارت دیگر نمی­توان لایه ۲ را مجددا بر روی خودش قرار داد و یک لایه ۳ ایجاد نمود و باعث افزایش مقیاس­پذیری مضاعف شد).

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

چرا نمی‌توان با قرار دادن رول­آپ­ها (لایه ۲) بر روی خودشان باعث افزایش مقیاس‌­پذیری شد؟

Rollupها¹⁰ فناوری­هایی هستند که تکنیک‌های مختلف را برای رفع دو چالش اصلی مقیاس‌­پذیری (محاسبات و داده¹¹) در یک بلاک­چین ترکیب می‌کنند.  

محاسبات توسط اثبات تقلب¹² یا SNARKها که برای پردازش و تأیید هر بلاک به تعداد بسیار کمی از بازیگران (نود¹³ و تاییدکننده¹⁴) متکی‌اند، مورد بررسی قرار می­گیرد. برای محاسبات از نودها خواسته می­شود تا حداقل محاسبات تضمین‌کننده صحت فرآیند تایید را انجام دهند. این‌گونه طرح‌ها، به ویژه SNARKها، می­توانند تقریباً بدون محدودیت، مقیاس شوند (گسترش پیدا کنند). در مورد SNARKها می‌توان به ساختن یک SNARK از SNARK‌های متعدد ادامه داد تا محاسبات را تنها به یک اثبات کاهش داد.

  اما داستان در رابطه با داده­ها متفاوت است. Rollupها از روش­های فشرده‌سازی برای کاهش مقدار داده‌ای که یک تراکنش برای ذخیره در بلاکچین نیاز دارد، استفاده می‌کنند؛ به طوری که، حجم اطلاعات¹⁵یک تراکنش معمولی برای یک ارز از ۱۰۰ به ۱۶ بایت¹⁶کاهش می‌یابد. انتقال ERC20 در یک زنجیره سازگار با ماشین مجازی اتریوم ¹⁷ از ۱۸۰ به  ۲۳ بایت و حجم  اطلاعات مورد نیاز برای یک تراکنش ZK-SNARK با حفظ حریم خصوصی می­تواند از ۶۰۰ تا ۸۰ بایت فشرده شود. به طور خلاصه Rollupها حجم اطلاعات برای هر نوع تراکنش را حدودا ۸ برابر فشرده می­­کنند. همچنین Rollupها باید داده‌ها را به صورت درون شبکه‌ای¹⁸ در بستری  قرار دهند که کاربران بتوانند به آن دسترسی داشته باشند و آن را تأیید کنند (به طوری که کاربران بتوانند به طور مستقل وضعیت Rollupها را محاسبه کرده و در صورت قطع ارتباط¹⁹ تائیدکننده­های²⁰ موجود، به‌عنوان یک تائیدکننده وارد عمل شوند).

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

پس کاربرد مناسب لایه ۳ها چیست؟

برای پاسخ به سوال بالا بهتر است به بررسی دیدگاه Starkware در رابطه با لایه ۳ها پرداخت. این پروژه توسط رمزنویس‌های[²¹ هوشمند پشتیبانی می شود و به طورخلاصه بیان می‌کند که “اگر رول‌آپ‌ها داده را ۸ برابر فشرده کنند، لایه ۳ها (رول‌آپ‌های قرار گرفته روی رول‌آپ‌های دیگر) داده‌ها را ۶۴ برابر فشرده می‌کنند”. گرچه این پروژه بسیار فراتر از این تعریف می‌باشد. نمای کلی از لایه سوم Starkware در تصویر زیر نمایش داده شده است.

اجزای موجود در لایه سوم اکوسیستم پیشنهادی Starkware عبارتند از:

• StarkNet با دسترسی به داده­های Validium: به عنوان مثال، برای استفاده عمومی توسط برنامه‌های کاربردی با حساسیت شدید نسبت به قیمت.
• سیستم‌های StarkNet اختصاصی برای برنامه‌ها²² به منظور عملکرد بهتر برنامه­­ها؛ برای مثال، با استفاده از ساختارهای ذخیره‌سازی یا فشرده‌سازی جهت دسترسی به داده‌ها.
• سیستم‌های StarkEx: مانند سیستم‌های مورد استفاده در dYdX، Sorare، Immutable و DeversiFi با دسترسی به داده توسط Rollup یا Validium که مزایای رقابتی در حوزه مقیاس‌پذیری برای StarkNet به همراه دارند.
• Privacy StarkNet: با امکان تراکنش با حفظ حریم خصوصی²³بدون گنجاندن آن ها در StarkNet عمومی (در این مورد می توان از آن به عنوان L4 نیز یاد کرد).

معرفی موارد استفاده لایه ۳ها

به طور خلاصه می‌توان سه کاربرد برای لایه ۳ها تعریف کرد.

L2 برای مقیاس­پذیری و L3 برای عملکرد سفارشی‌شده (برای مثال، حریم خصوصی)

در این حالت ضرورتی برای دو برابر کردن مقیاس‌پذیری وجود ندارد؛ بلکه صرفا یک لایه به مقیاس‌پذیری برنامه‌‌ای کاربردی کمک می‌کند و لایه‌های مجزای دیگری بنابر نیاز برای عملکردها و کاربردهای مختلف مورد استفاده قرار می‌گیرند.
L2 برای مقیاس‌پذیری عمومی و L3 برای مقیاس­پذیری سفارشی‌شده

مقیاس­ پذیری سفارشی  در انواع مختلفی وجود دارد؛ مانند:

• برنامه­های تخصصی²⁴ که برای محاسبات خود از چیزی غیر از EVM استفاده می­کنند.
• رول‌آپ‌هایی که فشرده‌سازی داده­ها در آن‌ها بر اساس نوع داده و کاربردهای مشخص بهینه‌سازی شده‌اند (شامل جدا کردن داده از “تاییدها” و جایگزینی تایید با یک SNARK به ازای کل بلاک).
• L2 برای مقیاس‌­پذیری بدون اعتماد²⁵ (برای rollupها) و L3 برای مقیاس‌­پذیری­ با اعتماد کم (برایvalidiumها)

Validiumها سیستم­هایی‌اند که از SNARK برای تأیید محاسبات استفاده می­کنند، اما دسترسی به داده‌ها را به یک شخص یا گروه ثالث و قابل اعتماد واگذار می­نمایند. Validiumها نسبت به rollupها درجه امنیت پایین­تری و هزینه کمتری دارند.

نمای کلی از ساختار دولایه و سه لایه یک شبکه

آیا واریز و برداشت در لایه ۳، ارزان‌تر و آسان‌تر می شود؟

در رابطه با مقایسه مدل سه لایه با دو لایه از این نظر می‌توان اینگونه استدلال کرد که مدل سه لایه به اکوسیستم فرعی خود اجازه می‌دهد تا درون یک رول آپ وجود داشته باشد و عملیات بین دامنه‌ای ²⁶را با هزینه خیلی کمتر درون آن اکوسیستم انجام دهد بدون اینکه نیاز به استفاده از لایه اول‌های گران‌قیمت داشته باشد. اما در عمل مشخص می‌شود که امکان تراکنش ارزان حتی بین دو لایه دوم (و حتی دو لایه سوم) متصل به یک لایه اول وجود دارد. در این رابطه یک نکته کلیدی وجود دارد: توکن­ها و سایر دارایی­ها  نباید در زنجیره اصلی (لایه اول) صادر²⁷ شده باشند. به عبارت دیگر، می‌توان یک توکن ERC20 در Arbitrum (در یک لایه ۲) داشت و یک Wrapped از آن در Optimism (یک لایه ۲ دیگر) ایجاد کرد و بدون نیاز به هیچ تراکنش لایه اولی، آن‌ها را بین این دو شبکه منتقل کرد. در ادامه عملکرد این گونه تراکنش‌ها مورد بررسی جزئی‌تر قرار می‌گیرد.

می توان تصور کرد که دو قرارداد هوشمند وجود دارد؛ قرارداد پایه بر روی آربیتروم و قرارداد توکن wrapped بر روی اپتیمیزم. برای تراکنش از آربیتروم به اپتیمزم نیاز است که توکن از قرارداد پایه ارسال و یک رسید ایجاد گردد. پس از تکمیل این فرآیند در آربیتروم، می‌توان یک اثبات از رسید در Merkle در اختیار داشت (به عبارت دیگر، نسخه هش شده آن رسید که قابل خواندن توسط قرارداد هوشمند است و در لایه اول ریشه²⁸ دارد). سپس می‌توان این رسید را به قرارداد توکن wrapped بر روی اپتیمیزم ارسال کرد تا تایید و توکن wrapped صادر گردد. برای جابجایی توکن­ها از Optimism بهArbitrum، همین فرآیند، به صورت معکوس انجام می­شود.

حتی اگر مسیر Merkle برای اثبات تراکنش در Arbitrum از لایه اول بگذرد، Optimism فقط باید ریشه وضعیت L1 را بخواند تا تراکنش را تایید کند و  هیچ تراکنش لایه اولی لازم نیست.

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

خوشبختانه هیچ یک از این مشکلات در ZK rollupها²⁹ وجود نخواهد داشت، چرا که نیازی به انتظار یک هفته‌ای برای دلایل امنیتی ندارند و صرفا به یک زمان انتظار کوتاه‌تر (حدود ۱۲ ساعت) نیاز است. فناوری نسل بعدی ZK-EVM شامل سخت افزارهای تخصصی می‌تواند برخی از این مشکلات از جمله بهینه‌سازی و تایید گروهی تراکنش‌ها را حل نماید که در ادامه به آن پرداخته می‌شود.  

راه حل لایه ۳: تقابل زمان تایید و هزینه ثابت

هزینه Rollupها برای هر تراکنش ارزان است، چرا که داده‌ها بنابر نوع کاربرد ۱۶-۶۰ بایت حجم دارند. اما برای ارسال دسته‌ای³⁰ از تراکنش‌ها به زنجیره، هزینه ثابت بالایی نیاز است. این هزینه برای رول‌آپ‌های اپتیمیزم معادل ۲۱۰۰۰ گس³¹ در لایه اول و بیش از ۴۰۰,۰۰۰ گس برای ZK-rollups می‌باشد (و در صورت استفاده STARKs معادل میلیون‌ها گس است).

البته Rollupها می‌توانند منتظر بمانند تا ۱۰ میلیون تراکنش L2 برای ارسال در یک دسته جمع شده و سپس همگی تراکنش­ها را در یک دسته ارسال کنند، اما در این صورت فاصه بین دسته‌ ها بسیار زیاد خواهد شد (افزایش زمان تائید تراکنش‌ها) و کاربران مجبورند برای دریافت یک تاییدیه با امنیت بالا زمان زیادی منتظر بمانند. بنابراین یک رابطه معکوس بین زمان و هزینه وجود خواهد داشت: فواصل طولانی دسته­ها (زمان بیشتر) با هزینه­های کمتر و فواصل کوتاه­تر دسته­ها با هزینه‌های بیشتر. این ارتباط معکوس بین زمان و هزینه در یک ZK rollup در جدول زیر نمایش داده شده است.

در محیط­های اختصاصی هر برنامه که دارای تعداد زیادی validiumهای سفارشی شده هستند، TPS³² معمولا کمتر از ۵ است؛ درنتیجه هزینه Gas برای هر تراکنش بسیار زیاد خواهد بود. مفهوم لایه ۳ به نوعی این مشکل را حل خواهد نمود. در واقع یک rollup ZK در داخل یک rollup ZK دیگر، فقط ۸۰۰۰ Gas لایه ۱ (۵۰۰ بایت برای اثبات) هزینه خواهد داشت. در این صورت جدول بالا به صورت زیر تغییر خواهد کرد:

از جدول بالا می­توان نتیجه گرفت که مشکل هزینه بالا تقریبا قابل حل است؛ گرچه رویکرد متفاوت دیگری برای حل این مشکل وجود دارد که از تایید تجمیع‌کننده³³ERC 4337 الهام گرفته شده و استراتژی آن در ادامه شرح داده می‌شود.

در این رویکرد هر validium یا rollup ZK یک ریشه حالت³⁴ را می‌پذیرد. rollup ZK پیامی را مبنی بر اثبات تایید یک دسته از تراکنش‌ها را از یک قرارداد هوشمند تأییدکننده³⁵ دریافت می­کند (این اثبات می­تواند از طریق یک SNARK ساخته شود). در این ساختار، هر ZK-rollup می­تواند اضافه شود و هر اثبات‌کننده دسته‌ای می­تواند اثبات را از هر ZKrollup جمع آوری کند. قرارداد دسته‌ای³⁶ یک بار اثبات را تأیید و سپس یک پیام را برای آن rollup ارسال می‌کندکه تضمینی برای معتبر بودن تراکنش است. هزینه هر rollup در این طرح (اگر به خوبی بهینه‌سازی شود) می‌تواند نزدیک به ۸.۰۰۰ Gas باشد.

بنابراین به جای ساختار زیر

Base Layer            ←            Rollup          ←             Validium

این ساختار را می‌توان داشت:

Base Layer          ←                  Batch Mechanism             ←                        Rollup or Validium

اما یک تفاوت مهم وجود دارد، لایه میانی به جای اینکه یک سیستم EVM پیچیده باشد، یک شی ساده شده است و درنتیجه احتمال امن بودن آن بیشتر می‌باشد.  

نتیجه­ گیری

به طور کلی یک ساختار سه لایه که راهکارهای مقیاس‌پذیری لایه ۲ به آن اضافه شده باشد، مفید نیست. در واقع ساختار Rollup برروی rollup، که در آن دو لایه rollup از یک فناوری استفاده می­کنند، مشکلات زیادی به همراه دارد. در مقابل، یک ساختار سه لایه که در آن لایه دوم و لایه سوم اهداف متفاوتی دارند، می­تواند مفیدتر باشد؛ به عبارت دیگر، Validiumها در بالای rollup ساختاری منطقی‌تر به نظر می­رسد.

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

Roll up / Validium —> Batch Mechanism —> Base Layer

از نظر عملکرد بیشتر شبیه ERC-4337 است تا یک rollup. نکته ای که وجود دارد این است که ERC-4337 معمولا به عنوان یک لایه ۲ در نظر گرفته نمی‌شود و نمی­توان یک سیستم متمرکز بر حریم خصوصی که بر روی لایه ۲ قرار می­گیرد را، لایه۳ در نظر گرفت. درنتیجه از نظر معناشناسی، اینکه چه چیزی را می‌توان در حقیقت یک لایه در نظر گرفت، مبهم است.

از نظر ایده‌های مطرح شده در این مقاله می‌توان ویژگی‌های زیر را برای لایه دوم‌ها برشمرد:

• به دنبال هدف افزایش مقیاس‌پذیری
• پیروی از الگوی “بلاکچین درون بلاکچین” و دارای مکانیزم خاص خود برای پردازش تراکنش‌ها
• بهره‌مندی از امنیت کامل بلاکچین اتریوم

بنابراین، optimistic rollupها و rollup ZKها را می­توان لایه‌ ۲ نامید، اما validiumها، طرح‌های تجمیع اثبات، ERC 4337، سیستم‌های حریم خصوصی درون شبکه و Solidity متفاوت هستند و شاید منطقی باشد که تنها برخی از آن‌ها (و نه همه) را لایه ۳ نامید. ساختار قرار دادن یک رول آپ روی خودش (multi–rollup) در حال حاضر دور از ذهن بوده و بیشتر در مباحث تئوری و نه عملی مورد بحث قرار می‌گیرد.

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

منبع

vitalik

¹ Decentralized Applications (DApps)

² Scalability

³ Layer one solutions (L1)

⁴ Layer two solutions (L2)

⁵ Off Chains

⁶ Layer three (L3)

⁷ Exponential Scaling

⁸ Stack

⁹ Starkware نام پروژه‌ای است که بر روی راه حل­های مقیاس‌پذیری اتریوم با استفاده از لایه دوم‌ها کار می­کند.

¹⁰ رول آپ (Rollup) یکی از روش­های لایه ۲ جهت افزایش مقیاس پذیری بلاکچین اتریوم است. به زبان ساده نحوه ی کار آن به این شکل است که مجموعه­ای از تراکنش­ها را به اصطلاح رول کرده و آن‌ها را به صورت آفچین در بیرون از زنجیره اصلی اتریوم پردازش نموده و سپس نتیجه­ی آن‌ها را به زنجیره اصلی منتقل می­کند و به همین دلیل رول­آپ نام گرفته است. رول آپ­ها شامل دو نوع کلی رول آپ دانش صفر(ZK Rollup)  و آپتیمیستیک رول‌آپ (Optimistic Rollup)  است. ZK Rollup و  Optimstic و Optimistic Rollup در نحوه انتشار داده‌ها روی لایه ۱ با یکدیگر تفاوت دارند.

¹¹ Data

¹² Proof of Fraud

¹³ Node

¹⁴ Validator

¹⁵ Data

¹⁶ Byte

¹⁷ EVM Compatible

¹⁸ On chain

¹⁹ Offline

²⁰ Prover

²¹ Cryptographer

²² App-specific

²³ Privacy-preserving

²⁴ Specialized Applications

²⁵ Trustless Scaling

²⁶ Cross-domain Operations

²⁷ Issue

²⁸ Rooted in L1 State

²⁹ Zero-knowledge | ZK

³⁰ همانطور که قبلا توضیح داده شد، رول­آپ­ها مجموعه‌ای از تراکنش‌ها را در یک دسته یا  batchرول کرده و آن را به لایه اول ارسال می­کنند.

³¹ Gas: هزینه تراکنشات در شبکه اتریوم با گس اندازه‌گیری می­شود که واحد آن GWEI است.

³² Transaction per Second

³³ Aggregate

³⁴ State Root

³⁵ Verifier

³⁶ Batch Handler Contract