آینده های اتریوم II - مقاومت در برابر سانسور

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

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

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

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

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

امروزه تقریباً 90 درصد از بلوک‌های اتریوم از طریق MEV-Boost ساخته می‌شوند و تنها دو نهاد - Beaverbuild و Titan Builder - 95 درصد از این بلوک‌ها را می‌سازند. این تمرکز نگرانی هایی را در مورد مقاومت در برابر سانسور، عدالت تراکنش و تمرکززدایی طولانی مدت تولید بلوک اتریوم ایجاد می کند.

اگرچه اختلالات یا رفتار مخرب توسط این سازندگان به طور قابل توجهی بر ایمنی شبکه اتریوم تأثیر نمی گذارد، اما تهدیدی جدی برای مقاومت در برابر سانسور است. اگر همه سازندگان MEV-Boost تصمیم به سانسور تراکنش‌های کاربران خاص داشته باشند، آن کاربران فقط می‌توانند تراکنش‌ها را از طریق بلوک‌هایی ارسال کنند که توسط اعتبارسنجی‌هایی که از MEV-Boost استفاده نمی‌کنند، که حدود 10٪ از کل است. در نتیجه، پردازش چنین تراکنش هایی به طور متوسط 10 بلوک (تقریباً 2 دقیقه) طول می کشد.

این وضعیت دو مسئله اساسی را ایجاد می کند:

1. آسیب پذیری های نظارتی

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

2. رقابت ناعادلانه در پروتکل هایی مانند مزایده

دوم، سانسور می‌تواند نتایج حراج‌های زنجیره‌ای را مخدوش کند. به عنوان مثال، حراجی را در نظر بگیرید که در آن یک NFT به بالاترین پیشنهاد در هر بلوک فروخته می شود. یک سازنده بلاک می‌تواند همه پیشنهادات دیگر را سانسور کند در حالی که قیمت بسیار پایینی ارائه می‌دهد و به آنها اجازه می‌دهد NFT را با قیمتی کاهش‌یافته به دست آورند.

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

راه حل ممکن 1: فهرست گنجاندن

زمینه: پیشنهاد فهرست گنجاندن اولیه، EIP-7547

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

در اینجا یک مدل ذهنی ساده وجود دارد: قبل از اینکه سازنده یک بلوک را بسازد، پیشنهاد دهنده سفارشی را با یک "فهرست گنجاندن" ارسال می کند که بیان می کند: "این تراکنش ها را در بلوک لحاظ کنید." سازندگان باید این تراکنش ها را در بلوکی که ایجاد می کنند بگنجانند و اگر بلوکی بدون تراکنش های موجود در فهرست گنجانده شود، نامعتبر تلقی می شود.

برای اتریوم قبل از PBS، ممپول، جایی که تراکنش‌ها قبل از وارد شدن به بلوک‌ها انجام می‌شوند، در اتریوم به‌عنوان یک جزء بدون اجماع گنجانده شده است. بنابراین، از منظر لایه اجماع اتریوم، مشخص نبود که تراکنش های موجود در بلاک ها از کجا آمده اند.

یکی از دلایل اصلی که MEV منجر به سانسور شد این است که mempool یک جزء غیر اجماع است، بنابراین سازندگانی که بلوک را ایجاد کردند، اختیار کاملی بر روی تراکنش‌هایی داشتند که باید سانسور یا در بلوک گنجانده شوند.

فهرست‌های گنجاندن مکانیزمی را معرفی می‌کنند که از اعتبارسنجی‌های متعدد استفاده می‌کند تا به عنوان یک «مپول روی زنجیره» در لایه اجماع عمل کند. به این ترتیب، لایه اجماع به اندازه کافی اختیار سازندگان را برای انتخاب تراکنش ها برای ایجاد مقاومت در برابر سانسور محدود می کند.

