Зведення до мінімуму кореляції є життєво важливим при розробці DVT, оскільки Ethereum Proof of Stake розроблено для суворого покарання корельованої поведінки. Розробляючи Obol, ми зробили ретельний вибір, щоб створити мінімізовану довіру та некорельовану архітектуру.

Ойсін Кайн

1 листопада 2022 р •8 хвилин читання

Я хвилювався щодо децентралізації підтвердження частки ще з початкової специфікації дизайну Serenity, запущеної на Devcon 4 . Сьогодні я хочу поговорити про те, як Charon , клієнт проміжного програмного забезпечення розподіленого валідатора Obol, розроблено таким чином, що дозволить йому збільшити набір валідатора Ethereum на порядок без введення корельованої поведінки в валідатори, які застосовують цю технологію.

По-перше, що такого важливого у кореляції?

Специфікація proof of stake Ethereum розроблена для заохочення децентралізації шляхом жорсткого штрафування за централізацію. Існують механізми, призначені для покарання за відповідну бездіяльність, і є механізми для максимального покарання за пов’язану зловмисну поведінку. Чим більше людей офлайн, коли ви офлайн, тим гірший штраф за бездіяльність (особливо, якщо >33% мережі офлайн). Подібним чином, якщо вважається, що ваш валідатор атакує мережу, вас буде скорочено, і штраф за скорочення зростатиме залежно від того, скільки інших валідаторів буде знищено протягом наступних трьох тижнів після вашого знищення. Якби ваш валідатор був єдиним, кого було скорочено за цей період, він втратив би, можливо, 2 ефіри. Якщо трапиться масова подія, ви можете втратити весь ефір свого валідатора.

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

Термінологія

Щоб швидко торкнутися кількох термінів для людей, які нещодавно познайомилися з Хароном і ТГВ загалом:

Розподілений валідатор : одна частка 32 ефірів, представлена відкритим ключем BLS, керована кількома закритими ключами разом у тандемі.
Кластер розподіленого валідатора : набір вузлів Ethereum (включаючи Charon), з’єднаних разом для роботи одного або кількох розподілених валідаторів.
Проміжне програмне забезпечення: програмне забезпечення, розташоване між двома іншими незалежними частинами програмного забезпечення, яке перехоплює лінію зв’язку між ними. Charon знаходиться між клієнтом валідатора та HTTP Beacon API на консенсусному клієнті.

Приватні ключі

З чого ще можна почати обговорення архітектури розподіленого валідатора, крім закритих ключів. Існує два типи закритих ключів, задіяних у розподіленому кластері перевірки:

Для ідентифікації клієнта Charon використовується пара відкритий/приватний ключ SECP256K1. Таким чином, Charon тісно пов’язаний з існуючими мережевими стеками eth1 і eth2, використовуючи записи Ethereum Node Records ( ENR ) і протокол виявлення discv5 для пошуку потрібних партнерів в Інтернеті незалежно від того, де вони опинилися.
Порогові ключові частки BLS12-381. Це приватні ключі BLS, які підписують обов’язки, як і звичайний валідатор Ethereum, але з особливостями. Кілька приватних ключів генеруються таким чином, що разом вони представляють окремий приватний ключ. Важливо, що не всі приватні ключі потрібні для створення дійсного підпису для пов’язаного відкритого ключа. Подумайте про це як про гаманець з кількома підписами для закритого ключа валідатора.

Під час налаштування нового кластера розподіленого валідатора кожен оператор генерує закритий ключ (1) для використання своїм клієнтом Charon, а потім вони готують церемонію генерації розподіленого ключа за допомогою панелі запуску розподіленого валідатора для створення приватних ключів розподіленого валідатора ( 2).

Після встановлення умов кластера, додавання всіх операторів і їх автентифікації через панель запуску оператори передають своїм клієнтам Charon створений файл визначення кластера , і починається процес DKG. Кожен клієнт Charon знаходить один одного в Інтернеті, встановлює безпечну та зашифровану лінію зв’язку, а потім створює ці приватні ключі BLS таким чином, що жоден клієнт ніколи не контролює та не знає, що таке повний приватний ключ. Після завершення кожен клієнт Charon записує свої закриті ключі на диск у широко поширеному EIP-2335формат сховища ключів. У рамках цього процесу приватні ключі використовуються для створення даних депозиту для активації валідатора у вибраній мережі. Це єдиний раз, коли Харон має опіку та можливість підписувати за допомогою закритих ключів розподіленого валідатора. Після завершення процесу DKG особисті ключі валідатора імпортуються в обраний оператором клієнт валідатора.

Щоб порівняти цей підхід до створення приватного ключа з іншим; Можна (але нерозумно) мати довірену особу (наприклад, потенційного клієнта) створити повний приватний ключ самостійно, попросити цю сутність розділити приватний ключ на частки, попросити цю сутність зашифрувати приватний ключ, який ділиться з приватним клієнтом кожного оператора. ключ і опублікуйте зашифровані приватні ключі в ланцюжку, щоб світ міг їх побачити. Це наш перший кореляційний ризик, і він стосується шкоди, яку може завдати оператор втрати закритого ключа свого клієнта. У Хароні нічого особливого не відбувається, цей вузол може почати діяти у візантійській манері, що не викликає серйозного занепокоєння, оскільки кластер стійкий до візантійських збоїв. В альтернативній архітектурі,

