Em uma nova postagem no fórum, propomos atualizar os requisitos da Fase 1 introduzindo um novo "teste de saída 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 requisito atual da Fase 1 permite o uso ativo da minoria do Conselho de Segurança para fornecer resistência à censura, garantias de vitalidade ou garantias de segurança, sem a necessidade de implementar mecanismos adequados sem permissões.

Embora na época tenhamos decidido não abordar essa possível brecha, notamos um interesse crescente dos projetos em usar tais estratégias para alcançar a Fase 1 e um interesse decrescente em reforçar os sistemas de prova ou implementar testes forçados.

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

Hoje, a Starknet atende ao requisito atual da Fase 1 usando a minoria do Conselho de Segurança como provedor autorizado. Se os usuários forem censurados, eles devem contatar os membros do Conselho de Segurança, que então devem administrar a infraestrutura provadora em tempo hábil.

Nenhum mecanismo exato jamais 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 administrar o provedor em tempo hábil, ou simplesmente desaparecer, os fundos podem ser comprometidos.

Uma forma mais robusta de satisfazer o princípio da Etapa 1 seria implementar transações forçadas e um recurso de liveness para o provedor. Atualmente, a Starknet não possui ambos os mecanismos.

.@KintoXYZ usou membros do Conselho de Segurança como únicos desafiantes autorizados no protocolo. Se o Conselho de Segurança "desistir" ou não conseguir fornecer o serviço em tempo hábil, os fundos podem ser comprometidos. Uma solução mais robusta seria abrir desafios sem permissões.

Por fim, enquanto @Scroll_ZKP já implementa transações forçadas e um recurso de ativação para o provedor autorizado, somente o Conselho de Segurança pode se recuperar de uma pausa maliciosa. Uma pausa que expire automaticamente seria suficiente para satisfazer o teste.

Notavelmente, muitas das principais cadeias já satisfazem os testes de saída do Conselho de Segurança e não precisariam de mudanças para manter a designação de Estágio 1: @arbitrum, @Optimism, @inkonchain e @unichain. Todos eles já implementam transmissões forçadas e provação sem permissões.

@Scroll_ZKP Notavelmente, muitas das principais cadeias já satisfazem os testes de abandono do Conselho de Segurança e não precisariam de mudanças para manter a designação de Estágio 1: @arbitrum, @Optimism, @base, @inkonchain e @unichain. Todos eles já implementam transmissões forçadas e provação sem permissões.