ObrigadoAmbição 3, terence 3, Artigo 9.º, Equipa do Protocolo de Pesquisa Titania para discussão e feedback
Este documento classifica os métodos de ataque contra o PoS Ethereum e propõe contramedidas, especialmente contra o notavelmente perigoso ataque de 51%. Os principais pontos são os seguintes:
O objetivo desta proposta é melhorar a segurança do Ethereum PoS, especificamente fortalecendo as defesas contra o perigoso ataque de 51%.
Vários métodos de ataque contra PoS Ethereum são conhecidos, com resultados potenciais que os atacantes podem alvejar realisticamente, incluindo reorg, dupla finalidade e atraso na finalidade. Um fator crucial nesta análise é a proporção de participação necessária para um ataque, indicando a participação mínima necessária, que serve como uma barreira à entrada. No entanto, quase tão crítico é a sustentabilidade do ataque, que mede quão continuamente um atacante pode manter o ataque. Se um ataque for sustentável, poderia causar danos significativos. Além disso, a furtividade do ataque também é importante, pois indica quão furtivamente um atacante pode executar um ataque. Se um protocolo não consegue detetar um ataque, torna-se difícil determinar se são necessárias medidas defensivas. Valores mais altos para ambas as métricas indicam uma perspetiva mais negativa do ponto de vista do protocolo. Os métodos de ataque representativos analisados incluem:
O atraso final é um ataque que pode ser executado com uma taxa de staking de 33%. O atacante impede a finalização ao não fornecer 33% dos atestados. Uma medida defensiva durante este ataque é o mecanismo de fuga de inatividade. Este mecanismo identifica validadores que não atestam ou atestam contra a maioria, reduzindo o ETH apostado de tais validadores inativos. Durante um ataque de 33%, o vazamento de inatividade é ativado, fazendo com que o ETH do atacante diminua e fique abaixo da quantidade necessária para sustentar o atraso final. Consequentemente, a sustentabilidade do ataque é relativamente baixa e temporária, tornando-o mais fácil de detetar devido ao vazamento de inatividade.
A dupla finalidade refere-se a um ataque em que o atacante envia certificações para finalizar duas ramificações simultaneamente. Para alcançar a dupla finalidade, o atacante requer uma proporção de aposta de 34%. O atacante se envolve em dupla votação para os 34% das certificações, trabalhando para finalizar ambos os forks. Medidas defensivas durante este ataque incluem o mecanismo de slashing. Uma vez que a dupla votação é proibida, o atacante perderia seu ETH apostado, tornando o ataque facilmente detectável (baixa indetectabilidade). Além disso, a penalidade substancial de slashing significa que o ataque provavelmente só acontecerá uma vez; se o atacante tivesse orçamento para atacar múltiplas vezes, provavelmente escolheria um ataque de 66% em vez disso. Assim, a sustentabilidade do ataque por este método também é muito baixa.
Quando um atacante possui uma taxa de participação de 51%, eles podem manipular o algoritmo de escolha de fork. Os ataques A e B foram direcionados ao Casper FFG (gadget de finalidade), enquanto este ataque visa o LMD GHOST (algoritmo de escolha de fork). Neste cenário, o atacante pode criar livremente o ramo mais pesado no LMD GHOST, fazendo com que os validadores honestos sigam o ramo do atacante, resultando em finalização. Isso permite que o atacante censure transações específicas e realize reorganização de curto prazo (reorg) para maximizar seu valor extraível de minerador (MEV) sem incorrer em penalidades de slashing.
Nos ataques A e B, existiam mecanismos para reduzir o potencial do atacante no momento da ocorrência. No ataque A, a fuga de inatividade diminui a proporção de aposta do atacante abaixo do limite de 33%, tornando o ataque impossível. No ataque B, um terço de sua proporção de aposta é cortado durante essa época, tornando ataques repetidos efetivamente inviáveis.
No entanto, atualmente não existem medidas defensivas algorítmicas contra o ataque C. Mesmo que haja um slot com uma taxa de votação de 51%, não há maneira de distinguir se essa atestação é maliciosa ou uma discordância legítima entre validadores honestos. Isso significa que a indetectabilidade do ataque é significativamente alta. Uma vez que um ataque tenha sucesso, o atacante pode continuar persistentemente o ataque até que uma decisão de hard fork seja tomada através da camada social, resultando em uma sustentabilidade de ataque muito alta.
No ataque curto-reorg e de censura de 66%, o atacante pode manipular livremente a finalização, reescrever cadeias passadas e finalizar novos ramos. As características do ataque D são semelhantes às do ataque C, ambos exibindo alta indetectabilidade e alta sustentabilidade.
Um ponto crítico a destacar é que, após executar um ataque de 51%, o atacante pode utilizar os lucros para visar um ataque de 66%. Os ganhos potenciais de um ataque de 51% são significativamente maiores em comparação com os ataques de 33% e 34%, e porque não incorrem em penalidades como vazamento de inatividade ou redução, uma tentativa bem-sucedida poderia aumentar exponencialmente sua dominação.
A seguinte tabela resume as características dos principais métodos de ataque analisados:
Método de Ataque | Taxa de Staking | Ataque Stealthability | Sustentabilidade de Ataque |
A. Ataque de atraso de finalidade | 33% | Baixo | Baixo |
B. Ataque de dupla finalidade | 34% | Baixo | Baixo |
Ataque C. Short-reorg & censura (controlo sobre o futuro) | 51% | Alto | Alto |
D. Ataque de reorganização curta e censura (controle sobre passado e futuro) | 66% | Alto | Alto |
A partir desta tabela, pode-se observar uma tendência interessante: ataques nos níveis de 33% e 34% (A e B) são fáceis de detectar e apresentam baixa sustentabilidade, enquanto ataques de 51% ou mais (C e D) são difíceis de detectar e mostram alta sustentabilidade, ilustrando uma clara dicotomia.
Gostaria de enfatizar a importância de considerar cenários de pior caso em relação à segurança do Ethereum PoS. Em termos simples, existe uma possibilidade real de que o Ethereum possa enfrentar uma situação descrita como 'game over'. Se tal cenário ocorresse, todas as atividades passadas e dados em inúmeros ecossistemas seriam anulados e tornados nulos.
Refira-se à tabela anterior, os ataques A e B têm baixos níveis tanto de detetabilidade de ataque como de sustentabilidade de ataque. Do ponto de vista de um atacante, há uma grande probabilidade de que as suas ações sejam expostas, e esses ataques tendem a ser de curta duração.
Em contrapartida, os ataques C e D exibem altos níveis tanto de furtividade quanto de sustentabilidade. Para os atacantes, essas ações são menos propensas a serem detectadas, permitindo que eles sustentem o ataque por um período mais longo e potencialmente obtenham lucros imensos. Ao considerar qual dos dois ataques, C ou D, focar, devemos primeiro prestar atenção à taxa de apostas como uma barreira ao ataque. Embora ambos os ataques possam causar danos significativos, o ataque C, que requer uma quantidade absoluta menor para ser executado, é mais realisticamente direcionado (especialmente considerando seu potencial para levar ao ataque D). À luz dessas considerações, esta discussão explorará medidas defensivas contra ataques de reorganização curta e censura de 51%.
O problema chave com os ataques de reorganização curta e censura de 51%, como mencionado acima, é o alto nível de indetectabilidade e sustentabilidade dos ataques, o que implica que o dano potencial pode ser extenso.
Vamos aprofundar a sustentabilidade do ataque. A razão pela qual esses ataques são sustentáveis é que a única medida defensiva disponível é um hard fork através de consenso social, o que leva tempo considerável (como demonstrado pelo incidente DAO, que levou um mês desde a descoberta do hack até o hard fork). Durante este intervalo, os blocos e épocas finalizados pelo atacante irão acumular na cadeia legítima. Validadores honestos correm o risco de serem penalizados por atestar blocos em uma cadeia ilegítima que se tornou a minoria, apesar de ser a canônica. A questão crucial reside no fato de que o número de épocas necessárias para a finalização é fixo; assim, mesmo em emergências, a finalização ocorre ao longo das mesmas duas épocas (aproximadamente 13 minutos) como ocorre em circunstâncias normais.
No caso de um ataque de 51%, prevemos que os atestados exibirão uma margem apertada, como 50,5% vs. 49,5%, e tais disputas próximas são relativamente raras durante as operações normais. Introduzimos uma métrica para indicar a probabilidade de a época atual ser atacada com base no número de faixas horárias em que os votos principais estão 'próximos'. Além disso, à medida que essa métrica aumenta, o número de épocas necessárias para a finalização aumentará exponencialmente. Este mecanismo permite o adiamento algorítmico da finalização durante emergências, permitindo que a comunidade responda aos atacantes através de meios sociais sem a necessidade de um hard fork. Como os períodos normais de finalização permanecerão inalterados, essa implementação pode ser perfeitamente integrada sem comprometer a experiência do usuário. Propomos o mecanismo de deteção de voto próximo para o primeiro e a finalização dinâmica emergente para o segundo como defesas contra ataques de 51%.
Quando ocorre um ataque de 51%, os atacantes escolhem deliberadamente um cabeçalho que parece canônico por ser o mais pesado. Os validadores honestos ainda podem propor blocos, mas os atacantes podem facilmente manipular o cabeçalho canônico através de reorganizações a curto prazo sempre que encontrarem os blocos propostos indesejáveis. Quanto mais próxima a proporção de participação do atacante estiver de 50%, mais próxima será a quantidade de atestações de 50%. Tais atestações que estão muito próximas de 50% do cabeçalho serão referidas como 'votos próximos'. Atualmente, a determinação de se finalizar um época é feita no último slot dessa época, onde adicionaremos a contagem de votos próximos.
Se a ocorrência de votos de encerramento exceder um determinado limite, o sistema reconhecerá um estado de emergência e aumentará significativamente o número de épocas necessárias para a finalização. Como resultado, o atacante precisará manter uma maioria substancial de votos por um período mais longo para alcançar a finalização. Durante esse tempo, a comunidade terá a oportunidade de implementar contramedidas. Especificamente, se o número de slots classificados como votos de encerramento na época atual exceder um determinado limite, o número de épocas necessárias para a finalização será dramaticamente aumentado em relação às duas épocas padrão. Referimo-nos a isso como modo de emergência. Embora haja muito espaço para debate sobre qual deve ser esse valor, buscar uma melhoria significativa em relação ao atraso de um mês ocorrido no incidente do DAO pode sugerir tentar um valor como
. Isso exigiria que o atacante continuasse seu ataque por cerca de nove dias (32.768 * 12 segundos ≈ 4.551.168 segundos ≈ 9 dias), proporcionando à comunidade tempo suficiente para implementar contramedidas rapidamente. Este mecanismo defensivo garante que as operações normais da rede não sejam afetadas e sejam ativadas apenas durante emergências, permitindo assim uma implementação suave sem degradar a experiência do utilizador. Além disso, uma vez que funciona algoritmicamente, pode ser executado imediatamente sem esperar pelo julgamento humano, permitindo respostas rápidas.
Vamos definir os seguintes símbolos, onde W, E, Fsão parâmetros:
Na sua forma inicial mais simples, propomos o seguinte:
Aqui estão os parâmetros definidos:
As fórmulas fornecidas definem dois indicadores que indicam a possibilidade de um ataque de 51%. Primeiro, Ci indica se um slot específico é considerado um voto fechado, resultando em 1 quando |Vi−0.5|
cai dentro do limiar W. Em segundo lugar, F indica o número de épocas necessárias para a finalização. Portanto, se o número de slots de votação fechada atingir o limite E, o número necessário de épocas aumenta para D, planejando assim ataques sustentados e mitigando seus impactos potenciais. Vamos considerar valores específicos:
Assim, temos:
Com essas configurações, se a porcentagem de atestação Vi de qualquer slot estiver dentro de ±1% de 50%, esse slot será contabilizado como um voto próximo. Se, por exemplo, 4 dos 32 slots forem votos próximos, o total de Ci será 4, exigindo que F seja ajustado para 215. Como resultado, o atacante não será capaz de finalizar a cadeia por aproximadamente nove dias, permitindo à comunidade tempo suficiente para implementar um hard fork rápido para restaurar a cadeia de blocos legítima do Ethereum.
O objetivo desta proposta é reduzir o dano máximo estimado durante um ataque de 51%. Visa atenuar a probabilidade de um cenário de «game over». Embora seja desafiador discutir mudanças quantitativas específicas, é viável definir o parâmetro D para garantir que a duração não se estenda a um mês, como no incidente DAO. É essencial considerar que o tempo de resposta previsto da camada social também deve ser levado em conta neste aspeto.
Além disso, vários serviços que interagem com o Ethereum, como outras cadeias e bolsas centralizadas, podem operar com base neste D. Ao introduzir mecanismos algorítmicos, os ecossistemas circundantes também poderão responder de forma algorítmica.
Existe uma preocupação de que esta proposta possa inadvertidamente criar um novo mecanismo de atraso na finalidade. Por exemplo, é possível controlar aleatoriamente 51% de domínio sobre
L ocorrências entre 32 slots, que podem ser facilmente calculadas usando uma distribuição binomial. Embora o incentivo econômico para atrasar a finalidade seja geralmente baixo, não podemos descartar incentivos potenciais que podem não ter sido considerados. Se tais incentivos surgirem, eles poderiam potencialmente ser abordados introduzindo um sistema de reputação. Uma vez que as atestações envolvem assinaturas, tentativas de se passar por outros validadores exigiriam tempo significativo para serem executadas.
Para determinar os parâmetros ótimos, precisamos examinar cuidadosamente os procedimentos específicos necessários para executar um hard fork através da camada social.
É necessário determinar empiricamente valores adequados para os parâmetros W (definindo o intervalo para votos de encerramento), E (definindo o limiar para a ativação do modo de emergência) e D (definindo quanto atrasar a finalização). Além disso, D é um componente da fórmula F, mas também poderíamos considerar um design mais dinâmico onde o aumento no número de votos de encerramento ∑iCi resultaria em um maior valor para F.
Precisamos determinar as especificações para atestações.
Nesta proposta, concentramo-nos no ataque de 51% particularmente perigoso como um dos métodos de ataque contra o PoS Ethereum, discutindo os seus riscos e implicações, ao mesmo tempo que propomos novas estratégias de defesa. Especificamente, o nosso objetivo era reforçar a resistência a ataques de 51% introduzindo mecanismos como a Detecção de Voto Próximo e a Finalização Dinâmica Emergente.
Pesquisas futuras devem explorar ainda mais a eficácia das estratégias de defesa propostas e sua aplicabilidade a outros métodos de ataque. Também é necessário continuar investigando a otimização de parâmetros e métodos de implementação específicos.
Além disso, analisar métodos de ataque contra diferentes algoritmos de consenso e formular estratégias de defesa com base em incentivos sociais são direções valiosas para discussão adicional. Estou ansioso para interagir com a comunidade Ethereum sobre o valor dessas ideias e abordar quaisquer preocupações.
ObrigadoAmbição 3, terence 3, Artigo 9.º, Equipa do Protocolo de Pesquisa Titania para discussão e feedback
Este documento classifica os métodos de ataque contra o PoS Ethereum e propõe contramedidas, especialmente contra o notavelmente perigoso ataque de 51%. Os principais pontos são os seguintes:
O objetivo desta proposta é melhorar a segurança do Ethereum PoS, especificamente fortalecendo as defesas contra o perigoso ataque de 51%.
Vários métodos de ataque contra PoS Ethereum são conhecidos, com resultados potenciais que os atacantes podem alvejar realisticamente, incluindo reorg, dupla finalidade e atraso na finalidade. Um fator crucial nesta análise é a proporção de participação necessária para um ataque, indicando a participação mínima necessária, que serve como uma barreira à entrada. No entanto, quase tão crítico é a sustentabilidade do ataque, que mede quão continuamente um atacante pode manter o ataque. Se um ataque for sustentável, poderia causar danos significativos. Além disso, a furtividade do ataque também é importante, pois indica quão furtivamente um atacante pode executar um ataque. Se um protocolo não consegue detetar um ataque, torna-se difícil determinar se são necessárias medidas defensivas. Valores mais altos para ambas as métricas indicam uma perspetiva mais negativa do ponto de vista do protocolo. Os métodos de ataque representativos analisados incluem:
O atraso final é um ataque que pode ser executado com uma taxa de staking de 33%. O atacante impede a finalização ao não fornecer 33% dos atestados. Uma medida defensiva durante este ataque é o mecanismo de fuga de inatividade. Este mecanismo identifica validadores que não atestam ou atestam contra a maioria, reduzindo o ETH apostado de tais validadores inativos. Durante um ataque de 33%, o vazamento de inatividade é ativado, fazendo com que o ETH do atacante diminua e fique abaixo da quantidade necessária para sustentar o atraso final. Consequentemente, a sustentabilidade do ataque é relativamente baixa e temporária, tornando-o mais fácil de detetar devido ao vazamento de inatividade.
A dupla finalidade refere-se a um ataque em que o atacante envia certificações para finalizar duas ramificações simultaneamente. Para alcançar a dupla finalidade, o atacante requer uma proporção de aposta de 34%. O atacante se envolve em dupla votação para os 34% das certificações, trabalhando para finalizar ambos os forks. Medidas defensivas durante este ataque incluem o mecanismo de slashing. Uma vez que a dupla votação é proibida, o atacante perderia seu ETH apostado, tornando o ataque facilmente detectável (baixa indetectabilidade). Além disso, a penalidade substancial de slashing significa que o ataque provavelmente só acontecerá uma vez; se o atacante tivesse orçamento para atacar múltiplas vezes, provavelmente escolheria um ataque de 66% em vez disso. Assim, a sustentabilidade do ataque por este método também é muito baixa.
Quando um atacante possui uma taxa de participação de 51%, eles podem manipular o algoritmo de escolha de fork. Os ataques A e B foram direcionados ao Casper FFG (gadget de finalidade), enquanto este ataque visa o LMD GHOST (algoritmo de escolha de fork). Neste cenário, o atacante pode criar livremente o ramo mais pesado no LMD GHOST, fazendo com que os validadores honestos sigam o ramo do atacante, resultando em finalização. Isso permite que o atacante censure transações específicas e realize reorganização de curto prazo (reorg) para maximizar seu valor extraível de minerador (MEV) sem incorrer em penalidades de slashing.
Nos ataques A e B, existiam mecanismos para reduzir o potencial do atacante no momento da ocorrência. No ataque A, a fuga de inatividade diminui a proporção de aposta do atacante abaixo do limite de 33%, tornando o ataque impossível. No ataque B, um terço de sua proporção de aposta é cortado durante essa época, tornando ataques repetidos efetivamente inviáveis.
No entanto, atualmente não existem medidas defensivas algorítmicas contra o ataque C. Mesmo que haja um slot com uma taxa de votação de 51%, não há maneira de distinguir se essa atestação é maliciosa ou uma discordância legítima entre validadores honestos. Isso significa que a indetectabilidade do ataque é significativamente alta. Uma vez que um ataque tenha sucesso, o atacante pode continuar persistentemente o ataque até que uma decisão de hard fork seja tomada através da camada social, resultando em uma sustentabilidade de ataque muito alta.
No ataque curto-reorg e de censura de 66%, o atacante pode manipular livremente a finalização, reescrever cadeias passadas e finalizar novos ramos. As características do ataque D são semelhantes às do ataque C, ambos exibindo alta indetectabilidade e alta sustentabilidade.
Um ponto crítico a destacar é que, após executar um ataque de 51%, o atacante pode utilizar os lucros para visar um ataque de 66%. Os ganhos potenciais de um ataque de 51% são significativamente maiores em comparação com os ataques de 33% e 34%, e porque não incorrem em penalidades como vazamento de inatividade ou redução, uma tentativa bem-sucedida poderia aumentar exponencialmente sua dominação.
A seguinte tabela resume as características dos principais métodos de ataque analisados:
Método de Ataque | Taxa de Staking | Ataque Stealthability | Sustentabilidade de Ataque |
A. Ataque de atraso de finalidade | 33% | Baixo | Baixo |
B. Ataque de dupla finalidade | 34% | Baixo | Baixo |
Ataque C. Short-reorg & censura (controlo sobre o futuro) | 51% | Alto | Alto |
D. Ataque de reorganização curta e censura (controle sobre passado e futuro) | 66% | Alto | Alto |
A partir desta tabela, pode-se observar uma tendência interessante: ataques nos níveis de 33% e 34% (A e B) são fáceis de detectar e apresentam baixa sustentabilidade, enquanto ataques de 51% ou mais (C e D) são difíceis de detectar e mostram alta sustentabilidade, ilustrando uma clara dicotomia.
Gostaria de enfatizar a importância de considerar cenários de pior caso em relação à segurança do Ethereum PoS. Em termos simples, existe uma possibilidade real de que o Ethereum possa enfrentar uma situação descrita como 'game over'. Se tal cenário ocorresse, todas as atividades passadas e dados em inúmeros ecossistemas seriam anulados e tornados nulos.
Refira-se à tabela anterior, os ataques A e B têm baixos níveis tanto de detetabilidade de ataque como de sustentabilidade de ataque. Do ponto de vista de um atacante, há uma grande probabilidade de que as suas ações sejam expostas, e esses ataques tendem a ser de curta duração.
Em contrapartida, os ataques C e D exibem altos níveis tanto de furtividade quanto de sustentabilidade. Para os atacantes, essas ações são menos propensas a serem detectadas, permitindo que eles sustentem o ataque por um período mais longo e potencialmente obtenham lucros imensos. Ao considerar qual dos dois ataques, C ou D, focar, devemos primeiro prestar atenção à taxa de apostas como uma barreira ao ataque. Embora ambos os ataques possam causar danos significativos, o ataque C, que requer uma quantidade absoluta menor para ser executado, é mais realisticamente direcionado (especialmente considerando seu potencial para levar ao ataque D). À luz dessas considerações, esta discussão explorará medidas defensivas contra ataques de reorganização curta e censura de 51%.
O problema chave com os ataques de reorganização curta e censura de 51%, como mencionado acima, é o alto nível de indetectabilidade e sustentabilidade dos ataques, o que implica que o dano potencial pode ser extenso.
Vamos aprofundar a sustentabilidade do ataque. A razão pela qual esses ataques são sustentáveis é que a única medida defensiva disponível é um hard fork através de consenso social, o que leva tempo considerável (como demonstrado pelo incidente DAO, que levou um mês desde a descoberta do hack até o hard fork). Durante este intervalo, os blocos e épocas finalizados pelo atacante irão acumular na cadeia legítima. Validadores honestos correm o risco de serem penalizados por atestar blocos em uma cadeia ilegítima que se tornou a minoria, apesar de ser a canônica. A questão crucial reside no fato de que o número de épocas necessárias para a finalização é fixo; assim, mesmo em emergências, a finalização ocorre ao longo das mesmas duas épocas (aproximadamente 13 minutos) como ocorre em circunstâncias normais.
No caso de um ataque de 51%, prevemos que os atestados exibirão uma margem apertada, como 50,5% vs. 49,5%, e tais disputas próximas são relativamente raras durante as operações normais. Introduzimos uma métrica para indicar a probabilidade de a época atual ser atacada com base no número de faixas horárias em que os votos principais estão 'próximos'. Além disso, à medida que essa métrica aumenta, o número de épocas necessárias para a finalização aumentará exponencialmente. Este mecanismo permite o adiamento algorítmico da finalização durante emergências, permitindo que a comunidade responda aos atacantes através de meios sociais sem a necessidade de um hard fork. Como os períodos normais de finalização permanecerão inalterados, essa implementação pode ser perfeitamente integrada sem comprometer a experiência do usuário. Propomos o mecanismo de deteção de voto próximo para o primeiro e a finalização dinâmica emergente para o segundo como defesas contra ataques de 51%.
Quando ocorre um ataque de 51%, os atacantes escolhem deliberadamente um cabeçalho que parece canônico por ser o mais pesado. Os validadores honestos ainda podem propor blocos, mas os atacantes podem facilmente manipular o cabeçalho canônico através de reorganizações a curto prazo sempre que encontrarem os blocos propostos indesejáveis. Quanto mais próxima a proporção de participação do atacante estiver de 50%, mais próxima será a quantidade de atestações de 50%. Tais atestações que estão muito próximas de 50% do cabeçalho serão referidas como 'votos próximos'. Atualmente, a determinação de se finalizar um época é feita no último slot dessa época, onde adicionaremos a contagem de votos próximos.
Se a ocorrência de votos de encerramento exceder um determinado limite, o sistema reconhecerá um estado de emergência e aumentará significativamente o número de épocas necessárias para a finalização. Como resultado, o atacante precisará manter uma maioria substancial de votos por um período mais longo para alcançar a finalização. Durante esse tempo, a comunidade terá a oportunidade de implementar contramedidas. Especificamente, se o número de slots classificados como votos de encerramento na época atual exceder um determinado limite, o número de épocas necessárias para a finalização será dramaticamente aumentado em relação às duas épocas padrão. Referimo-nos a isso como modo de emergência. Embora haja muito espaço para debate sobre qual deve ser esse valor, buscar uma melhoria significativa em relação ao atraso de um mês ocorrido no incidente do DAO pode sugerir tentar um valor como
. Isso exigiria que o atacante continuasse seu ataque por cerca de nove dias (32.768 * 12 segundos ≈ 4.551.168 segundos ≈ 9 dias), proporcionando à comunidade tempo suficiente para implementar contramedidas rapidamente. Este mecanismo defensivo garante que as operações normais da rede não sejam afetadas e sejam ativadas apenas durante emergências, permitindo assim uma implementação suave sem degradar a experiência do utilizador. Além disso, uma vez que funciona algoritmicamente, pode ser executado imediatamente sem esperar pelo julgamento humano, permitindo respostas rápidas.
Vamos definir os seguintes símbolos, onde W, E, Fsão parâmetros:
Na sua forma inicial mais simples, propomos o seguinte:
Aqui estão os parâmetros definidos:
As fórmulas fornecidas definem dois indicadores que indicam a possibilidade de um ataque de 51%. Primeiro, Ci indica se um slot específico é considerado um voto fechado, resultando em 1 quando |Vi−0.5|
cai dentro do limiar W. Em segundo lugar, F indica o número de épocas necessárias para a finalização. Portanto, se o número de slots de votação fechada atingir o limite E, o número necessário de épocas aumenta para D, planejando assim ataques sustentados e mitigando seus impactos potenciais. Vamos considerar valores específicos:
Assim, temos:
Com essas configurações, se a porcentagem de atestação Vi de qualquer slot estiver dentro de ±1% de 50%, esse slot será contabilizado como um voto próximo. Se, por exemplo, 4 dos 32 slots forem votos próximos, o total de Ci será 4, exigindo que F seja ajustado para 215. Como resultado, o atacante não será capaz de finalizar a cadeia por aproximadamente nove dias, permitindo à comunidade tempo suficiente para implementar um hard fork rápido para restaurar a cadeia de blocos legítima do Ethereum.
O objetivo desta proposta é reduzir o dano máximo estimado durante um ataque de 51%. Visa atenuar a probabilidade de um cenário de «game over». Embora seja desafiador discutir mudanças quantitativas específicas, é viável definir o parâmetro D para garantir que a duração não se estenda a um mês, como no incidente DAO. É essencial considerar que o tempo de resposta previsto da camada social também deve ser levado em conta neste aspeto.
Além disso, vários serviços que interagem com o Ethereum, como outras cadeias e bolsas centralizadas, podem operar com base neste D. Ao introduzir mecanismos algorítmicos, os ecossistemas circundantes também poderão responder de forma algorítmica.
Existe uma preocupação de que esta proposta possa inadvertidamente criar um novo mecanismo de atraso na finalidade. Por exemplo, é possível controlar aleatoriamente 51% de domínio sobre
L ocorrências entre 32 slots, que podem ser facilmente calculadas usando uma distribuição binomial. Embora o incentivo econômico para atrasar a finalidade seja geralmente baixo, não podemos descartar incentivos potenciais que podem não ter sido considerados. Se tais incentivos surgirem, eles poderiam potencialmente ser abordados introduzindo um sistema de reputação. Uma vez que as atestações envolvem assinaturas, tentativas de se passar por outros validadores exigiriam tempo significativo para serem executadas.
Para determinar os parâmetros ótimos, precisamos examinar cuidadosamente os procedimentos específicos necessários para executar um hard fork através da camada social.
É necessário determinar empiricamente valores adequados para os parâmetros W (definindo o intervalo para votos de encerramento), E (definindo o limiar para a ativação do modo de emergência) e D (definindo quanto atrasar a finalização). Além disso, D é um componente da fórmula F, mas também poderíamos considerar um design mais dinâmico onde o aumento no número de votos de encerramento ∑iCi resultaria em um maior valor para F.
Precisamos determinar as especificações para atestações.
Nesta proposta, concentramo-nos no ataque de 51% particularmente perigoso como um dos métodos de ataque contra o PoS Ethereum, discutindo os seus riscos e implicações, ao mesmo tempo que propomos novas estratégias de defesa. Especificamente, o nosso objetivo era reforçar a resistência a ataques de 51% introduzindo mecanismos como a Detecção de Voto Próximo e a Finalização Dinâmica Emergente.
Pesquisas futuras devem explorar ainda mais a eficácia das estratégias de defesa propostas e sua aplicabilidade a outros métodos de ataque. Também é necessário continuar investigando a otimização de parâmetros e métodos de implementação específicos.
Além disso, analisar métodos de ataque contra diferentes algoritmos de consenso e formular estratégias de defesa com base em incentivos sociais são direções valiosas para discussão adicional. Estou ansioso para interagir com a comunidade Ethereum sobre o valor dessas ideias e abordar quaisquer preocupações.