TL;DR

• ePBS розроблений з увагою до безпеки Builder, надаючи Builder повний контроль над блоковими транзакціями.
• Він інтегрує Proposer-Builder Separation (PBS) безпосередньо в рівень консенсусу Ethereum, який називається In-Protocol PBS, для усунення потенційних збоїв ретрансляції та усунення єдиних точок відмови системи.
• ePBS продовжує основу PBS, зменшуючи контроль однієї сутності над блоковим вмістом, покращуючи опірність мережі до цензури та децентралізацію.
• Комітет з Часової Доставки Даних (PTC) забезпечує своєчасність та валідність транзакцій у нових блоках.

Вступ

У лютому розробник Prysm Potuz висловив занепокоєння щодо проблем довіри у головній мережі Ethereum, запропонувавши відкладення вілки Electra до 2025 року з використанням заходу взаємодії для уточнення дизайну ePBS. Однак в Ethereum-спільноті були різні думки, і деякі розробники та дослідники були занепокоєні можливими ризиками. Думки про ePBS розділені, тому сьогодні ми розглянемо, що таке ePBS та в чому він відрізняється від PBS.

Раніше ми зазначали, що механізм PBS забезпечує безпеку зобов'язання Пропонента та пояснення Забудовника, делегуючи цю відповідальність довіреним ретрансляторам. Ретранслятори зберігають вміст блоку та забезпечують, що Пропонент отримує вміст блоку, але не може легко викрасти вміст Забудовника. Однак, якщо ретранслятор є зловмисним, обидва - Пропонент та Забудовник - можуть постраждати, і вони можуть лише переключитися на інший ретранслятор і сподіватися, що він не є зловмисним. Це створює проблему: нам потрібно знайти довірену третю сторону для делегування. PBS - це рішення поза ланцюжком, яке залежить від загальної згоди спільноти та добровільного виконання, що вимагає додаткової координації та довіри.

У PBS повинна бути посередницька роль, яка виступатиме у вигляді обробника довіри третьої сторони:

• Пропоненти повинні довіряти посереднику, якщо вони хочуть продати права на вміст блоку.
• Будівельники повинні довіряти посереднику, якщо вони хочуть придбати права на блок-будівництво.

Революційний дизайн ePBS

Вбудований роздільник пропонента-будівельника

Enshrined Proposer-Builder Separation (ePBS) - це варіант PBS, інтегрований безпосередньо в консенсусний шар Ethereum, який також відомий як In-Protocol PBS. Його було розроблено для вирішення можливих відмов ретрансляції та усунення одиночних точок відмови системи. Як новий механізм консенсусу, ми зараз детальніше розглянемо ePBS, пояснюючи його основні принципи, переваги та відмінності від традиційного розподілу пропозицій та побудови (PBS).

PBS замінює потребу в довіреній ролі ретрансляції за допомогою самого протоколу Ethereum. Якщо будь-хто з Пропозерів або Білдерів вчиняє злочинно, протокол Ethereum може накладати покарання (такі як конфіскація), позбавляючи залежності від довіри до ролі третьої сторони. Це основна відмінність від PBS, де довіра є зовнішньою.

Незважаючи на це, розподіл ролей в ePBS все ще відповідає початковій структурі PBS, зменшуючи контроль одного суб'єкта над вмістом блоку, тим самим підвищуючи опір цензурі та децентралізацію мережі блокчейн.

• Пропозиція: Відповідальний за запропонування блоку, включаючи інформацію заголовка блоку.
• Будівельник: Відповідальний за конструювання вмісту блоку.

Дві основні переваги

Пряме покарання за зловмисні дії та відсутність потреби в довірі третіх осіб

Зі свого назви стає зрозуміло, що термін «Enshrined» в ePBS відображає його протокольно-інтегрований дизайн, що дозволяє пряме покарання за зловживання. Ця інтеграція непомітно перетворює модель довіри всередині системи.

