Агрегації комітетів із розподіленими валідаторами Пропозиція додати дві нові кінцеві точки до API маяка, що дозволить клієнтам валідатора DVT підтримувати агрегації комітетів.

Абхішек Кумар

8 грудня 2022 р •5 хвилин читання

Основні принципи агрегування комітетів

Сьогодні ми хочемо поговорити про два обов’язки агрегації в Ethereum proof of stake і про те, як розподілене проміжне програмне забезпечення валідатора, таке як Charon , може підтримувати їх.

Протокол Ethereum має два види комітетів: комітети маяків і комітети синхронізації . Комітети — це підмножини повного набору активних валідаторів, які використовуються для розподілу загального робочого навантаження.

Комітети маяків керують атестаціями для протоколу консенсусу, тоді як комітети синхронізації дозволяють легким клієнтам швидко та надійно визначати голову ланцюга маяків.

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

Обов’язки агрегації передбачають об’єднання (агрегування) кількох стандартних повідомлень обов’язків в одне повідомлення Aggregate And Proof . Це агрегування забезпечується схемою підпису BLS, яка використовується в Ethereum, що дозволило масштабувати ланцюжок маяків підтвердження частки до сотень тисяч валідаторів.

Ці обов’язки агрегації складніші за стандартні. По-перше, кожен валідатор у комітеті повинен створити підтвердження вибору, яким є підпис BLS. Підтвердження вибору передається до функції IsAggregator , яка визначає, чи є цей валідатор агрегатором для цього слота чи ні. Якщо валідатор є агрегатором, він інформує свого консенсусного клієнта про підписку на асоційовану підмережу комітету, яка прослуховує повідомлення для агрегування. Через деякий час він отримає сукупність зібраних повідомлень і об’єднає її з підтвердженням вибору в повідомлення під назвою Агрегат і доказ(A&P). Потім валідатор підписує A&P і надсилає його до ланцюжка маяків. Важливо зазначити, що підписаний агрегат і доказ є вкладеним підписом, який містить підтвердження вибору всередині нього.

Поточна проблема у виконанні агрегацій комітетів за допомогою розподілених валідаторів

Для архітектури проміжного програмного забезпечення DVT, такої як Obol, кожен клієнт валідатора (VC) у кластері має доступ лише до частки приватного ключа , а не до повного приватного ключа. У контексті DVT підпис, який генерує приватний ключ, називається частковим підписом . DVT об’єднує кворум цих часткових підписів за допомогою агрегації порогових значень BLS у остаточний підпис, який надсилається до ланцюжка маяків, який називається комбінованим підписом.

Це означає, що доказ вибору, який генерує DVT VC, є частковим доказом вибору . Використання часткового підтвердження вибору у функції Is Aggregator дає неправильні результати, тому VC не може правильно визначити, чи є він агрегатором чи ні. Крім того, об’єднання часткового підтвердження вибору в підписаному агрегаті та підтверджувальному повідомленні дає різні результати, які не можуть бути агреговані пороговими значеннями клієнтом проміжного програмного забезпечення DVT.

Таким чином, VC має якимось чином отримати доступ до повного комбінованого підтвердження вибору , щоб виконувати свої обов’язки з агрегації.

Пропоноване рішення

Ми працювали з ключовими зацікавленими сторонами консенсусного рівня ( 1 , 2 ), щоб створити ненав’язливе, беззламне доповнення до API-маяка, додавши дві нові кінцеві точки, які дозволяють венчурним клієнтам запитувати у клієнта проміжного програмного забезпечення (Charon) комбіноване підтвердження вибору шляхом надання часткового підтвердження вибору .

• POST /eth/v1/validator/beacon_committee_selections
• POST /eth/v1/validator/sync_committee_selections

VC, які підтримують DVT проміжного програмного забезпечення, ПОВИННІ викликати ці кінцеві точки на ПОЧАТКУ слота, щоб отримати комбіноване підтвердження вибору для використання в обов’язках агрегатора комітету (комітет маяків і комітет синхронізації).

