Ядро дизайну ePBS побудоване навколо концепції безпеки Builder, що надає Builder повний контроль над транзакціями Блок.
ePBS - це пропозиція з включення PBS безпосередньо до протоколу ETH, відома як In-Protocol PBS, з метою вирішення потенційних проблем з Реле та усунення одної точки відмови в системі.
ePBS продовжує засновуватися на базі оригінального PBS, здатного до падіння контролю над вмістом блоку однієї сутності, що підвищує здатність мережі до опору до цензури та децентралізації.
Комітет з вчасності навантаження (PTC) виступає в ролі нагляду, щоб забезпечити своєчасність та ефективність вмісту транзакцій у новому блоку.
Передмова
У лютому розробник Prysm Potuz вважає, що у мережі ETH є проблеми з довірою і пропонує відкласти форк Electra до 2025 року та використовувати подію Interop для вдосконалення дизайну ePBS. Однак у спільноті ETH щодо ePBS існують різні точки зору, деякі розробники та дослідники хвилюються щодо можливих ризиків. Щодо ePBS у всіх різні думки, сьогодні ми розберемо, що це таке? Яка різниця між ePBS і PBS?
Раніше ми згадували, що механізм PBS призначений для забезпечення безпеки обіцянок Proposer та забезпечення безпеки тлумачень Builder, тому це право передається довіреним Реле. Реле відповідає за збереження вмісту Блоку, забезпечуючи, що Proposer отримає вміст Блоку, але не зможе легко вкрасти вміст Блоку від Builder. Проте, якщо Реле є зловмисним, то Proposer та Builder страждатимуть, і їм доведеться співпрацювати з іншими Реле та сподіватися, що інші Реле не є зловмисними. Тут виникає проблема - нам потрібно знайти довіреного третього учасника для делегування довіри. Оскільки PBS - це рішення поза протоколом. PBS залежить від Консенсусу спільноти та добровільного дотримання, вимагає додаткової координації та довіри.
У ПБС має бути посередникова роль у вигляді третьої сторони, що вирішує проблеми:
Якщо Proposer бажає продати права на вміст Блок, він повинен довіряти посереднику.
Людина, яка хоче придбати право будівництва, повинна довіряти посереднику.
Революційний дизайн ePBS
Вбудований пропонувач-розділення розробників
Enshrined Proposer-Builder Separation (ePBS) - вбудований розділ пропонувальника-будівельника, який є ще одним варіантом PBS. ePBS - це пропозиція безпосереднього включення PBS до шару консенсусу ETH, тому його також називають In-Protocol PBS. Він був створений, щоб відповісти на потенційну несправність Реле та виправити одиночні несправності в системі. Як новий механізм консенсусу, ми докладніше розглянемо ePBS з метою роз'яснення його основних принципів, переваг та відмінностей від традиційного розділу пропонувальника-будівельника (PBS).
ePBS, або Embedded Proposer-Builder Separation, - це механізм, що вбудований в протокол блокчейну. Ethereum протокол замінює довірчу роль ретранслятора, якого потрібно довіряти, і якщо Proposer або Builder зловживають своїми повноваженнями, то покарання (розрізання) буде накладено самим Ethereum протоколом, а не потрібно довіряти різним ролям. Це є найбільшою відмінністю між цим та попереднім PBS протоколом, про який ми раніше говорили.
Звичайно, розподіл ролей в застосуванні ePBS продовжує базуватися на основі оригінальної PBS, що дозволяє підвищити рівень блокчейн мережі з опором до цензури та децентралізацією шляхом падіння здатності одного суб'єкта контролювати вміст блоку.
Пропонувальник: відповідає за пропозиції Блоків, включаючи інформацію заголовка Блоку
Builder: Конкретний зміст Блоку
Дві великі переваги
Пряма покарання злочинів і не потребує кредитування третьої сторони
З назви можна зрозуміти, що Enshrined в ePBS вказує на те, що протокол вбудовує роботу по прямому покаранню злочинної поведінки, а також змінюється центр довіри в цьому налаштуванні.
протокол має здатність розпізнавати та обробляти, безпосередньо покарати
PBS, визнання та покарання злочинної поведінки потребує втручання третьої сторони (валідатор, реле тощо). У ePBS, завдяки його конструкції в межах протоколу, злочинну поведінку можна визначити та обробити протоколом безпосередньо.
Не потрібно надавати відкладення третій стороні, підвищено рівень Децентралізація
PBS до певної міри залежить від зовнішнього управління або сторонньої участі, існує проблема централізації довіри. Натомість ePBS, включивши правила в протокол, з кореня зменшив потребу в довірі до зовнішніх сторонніх учасників, підвищив рівень Децентралізація системи.
*Порівняльна схема традиційного PBS та ePBS
Дизайн ePBS
Танець виконання та перевірки
В Ethereum POS, час слота розділяється на інтервали по 12 секунд. У кожному слоті випадковим чином обирається валідатор, щоб запропонувати Блок. В той же час визначається комітет, щоб перевірити дійсність Блоку. Якщо Блок не пропонується протягом визначеного слоту, через 4 секунди валідатори, що відповідають за підтвердження, перевірятимуть попередній Блок.
source：ethresearch，один еПБС слот буде оброблятися CL (шара консенсусу) та EL (шар виконання). Інформація про Блок буде розповсюджена на шарі консенсусу, після чого Блок буде переданий на виконавчий шар для перевірки.
Етап БлокТорги: Bulider почне Торги та надішле їх Proposer.
proposer 广播：Proposer вибирає Торги та вирішує, чи використовувати список включень для побудови власного вмісту Блок. Потім він транслює Блок.
Валідатори голосують: після отримання блоку вони голосують залежно від його результатів перевірки.
Агрегатне підтвердження: Агрегатори створюють агрегатне підтвердження шляхом агрегування підтверджень від декількох валідаторів для того ж самого Блоку. Валідатори проводять перевірку за допомогою агрегатного підтвердження.
передача вещания: Builder повинен публічно розкрити повний виконавчий навантаження (ution Payload) протягом встановленого часу.
Голосування PTC: спеціальний комітет, який контролює та перевіряє, чи вчасно та ефективно виконується навантаження Builder.
Наступний Proposer слот публікує свій Блок, побудований на основі результатів голосування PTC та агрегованого доказу, на повному блоку або порожньому блоку. Якщо відсоток своєчасно публікованих голосів PT у блоку є вищим, то цей блок вважається повним блоком.
PTC, наглядач вмісту та своєчасності та ефективності угод в новому блоку
Комітет з вчасності навантаження (PTC), "Комітет з вчасності навантаження". Основна мета полягає в забезпеченні того, що вміст транзакцій у новому блоку може бути доданий вчасно та точно. Цей комітет складається з валідаторів (які є частиною комітету, позиченого від комітету зі знаками 521 особа), їх завданням є перевірка того, чи завершив Білдер заповнення транзакцій у кожному циклі створення блоку та чи вони виконуються правильно згідно правил.
Просто кажучи, PTC схожий на команду нагляду, яка спостерігає за тим, чи вчасно подається робота Builder, чи містить правильні блоки транзакцій. Якщо Builder працює добре і вчасно подає вимогам відповідні блоки, PTC підтверджує це шляхом голосування. Таким чином, мережа може знати, які блоки є повними та дійсними, а які можуть мати проблеми або бути неповними.
За допомогою механізму голосування PTC впливає на стан блоку, який може бути визнаний як «повний блок» або «Порожній блок». Якщо PTC перевіряє своєчасність та правильність завантаження, то цей блок може бути визнаний як «повний блок»; якщо немає завантаження або завантаження затримується, то блок може бути позначений як «Порожній блок». Після цього, залежно від результатів голосування PTC, мережа прямо надає винагороду або покарання Proposer та Builder, щоб стимулювати своєчасну та точну побудову блоків.
Повний блок (full block): Блок, що містить набір дійсних даних, він також може містити кілька транзакцій, і стан виконання транзакцій буде оновлюватися негайно.
Порожній блок（empty block）：Блок几乎没有包含任何交易，或者只包含极少数交易。它可以 быть CL блоком, але не буде оновлювати стан EL.
Відсутній блок (missing block): порожній слот. Блок, який повинен бути присутнім у блокчейні, але не був створений або успішно доданий до у блокчейні. Відсутній блок може бути класифікований як повний блок або порожній блок за допомогою голосування (блок, слот) вибору форка.
Реалізація ePBS зі спротивом до цензури, поєднана з дизайном Inclusion List
Незважаючи на те, що центральним пунктом дизайну ePBS є концепція безпеки для Builder, вона надає Builder повний контроль над Блок-транзакціями. Таким чином, застосування списку включень буде ідеальною комбінацією для досягнення антицензурності та Децентралізації.
Раніше в наших статтях ми згадували CL і взагалі розповідали про процес (детальніше можна перейти за посиланням: undefined). ** Передайте цей список Builder, пріоритет слід віддавати цим угодам. Це має охоплювати всі поточні активні угоди, незалежно від того, чи вони є у дорозі. Якщо Блок залишається вільним, угоди зі списку мають бути включені у Блок Builder. Якщо Блок заповнений, Builder повинен чітко позначити це і підтвердити, що вони помітили цей список.
Коли Builder намагається переглянути деякі транзакції, Блок, який постійно заповнюється транзакціями, через впровадження EIP-1559, призводить до швидкого підйому базової комісії. Якщо в цей час Builder продовжує перевіряти, додавши фальшиві транзакції до Блоку, постійно зростаючі витрати зроблять цю поведінку непрактичною.
Підсумок
ePBS розділяє ролі пропонента та будівельника через вбудований протокол. PTC, як підмножина відомчої комісії, відповідає за голосування щодо валідності та своєчасності випуску Builder ution Payload. Основною перевагою є перетворення ролі традиційного довірчого третього лиця виконання нагляду та покарання з боку самого протоколу Ethereum, що зменшує потребу в довірі до єдиного суб'єкта. Це не тільки підвищує З спротивом до цензури системи, але й забезпечує захист транзакцій за допомогою механізмів, таких як Inclusion List, що робить високі витрати на перевірку транзакцій нереальними.
Додатково заявляю, що ePBS просто надає можливість розділення Блок Proposer та Builder на рівні протоколу, а не є обов'язковим. Їх найбільшим відмінністю є механізм платежів та модель довіри. При розгляді питання довіри до всього протоколу, потрібно заплатити певну ціну, передбачаючи витрати. Порівняно з ePBS, MEV-Boost може вирішити суму, яку слід заплатити Beacon Proposer, залежно від отриманого прибутку від власного упорядкування ураженого Payload, маючи більше прибутку та простору. Можливо, якщо механізм ePBS буде реалізований якось без необхідності викупувати передоплату, можна мати невеличку фантазію та очікування в майбутньому!
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Криза довіри експерименту з вбудованим протоколом ePBS
У кількох словах
Передмова
У лютому розробник Prysm Potuz вважає, що у мережі ETH є проблеми з довірою і пропонує відкласти форк Electra до 2025 року та використовувати подію Interop для вдосконалення дизайну ePBS. Однак у спільноті ETH щодо ePBS існують різні точки зору, деякі розробники та дослідники хвилюються щодо можливих ризиків. Щодо ePBS у всіх різні думки, сьогодні ми розберемо, що це таке? Яка різниця між ePBS і PBS?
Раніше ми згадували, що механізм PBS призначений для забезпечення безпеки обіцянок Proposer та забезпечення безпеки тлумачень Builder, тому це право передається довіреним Реле. Реле відповідає за збереження вмісту Блоку, забезпечуючи, що Proposer отримає вміст Блоку, але не зможе легко вкрасти вміст Блоку від Builder. Проте, якщо Реле є зловмисним, то Proposer та Builder страждатимуть, і їм доведеться співпрацювати з іншими Реле та сподіватися, що інші Реле не є зловмисними. Тут виникає проблема - нам потрібно знайти довіреного третього учасника для делегування довіри. Оскільки PBS - це рішення поза протоколом. PBS залежить від Консенсусу спільноти та добровільного дотримання, вимагає додаткової координації та довіри.
У ПБС має бути посередникова роль у вигляді третьої сторони, що вирішує проблеми:
Революційний дизайн ePBS
Вбудований пропонувач-розділення розробників
Enshrined Proposer-Builder Separation (ePBS) - вбудований розділ пропонувальника-будівельника, який є ще одним варіантом PBS. ePBS - це пропозиція безпосереднього включення PBS до шару консенсусу ETH, тому його також називають In-Protocol PBS. Він був створений, щоб відповісти на потенційну несправність Реле та виправити одиночні несправності в системі. Як новий механізм консенсусу, ми докладніше розглянемо ePBS з метою роз'яснення його основних принципів, переваг та відмінностей від традиційного розділу пропонувальника-будівельника (PBS).
ePBS, або Embedded Proposer-Builder Separation, - це механізм, що вбудований в протокол блокчейну. Ethereum протокол замінює довірчу роль ретранслятора, якого потрібно довіряти, і якщо Proposer або Builder зловживають своїми повноваженнями, то покарання (розрізання) буде накладено самим Ethereum протоколом, а не потрібно довіряти різним ролям. Це є найбільшою відмінністю між цим та попереднім PBS протоколом, про який ми раніше говорили.
Звичайно, розподіл ролей в застосуванні ePBS продовжує базуватися на основі оригінальної PBS, що дозволяє підвищити рівень блокчейн мережі з опором до цензури та децентралізацією шляхом падіння здатності одного суб'єкта контролювати вміст блоку.
Дві великі переваги
Пряма покарання злочинів і не потребує кредитування третьої сторони
З назви можна зрозуміти, що Enshrined в ePBS вказує на те, що протокол вбудовує роботу по прямому покаранню злочинної поведінки, а також змінюється центр довіри в цьому налаштуванні.
PBS, визнання та покарання злочинної поведінки потребує втручання третьої сторони (валідатор, реле тощо). У ePBS, завдяки його конструкції в межах протоколу, злочинну поведінку можна визначити та обробити протоколом безпосередньо.
PBS до певної міри залежить від зовнішнього управління або сторонньої участі, існує проблема централізації довіри. Натомість ePBS, включивши правила в протокол, з кореня зменшив потребу в довірі до зовнішніх сторонніх учасників, підвищив рівень Децентралізація системи.
*Порівняльна схема традиційного PBS та ePBS
Дизайн ePBS
Танець виконання та перевірки
В Ethereum POS, час слота розділяється на інтервали по 12 секунд. У кожному слоті випадковим чином обирається валідатор, щоб запропонувати Блок. В той же час визначається комітет, щоб перевірити дійсність Блоку. Якщо Блок не пропонується протягом визначеного слоту, через 4 секунди валідатори, що відповідають за підтвердження, перевірятимуть попередній Блок.
source：ethresearch，один еПБС слот буде оброблятися CL (шара консенсусу) та EL (шар виконання). Інформація про Блок буде розповсюджена на шарі консенсусу, після чого Блок буде переданий на виконавчий шар для перевірки.
PTC, наглядач вмісту та своєчасності та ефективності угод в новому блоку
Комітет з вчасності навантаження (PTC), "Комітет з вчасності навантаження". Основна мета полягає в забезпеченні того, що вміст транзакцій у новому блоку може бути доданий вчасно та точно. Цей комітет складається з валідаторів (які є частиною комітету, позиченого від комітету зі знаками 521 особа), їх завданням є перевірка того, чи завершив Білдер заповнення транзакцій у кожному циклі створення блоку та чи вони виконуються правильно згідно правил.
Просто кажучи, PTC схожий на команду нагляду, яка спостерігає за тим, чи вчасно подається робота Builder, чи містить правильні блоки транзакцій. Якщо Builder працює добре і вчасно подає вимогам відповідні блоки, PTC підтверджує це шляхом голосування. Таким чином, мережа може знати, які блоки є повними та дійсними, а які можуть мати проблеми або бути неповними.
За допомогою механізму голосування PTC впливає на стан блоку, який може бути визнаний як «повний блок» або «Порожній блок». Якщо PTC перевіряє своєчасність та правильність завантаження, то цей блок може бути визнаний як «повний блок»; якщо немає завантаження або завантаження затримується, то блок може бути позначений як «Порожній блок». Після цього, залежно від результатів голосування PTC, мережа прямо надає винагороду або покарання Proposer та Builder, щоб стимулювати своєчасну та точну побудову блоків.
Реалізація ePBS зі спротивом до цензури, поєднана з дизайном Inclusion List
Незважаючи на те, що центральним пунктом дизайну ePBS є концепція безпеки для Builder, вона надає Builder повний контроль над Блок-транзакціями. Таким чином, застосування списку включень буде ідеальною комбінацією для досягнення антицензурності та Децентралізації.
Раніше в наших статтях ми згадували CL і взагалі розповідали про процес (детальніше можна перейти за посиланням: undefined). ** Передайте цей список Builder, пріоритет слід віддавати цим угодам. Це має охоплювати всі поточні активні угоди, незалежно від того, чи вони є у дорозі. Якщо Блок залишається вільним, угоди зі списку мають бути включені у Блок Builder. Якщо Блок заповнений, Builder повинен чітко позначити це і підтвердити, що вони помітили цей список.
Коли Builder намагається переглянути деякі транзакції, Блок, який постійно заповнюється транзакціями, через впровадження EIP-1559, призводить до швидкого підйому базової комісії. Якщо в цей час Builder продовжує перевіряти, додавши фальшиві транзакції до Блоку, постійно зростаючі витрати зроблять цю поведінку непрактичною.
Підсумок
ePBS розділяє ролі пропонента та будівельника через вбудований протокол. PTC, як підмножина відомчої комісії, відповідає за голосування щодо валідності та своєчасності випуску Builder ution Payload. Основною перевагою є перетворення ролі традиційного довірчого третього лиця виконання нагляду та покарання з боку самого протоколу Ethereum, що зменшує потребу в довірі до єдиного суб'єкта. Це не тільки підвищує З спротивом до цензури системи, але й забезпечує захист транзакцій за допомогою механізмів, таких як Inclusion List, що робить високі витрати на перевірку транзакцій нереальними.
Додатково заявляю, що ePBS просто надає можливість розділення Блок Proposer та Builder на рівні протоколу, а не є обов'язковим. Їх найбільшим відмінністю є механізм платежів та модель довіри. При розгляді питання довіри до всього протоколу, потрібно заплатити певну ціну, передбачаючи витрати. Порівняно з ePBS, MEV-Boost може вирішити суму, яку слід заплатити Beacon Proposer, залежно від отриманого прибутку від власного упорядкування ураженого Payload, маючи більше прибутку та простору. Можливо, якщо механізм ePBS буде реалізований якось без необхідності викупувати передоплату, можна мати невеличку фантазію та очікування в майбутньому!