یکی از برجسته‌ترین پیشنهادها برای اجرای فهرست گنجاندن EIP-7547 ، فهرست گنجاندن پیشرو بود. این پیشنهاد به یک پیشنهاد دهنده اجازه می داد تا حداکثر 16 تراکنش را در فهرست گنجاندن قرار دهد. مکانیسم "Forwarding" تضمین کرد که فهرست گنجاندن پیشنهادی برای بلوک N برای بلوک N+1 اعمال خواهد شد.

این پیشنهاد در ابتدا قرار بود بخشی از ارتقای پکترا اتریوم باشد، اما در نهایت کنار گذاشته شد و یکی از دلایل آن مشکلات سازگاری بین مکانیزم ارسال و EIP-3074 بود.

EIP-3074 شکلی از انتزاع حساب بومی را معرفی می‌کند که از یک کد عملیاتی به نام AUTHCALL استفاده می‌کند و یک حساب را قادر می‌سازد تا مانده چندین EOA (حساب‌های دارای مالکیت خارجی) را تنظیم کند. این مکانیسم می تواند به راحتی فهرست گنجاندن را تضعیف کند.

به عنوان مثال، فرض کنید آلیس یک تراکنش (A) را در فهرست گنجاندن گنجانده است، جایی که EOA او ETH را برای باب می فرستد. در همان زمان، او تراکنش دیگری (B) با استفاده از AUTHCALL EIP-3074 ایجاد می کند تا تمام موجودی های EOA خود را به حساب دیگری منتقل کند. بیایید فرض کنیم تراکنش B در بلوک N گنجانده شده است، در حالی که تراکنش A در فهرست گنجاندن بلوک N+1 گنجانده شده است.

مسئله کلیدی اینجاست: وقتی پیشنهاددهنده فهرست گنجاندن را ایجاد می‌کند، نمی‌داند سازنده چه تراکنش‌هایی را در بلوک فعلی وارد می‌کند. در این سناریو، تراکنش B در بلوک N، تراکنش A را نامعتبر می کند. در نتیجه، سازنده بلوک N+1 به دلیل نامعتبر بودن تراکنش A در فهرست گنجاندن، قادر به ساخت بلوک معتبر نخواهد بود.

تلاش‌هایی برای حل این مشکل از طریق محدودیت‌های اضافی در فهرست گنجاندن انجام شده است. با این حال، مسئله اصلی همچنان باقی است: EIP-3074 ذاتاً امکان دستکاری تعادل در سایر EOAها را فراهم می کند. بررسی‌های ساده، مانند تأیید آدرس «از»، نمی‌تواند تداخل بین تراکنش‌های فهرست گنجاندن و سایر تراکنش‌ها را تشخیص دهد. این مشکل در دسترس بودن داده های رایگان نامیده می شود که در مقاله "بدون ناهار رایگان - طراحی لیست گنجاندن جدید" ذکر شده است.

اگرچه EIP-3074 از ارتقای Pectra مستثنی شد، یک عملکرد مشابه - EIP-7702 - گنجانده شد. در نتیجه، این مشکلات باید قبل از پیاده سازی EIP-7547 در شبکه اصلی اتریوم حل شوند.

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

FOCIL

آیا راه حلی برای این مسائل وجود ندارد؟ اخیراً راه حلی به نام FOCIL (فهرست های گنجانده شده با انتخاب فورک) توجه قابل توجهی را در اکوسیستم اتریوم به خود جلب کرده است و یکی از محتمل ترین راه حل هایی است که در شبکه اصلی اتریوم اجرا می شود. FOCIL که به عنوان EIP-7805 پیشنهاد می‌شود، مکانیزمی را معرفی می‌کند که در آن نه تنها یک بلکه چندین نهاد فهرست‌های گنجاندن را پیشنهاد می‌کنند. مشخصات و مشخصات آن به شرح زیر است:

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

