بعد از بروزرسانی «اوپی استک» (OP Stack) با نام «بِدراک» (Bedrock)، گام بعدی برای بهبود قابل توجه قابلیت مقیاس‌پذیری، معرفی مفهوم «سوپرچین» (Superchain) است. سوپرچین شبکه‌ای از زنجیره‌ها است که اشتراکاتی از جمله پل‌زنی، حاکمیت غیرمتمرکز، ارتقاء، لایه ارتباطی و موارد دیگر دارند – که همگی روی اوپی استک ساخته شده‌اند.

راه‌اندازی سوپرچین، شبکه OP Mainnnet و سایر زنجیره‌ها را در یک شبکه واحد تحت عنوان «OP Chains» (یعنی زنجیره‌های درون سوپرچین) ادغام می‌کند و این یک گام مهم به سوی دستیابی به محاسبات مقیاس‌پذیر و غیرمتمرکز در سطح جهان به شمار می‌رود. هدف این سند، توصیف چشم‌انداز مقیاس‌پذیری، مفهوم سوپرچین و برخی تغییرات مورد نیاز در اوپی استک برای تحقق این چشم‌انداز است.

این توضیح با جزئیات است. برای مقدمه‌ای با اصطلاحات کمتر فنی، اینجا را کلیک کنید.

فناوری بلاک‌چین امروز برای وب غیرمتمرکز کافی نیست.

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

در واقع، در نمایشی از دوراندیشی قابل توجه، اولین پاسخ به وایت‌پیپر بیت‌کوین این بود که:

«ما به شدت، به شدت به چنین سیستمی نیاز داریم، اما با توجه به درکی که از پروپوزال شما دارم، به نظر نمی رسد قابلیت مقیاس‌پذیری به اندازه‌ی مورد نیاز داشته باشد. »

با گذشت بیش از یک دهه، این موضوع تغییری نکرده است.»

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

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

• به دلیل محیط اجرای قرارداد هوشمند مشترک، قابلیت ترکیب‌پذیری فراتر از توانایی‌های APIهای REST سنتی به طور قابل توجهی افزایش می‌یابد.

• با وجود بازارهای گس استاندارد، توسعه‌دهندگان مجبور نیستند تمام هزینه‌های زیرساخت را برای کاربران خود بپردازند. پرداخت هزینه برای یک برنامه‌ی محبوب دیگر مانعی برای ورود توسعه‌دهندگان اپلیکیشن نخواهد بود و استراتژی‌های کسب درآمد بیشتری امکان‌پذیر می‌شود.

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

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

بدون شک، وعده بلاک‌چین‌ها می‌تواند اینترنت را آنطور که می‌شناسیم، تغییر دهد.

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

با حمایت این صنعت، فکر می‌کنیم تصویری واضح از چگونگی معماری یک بلاک‌چین با قابلیت مقیاس‌پذیری واقعی شروع به شکل‌گیری کرده است. ما آن را «سوپرچین» (Superchain) می‌نامیم. این سند اصول فنی کلیدی زیربنای معماری سوپرچین، و همچنین مجموعه‌ای از پروژه‌های ملموس را تشریح می‌کند که ما معتقدیم با تکمیل آن‌ها، سرانجام چشم‌انداز مقیاس‌پذیری بلاک‌چین را محقق خواهیم کرد. این سفری چند ساله (اگر نگوییم چند دهه‌ای) خواهد بود. با این حال، اگر بدانیم تقریباً به کجا می‌رویم، کمی سریع‌تر به آنجا خواهیم رسید.

قابلیت مقیاس‌پذیری افقی به چندین زنجیره نیاز دارد...

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

رویکردهای سنتی به معماری‌های «مالتی چین» از دو مشکل اساسی رنج می‌برند:

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

2. راه‌اندازی زنجیره‌های جدید پرهزینه است زیرا به مجموعه‌های اعتبارسنج و تولیدکنندگان بلاک جدید نیاز دارند.

