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 fases da rede L2: do 0 ao 1 e depois ao 2, a segurança é determinada pela participação na governança.
A segurança do rollup do Ethereum pode ser determinada em três estágios, dependendo de quando o comitê de segurança pode cobrir 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 por maioria simples. Portanto, o sistema de prova é apenas de "natureza consultiva".
Fase 1: O Conselho de Segurança precisa de 75% (pelo menos 6/8) de aprovação para sobrepor o sistema operacional. Deve haver um quórum que impeça um subconjunto (como ≥ 3) fora da organização principal. Portanto, a dificuldade de controlar o sistema de prova é relativamente alta, mas não insuperá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 (como OP e ZK). Se houver um erro comprovável, ele só pode escolher uma das respostas apresentadas: 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 etapas:
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 para o desenvolvimento 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 - essa é uma preocupação compreensível: o sistema é composto por um grande conjunto de códigos e, se houver falhas no código, um atacante pode 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 uma probabilidade de 10% de "falha individual";
Consideramos falhas de atividade (recusa em assinar contratos ou chaves indisponíveis) e falhas de segurança (assinar questões erradas ou chaves comprometidas) como eventos de igual probabilidade. Na verdade, apenas assumimos uma categoria de "falha", na qual os membros do conselho de segurança "falharam" tanto ao assinar questões erradas quanto ao não assinar questões corretas para avanço.
Na fase 0, o critério de julgamento do comitê de segurança é 4/7, na fase 1 é 6/8;
Suponha-se que exista um único sistema de prova global (em contraste com o mecanismo de design de 2/3, onde um comitê de segurança pode quebrar um impasse quando as opiniões de ambos são contraditórias). Portanto, na fase 2, a presença do comitê de segurança é completamente irrelevante.
Tendo em conta essas suposições e a probabilidade específica de 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 chance de falha independente de 10%, então a probabilidade de pelo menos 4 em 7 falharem é ∑𝑖= 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 em fazer a sobreposição de cálculo da rede (probabilidade ∑i= 38( 8 i)∗ 0,1 i∗ 0,98 −i= 0,03809179 multiplicada pela taxa de falha do sistema de atestado), 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 fase 2 é consistente com a probabilidade de falha do sistema de prova.
Aqui é apresentado na forma de gráfico:
Probabilidade de falha do sistema de prova em diferentes estágios da rede L2
Conforme os resultados acima especulados, à medida que a qualidade do sistema de prova melhora, a fase ideal muda da fase 0 para a fase 1, e então da fase 1 para a fase 2. Usar um sistema de prova de qualidade da fase 0 para a operação de 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, (pode haver) uma "falha de modo comum" entre eles: podem conluir, ou podem estar sujeitos à mesma coação ou ataque hacker, entre outras coisas. O objetivo de exigir um quórum fora da organização principal para impedir subconjuntos é evitar que isso ocorra, mas ainda assim não é perfeito.
O sistema de prova pode ser composto por vários sistemas independentes (o que eu defendi em meu blog anterior). Nesse caso, (i) a probabilidade de falha do sistema de prova é muito baixa, e (ii) mesmo na fase 2, o conselho 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, a existência da Fase 1 quase nunca será provada como razoável: você deve ir diretamente para a 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 para atrasar a retirada de 1 a 2 semanas, dando aos outros tempo suficiente para tomar medidas (de remédio).
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 à custa de fortalecer o trabalho do sistema de prova subjacente. Idealmente, fornecedores de dados como o L2Beat deveriam mostrar auditorias do sistema de prova e indicadores de maturidade (de preferência indicadores da implementação do sistema de prova em vez de indicadores de toda a agregação, para que possamos reutilizá-los), acompanhados da exibição da fase.
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 novo artigo: Uma breve discussão sobre os princípios matemáticos para a divisão razoável da fase L2
Escrito por: Vitalik Buterin
Compilado por: Wenser, Odaily Planet Daily
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 fases da rede L2: do 0 ao 1 e depois ao 2, a segurança é determinada pela participação na governança.
A segurança do rollup do Ethereum pode ser determinada em três estágios, dependendo de quando o comitê de segurança pode cobrir 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 por maioria simples. Portanto, o sistema de prova é apenas de "natureza consultiva".
Fase 1: O Conselho de Segurança precisa de 75% (pelo menos 6/8) de aprovação para sobrepor o sistema operacional. Deve haver um quórum que impeça um subconjunto (como ≥ 3) fora da organização principal. Portanto, a dificuldade de controlar o sistema de prova é relativamente alta, mas não insuperá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 (como OP e ZK). Se houver um erro comprovável, ele só pode escolher uma das respostas apresentadas: 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 etapas:
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 para o desenvolvimento 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 - essa é uma preocupação compreensível: o sistema é composto por um grande conjunto de códigos e, se houver falhas no código, um atacante pode 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 uma probabilidade de 10% de "falha individual";
Consideramos falhas de atividade (recusa em assinar contratos ou chaves indisponíveis) e falhas de segurança (assinar questões erradas ou chaves comprometidas) como eventos de igual probabilidade. Na verdade, apenas assumimos uma categoria de "falha", na qual os membros do conselho de segurança "falharam" tanto ao assinar questões erradas quanto ao não assinar questões corretas para avanço.
Na fase 0, o critério de julgamento do comitê de segurança é 4/7, na fase 1 é 6/8;
Suponha-se que exista um único sistema de prova global (em contraste com o mecanismo de design de 2/3, onde um comitê de segurança pode quebrar um impasse quando as opiniões de ambos são contraditórias). Portanto, na fase 2, a presença do comitê de segurança é completamente irrelevante.
Tendo em conta essas suposições e a probabilidade específica de 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 chance de falha independente de 10%, então a probabilidade de pelo menos 4 em 7 falharem é ∑𝑖= 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 em fazer a sobreposição de cálculo da rede (probabilidade ∑i= 38( 8 i)∗ 0,1 i∗ 0,98 −i= 0,03809179 multiplicada pela taxa de falha do sistema de atestado), 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 fase 2 é consistente com a probabilidade de falha do sistema de prova.
Aqui é apresentado na forma de gráfico:
Probabilidade de falha do sistema de prova em diferentes estágios da rede L2
Conforme os resultados acima especulados, à medida que a qualidade do sistema de prova melhora, a fase ideal muda da fase 0 para a fase 1, e então da fase 1 para a fase 2. Usar um sistema de prova de qualidade da fase 0 para a operação de 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, (pode haver) uma "falha de modo comum" entre eles: podem conluir, ou podem estar sujeitos à mesma coação ou ataque hacker, entre outras coisas. O objetivo de exigir um quórum fora da organização principal para impedir subconjuntos é evitar que isso ocorra, mas ainda assim não é perfeito.
O sistema de prova pode ser composto por vários sistemas independentes (o que eu defendi em meu blog anterior). Nesse caso, (i) a probabilidade de falha do sistema de prova é muito baixa, e (ii) mesmo na fase 2, o conselho 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, a existência da Fase 1 quase nunca será provada como razoável: você deve ir diretamente para a 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 para atrasar a retirada de 1 a 2 semanas, dando aos outros tempo suficiente para tomar medidas (de remédio).
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 à custa de fortalecer o trabalho do sistema de prova subjacente. Idealmente, fornecedores de dados como o L2Beat deveriam mostrar auditorias do sistema de prova e indicadores de maturidade (de preferência indicadores da implementação do sistema de prova em vez de indicadores de toda a agregação, para que possamos reutilizá-los), acompanhados da exibição da fase.