1. به جای یک پیشنهاد دهنده، یک کمیته IL متشکل از 16 عضو به طور مستقل فهرست های گنجاندن را پیشنهاد می کند.
2. فهرست گنجاندن پیشنهادی برای بلوک N در خود بلوک N گنجانده شده است، نه بلوک N+1.

جزئیات مکانیزم

ساخت فهرست گنجاندن بلوک N زمانی آغاز می شود که شکاف بلوک N-1 شروع شود. یک کمیته IL متشکل از 16 اعتبارسنجی که به‌طور تصادفی انتخاب شده‌اند، بلوک N-1 را دریافت می‌کنند، آن را به‌عنوان سر خود تنظیم می‌کنند، فهرست‌های گنجاندن مربوطه خود را می‌سازند و از طریق همتا به همتا منتشر می‌کنند.

روند ساخت و ساز 9 ثانیه به اسلات 12 ثانیه ای N-1 پایان می یابد، پس از آن کمیته دیگر نمی تواند به لیست اضافه کند. پس از دریافت این لیست ها از طریق شبکه P2P، سازنده بلوک N باید آنها را در حین ساخت بلوک شامل شود. مدت کوتاهی پس از شروع شکاف N، بلوک به پیشنهاد دهنده تحویل داده می شود.

اعتبارسنجی‌هایی که بلوک N را تأیید می‌کنند، تراکنش‌های موجود در فهرست‌های شامل را که قبلاً دریافت کرده‌اند با موارد موجود در بلوک N مقایسه می‌کنند تا از انطباق اطمینان حاصل کنند.

مزایای FOCIL نسبت به EIP-7547

در مقایسه با EIP-7547 پیشنهادی قبلی، FOCIL مزایای زیر را ارائه می دهد:

1. مقاومت بالاتر در برابر سانسور

هر شکاف شامل یک کمیته IL متشکل از 16 اعتباردهنده است که فهرست گنجاندن را می سازند. این مقاومت قوی‌تری نسبت به EIP-7547 در برابر سانسور ایجاد می‌کند، جایی که تنها یک اعتبارسنجی مسئول بود.

2. اجرای بدون درز

با استفاده از استاندارد API forkChoiceUpdate که توسط مشتریان توافقی استفاده می شود، فهرست های گنجانده شده را می توان به راحتی و به طور یکپارچه در پروتکل ادغام کرد.

3. مقاومت در برابر سانسور "زمان واقعی".

بر خلاف EIP-7547، که در آن فهرست گنجاندن پیشنهادی برای بلوک N+1 باعث تأخیر می‌شود، FOCIL شامل IL در بلوک پیشنهادی برای خود N می‌شود و به تراکنش‌ها اجازه می‌دهد بدون تأخیر ادغام شوند.

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

سازندگان قبل از نهایی کردن ساخت بلوک، IL را دریافت می‌کنند و آنها را قادر می‌سازد تا هرگونه تراکنش‌هایی را که IL را نامعتبر می‌کند، کنار بگذارند. این فرآیند ساده است: سازندگان عدم وجود و تعادل تمام EOA های درگیر در IL را ثبت می کنند و هر زمان که تغییراتی رخ می دهد این مقادیر را به روز می کنند. این روش ساده به سازندگان اجازه می‌دهد اعتبار تراکنش‌های IL را تأیید کرده و ساخت بلوک را با موفقیت کامل کنند.

نقش FOCIL در بلوک ها

FOCIL اجازه می دهد تا حداکثر 16 فهرست گنجاندن در هر بلوک، با هر لیست به حداکثر اندازه 8 کیلوبایت (8192 بایت) محدود شود. اگر در تراکنش های پیشنهادی 16 فهرست شامل همپوشانی وجود نداشته باشد، حداکثر اندازه تراکنش های IL در یک بلوک می تواند به 128 کیلوبایت برسد. این محدودیت برای به حداقل رساندن استفاده از منابع برای اعتبار سنجی طراحی شده است، زیرا فهرست های گنجاندن از طریق شبکه P2P منتشر می شوند.