Проміжне програмне забезпечення

Після створення кластера розподіленого валідатора наступним рішенням щодо розробки архітектури є зменшення ризику корельованого скорочення будь-якою ціною. Харон прагне досягти цього, не маючи можливості робити щось різке. Charon не зберігає закриті ключі валідатора та не має можливості підписувати довільні дані. Натомість Charon є проміжним програмним забезпеченням, яке знаходиться між існуючими клієнтами консенсусу та клієнтами валідатора та перехоплює дані, що передаються між ними. Усе, що роблять клієнти Charon, це:

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

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

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

спілкування

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

Замість того, щоб кожен окремий клієнт Charon підключався до однієї спільної мережі пліток, кожен кластер повністю ізольований від інших. Клієнти Charon у кластері встановлюють прямі TCP-з’єднання зі своїми однолітками. Цей підхід вимагає більш початкових налаштувань, ніж підключення до загальнодоступної мережі пліток, оскільки вам потрібно переконатися, що ваш вузол Charon доступний безпосередньо в загальнодоступному Інтернеті, але, на мою думку, виграш того вартий.

Прямі TCP-з’єднання надійні, повідомлення не губляться, як це відбувається в мережі пліток.
Прямі з’єднання TCP є набагато швидшими, ніж сигнатури, що переміщуються по мережі через декілька переходів, перш ніж дістатися до вас. Це підвищує прибутковість валідатора.
Вашому клієнту не надсилаються повідомлення, які не призначені для нього.
Немає жодного центрального мережевого рівня, який, якщо він виходить з ладу, кожен окремий розподілений валідатор вимикається в автономному режимі через корельований збій.
Якщо ви використовуєте кластер у постачальника хмарної інфраструктури, використання його приватної мережі між центрами обробки даних є швидким, високопродуктивним і субсидованим. Використання їх мережевого виходу в загальнодоступний Інтернет для протоколу пліток спричиняє більше витрат на хмару для повільнішої мережі з меншою пропускною здатністю.

Існує лише одна частина загальної мережевої інфраструктури, яку зараз розміщує Obol, і це вузол завантаження discv5, який дозволяє вузлам Charon знаходити один одного. Для спільноти, яка піклується про безпеку, має сенс самостійно розмістити власну завантажувальну вузол замість того, щоб розірвати єдиний спільний зв’язок між кластерами Charon. Ми полегшили це зробити , і ми бачили, як багато учасників нашої тестової мережі Athena вже вибрали це.

Керування версіями

І останнє, але не менш важливе: виконання наполегливої роботи з відокремлення кластерів один від одного відкриває ще один спосіб гарантувати, що ви не будете виходити з ладу корельованим чином, і це стосується оновлення програмного забезпечення. Оновлення програмного забезпечення завжди страшне та ризиковане, особливо в розподіленій системі. Якщо у вас є всі клієнти, які спільно використовують ту саму шину повідомлень; якщо ви випустите нову версію, яка змінює структуру повідомлень, старі версії програмного забезпечення не знатимуть, що робити з цими повідомленнями. Отже, щоб обійти це, вам потрібно встановити час (або номер слота), коли новий протокол стане активним, і ви вибухнете всіх, хто запускає ваше програмне забезпечення на ваших каналах зв’язку, кажучи, що вони мають запустити останню версію вашого програмного забезпечення до цього часу, інакше їхні вузли перейдуть в режим офлайн. Коли цей слот надходить, кожен окремий розподілений валідатор одночасно переходить на новий протокол. Мені майже не потрібно підкреслювати, наскільки це пов’язано, якщо щось піде не так, це піде не для всіх. Навіть якщо нічого не йде не так, якщо люди не оновили вчасно, вони змушені залишатися в автономному режимі.

Іноді, наприклад, коли ви запускаєте блокчейн рівня 1 із кількома незалежними клієнтськими реалізаціями, вибір узгодженого моменту для оновлення є єдиним можливим рішенням для впровадження змін, проте в Obol, оскільки кожен кластер незалежний один від одного, у поєднанні з Той факт, що ці кластери мають візантійські відмовостійкі можливості, стає можливим дозволити кожному кластеру оновлюватися до найновішого протоколу на дозвіллі, коли вони будуть готові. Ми впроваджуємо ефективні оновлення версій у клієнти Charon, щоб вони періодично досягали консенсусу щодо найновішої версії протоколу, яку вони всі використовують, і коли всі використовують найновіше програмне забезпечення, кластер розуміє: «Гей, ми всі говоримо версією n+ 1 тепер, давайте використовувати його з наступної епохи і далі».

Висновок

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

Дякую, що прочитали.