Recentemente, $Obol subiu na Binance, e aproveitamos essa oportunidade para falar sobre a arquitetura técnica do Obol.

Primeiramente, o significado da existência do projeto Obol é aumentar a tolerância a falhas do Staking de ETH.

De maneira não muito precisa, o Obol equivale a criar um mecanismo de multi-assinatura especificamente para gerenciar o Staking.

Um dos cenários mais comuns é: se você executar diretamente um cliente Ethereum para Staking de ETH, assim que o nó cair, o tempo em que você ficou offline não apenas resultará em zero retorno, mas você poderá até ser penalizado com uma multa de ETH equivalente ao valor do seu Staking.

Portanto, como evitar que os nós de Staking de ETH caiam se tornou um tópico de pesquisa para todos.

A abordagem de solução do Obol é:

Enquanto você executa o cliente ETH, execute também um conjunto adicional de clientes Obol (middleware).

Após executar o cliente Obol, você pode escolher de 3 a 10 operadores de nós para gerenciar seu nó em conjunto, assim, mesmo que alguns nós caiam, os outros ainda poderão funcionar normalmente.

PS: Claro, teoricamente você também pode rodar em vários servidores sozinhos ou pedir para seus amigos ajudarem.

No entanto, esse processo parece fácil, mas na prática é desafiador.

O mecanismo de Staking de ETH está ali, e no início do seu design não foi reservado um espaço específico para o protocolo DVT, portanto, os protocolos DVT devem operar sob as restrições do mecanismo de Staking de ETH existente.

Assim, a abordagem indireta adotada pelo Obol é, através da execução de clientes adicionais nos nós, estabelecendo uma rede Obol, independente da rede ETH.

(Charon é o nome do cliente Obol)

Essa rede é uma rede ponto a ponto, que resolve o problema de segurança na comunicação entre diferentes nós.

Então, após os nós no mesmo grupo completarem o handshake entre si, eles realizarão uma cerimônia DKG.

O que é DKG? Seu nome completo é Geração de Chave Distribuída, esse design pode ser realizado (usando 3/4 de assinaturas como exemplo):

1. Sem intermediários

2. Quatro nós não conhecem os fragmentos de chave uns dos outros

3. Pelo menos três nós online podem executar o trabalho do validador

Dessa forma, a chave privada é armazenada localmente nos nós. Além disso, o Obol não possui a ação de [dividir], ele exige que os nós gerem um dos fragmentos localmente, evitando assim o problema de exposição da chave.

Além disso, uma vez que o próprio Staking de ETH possui [chave privada de ativo] e [chave privada de validador] que são duas chaves diferentes.

Assim como no Staking não custodial, o protocolo DVT aqui também se responsabiliza apenas pela chave do validador, não tocando na chave privada do ativo, que permanece sob o controle do possuidor de ETH.

Portanto, mesmo que o protocolo DVT enfrente conluio entre várias partes, o máximo que pode ocorrer é a interferência que impede os nós de gerar blocos, mas tecnicamente não pode roubar diretamente o seu ETH Staked, resultando em perdas reais de capital.

Ao contrário, se o seu Staking cair acidentalmente, os outros 3 ainda poderão recuperar seu nó.

Além disso, há alguns pequenos designs de mecanismo que também são interessantes, como o Obol permitindo que os clientes decidam atualizar com base em sua própria vontade, podendo executar diferentes versões, sem necessidade de atualizar simultaneamente.

Assim, quando o Obol lançar uma nova versão, os 3/4 existentes que não atualizarem ainda poderão continuar a usar, desde que os clientes dentro do grupo permaneçam consistentes. Isso minimiza a possibilidade de falhas causadas oficialmente pelo Obol.

Essa é a forma como o Obol aumenta a tolerância a falhas do Staking de ETH.