بنابراین، چه مقدار از یک بلوک اتریوم را می توان با استفاده از IL تحت FOCIL ساخت؟ از لحاظ تاریخی، متوسط اندازه بلوک اتریوم حدود 80 تا 100 کیلوبایت بوده است که حداکثر آن تقریباً 300 کیلوبایت است. اگر در تراکنش‌های پیشنهادی 16 فهرست شامل همپوشانی وجود نداشته باشد، از نظر تئوری امکان ساخت یک بلوک کامل اتریوم تنها با استفاده از تراکنش‌های IL وجود دارد.

با این حال، این سناریو بعید است. از آنجایی که تراکنش‌ها در فهرست گنجاندن عموماً از ممپول عمومی تهیه می‌شوند، احتمال همپوشانی بالایی وجود دارد، مگر اینکه 16 عضو کمیته IL از پیکربندی‌های کاملاً متفاوتی استفاده کنند.

به‌طور خلاصه، انتظار می‌رود که تراکنش‌های موجود در فهرست‌های گنجاندن FOCIL بین 6 تا 10 درصد و حداکثر 100 درصد از یک بلوک اتریوم را اشغال کنند و موارد به محدوده 6 تا 10 درصد نزدیک‌تر می‌شوند، مشروط بر اینکه اعضای کمیته IL به همان ممپول عمومی نگاه کنند.

فراتر از FOCIL: ترکیب APS با FOCIL

پس زمینه APS

یکی از دلایلی که FOCIL به یک راه حل پیشرو تبدیل شده است، هم افزایی بالقوه آن با پیشنهادات جداسازی پیشنهاددهنده (APS) مانند Execution Tickets است. APS چیست و چگونه FOCIL را تکمیل می کند؟

APS جداسازی نقش های پیشنهاد دهنده و تایید کننده برای بلوک ها را پیشنهاد می کند.

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

این مشکل از طریق MEV-Boost حل شد و یک سیستم رله درون پروتکل (ePBS) برای رسیدگی به نگرانی‌های متمرکز باقی مانده پیشنهاد شده است. با این حال، آیا PBS واقعا ساختار بهینه است؟

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

لایه اجرا، با این حال، محدودیت های یکسانی ندارد. وظایفی مانند استخراج MEV و سفارش تراکنش ذاتاً پیچیده و استراتژیک هستند و به نهادهای متمرکز نیاز دارند. اگر این وظایف بر تمامی اعتبار سنجی ها تحمیل می شد، زنجیره را به سمت تمرکز می برد.

در این رابطه، فلسفه اتریوم این است که "شرکت کنندگان اجماع نباید انگیزه ای برای پیگیری کارهای پیچیده برای سود فردی داشته باشند."

از طریق PBS، اتریوم اعتبار سنجی ها را از بازیگران MEV (سازندگان، جستجوگران) جدا می کند تا سود MEV را به طور مساوی در کل شبکه توزیع کند.

با این حال، پیشنهاد دهندگان می توانند از استراتژی های غیر متعارف برای به دست آوردن سود اضافی استفاده کنند:

1. تبانی پیشنهاد دهندگان و سازندگان

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

2. بازی های زمان بندی پیشنهادی

زمان بلاک نسبتا طولانی اتریوم 12 ثانیه ای دینامیک جالبی به نام بازی های زمان بندی را معرفی می کند که در آن پیشنهاد دهندگان انتشار بلوک را به تاخیر می اندازند تا سود MEV را به حداکثر برسانند.

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

بنابراین، یک پیشنهاد دهنده چقدر می تواند انتشار را در یک شکاف (12 ثانیه) به تاخیر بیندازد؟ با توجه به مشخصات پروتکل اتریوم، برای اینکه پیشنهاد دهنده بعدی بلاک قبلی را معتبر بداند، بلاک باید از 40% اعتباردهنده ها (تأیید کنندگان) که به کمیته اسلات قبلی اختصاص داده شده اند رای دریافت کند.

