Num novo post no fórum, propomos atualizar os requisitos da Fase 1 introduzindo um novo "teste de desistência do Conselho de Segurança" que tenta responder à pergunta: Os usuários podem sair, na presença de operadores maliciosos, mesmo que o Conselho de Segurança desapareça?

O atual requisito da Fase 1 permite o uso ativo da minoria do Conselho de Segurança para fornecer resistência à censura, garantias de continuidade ou garantias de segurança, sem a necessidade de implementar mecanismos verdadeiramente sem permissões.

Embora na altura tenhamos decidido não abordar esta potencial falha, notámos um aumento do interesse por parte dos projetos em utilizar tais estratégias para alcançar a Fase 1 e um declínio do interesse em fortalecer os sistemas de prova ou implementar txs forçados.

Discutimos três projetos da Fase 1 que atualmente não passam no teste de desistência: @Starknet, @KintoXYZ (agora encerrado) e @Scroll_ZKP. Embora forneçamos um breve resumo aqui, convidamos as pessoas a lerem os detalhes no post.

Hoje, a Starknet satisfaz o requisito atual da Fase 1 utilizando a minoria do Conselho de Segurança como um provedor com permissão. Se os usuários forem censurados, devem entrar em contato com os membros do Conselho de Segurança, que devem então operar a infraestrutura do provedor de forma oportuna.

Nenhum mecanismo exato foi definido sobre como contatar o Conselho de Segurança em termos de censura. De forma equivalente, se o Conselho de Segurança não conseguir executar o provador a tempo, ou simplesmente desaparecer, os fundos podem ser comprometidos.

Uma forma mais robusta de satisfazer o princípio da Fase 1 seria implementar transações forçadas e um fallback de liveness para o provador. O Starknet atualmente carece de ambos os mecanismos.

.@KintoXYZ usou membros do Conselho de Segurança como os únicos desafiantes com permissão no protocolo. Se o Conselho de Segurança "se afastar", ou não conseguir fornecer o serviço de maneira oportuna, os fundos podem ser comprometidos. Uma solução mais robusta seria abrir desafios sem permissão.

Finalmente, enquanto @Scroll_ZKP já implementa transações forçadas e um fallback de liveness para o provador com permissão, apenas o Conselho de Segurança pode recuperar de uma pausa maliciosa. Uma pausa que expira automaticamente seria suficiente para satisfazer o teste.

Notavelmente, muitas das principais cadeias já satisfazem os testes de desistência do Conselho de Segurança e não precisariam de alterações para manter a designação de Fase 1: @arbitrum, @Optimism, @inkonchain e @unichain. Todas elas já implementam txs forçadas e prova sem permissão.

@Scroll_ZKP Notavelmente, muitas das principais cadeias já satisfazem os testes de desistência do Conselho de Segurança e não precisariam de alterações para manter a designação de Fase 1: @arbitrum, @Optimism, @base, @inkonchain e @unichain. Todas elas já implementam txs forçados e prova sem permissão.