این مشکلات ناشی از فقدان یک بلاکچین مشترک واحد (یک زنجیره "لایه ۱") است که به عنوان منبع مشترک درستی برای همه زنجیره‌ها ("زنجیره‌های لایه ۲") در سیستم مالتی چین عمل می‌کند. با استفاده از منبع مشترک درستی، موارد زیر امکان پذیر می‌شود:

الف) اعمال مدل‌های امنیتی استاندارد در همه زنجیره‌ها؛ ب) حذف الزام به داشتن مجموعه جدیدی از اعتبارسنج‌ها برای راه‌اندازی زنجیره زیرا هر زنجیره لایه ۲ از اجماع لایه ۱ استفاده می‌کند.

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

سوپرچین شبکه‌ای از زنجیره‌های لایه ۲ (L2) است که با نام «زنجیره‌های OP» (OP Chains)شناخته می‌شوند. این زنجیره‌ها امنیت، لایه‌ای برای ارتباط و یک پشته فناوری منبع باز را به اشتراک می‌گذارند. با این حال، برخلاف طرح‌های مالتی چین، این زنجیره‌ها استانداردسازی شده‌اند و برای استفاده به عنوان منابع قابل تعویض در نظر گرفته شده‌اند. این امر امکان می‌دهد توسعه‌دهندگان برنامه‌هایی را بسازند که کل سوپرچین را هدف قرار دهند و از زنجیره‌های زیربنایی که برنامه بر روی آن‌ها اجرا می‌شود، صرف نظر کنند.

برای اینکه Optimism به یک سوپرچین ارتقا یابد، باید دارای ویژگی‌های زیر باشد:

پس از برآورده شدن این ویژگی‌ها توسط Optimism، می‌توان آن را یک سوپرچین در نظر گرفت.

ما بر این باوریم که تغییرات زیر (پس از انتشار Bedrock) برای ایجاد یک سوپرچین اولیه که امکان استقرار و ارتقای چندین زنجیره با همان پل را فراهم می‌کند، ضروری است:

ارتقای پل Bedrock به یک کارخانه‌ی زنجیره

Bedrock قرارداد SystemConfig را معرفی کرد که شروع به تعریف مستقیم زنجیره لایه ۲ با قراردادهای هوشمند لایه ۱ کرد. این قابلیت می‌تواند برای قراردادن تمام اطلاعات تعریف‌کننده‌ی زنجیره لایه ۲ روی زنجیره، از جمله ایجاد یک شناسه زنجیره منحصر به فرد، مقادیر پیکربندی کلیدی مانند محدودیت گس بلاک و غیره، گسترش یابد.

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

استخراج داده‌های زنجیره OP با استفاده از کارخانه زنجیره

Bedrock مشتق‌گیری زنجیره لایه ۲ از یک زنجیره لایه ۱ را معرفی کرد، جایی که همه داده‌های زنجیره می‌توانند بر اساس بلاک‌های لایه ۱ همگام‌سازی شوند. با گسترش کارخانه زنجیره لایه ۱ برای قرار دادن تمام پیکربندی روی زنجیره، نود های Optimism باید بتوانند هر زنجیره OP را با یک آدرس لایه ۱ به اضافه یک اتصال به لایه ۱ به صورت قطعی همگام‌سازی کنند.

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

برای رفع این مشکلات، می‌توانیم دو ویژگی را معرفی کنیم:

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

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

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

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

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

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

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

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

Bedrock قابلیت تنظیم آدرس سیکوئنسر(sequencer) را در قرارداد SystemConfig معرفی کرد. با توجه به راه‌اندازی چندین زنجیره با قراردادهای SystemConfig اختصاصی خود، می‌توانیم آدرس سیکوئنسر را برای پیکربندی توسط توسعه‌دهنده زنجیره OP فعال کنیم. ما این طراحی سیکوئنسر قابل تنظیم را توالی‌یابی ماژولار(modular sequencing) می‌نامیم. این امر امکان توالی‌یابی زنجیره‌های OP توسط نهادهای مختلف را در عین حال حفظ مدل امنیتی استاندارد [پل سوپرچین] فراهم می‌کند - که گامی اساسی به سمت غیرمتمرکزسازی سیکوئنسر است.

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