در شبکه اصلی اتریوم فعلی، نقطه ای که در آن 40 درصد از آرای اعتبارسنجی دریافت می شود، تقریباً 3.8 ثانیه پس از اسلات اتفاق می افتد.

پیشنهاد دهنده ای که سعی می کند بازی های زمان بندی را انجام دهد، استراتژی به تاخیر انداختن انتشار بلوک را تا حد امکان اتخاذ می کند و منتظر می ماند تا آرای کافی (40٪ یا بیشتر) برای جلوگیری از رد توسط پیشنهاد دهنده بعدی دریافت شود.

با این حال، نتیجه همیشه با نیات پیشنهاد دهنده همسو نمی شود. اگر بلوک نتواند 40 درصد آرا را دریافت کند، پیشنهاد دهنده بعدی آن را رد خواهد کرد. در چنین مواردی، اعتباردهندگانی که به بلوک رد شده رای داده اند، به بلوکی که بخشی از زنجیره متعارف نیست رای داده اند، که منجر به کاهش مجازات می شود.

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

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

نقش APS

APS راه حلی است که برای رفع این مشکل طراحی شده است. APS ایجاد یک پیشنهاد دهنده مجزا برای لایه اجرا را پیشنهاد می کند که لایه اجماع را به طور کامل از MEV جدا می کند.

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

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

سپس، پیشنهاد دهنده زنجیره فانوس دریایی تحت APS چه وظایفی را انجام خواهد داد؟

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

مطلوب تر است که فهرست گنجاندن به جای پیشنهاد دهندگان اجرای نسبتا متمرکز تر، بر مجموعه اعتبارسنجی غیرمتمرکز لایه اجماع تکیه کند. این به کاهش احتمال تبانی مهاجمان سانسور با پیشنهاد دهندگان برای سانسور تراکنش ها کمک می کند.

بنابراین، پیشنهادات APS مانند Execution Ticket مکانیزمی را پیشنهاد می‌کنند که در آن اعتبار‌دهنده‌های لایه توافق، فهرست‌های گنجاندن را به عنوان بخشی از بلوک فانوس دریایی می‌سازند. سپس این لیست ها به عنوان پایه ای برای پیشنهاد دهنده اجرا برای ساخت و پیشنهاد بلوک کامل عمل می کنند.

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

مزایای FOCIL

FOCIL با محدود کردن هر IL به 8KB و داشتن یک کمیته IL متشکل از 16 اعتبارسنجی (که به اندازه یک لکه است) مقاومت موثر در برابر سانسور را تضمین می کند و در عین حال استفاده از منابع شبکه را در سطوح معقول حفظ می کند.

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

راه حل ممکن 2: چند پیشنهاد دهنده/سازنده همزمان

چگونه می توان چندین شرکت کننده را قادر ساخت که یک بلوک کامل را با هم پیشنهاد کنند؟ این مفهوم به عنوان "پیشنهاد کننده همزمان چندگانه" شناخته می شود.

به جای اینکه یک موجودیت واحد یک بلوک را در یک زمان پیشنهاد کند، چندین موجودیت به طور همزمان بلوک هایی را برای یک اسلات پیشنهاد می کنند.

تحت شرایط خاص، اتخاذ چنین راه حلی می تواند هزینه سانسور را به میزان قابل توجهی افزایش دهد. اتریوم مکانیزمی دارد که در آن پیشنهاد دهندگان 32 بلاک در هر دوره به طور همزمان آشکار می شوند. این راه‌اندازی امکان سناریوهایی را فراهم می‌کند که در آن شخصی می‌تواند برای سانسور تراکنش‌های خاص به پیشنهادکنندگان «رشوه» بدهد. اما اگر بلوک ها نه توسط یک نفر بلکه توسط N پیشنهاد دهنده به طور همزمان پیشنهاد شوند چه؟ در این سناریو، به کارگیری مکانیزمی مانند نکات مشروط، امکان معرفی یک "معضل زندانی" را در میان پیشنهاد دهندگان N فراهم می کند و در نتیجه هزینه سانسور را به شدت افزایش می دهد.

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