Серверна сторона цих кінцевих точок має бути реалізована лише проміжним програмним забезпеченням DVT, а не будь-якими консенсусними клієнтами (вузлами-маяками).

Клієнтська сторона цих кінцевих точок має бути реалізована лише клієнтами перевірки, які націлені на підтримку проміжного програмного забезпечення DVT. Його слід увімкнути за допомогою прапора функції, наприклад: `--distributed-validator`.

Потік валідатора

Давайте подивимося, як це працює для потоку агрегації атестації .

• На початку слота, де валідатор має зробити атестацію, VC генерує часткове підтвердження вибору.
• Він негайно викликає нову кінцеву точку POST /eth/v1/validator/beacon_committee_selections із цим підписом, який повертає комбіноване підтвердження вибору , коли кворум часткових підписів отримано та об’єднано для створення дійсного агрегату .
• Використовуючи комбіновану відповідь підтвердження вибору, VC обчислює, чи є він агрегатором атестації для слота за допомогою функції is_aggregator .
• Якщо VC не є агрегатором, він виходить із цього потоку. Інакше;
• VC викликає POST /eth/v1/validator/beacon_committee_subscriptions зі значенням IsAggregator=true , це повідомляє клієнту маяка почати підготовку сукупної атестації для підписання.
• Дві третини в слот, VC викликає GET /eth/v1/validator/aggregate_attestation . Це отримує комбіновану атестацію з вузла маяка.
• Комбінована атестація поєднується з сукупним підтвердженням вибору в повідомлення Aggregate And Proof.
• Нарешті, VC підписує повідомлення Aggregate і Proof і викликає POST /eth/v1/validator/aggregate_and_proofs . Це публікує підписану зведену атестацію. 🎉
• Зауважте, що ця остаточна підписана сукупність і доказ сама по собі є частковою сукупністю та доказом. Але оскільки він містить комбіноване підтвердження вибору, проміжне програмне забезпечення DVT може за пороговим значенням агрегувати його в комбіноване підписане агрегування та підтвердження , яке надсилається до ланцюга маяків.

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

Висновок

У цій статті описано, як ми можемо додати високу доступність до існуючих валідаторів на Ethereum за допомогою деяких незначних розширень специфікації консенсусного API та певної поведінки для клієнта валідатора. Ми вважаємо, що зробити DVT додатковою функцією, яку зможуть використовувати всі клієнти, краще для децентралізації, ніж зробити власний клієнт валідатора, здатний підписувати довільні повідомлення, подібно до того, як mev-geth було замінено на mev-boost, щоб частково зменшити силу централізації клієнта. .

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

Дякуємо за читання!

Додаток

Структура API

Кінцева точка

POST /eth/v1/validator/beacon_committee_selections

опис

Повертає порогові агреговані докази вибору комітету маяків.

запит

[

{

"validator_index": "1",

"слот": "1",

"selection_proof": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"

}

]

Відповідь

{

"дані": [

{

"validator_index": "1",

"слот": "1",

"selection_proof": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"

}

]

}

Кінцева точка

POST /eth/v1/validator/sync_committee_selections

опис

Повертає порогові агреговані докази вибору комітету синхронізації.

запит

[

{

"validator_index": "1",

"слот": "1",

"індекс_підкомісії": "1",

"selection_proof": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"

}

]

Відповідь

{

"дані": [

{

"validator_index": "1",

"слот": "1",

"індекс_підкомісії": "1",

"selection_proof": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"

}

]

}

Контейнери SSZ

// BeaconCommitteeSelection — це дані, необхідні для вибору маякового комітету.

клас BeaconCommitteeSelection(Container):

ValidatorIndex: Індекс перевірки

Слот: Слот

SelectionProof: BLSSaignature

// SyncCommitteeSelection — дані, необхідні для вибору комітету синхронізації.

клас SyncCommitteeSelection(Container):

ValidatorIndex: Індекс перевірки

Слот: Слот

SubcommitteeIndex: Індекс комітету

SelectionProof: BLSSaignature