Modelo matemático revela a lógica de seleção da fase L2: por que a fase 1 pode ser ignorada?

Escrito por: Vitalik Buterin

Compilado por: Wenser, Odaily Jornal Planetário

Nota do editor: Desde sempre, a discussão sobre as três fases de segurança do rollup do Ethereum tem sido um foco de atenção da comunidade ecossistêmica do Ethereum, o que não diz respeito apenas à estabilidade operacional da mainnet do Ethereum e das redes L2, mas também à verdadeira situação de desenvolvimento das redes L2. Recentemente, Daniel Wang, membro da comunidade Ethereum, propôs na plataforma X a etiqueta de nomeação da fase 2 da rede L2, #BattleTested, acreditando que apenas as redes L2 cujos códigos e configurações atuais estejam em operação na mainnet do Ethereum por mais de 6 meses, mantendo um valor total de ativos bloqueados (TVL) superior a 100 milhões de dólares, dos quais pelo menos 50 milhões de dólares são ETH e principais stablecoins, podem obter esse título, que será avaliado dinamicamente para evitar a criação de “fantasmas on-chain”. O co-fundador do Ethereum, Vitalik, em seguida, forneceu uma resposta detalhada e compartilhou suas opiniões sobre essa questão, conforme traduzido pelo Odaily Planet Daily.

As 3 grandes fases da rede L2: de 0 a 1 e depois a 2, a segurança é determinada pela participação na governança.

As três fases da segurança do rollup do Ethereum podem ser determinadas com base em quando o comitê de segurança pode cobrir os componentes sem confiança (ou seja, puramente criptográficos ou de teoria dos jogos):

• Fase 0: O comitê de segurança tem controle total. Pode haver um sistema de prova em funcionamento (modo Optimism ou ZK), mas o comitê de segurança pode derrubá-lo por meio de um mecanismo de voto de maioria simples. Portanto, o sistema de prova é apenas de “natureza consultiva”.
• Fase 1: O comitê de segurança precisa de 75% (pelo menos 6/8) de aprovação para substituir o sistema operacional. Deve haver um quórum que impeça um subconjunto (como ≥ 3) fora da organização principal. Assim, a dificuldade de controlar o sistema de prova é relativamente alta, mas não impossível de superar.
• Fase 2: O comitê de segurança só pode agir em caso de erro comprovável. Por exemplo, um erro comprovável pode ser a contradição entre dois sistemas de prova redundantes (por exemplo, OP e ZK). Se houver um erro comprovável, ele só pode escolher uma das respostas propostas: não pode responder arbitrariamente a um determinado mecanismo.

Podemos usar o gráfico abaixo para representar a “quota de voto” que o comitê de segurança possui em diferentes fases:

Estrutura de votação de governança em três fases

Uma questão importante é: qual é o momento ideal para a transição da Rede L2 da Fase 0 para a Fase 1, e da Fase 1 para a Fase 2?

A única razão válida para não entrar imediatamente na fase 2 é que você não pode confiar completamente no sistema de prova - esta é uma preocupação compreensível: o sistema é composto por uma grande quantidade de código, e se houver vulnerabilidades no código, os atacantes podem roubar os ativos de todos os usuários. Quanto mais forte for sua confiança no sistema de prova (ou, inversamente, quanto mais fraca for sua confiança no comitê de segurança), mais você desejará impulsionar todo o ecossistema da rede para a próxima fase.

Na verdade, podemos quantificar isso usando um modelo matemático simplificado. Primeiro, vamos listar as suposições:

• Cada membro do comitê de segurança tem 10% de chance de “falha isolada”;
• Consideramos falhas de atividade (recusa em assinar contratos ou chaves indisponíveis) e falhas de segurança (assinar itens incorretos ou chaves comprometidas) como eventos igualmente prováveis. Na prática, supomos apenas uma categoria de “falha”, onde os membros do conselho de segurança da falha assinaram itens incorretos e falharam em assinar itens corretos que avançam;
• No estágio 0, o critério de julgamento do comitê de segurança é 4/7, no estágio 1 é 6/8;
• Assumimos a existência de um único sistema de prova global (em contraste com o mecanismo de design de 2/3, onde um comitê de segurança pode quebrar o impasse quando há desacordo entre as duas partes). Assim, na fase 2, a existência do comitê de segurança é completamente irrelevante.

Sob essas suposições, considerando a probabilidade específica de colapso do sistema de prova, desejamos minimizar a possibilidade de colapso da rede L2.

Podemos usar a distribuição binomial para completar este trabalho:

• Se cada membro do Conselho de Segurança tiver uma probabilidade de falha independente de 10%, a probabilidade de que pelo menos 4 dos 7 falhem é ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728 Portanto, o sistema integrado na fase 0 tem uma probabilidade fixa de falha de 0.2728%.
• A integração da Fase 1 também pode falhar, se o sistema de prova falhar e o mecanismo de verificação do comitê de segurança tiver ≥ 3 falhas, não é possível realizar a cobertura de cálculo da rede (probabilidade ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 multiplicado pela taxa de falha do sistema de prova), ou se o comitê de segurança tiver 6 ou mais falhas, pode forçar a geração de uma resposta de cálculo incorreta (fixo ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 probabilidade);
• A probabilidade de falha da fusão na fase 2 é consistente com a probabilidade de falha do sistema de prova.

Aqui apresentado sob a forma de gráfico:

Probabilidade de falha do sistema de prova em diferentes fases da rede L2

Como resultado da conjectura acima, à medida que a qualidade do sistema de provas melhora, a melhor fase passa da fase 0 para a fase 1, e depois da fase 1 para a fase 2. Usar um sistema de provas da qualidade da fase 0 para a operação da rede da fase 2 é o pior resultado.

Agora, por favor, note que as suposições no modelo simplificado acima não são perfeitas:

• Na realidade, os membros do comitê de segurança não são totalmente independentes, podendo existir entre eles uma “falha de padrão comum”: eles podem conluiar-se ou estar sujeitos à mesma coerção ou ataque hacker, etc. A exigência de ter um quórum legal fora da organização principal para impedir subconjuntos tem como objetivo evitar que isso aconteça, mas ainda assim não é perfeito.
• O sistema de prova em si pode ser composto por múltiplos sistemas independentes (eu já defendi isso em um blog anterior). Nesse caso, (i) a probabilidade de colapso do sistema de prova é muito baixa, e (ii) mesmo na fase 2, o comitê de segurança é importante, pois é a chave para resolver disputas.

Ambos os argumentos indicam que, em comparação com o que é mostrado no gráfico, a Fase 1 e a Fase 2 são mais atraentes.

Se você acredita em matemática, então a existência da Fase 1 quase nunca será provada como razoável: você deve entrar diretamente na Fase 1. A principal objeção que ouvi é: se ocorrer um erro crítico, pode ser difícil obter rapidamente a assinatura de 6 dos 8 membros do comitê de segurança para corrigi-lo. Mas há uma solução simples: conceder a qualquer membro do comitê de segurança a autoridade de atrasar a retirada de 1 a 2 semanas, dando aos outros tempo suficiente para tomar medidas (remediar).

Ao mesmo tempo, no entanto, saltar prematuramente para a fase 2 também é errado, especialmente se o trabalho de transição para a fase 2 for feito à custa de fortalecer o trabalho do sistema de prova subjacente. Idealmente, fornecedores de dados como o L2Beat devem mostrar auditorias do sistema de prova e indicadores de maturidade (de preferência indicadores de implementação do sistema de prova em vez de indicadores de toda a agregação, para que possamos reutilizá-los) e acompanhar a exibição da fase.