1. اگر دو یا چند پیشنهاد دهنده شامل تراکنش باشند، آلیس به هر یک از آنها یک انعام کوچک از t می دهد.
2. اگر فقط یک پیشنهاد دهنده شامل تراکنش باشد، آلیس یک انعام بزرگ از T به آن پیشنهاد دهنده می دهد.

در این حالت، پیشنهاد دهندگان خود را در سناریویی شبیه به «معضل زندانی» می‌بینند. استراتژی بهینه برای هر پیشنهاد دهنده در این بازی، گنجاندن تراکنش به جای سانسور آن است. برای اینکه باب بتواند تراکنش آلیس را با موفقیت سانسور کند، باید به همه N پیشنهاد دهنده رشوه بدهد و این به قیمت NT تمام می شود. از سوی دیگر، آلیس فقط باید حداکثر Nt خرج کند تا مطمئن شود که تراکنش او گنجانده شده است. این به طور قابل توجهی هزینه سانسور را افزایش می دهد.

این مفهوم را می توان به روش های مختلفی در بالای PBS پیاده سازی کرد. به عنوان مثال، چندین پیشنهاد دهنده می توانند بلوک ها را به طور همزمان بسازند، یا سازنده های متعدد می توانند بلوک ها را همزمان بسازند.

این بخش دو مکانیسم را برای دستیابی به این هدف در ساختار PBS معرفی می کند:

1. BRAID - پیشنهاد دهنده همزمان چندگانه
2. BuilderNet - سازنده همزمان چندگانه

بافته

نمای کلی BRAID

BRAID یک راه حل مقاوم در برابر سانسور اتریوم است که توسط Max Resnick، که بخشی از گروه مکانیزم ویژه بود، پیشنهاد شده است.

این مکانیسم مبتنی بر یک مفهوم ساده و در عین حال قدرتمند است: به جای اجرای یک زنجیره منفرد همانطور که اتریوم اکنون انجام می دهد، k زنجیره LMD-GHOST هماهنگ شده به صورت موازی اجرا می شوند. به عبارت دیگر، با BRAID، k پیشنهاد دهنده به طور همزمان بلوک های خود را برای هر شکاف تولید می کنند.

BRAID چگونه کار می کند

یک سوال واضح مطرح می شود: بلاک های k چگونه پردازش می شوند؟ از آنجایی که برای حفظ یک بلاک چین، بلوک ها در نهایت باید در یک واحد ادغام شوند، BRAID از یک قانون ترتیب از پیش تعریف شده برای ادغام آنها استفاده می کند.

برای مثال، بلوک‌ها را می‌توان با حذف موارد تکراری و مرتب‌سازی تراکنش‌ها به ترتیب نزولی کارمزدها ادغام کرد. سپس بلوک نهایی شامل تراکنش های تلفیقی و سفارش شده خواهد بود.

مزایا و محدودیت ها

BRAID چندین مزیت را ارائه می دهد:

1. مقاومت شدید در برابر سانسور

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

2. دستور تراکنش اجباری

این مکانیسم به صراحت سفارش تراکنش را تعریف می کند و آن را برای برنامه هایی مانند حراج های زنجیره ای بلادرنگ که به سفارش تراکنش حساس هستند مناسب می کند.

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

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

BuilderNet

نمای کلی BuilderNet

BuilderNet راه حلی است که توسط Flashbots برای افزایش مقاومت در برابر سانسور با اجازه دادن به چندین نهاد به عنوان سازنده بلوک به طور همزمان پیشنهاد شده است.

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

اولین نسخه BuilderNet به طور مشترک توسط Flashbots، Beaverbuild و Nethermind اداره می شود و برنامه هایی برای نصب سازندگان بیشتری در آینده وجود دارد.

