Розробка технології розподіленої валідації (DVT)
DVT (Distributed Validator Technology) — родина криптографічних протоколів, що дозволяють керувати одним Ethereum валідатором через кілька незалежних нод. Усуває єдину точку відмови у валідації: один сервер впав або скомпрометований — валідатор продовжує роботу. Активні реалізації: Obol Network та SSV Network.
Криптографічна основа
Threshold BLS Signatures
Ethereum використовує BLS12-381 для підписання повідомлень валідатора. DVT використовує властивість BLS: підписи можна агрегувати.
Shamir's Secret Sharing: секрет (приватний ключ) розбивається на N частин. Будь-які M з N частин дозволяють відновити секрет. Це математична основа threshold schemes.
Threshold BLS: варіант Shamir's для BLS. M з N частин ключа підписують повідомлення незалежно. M часткових підписів агрегуються в один валідний BLS підпис.
Повний ключ валідатора k → частини: k1, k2, k3, k4 (3-of-4 threshold)
Підписання:
Node 1 (k1): sign(msg) → σ1
Node 2 (k2): sign(msg) → σ2
Node 3 (k3): sign(msg) → σ3
Агрегація: σ1 + σ2 + σ3 → σ (валідний повний підпис)
Distributed Key Generation (DKG)
Наївний підхід: одна людина генерує ключ, розбиває на частини, розповсюджує. Проблема: ця людина бачила повний ключ.
DKG вирішує: кожен учасник вносить ентропію, фінальний ключ створюється колективно, ніхто ніколи не бачив повного секрету.
Pedersen DKG: Кожен учасник генерує випадкові поліноми, обмінюються commitments, верифікують частини проти commitments. Потребує кілька раундів комунікації.
Архітектура DVT системи
Компоненти:
- Node software: кожен оператор запускає DVT middleware (Charon для Obol, SSV node для SSV)
- Consensus механізм: оператори договорюються про те, що підписувати. Використовують BFT (Byzantine Fault Tolerant) консенсус
- P2P комунікація: оператори спілкуються peer-to-peer, обмінюючи часткові підписи
Slashing Protection у DVT
Подвійне підписання — основний ризик слешингу. У контексті DVT: кожен оператор веде slashing protection DB, перевіряє нема конфлікту перед підписанням. Якщо M-of-N операторів відмовляються підписати — підписання не відбувається.
Коли будувати DVT самостійно
Використовуйте Obol/SSV у 95% випадків — зрілі аудировані протоколи. Власний DVT виправданий для:
- Специфічних вимог безпеки (проприетарна HSM інтеграція)
- Регуляторних вимог, що запобігають зовнішньому middleware
- Екзотичних threshold схем
- Дослідницьких контекстів
Розробка production-grade DVT з нуля — 12-18 місяців. Інтеграція Obol або SSV — 4-8 тижнів.