A combinação de governança e mecanismos torna a segunda fase do L2 mais anti-frágil.
Escrito por: Vitalik Buterin
Compilado por: Wenser, Odaily Jornal Planetário
Nota do editor: Por muito tempo, a discussão sobre as três fases da segurança do rollup Ethereum tem sido o foco da comunidade ecológica Ethereum, que não está apenas relacionada à estabilidade operacional da rede principal Ethereum e da rede L2, mas também relacionada ao desenvolvimento real da rede L2. Recentemente, Daniel Wang, um membro da comunidade Ethereum, propôs o rótulo de nomenclatura #BattleTested para a fase 2 da rede L2 na plataforma X, argumentando que apenas redes L2 com o código e configuração atuais que estão online na mainnet Ethereum há mais de 6 meses e mantiveram um valor total de bloqueio (TVL) de mais de US$ 100 milhões e pelo menos US$ 50 milhões em ETH e grandes stablecoins podem obter esse título, e o título é avaliado dinamicamente para evitar "fantasmas on-chain". 」。 O cofundador do Ethereum, Vitalik, então deu uma resposta detalhada a essa pergunta e compartilhou suas opiniões, compiladas pelo Odaily Planet Daily abaixo.
As 3 grandes fases da rede L2: de 0 a 1 e depois a 2, a segurança é determinada pela participação de 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 componentes não confiáveis (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 através de um mecanismo simples de voto da maioria. Assim, 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 para impedir que um subconjunto (como ≥ 3) esteja fora da organização principal. Portanto, a dificuldade de controlar o sistema de prova é relativamente alta, mas não é intransponível.
Fase 2: O comitê de segurança só pode agir em casos 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 votos" que o comitê de segurança possui em diferentes estágios:
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 ir para a Fase 2 imediatamente é que você não pode confiar totalmente no sistema de prova de prova – uma preocupação compreensível: o sistema consiste em um monte de código e, se o código for vulnerável, um invasor pode roubar todos os ativos do usuário. Quanto mais confiança você tiver no sistema de certificação (ou, inversamente, menos confiança você tiver no comitê de segurança), mais você deseja empurrar todo o ecossistema de rede para o próximo estágio.
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 probabilidade de "falha isolada";
Consideramos as falhas de atividade (recusa em assinar um contrato ou chave indisponível) e as falhas de segurança (assinar questões erradas ou chave comprometida) como eventos igualmente prováveis. Na verdade, apenas assumimos uma categoria de "falha", onde os membros do conselho de segurança da "falha" assinaram tanto questões erradas quanto falharam em assinar questões corretas;
Na fase 0, o critério de julgamento do comitê de segurança é 4/7, na fase 1 é 6/8;
Suponhamos que exista um único sistema de prova global (em contraste com o mecanismo de design de 2/3, onde o comitê de segurança pode quebrar o impasse quando houver discordância entre as duas partes). Assim, na fase 2, a existência do comitê de segurança é completamente irrelevante.
Sob estas suposições, considerando a probabilidade específica do colapso do sistema de prova, queremos minimizar a possibilidade de colapso da rede L2.
Podemos usar a distribuição binomial para realizar este trabalho:
Se cada membro do Conselho de Segurança tiver uma probabilidade de falha independente de 10%, então a probabilidade de pelo menos 4 falharem em 7 é ∑𝑖= 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 certificação falhar e o mecanismo de verificação do comité de segurança falhar ≥ 3 vezes e a cobertura do cálculo da rede não puder ser feita (probabilidade ∑i= 38( 8 i)∗ 0,1 i∗ 0,98 −i= 0,03809179 multiplicada pela taxa de falhas do sistema de certificação), ou se o comité de segurança tiver 6 ou mais falhas, É possível forçar-se a gerar uma resposta calculada incorreta (fixo ∑i= 68( 8 i)∗ 0,1 i∗ 0,98 −i= 0,00002341 probabilidade);
A probabilidade de falha na fusão da Fase 2 é a mesma que a probabilidade de falha do sistema de provas.
Aqui apresentado na forma de gráfico:
Probabilidade de falha do sistema de prova em diferentes estágios da rede L2
Como resultado da especulação acima, à medida que a qualidade do sistema de prova melhora, a melhor fase muda da fase 0 para a fase 1, e então da fase 1 para a fase 2. Usar um sistema de prova da qualidade da fase 0 para a operação da rede da fase 2 resulta no pior resultado.
Agora, por favor, note que as suposições no modelo simplificado acima não são perfeitas:
Na realidade, os membros da comissão de segurança não são completamente independentes, (pode haver) uma "falha de modo comum" entre eles: podem conluir, ou todos podem estar sob a mesma coação ou ataque de hackers, etc. A exigência de ter um número legal fora da organização principal para impedir um subconjunto tem como objetivo evitar que isso aconteça, mas ainda não é perfeito.
O sistema de provas pode ser composto por vários sistemas independentes (já defendi isso em um blog anterior). Nesse caso, (i) a probabilidade de colapso do sistema de provas é muito baixa, e (ii) mesmo na fase 2, o conselho de segurança é importante, pois é a chave para resolver disputas.
Estes dois argumentos indicam que, em comparação com o 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 um erro crítico ocorrer, pode ser difícil obter rapidamente a assinatura de 6 dos 8 membros do comitê de segurança para corrigir isso. Mas há uma solução simples: conceder a qualquer membro do comitê de segurança a autorização para atrasar retiradas de 1 a 2 semanas, dando aos outros tempo suficiente para tomar ações (remediativas).
Ao mesmo tempo, no entanto, pular prematuramente para a fase 2 também é um erro, especialmente se o trabalho de transição para a fase 2 estiver à custa de fortalecer o trabalho do sistema de prova subjacente. Idealmente, provedores de dados como L2Beat deveriam demonstrar 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 todo o resumo, assim podemos reutilizá-los) e exibir a fase correspondente.
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Vitalik nova obra: Uma breve discussão sobre os princípios matemáticos da divisão razoável da fase L2
Escrito por: Vitalik Buterin
Compilado por: Wenser, Odaily Jornal Planetário
Nota do editor: Por muito tempo, a discussão sobre as três fases da segurança do rollup Ethereum tem sido o foco da comunidade ecológica Ethereum, que não está apenas relacionada à estabilidade operacional da rede principal Ethereum e da rede L2, mas também relacionada ao desenvolvimento real da rede L2. Recentemente, Daniel Wang, um membro da comunidade Ethereum, propôs o rótulo de nomenclatura #BattleTested para a fase 2 da rede L2 na plataforma X, argumentando que apenas redes L2 com o código e configuração atuais que estão online na mainnet Ethereum há mais de 6 meses e mantiveram um valor total de bloqueio (TVL) de mais de US$ 100 milhões e pelo menos US$ 50 milhões em ETH e grandes stablecoins podem obter esse título, e o título é avaliado dinamicamente para evitar "fantasmas on-chain". 」。 O cofundador do Ethereum, Vitalik, então deu uma resposta detalhada a essa pergunta e compartilhou suas opiniões, compiladas pelo Odaily Planet Daily abaixo.
As 3 grandes fases da rede L2: de 0 a 1 e depois a 2, a segurança é determinada pela participação de 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 componentes não confiáveis (ou seja, puramente criptográficos ou de teoria dos jogos):
Podemos usar o gráfico abaixo para representar a "quota de votos" que o comitê de segurança possui em diferentes estágios:
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 ir para a Fase 2 imediatamente é que você não pode confiar totalmente no sistema de prova de prova – uma preocupação compreensível: o sistema consiste em um monte de código e, se o código for vulnerável, um invasor pode roubar todos os ativos do usuário. Quanto mais confiança você tiver no sistema de certificação (ou, inversamente, menos confiança você tiver no comitê de segurança), mais você deseja empurrar todo o ecossistema de rede para o próximo estágio.
Na verdade, podemos quantificar isso usando um modelo matemático simplificado. Primeiro, vamos listar as suposições:
Sob estas suposições, considerando a probabilidade específica do colapso do sistema de prova, queremos minimizar a possibilidade de colapso da rede L2.
Podemos usar a distribuição binomial para realizar este trabalho:
Aqui apresentado na forma de gráfico:
Probabilidade de falha do sistema de prova em diferentes estágios da rede L2
Como resultado da especulação acima, à medida que a qualidade do sistema de prova melhora, a melhor fase muda da fase 0 para a fase 1, e então da fase 1 para a fase 2. Usar um sistema de prova da qualidade da fase 0 para a operação da rede da fase 2 resulta no pior resultado.
Agora, por favor, note que as suposições no modelo simplificado acima não são perfeitas:
Estes dois argumentos indicam que, em comparação com o 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 um erro crítico ocorrer, pode ser difícil obter rapidamente a assinatura de 6 dos 8 membros do comitê de segurança para corrigir isso. Mas há uma solução simples: conceder a qualquer membro do comitê de segurança a autorização para atrasar retiradas de 1 a 2 semanas, dando aos outros tempo suficiente para tomar ações (remediativas).
Ao mesmo tempo, no entanto, pular prematuramente para a fase 2 também é um erro, especialmente se o trabalho de transição para a fase 2 estiver à custa de fortalecer o trabalho do sistema de prova subjacente. Idealmente, provedores de dados como L2Beat deveriam demonstrar 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 todo o resumo, assim podemos reutilizá-los) e exibir a fase correspondente.