برنامه های تمرکززدایی آتی برای BuilderNet

مدل چند اپراتور کنونی هنوز به عنوان یک سازنده برای ناظران خارجی ظاهر می شود و سطح مقاومت سانسوری را که می تواند به دست آورد محدود می کند. هدف انتشارات آینده BuilderNet تمرکززدایی بیشتر شبکه و افزایش مقاومت در برابر سانسور از طریق تغییرات زیر است:

1. به اشتراک گذاری جریان سفارش در بین سازندگان

نسخه های آینده BuilderNet فرآیند ساخت بلوک را غیرمتمرکز می کند و به سازنده اجازه می دهد تراکنش های سانسور شده توسط سازنده دیگر را انتخاب کند. در تئوری، تا زمانی که حداقل یک سازنده بدون سانسور وجود داشته باشد، همه تراکنش های کاربر همچنان می توانند در یک بلوک گنجانده شوند. انتظار می رود این رویکرد BuilderNet را به یک مدل واقعی سازنده چندگانه همزمان تبدیل کند.

2. زیرساخت های غیرمتمرکز

نسخه فعلی BuilderNet برای ورود تراکنش و ذخیره سازی داده به زیرساخت متمرکز متکی است و مشارکت نیاز به مجوز دارد. هدف نسخه‌های آینده رفع این مشکل با بدون مجوز ساختن BuilderNet است.

TEE برای UX و DX بهتر

BuilderNet همچنین با استفاده از Trusted Execution Environments، محیط کاربرپسندتری را برای اپلیکیشن ها، کیف پول ها، جستجوگران و کاربران ایجاد می کند.

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

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

BuilderNet در L2s

یکی از جنبه های قابل توجه BuilderNet قابلیت کاربرد بالقوه آن برای راه حل های لایه 2 است.

اتریوم L2 به طور فعال در حال توسعه سیستم‌های اثبات و معماری اعتبارسنجی غیرمتمرکز برای به ارث بردن امنیت اتریوم است. در حالی که این سیستم‌ها ایمنی وجوه کاربران را در پل‌ها تضمین می‌کنند، اما مقاومت سانسور اتریوم را به ارث نمی‌برند.

مکانیسم تراکنش اجباری برای تراکنش‌های L1 به L2 در حال حاضر حداکثر 12 تا 24 ساعت طول می‌کشد (بسته به طراحی) تا تراکنش‌ها را در L2 لحاظ کند، که مقاومت در برابر سانسور بلادرنگ را ارائه نمی‌کند.

با برون سپاری ساخت بلوک به BuilderNet، L2s می‌تواند مقاومت سانسور بالاتری نسبت به توالی‌سنج‌های منفرد داشته باشد و در عین حال توزیع مجدد MEV را از طریق سفارش تراکنش اجباری با TEE، مشابه معماری‌هایی مانند Unichain، امکان‌پذیر می‌سازد.

نتیجه گیری

در حالت ایده‌آل، بلاک چین‌ها باید در برابر سانسور مقاومت کنند و جامعه اتریوم راه‌حل‌های مختلفی را برای رسیدگی به مشکلات مقاومت در برابر سانسور ناشی از تمرکز سازنده‌ها پیشنهاد کرده است. یکی از امیدوارکننده‌ترین راه‌حل‌ها، FOCIL است، که در آن 16 تأییدکننده فهرست‌های گنجاندن را برای هر بلوک پیشنهاد می‌کنند که مقاومت سانسور کارآمد و سازگاری با APS را ارائه می‌دهد. انتظار می رود FOCIL برای گنجاندن در ارتقاء Fusaka که برای اواخر سال 2025 یا اوایل سال 2026 برنامه ریزی شده است مورد بحث قرار گیرد.

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

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

نسخه ای از این مقاله در ابتدا منتشر شد اینجا .