imagem cortesia do post sobre o Estágio Final do Vitalik
Prefácio
O Ethereum pode suportar nós completos e clientes light, ele contém uma camada ponto a ponto que permite que os nós enviem mensagens entre si. Embora a arquitetura atual do Ethereum não seja particularmente adequada para clientes light, a arquitetura da beacon chain é. Isso significa que após o merge, eles terão um papel importante a desempenhar. Um cliente light é uma alternativa mais barata para um nó completo (do ponto de vista de largura de banda e consumo de recursos), pois ele apenas faz o download do cabeçalho de cada bloco e confia nos nós completos para verificar se as transições de estado estão corretas (em outras palavras, um cliente light confia nos nós completos com os quais é emparelhado para verificar se o produtor do bloco não tentou imprimir novas moedas, gastar moedas de um endereço para o qual não possui a chave privada ou fazer blocos maiores do que as regras de consenso o permitem fazer). No entanto, isso levanta a questão: sob quais suposições os clientes light são capazes de se proteger de produtores de blocos maliciosos?
Suposições relaxantes
No estágio final, esperamos que a maioria das pessoas faça transações no Ethereum usando clientes light sem nem saber. Por exemplo, o plano sempre foi que o aplicativo móvel Status fosse integrado a uma versão light do Nimbus.
Como os clientes light normalmente fazem o download apenas de cabeçalhos de bloco e não verificam as transações, estamos acostumados a pensar neles como tendo garantias de segurança fracas em comparação com nós completos: no modelo convencional, eles são forçados a confiar em uma suposição de maioria honesta ( o que significa que eles devem assumir que a cadeia é válida por padrão).
No entanto, acontece que podemos fazer significativamente melhor do que isso.
Graças à magia das provas de fraude e disponibilidade de dados, podemos fazer uma suposição de honestidade 1/N. Praticamente falando, isso significa que um cliente light só precisa ser emparelhado com um único nó completo honesto para herdar quase as mesmas garantias de segurança. No restante deste post, nos referiremos a esse gênero de cliente light como um nó light.
Um esboço light
Embora não entremos em detalhes internos aqui, aqui está um esboço leve de como isso funciona.
Quando um nó light recebe um cabeçalho de bloco, ele prova probabilisticamente com compartilhamentos suficientes da árvore Merkle que a raiz Merkle representa, para se convencer de que a árvore inteira está realmente disponível para verificação de nós completos (em outras palavras, o nó light é capaz de verificar que o produtor do bloco não reteve nenhum dado da rede).
Ao mesmo tempo, ele procura por provas de fraude – uma prova pequena e rapidamente verificável de que uma transação específica em um bloco é inválida – dos nós com os quais é emparelhado. Uma prova de fraude válida convence aquele nó light de que a raiz Merkle no cabeçalho do bloco está de fato incorreta. Na ausência de uma prova de fraude válida, ele segue em frente e aceita o cabeçalho do bloco como verdadeiro.
O que isso nos diz?
A principal conclusão aqui é que, desde que um nó light seja emparelhado com pelo menos um nó completo honesto, ele tem praticamente as mesmas garantias de segurança que esse nó completo (já que pode esperar receber uma prova de fraude dele se o cabeçalho do bloco recebido estiver incorreto).
Uma visão mais sutil a ser obtida aqui é a seguinte: os nós light só podem oferecer a mesma proteção que os nós completos se um número suficiente de pessoas executar tanto os nós light quanto os completos. Isso é verdade porque você precisa de nós light suficientes na rede para recuperar blocos coletivamente e nós completos honestos suficientes para dar a cada cliente light uma boa chance de estar conectado a pelo menos um deles.Segue-se que, para garantir uma rede resiliente, na qual os indivíduos que realizam transações no Ethereum possam detectar se/quando os produtores de blocos estão tentando alterar as regras sobre eles, precisamos fazer duas coisas:
- Simplificar a execução de um nó light em dispositivos móveis (e outros dispositivos com restrição de recursos).
- Simplificar a execução de um nó completo em hardware de baixo consumo de energia (em particular, isso inclui Raspberry Pis e laptops comuns).
Essas duas coisas se tornam especialmente importantes em um mundo em que a produção de blocos é centralizada (o provável estágio final para o qual estamos caminhando).
Um meio para a auto-soberania
Para bifurcar as palavras de John Adler: graças às provas de fraude e amostragem de disponibilidade de dados, podemos pensar na descentralização como uma função do custo para executar um nó completo e o custo para executar um nó light. Não porque executar também seja algo especial, mas porque são um meio para um fim: auto-soberania*.
*A auto-soberania neste contexto significa que nós, a comunidade, somos capazes de detectar quando os produtores de blocos tentam mudar as regras com as quais todos concordamos.
Recursos
- Classificação do cliente Beacon Chain Light
- Rede de clientes Beacon Chain Light
- Documento de design do cliente Beacon Chain Light
- Inicializando o ecossistema do cliente Beacon Chain Light
- Altair: especificações mínimas do cliente light
- Altair: especificações mínimas do cliente light
- Implementação de sincronização do cliente Nimbus Light
- Servidor cliente experimental Nimbus Light
(expand the commit description ... for instructions on how to play with it) - Servidor cliente experimental Nimbus Light
Obrigado a Barnabé Monnot e Ștefan Talpalaru por lerem os rascunhos deste texto.