1. Вбудована можливість виявлення та забезпечення виконання

   У PBS виявлення та покарання зловмисних дій ґрунтується на втручанні сторонніх осіб, таких як валідатори чи ретранслятори. У відміну від цього, ePBS, будучи протокольно-рідним, дозволяє самому протоколу безпосередньо виявляти та усувати порушення без потреби залучення зовнішніх осіб.

2. Зменшення залежності від сторонніх учасників, підвищення децентралізації

   PBS властиво залежить від зовнішнього управління або сторонніх сторін, що вводить елемент централізації довіри. Однак ePBS вбирає правила в протокол, фундаментально зменшуючи залежність від зовнішнього довіри. Цей зсув підвищує децентралізацію системи, роблячи її більш стійкою та стійкою до маніпуляцій.

*Порівняння між традиційним PBS та ePBS👇

ePBS Дизайн

Танець виконання та перевірки

У системі Proof of Stake (PoS) Ethereum час для кожного слоту розділений на інтервали по 12 секунд. У кожному слоті випадковим чином вибирається валідатор для запропонування блоку, а комітет призначається для перевірки його валідності. Якщо блок не запропоновано протягом відведеного слоту, відповідний валідатор перевірить попередній блок через 4 секунди.

Джерело: ethresearch, один слот ePBS буде оброблятися шаром консенсусу (CL) та шаром виконання (EL). Інформація про блок розповсюджується в шарі консенсусу, а потім блок подається в шар виконання для перевірки.

1. Етап блоку торгів: Забудовник починає торги та відправляє ставку Пропоненту.
2. Трансляція пропонента: пропонент вибирає переможну пропозицію і вирішує, чи використовувати список включень для побудови вмісту блоку, потім транслює блок.
3. Голосування валідаторів: Після перегляду блоку валідатори голосують на підставі їх результатів перевірки.
4. Агрегована атестація: агреговані атестації створюють агрегатори, які поєднують докази кількох валідаторів для одного й того ж блоку. Валідатори потім використовують агреговану атестацію для перевірки блоку.
5. Трансляція корисного навантаження: Розробник повинен опублікувати повне корисне навантаження виконання протягом визначеного часу.
6. Голосування PTC: Комітет з вчасності платежів (PTC) наглядає за тим, щоб перевірити, чи вчасно і чи є дійсними вантаж забудовника.
7. Пропонент наступного слоту публікує свій блок, будуючи його на повному або порожньому блоку на основі результатів голосування PTC та агрегованих свідчень. Блок з вищим відсотком своєчасних голосів PT вважається повним.

PTC - Забезпечення своєчасності та валідності транзакцій в нових блоках \Комітет з вчасності навантаження (PTC) забезпечує своєчасне та точне додавання транзакцій у нові блоки. Цей комітет складається з валідаторів (521 учасник, позичених з комітету ланцюга маяка), які перевіряють, чи завершив Будівельник заповнення транзакцій блоку та чи вони виконані правильно відповідно до правил до завершення кожного циклу створення блоку.

Говорячи простою мовою, PTC діє як наглядова команда, гарантуючи, що Забудовник вчасно здає свою роботу та включає правильні транзакції в блок. Якщо Забудовник добре справляється і вчасно подає необхідний блок, PTC підтверджує це шляхом голосування. Таким чином, мережа може визначити, які блоки є повними та дійсними, а які можуть мати проблеми або бути неповними.

За допомогою механізму голосування PTC впливає на те, чи вважати блок «повним блоком» або «порожнім блоком». Якщо PTC перевіряє своєчасність і правильність корисного навантаження, блок розпізнається як «повний блок». Якщо корисне навантаження відсутнє або корисне навантаження затримується, блок може бути позначений як «порожній блок». Ґрунтуючись на голосуванні PTC, мережа безпосередньо винагороджує або карає Ініціатора та Будівельника, щоб стимулювати своєчасне та точне будівництво блоків.

• Повний блок: Блок містить повний набір дійсних корисних навантажень, потенційно включаючи кілька транзакцій, і стан виконання транзакцій оновлюється вчасно.
• Порожній блок: блок містить дуже мало або зовсім не має транзакцій. Це може бути блоком CL, але він не оновлює стан EL.
• Відсутній блок: слот порожній. Мається на увазі блок, який був очікуваний, але не створений або успішно доданий до ланцюжка. Відсутні блоки можуть бути класифіковані як повні або порожні на основі голосування за вибір форку (блок, слот).

