محققان اتریوم گزارش داده‌اند که انتشار میانه برای یک بار اجرایی شبیه‌سازی شده ۱ مگابایتی (MiB) با استفاده از طراحی پخش قطعه‌ای EIP-8411، کمتر از یک ثانیه بوده است، در مقایسه با تقریباً پنج ثانیه هنگام ارسال بار اجرایی به عنوان یک پیام واحد.

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

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

EIP-8411 اتریوم انتظار برای کل بار اجرایی را حذف می‌کند

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

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

علاوه بر این، بحث EIP در Ethereum Magicians تغییر برنامه‌ریزی شده را به عنوان جایگزینی پیام تک‌بار EIP-7732 با تکه‌هایی که به طور مستقل قابل تأیید هستند، توصیف می‌کند. پیش‌نویس فعلی ۶۴ تکه و ساختار اثبات مرکل را پیشنهاد می‌کند که هر قطعه را به تعهد اصلی بار اجرایی متصل می‌کند. محققان گفتند که تعهد مرکل اصلی‌ترین افزوده‌ی سطح اجماع مورد نیاز برای بخش‌بندی پایه را نشان می‌دهد. جدیدترین نمونه اولیه تحقیق، فرمت گاسپ‌ساب موجود، ساختار مشبک شبکه، درجه همتا و سیستم امتیازدهی را دست‌نخورده نگه می‌دارد، در حالی که نحوه انتشار و ارسال قطعات بار اجرایی را تغییر می‌دهد.

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

شبیه‌سازی ۱ مگابایت میانه را از پنج ثانیه کاهش می‌دهد

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

در این تنظیمات، ارسال بار اجرایی به عنوان یک پیام کامل گاسپ‌ساب، تقریباً پنج ثانیه طول کشید تا به نیمی از نودهای گیرنده برسد و نزدیک به شش ثانیه در انتهای توزیع بود. نسخه قطعه‌ای تنظیم شده به میانه تقریباً ۰.۷۵ ثانیه و انتهای توزیع نزدیک به یک ثانیه رسید.

محققان تأکید می‌کنند که اندازه‌گیری‌ها از یک ابزار شبیه‌سازی که کد واقعی Prysm و go-libp2p-pubsub را در برابر یک شبکه شبیه‌سازی شده و ساعت مجازی اجرا می‌کند، به دست آمده‌اند. هر اندازه‌گیری از ده پیکربندی شبکه تصادفی استفاده کرد. شرایط شبکه اصلی ممکن است با توپولوژی، پهنای باند و مفروضات ترافیکی مدل‌سازی شده متفاوت باشد.

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

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

لایه‌های پیشرفته‌تر، ترافیک شبکه تکراری را کاهش می‌دهند

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

این نمونه اولیه آن سیستم را با آنچه نویسندگان آن "کشش‌های منظم" می‌نامند، ترکیب می‌کند. یک نود در ابتدا یک قطعه را از یک همتا درخواست می‌کند، برای یک مهلت زمانی مشخص منتظر می‌ماند و اگر همتای اول نتواند آن را تحویل دهد، به منبع دیگری می‌رود.

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

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

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

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

EIP-8411 اکنون با بحث گنجاندن در هگوتا روبرو است

EIP-8411 در حال حاضر یک ویژگی فعال شده اتریوم نیست. پیشنهاد گیت‌هاب در ۴ سپتامبر افتتاح شد و همچنان به عنوان یک EIP شبکه‌ای پیش‌نویس در انتظار بررسی برچسب خورده است. این پیشنهاد به EIP-7732، طراحی جداسازی سازنده-پیشنهاددهنده محصور اتریوم، نیاز دارد.

توسعه‌دهندگان اتریوم درخواست کرده‌اند که EIP-8411 وضعیت PFI یا "پیشنهاد شده برای گنجاندن" را برای هگوتا، ارتقاء شبکه مورد انتظار پس از گلمستردام، دریافت کند. در طول بحث اجرایی توسعه‌دهندگان اصلی در ۱۰ سپتامبر، توسعه‌دهندگان گفتند که این پیشنهاد باید توسط تماس توسعه‌دهنده لایه اجماع مورد بررسی قرار گیرد زیرا این تغییر عمدتاً بر شبکه‌سازی اجماع تأثیر می‌گذارد.

این درخواست پس از مهلت عادی PFI هگوتا ارائه شد. طرفداران آن EIP-8411 را به عنوان جایگزینی برای EIP-8142 پیشنهاد کردند که به قرار دادن بلوک‌ها در بلاپ‌ها پرداخته بود اما نگرانی‌هایی در مورد اثبات KZG سمت سازنده و استفاده مجدد از زیرشبکه‌های دسترسی به داده‌ها ایجاد کرده بود.

دستور کار ACDC #187، بحث PFI EIP-8411 را برای ۱۷ سپتامبر ساعت ۱۴:۰۰ به وقت جهانی برنامه‌ریزی کرده است. در زمان این گزارش، تماس هنوز انجام نشده بود، بنابراین هیچ تصمیمی برای گنجاندن EIP-8411 در هگوتا ثبت نشده بود.

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

پیشنهاد شبکه‌سازی با کار اتریوم در مورد افزایش ظرفیت لایه ۱ گره خورده است. محدودیت‌های گس بزرگتر می‌توانند منجر به بارهای اجرایی بزرگتر شوند و میزان داده‌ای را که اعتبارسنج‌ها باید در مهلت‌های زمانی اجماع ثابت دریافت کنند، افزایش دهند. محدودیت گس اتریوم در اواخر سال ۲۰۲۵ پس از اعلام حمایت اعتبارسنج‌ها برای افزایش، به ۶۰ میلیون رسید.

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

کد نمونه اولیه موجود است اما آزمایشی باقی می‌ماند

محققان پیاده‌سازی‌های نمونه اولیه را برای Prysm و go-libp2p-pubsub منتشر کرده‌اند. شاخه توصیه شده Prysm (variant-a) شامل مجموعه‌ای از تغییرات پشت یک پرچم –enable-segmented-payload-gossip است، در حالی که شاخه همراه libp2p سیاست‌های ارسال و درخواست مورد استفاده در مطالعه را پیاده‌سازی می‌کند.

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

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

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