توالی‌یابی ماژولار همچنین امکان آزمایش بدون مجوز مدل‌های مختلف توالی‌یابی را فراهم می‌کند. توسعه‌دهندگان می‌توانند اجرای پروتکل‌های توالی‌یابی مانند: توالی‌یابی دوره‌ای (round robin sequencing)، پروتکل‌های اجماع سیکوئنسر، ترتیب PGA یا ترتیب FIFO را پیش‌بینی کنند. می‌توانیم انتظار داشته باشیم که با گذشت زمان، استانداردهای کاربرپسند توالی‌یابی از رقابت بین پروتکل‌های توالی‌یابی رقیب پدیدار شوند.

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

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

برای رسیدگی به پل مسدود شده، یک مکانیسم بازیابی نهایی بالقوه وجود دارد که توسط جامعه L2 مورد بحث قرار گرفته است، که ما آن را «مکانیسم بازیابی ارتقاء سافت فورک L1» می‌نامیم. این مکانیسم L1 را قادر می‌سازد تا ارتقاء پل را با یک سافت فورک آغاز کند و از تمام مجوزهای دیگر درون قراردادهای پل زنجیره فوق عبور کند. این رویکرد ممکن است ریسک سیستمی برای اتریوم به همراه داشته باشد و قبل از اجرا نیاز به تحقیق و پذیرش جامعه دارد. برای اجرای سوپرچین الزامی نیست و برای تکمیل تحقیقات مستند شده است. بدون تحقیقات بیشتر در مورد پیامدها و ایمنی، این رویکردی نیست که تیم در حال حاضر آن را تأیید کند.

مکانیسم به شرح زیر است:

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

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

ما انتظار داریم که هرگز از این دریچه خروج استفاده نشود، اما وجود آن می‌تواند رفتارهای مخرب را بازدارنده کند.

ترکیب این ویژگی‌ها منجر به سیستمی می‌شود که ویژگی‌های اصلی سوپرچین را برآورده می‌کند.

ما بر این باوریم که این ارتقاءها می‌توانند پلی مشترک برای همه زنجیره‌های OP، استقرار ارزان زنجیره‌های OP، گزینه‌های پیکربندی مهم برای زنجیره‌های OP و همچنین تراکنش‌های امن و پیام‌های چند زنجیره‌ای را فراهم کنند. از آنجایی که انتشار Bedrock قبلاً ویژگی بلاکچین اشتراکی لایه ۱ را ارائه می‌دهد، پس از اعمال این تغییرات، به همه ویژگی‌های هسته‌ای مورد نیاز برای سوپرچین دست خواهیم یافت.

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

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

• تراکنش‌های چند زنجیره‌ای کند هستند زیرا نیاز به انتظار برای دوره چالش دارند.

• تراکنش‌های چند زنجیره‌ای ناهمزمان هستند، که قابلیت انجام تراکنش‌های اتمی چند زنجیره‌ای (مانند وام‌های فلش) را از بین می‌برد.

• ارسال تراکنش به سوپرچین مقیاس‌پذیر نیست زیرا داده‌های تراکنش باید به لایه ۱ ارسال شوند که ظرفیت محدودی دارد.

• چارچوب‌های آسان برای ساخت برنامه‌های کاربردی مقیاس‌پذیر که از چندین زنجیره OP استفاده می‌کنند وجود ندارد.

• کیف پول آسانی برای مدیریت توکن‌ها و برنامه‌ها در سراسر چندین زنجیره OP وجود ندارد.

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

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

نقطه ضعف:

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

راه حل پیشنهادی:

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

نقطه ضعف:

تراکنش‌های مالتی چین کند هستند زیرا نیاز به انتظار برای دوره چالش دارند.

راه حل پیشنهادی:

اثبات خطا به دلیل نیاز به انتظار برای دوره چالش جهت نهایی‌سازی ایمن، بار تجربه‌ی کاربری (UX) را افزایش می‌دهد. این بدان معناست که بسته به طول دوره چالش شما، کاربران باید مدت زیادی منتظر بمانند تا ETH و توکن‌های آن‌ها از یک زنجیره OP به زنجیره دیگر منتقل شوند.