Censorship Resistance, Combined with the Inclusion List Design ePBS

Хоча основний дизайн ePBS ґрунтується на безпеці будівельника та надає будівельникам повний контроль над транзакціями блоку, впровадження Списку включення робить його ідеальною комбінацією для досягнення опору до цензури та децентралізації.

У наших попередніх статтях ми обговорювали CLпроцес (для докладнішої інформації, будь ласка, відвідайте: https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rgКоротко кажучи, Заявник надає Будівельнику список транзакцій, які повинні бути пріоритетними. Цей список повинен включати всі поточні активні транзакції, незалежно від того, чи вони знаходяться у пулі транзакцій. Поки у блоку є вільне місце, транзакції зі списку повинні бути включені у блок Будівельника. Якщо блок заповнений, Будівельник повинен чітко показати та підтвердити, що він визнає цей список.

Коли Builder намагається цензурувати певні транзакції, базова комісія швидко зростає через впровадження EIP-1559, оскільки блоки безперервно заповнюються транзакціями. Якщо Builder наполягатиме на додаванні фальшивих транзакцій до блоку для виконання цензури, зростання комісій зробить такі дії непомірно дорогими та непрактичними.

Короткий опис

ePBS розділяє ролі Proposer і Builder за допомогою інтеграції протоколів. Оскільки PTC діє як підмножина комітету з перевірки, він відповідає за голосування щодо дійсності та своєчасності корисного навантаження виконання, випущеного Розробником. Основна перевага ePBS полягає в тому, що він переходить від залежності від довірених третіх сторін до нагляду та покарань безпосередньо самим протоколом Ethereum, зменшуючи потребу довіряти одній організації. Це не тільки підвищує стійкість системи до цензури, але й посилює захист транзакцій за допомогою таких механізмів, як Список включення, що робить вартість цензури транзакцій непомірно високою та непрактичною.

Важливо зауважити, що ePBS надає можливість розділення Proposer-Builder на рівні протоколу, а не є обов'язковим. Головна відмінність між ePBS та іншими моделями полягає в їх механізмах оплати та довірчих моделях. При розгляді питань довіри до всього протоколу, вартість, яку слід заплатити, - це потреба зобов'язатися заплатити комісію наперед. На відміну від цього, MEV-Boost дозволяє здійснювати платежі Beacon Proposer на основі прибутків, отриманих від послідовності Execution Payload, пропонуючи більше можливостей для отримання прибутку. Можливо, одного дня ePBS зможе розвиватися до такої міри, коли передплати комісій вже не будуть необхідні - це маленька надія на майбутнє!

Посилання

@ttsao/epbs-faq0">https://hackmd.io/@ttsao/epbs-faq0

@potuz/rJ9GCnT1C"">https://hackmd.io/@potuz/rJ9GCnT1C

https://mirror.xyz/ohotties.eth/kw_7qbkOl4NV1pmpRgVwtsS-7TZff_zTmmNEOm2BbmU

https://mirror.xyz/barnabe.eth/LJUb_TpANS0VWi3TOwGx_fgomBvqPaQ39anVj3mnCOg

https://ethresear.ch/t/epbs-design-constraints/18728?u=barnabe

@potuz/ry9NirU2p"">https://hackmd.io/@potuz/ry9NirU2p

https://vitalik.eth.limo/general/2023/09/30/enshrinement.html

https://ethresear.ch/t/three-dichotomies-in-epbs/16267

https://ethresear.ch/t/the-contention-between-preconfs-and-epbs/19770?utm_source=substack&utm_medium=email

Застереження:

1. Цю статтю перепечатовано з [Uncommons], Усі авторські права належать оригінальному автору [Джоселін]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно цим займуться.
2. Відмова від відповідальності: Погляди та думки, висловлені у цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклад статті на інші мови виконується командою gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.