Разработка системы распределенной валидации (DVT)
DVT (Distributed Validator Technology) — это семейство криптографических протоколов позволяющих управлять одним Ethereum валидатором через несколько независимых нод. Это устраняет single point of failure в валидации: один сервер упал или взломан — валидатор продолжает работу. Активные реализации: Obol Network и SSV Network.
Криптографическая основа DVT
Threshold BLS Signatures
Ethereum использует BLS12-381 для подписания validator messages. DVT использует свойство BLS: подписи можно агрегировать.
Shamir's Secret Sharing: секрет (приватный ключ) разбивается на N shares. Любые M из N shares позволяют восстановить секрет. Это математическая основа threshold schemes.
Threshold BLS: версия Shamir's для BLS. M из N частей ключа подписывают сообщение независимо. M partial signatures агрегируются в одну валидную BLS подпись — неотличимую от подписи полным ключом.
Full validator key k → shares: k1, k2, k3, k4 (3-of-4 threshold)
Signing:
Node 1 (k1): sign(msg) → σ1
Node 2 (k2): sign(msg) → σ2
Node 3 (k3): sign(msg) → σ3
Aggregation: σ1 + σ2 + σ3 → σ (valid full signature)
Distributed Key Generation (DKG)
Наивный подход: один человек генерирует ключ, разбивает на shares, раздаёт. Проблема: этот человек видел полный ключ.
DKG решает это: каждый участник вносит энтропию, итоговый ключ создаётся коллективно, никто никогда не видел полного секрета.
Pedersen DKG protocol:
- Каждый участник генерирует random polynomial
- Участники обмениваются commitments (не секретами)
- Участники отправляют секретные shares друг другу (зашифровано)
- Каждый верифицирует полученные shares против commitments
- Итоговые shares: суммы всех полученных shares
Это занимает несколько раундов коммуникации. Obol автоматизирует через obol create dkg ceremony.
Архитектура DVT системы
Компоненты
Node software: каждый оператор запускает DVT middleware (Charon для Obol, SSV node для SSV). Middleware перехватывает signing requests от consensus клиента.
Consensus механизм: операторы должны договориться о том, что подписывать. Используют BFT (Byzantine Fault Tolerant) consensus — Tendermint-style или QBFT:
- Один из операторов предлагает duty (attestation, proposal)
- Другие верифицируют и подписывают
- При кворуме — агрегированная подпись отправляется в сеть
P2P communication: операторы общаются peer-to-peer, обменивая partial signatures и consensus messages. LibP2P — стандартный протокол.
Slashing protection в DVT
Двойное подписание — главный риск слешинга. В DVT контексте:
- Каждый оператор ведёт свою slashing protection DB
- Прежде чем подписать — проверяет нет ли конфликта
- Если M-of-N операторов отказались подписать — signing не происходит
Это strong slashing protection: для slashing нужно M операторов одновременно пойти на нарушение.
Реализация собственного DVT
Если нужно не интегрировать Obol/SSV а строить собственный DVT:
Threshold BLS library: blst (C, production-ready), herumi/bls-eth-go (Go). Для Rust — bls12_381 crate.
DKG implementation: Pedersen DKG или более современный FROST (Flexible Round-Optimized Schnorr Threshold Signatures). FROST эффективнее по числу rounds.
Networking: LibP2P для P2P коммуникации между операторами.
Consensus: для небольших clusters (3-7 операторов) — простой BFT протокол достаточен.
Когда строить DVT самостоятельно
Использовать Obol/SSV разумно в 95% случаев — это зрелые аудированные протоколы. Собственный DVT оправдан:
- Специфические security требования (проприетарный HSM integration)
- Регуляторные требования не позволяющие использовать external middleware
- Экзотические threshold схемы не поддерживаемые существующими протоколами
- Исследовательский контекст
Разработка production-grade DVT с нуля — 12-18 месяцев. Интеграция Obol или SSV — 4-8 недель.