از طرف دیگر، اثبات اعتبار این مشکل را ندارد. اثبات اعتبار دوره‌ی چالش ندارد و بنابراین امکان برداشت فوری از یک زنجیره OP به زنجیره‌ی دیگر را فراهم می‌کند. این امر در صورتی که از کاربران انتظار می‌رود به‌طور مکرر حتی در حین اجرای عادی برنامه، بین زنجیره‌ها مهاجرت کنند، بسیار مهم است. با این حال، اثبات اعتبار معمولاً با استفاده از اثبات دانش صفر (ZKPs) پیاده‌سازی می‌شود که گران‌قیمت و مستعد اشکال است. به احتمال زیاد سال‌ها طول می‌کشد تا ZKPها به اندازه‌ی کافی برای تبدیل شدن به پروتکل اصلی ارتباط چند زنجیره‌ای، در مرحله‌ی تولید انبوه قرار بگیرند.

با این حال، در حالی که ZKPها در حال تولید انبوه هستند، می‌توان با استفاده از سیستم اثبات ماژولار OP Stack به پیام‌رسانی با تأخیر کم بین لایه ۲ به لایه ۲ دست یافت. با اثبات‌های ماژولار، استفاده از دو سیستم اثبات برای یک زنجیره امکان‌پذیر است. این امکان را برای ارائه‌ی بریج با تأخیر کم باز می‌کند که در عین حال امنیت را کاهش می‌دهد و همچنین بریج با تأخیر زیاد و امنیت بالا ارائه می‌دهد.

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

• امنیت بالا، تأخیر زیاد، اثبات خطا(پل استاندارد با امنیت بالا)

• امنیت پایین، تأخیر کم، اثبات خطا(دوره چالش کوتاه برای دستیابی به تأخیر کم)

• امنیت پایین، تأخیر کم، اثبات اعتبار (با استفاده از تأییدکنندگان زنجیره قابل اعتماد به جای ZKP)

• امنیت بالا، تأخیر کم، اثبات اعتبار (پس از آماده شدن ZKPها)

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

نقطه ضعف:

تراکنش‌های چند زنجیره‌ای ناهمزمان هستند، که قابلیت انجام تراکنش‌های اتمی چند زنجیره‌ای (مانند وام‌های فلش) را از بین می‌برد.

راه حل پیشنهادی:

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

با استفاده از یک پروتکل توالی‌یابی مشترک در هر دو زنجیره OP، می‌توان پیام‌رسانی همزمان چند زنجیره‌ای را معرفی کرد و تعاملات اتمی چند زنجیره‌ای را فعال کرد. در مثال ما، سیکوئنسرهای زنجیره A و زنجیره B هر کدام تراکنش آربیتراژ را دریافت می‌کنند، در مورد زمان گنجاندن آن به اجماع می‌رسند و سپس هر تراکنش را به طور اتمی در بلاک مرتبط قرار می‌دهند. هزینه‌ها تنها در صورتی پرداخت می‌شوند که تراکنش واقعاً در هر زنجیره گنجانده شود، به این معنی که سیکوئنسرها به جای کاربر در مثال اولیه ما، ریسک همگام‌سازی را بر عهده می‌گیرند. این پروتکل‌های توالی‌یابی مشترک را می‌توان بدون نیاز به مجوز روی لایه توالی‌یابی ماژولار سوپرچین پس از Bedrock پیاده‌سازی کرد.

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

نقطه ضعف:

ارسال تراکنش به سوپرچین مقیاس‌پذیر نیست زیرا داده‌های تراکنش باید به لایه ۱ ارسال شوند که ظرفیت محدودی دارد.

راه حل پیشنهادی:

امروزه، در دسترس بودن داده‌های لایه ۱ (DA) به اندازه‌ای مقیاس‌پذیر نیست که بتواند از مقیاس سطح اینترنت پشتیبانی کند. با این حال، با استفاده از پروتکل پلاسما که به ارائه‌دهندگان جایگزین DA اجازه می‌دهد تا DA محدودتر لایه ۱ را تکمیل کنند، می‌توان میزان داده‌های در دسترس برای زنجیره‌های OP را افزایش داد.

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

