Grite para Paul Harris @rolfyone e Luca @eth2353 pelos seus comentários e revisão.
O rastreamento do uso do cliente CL/EL é fundamental para compreender a resiliência da rede, mas não existe uma solução de relatórios confiável.
Esforços anteriores
- Impressão digital: Blockprint monitorou estilos de proposta de bloco de cliente para adivinhar qual cliente está sendo usado, mas isso se tornou impreciso após a atualização do Ethereum Electra e desde então foi descontinuado. (1)(2)
- Rastejando: MigaLabs monitora nós na rede, mas isso não é exclusivo dos nós validadores e tem polarização de pares. (3)
- Dados de retransmissão: Os relés possuem dados do cliente, mas o ePBS remove os relés (também precisaria convencê-los a compartilhar os dados a serem agregados). (4)
- Marca d’água Graffiti: usa o campo de graffiti de proposta para relatar o cliente CL/EL, mas a implementação não é padronizada, depende de haver espaço suficiente se um graffiti personalizado for definido e não leva em conta configurações de vários nós/DVT. (5), (6)
Pesquisa Prévia
Esta postagem de pesquisa aborda os seguintes tópicos e desafios de implementação:
- Tornando os dados do cliente visíveis nos blocos propostos
- Melhorando a confiabilidade dos métodos de rastreamento
- Subprotocolo dedicado para coleta de dados do cliente
- Esquema de votação privada dedicado
Proposta: Novo campo de proposta de 32 bytes
Um novo campo de dados do corpo do bloco beacon de 32 bytes inspirado em marcas d’água graffiti, mas como um campo dedicado e com um esquema expandido que leva em conta configurações de vários nós como Vero, Vouch e DVT. Também seria benéfico para monitorar a diversidade de provas de zkCL no futuro.
Terminologia
- Versão do campo – Versionamento para este novo campo de dados.
- Configurar – O tipo de configuração usada, como configuração simples regular, obol, ssv, vero, voucher, etc.
- Limite – O M-de-N de clientes conectados que precisam concordar antes de votar.
- Pares de clientes – O número de conjuntos de combinações de clientes. Por exemplo, se estiver executando Prysm+Nethermind e Teku+Besu, são 2 pares de clientes.
Codificação
- byte 0 (7-0) = Versão do campo (máx. 2 ^ 8 = 256)
- byte 1 (7-3) = Configuração (máx. 2 ^ 5 = 32)
- byte 1 (2-0) = Limite (máx. 2 ^ 3 = 8)
- bytes 2-15 = 1 byte por par de cliente CL/EL (14 pares, máximo 2^4 = 16 opções cada)
- bytes 16-31 = não utilizado para implementação inicial, mas permite rastreamento adicional no futuro
No futuro, quando as provas zkCL forem introduzidas, poderemos alterar a versão dos dados do cliente e usar os bytes adicionais para coletar esses dados de diversidade também.
Algumas outras variações foram consideradas antes de nos restringirmos a isso. Você pode verificar esta essência se estiver interessado.
Listas de Referência
Listas de referência serão necessárias para as configurações e pares de clientes que mapeiam valores numéricos para as opções de configuração, CL e EL que serão usadas para codificação/decodificação de bytes.
Um valor de 0 e 1 pode ser reservado para “indefinido” e “outro”.
Exemplo
Suposições:
- Versão de campo: 1
- Configuração: Vero
- Configurar mapeamentos de lista de referência:
- Indefinido: 0
- Outro: 1
- Simples: 2
- Óbolo: 3
- SSV: 4
- Verdade: 5
- Comprovante: 6
- Limiar: 3/4
- Pares de clientes: TK+NM,LS+GE,NB+NM,LH+BU
- Mapeamentos da lista de referências CL:
- Indefinido: 0
- Outro: 1
- GR: 2
- ES: 3
- LS: 4
- Nota: 5
- TK: 6
- Tarde: 19h
- Mapeamentos da lista de referências EL:
- Indefinido: 0
- Outro: 1
- BU: 2
- EJ: 3
- EX.: 4
- EX: 5
- GE: 6
- Nota: 7
- nm: 8
- RH: 9
Codificação de bytes:
- Byte 0 = 00000001 (versão)
- Byte 1 = 00101011 (configuração 00101 + limite 011)
- Byte 2 = 01101000 (TK 0110 + NM 1000)
- Byte 3 = 01000110 (LS 0100 + GE 0110)
- Byte 4 = 01011000 (NB 0101 + NM 1000)
- Byte 5 = 00110010 (LH 0011 + BU 0010)
- Byte 6-15 = 00000000 (pares de clientes indefinidos)
- Bytes 16-31 = 00000000 (não utilizado)
Configurações
- Padrão ativado
- Permitir que o usuário desative os relatórios do cliente
- Há algum argumento para poder cancelar os relatórios de prova EL, CL e zkCL separadamente, em vez de uma configuração que controla tudo?
- Permitir que o usuário desabilite a configuração do cliente
Preocupações/deficiências
- Privacidade
- Alguns podem estar preocupados com a privacidade, mas não há informações de versão do cliente listadas, há a opção de desativá-la e os clientes já adicionam informações do cliente, o que não parece ser um problema real.
- Com clientes multinode como o Vero, o risco de conhecer o cliente que você está executando no momento é bastante reduzido.
- Falsificação de dados – Embora seja possível falsificar os dados, dado o grande conjunto de validadores, acredito que ainda será melhor do que o que estamos trabalhando atualmente.
- Dados obsoletos – Esta implementação depende de propostas para que os dados não forneçam uma visualização ao vivo da rede (atualmente levaria pelo menos cerca de 129 dias para passar pelo conjunto de validadores). Concedido, isso pode continuar a diminuir com as consolidações, uma vez que foram cerca de 131 dias, apenas algumas semanas antes de escrever isto.
Discussão
Adoraria ouvir outras ideias sobre maneiras simples de implementar relatórios de clientes.
Embora esta proposta possa não ser a melhor solução tecnicamente, acredito que a facilidade de implementação e a flexibilidade fazem com que valha a pena. Vamos obter o conhecimento necessário sobre nossa rede.
Se não surgirem outras ideias ou preocupações fortes, gostaria de avançar com uma proposta de EIP. Precisaria de um parceiro técnico para isso, então adoraria saber se alguém está interessado em ajudar.
5 curtidas
Só para esclarecer este ponto, porque ainda hoje não existe uma única maneira de exigir que vários clientes concordem em configurações de vários nós. O requisito mínimo aqui é que vários clientes concordem com o ponto de verificação da origem do atestado. Idealmente, porém, o acordo já seria/também seria necessário no ponto de verificação alvo – o que ajuda outros participantes da rede a não emitirem votos errados na fonte mais tarde.
Para os implementadores, o novo /eth/v2/node/version O endpoint Beacon API (Gloas+) fornece todos os dados necessários (informações do cliente CL+EL) para clientes validadores.
Estou feliz em continuar ajudando nisso em nível técnico.
1 Curtir
O prazo para propor EIPs para upgrade do Hegotá é 6 de agosto, então é preciso fazer um EIP e fazer a proposta antes disso, caso contrário terá que esperar pelo upgrade I*. Fico feliz em ajudar nos princípios básicos do EIP (sou editor associado, ajudo a atribuir números).
Uma alternativa de curto prazo seria trabalhar com equipes de clientes para que os dados dos clientes fossem adicionados ao graffiti por padrão. Isso não exigiria uma atualização de rede, embora pudesse demorar um pouco para que os stakers atualizassem.
Fontesethresear