ارائه‌دهندگان دسترسی به داده (DA):

• داده‌های تراکنش را از کاربران دریافت می‌کنند.

• سپس داده‌های تراکنش را هش (hash) می‌کنند و هش را به قرارداد پلاسما ارسال می‌کنند.

• پس از ارسال هش، ارائه‌دهنده‌ی DA مدرکی را برای کاربر ارسال می‌کند که حاوی اثبات قرارگیری داده‌های تراکنش آن‌ها در هش است. اگر ارائه‌دهنده‌ی DA عملکرد درستی نداشته باشد، این مدرک را برای کاربر ارسال نمی‌کند.

چالش دسترسی به داده (DA):

• اگر ارائه‌دهنده‌ی DA مدرک را برای کاربر ارسال نکند، کاربر می‌تواند چالش دسترسی به داده را ثبت کند.

• این کار، ارائه‌دهنده‌ی DA را مجبور می‌کند تا داده‌های تراکنش را مستقیماً روی زنجیره ارسال کند (onchain).

• اگر ارائه‌دهنده‌ی DA مدرک را روی زنجیره ارسال نکند، هش حذف می‌شود.

• این امر اطمینان می‌دهد که کاربر همیشه (پس از دوره چالش) می‌تواند با زنجیره پلاسما همگام‌سازی کند.

• در صورت ازدحام شدید لایه ۱، دوره‌های چالش دسترسی به داده قابل تمدید هستند.

خروج از زنجیره پلاسما:

• کاربر همچنین می‌تواند یک تراکنش لایه ۱ برای خروج از زنجیره پلاسما به منظور تغییر ارائه‌دهنده‌ی DA خود ارسال کند.

تسویه حساب در زنجیره‌های پلاسما:

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

مزایای مقیاس‌پذیری پلاسما:

• به دلیل توانایی هش (hash) برای کاهش داده‌های با اندازه دلخواه به تعهدی با اندازه ثابت، و همچنین توانایی موازی‌سازی هش داده‌های تراکنش، می‌توان با استفاده از دسترسی به داده‌ی پلاسما به مقیاس‌پذیری افقی تقریباً کامل تعهدات داده دست یافت.

• این بدان معنی است که می‌توان برنامه‌های کاربردی با مقیاس‌پذیری عظیم مانند بازی‌ها یا رسانه‌های اجتماعی را روی زنجیره‌های پلاسما قرار داد.

  چارچوب‌های برنامه چند زنجیره‌ای

  نقطه ضعف:

  • چارچوب‌های آسانی برای ساخت برنامه‌های کاربردی مقیاس‌پذیر که از چندین زنجیره OP استفاده می‌کنند وجود ندارد.

  • کیف پول آسانی برای مدیریت ETH و توکن‌ها و برنامه‌ها در سراسر چندین زنجیره OP وجود ندارد.

  راه حل پیشنهادی (طرح کلی):

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

  اینها برخی از ابزارهایی هستند که می‌توانند توسعه بر روی سوپرچین را به تجربه‌ای بهتر تبدیل کنند:

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

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

1. نقطه انتهایی RPC سوپرچین: یکی از ویژگی‌های این چارچوب‌ها، ایجاد یک نقطه انتهایی RPC واحد است که در آن کاربران می‌توانند تراکنش‌های سوپرچین خود را ارسال کنند، صرف نظر از اینکه آن تراکنش‌ها برای کدام زنجیره OP در نظر گرفته شده‌اند. این ویژگی به کاربران امکان می‌دهد تا از تغییر مداوم شبکه خودداری کنند.

   با وجود چارچوب‌های قدرتمند برنامه چند زنجیره‌ای، استقرار برنامه‌های کاربردی چند زنجیره‌ای ممکن است به همان آسانیِ استقرار برنامه‌هایی درآید که تنها روی یک زنجیره خاص کار می‌کنند.