Leia mais sobre por que os Rollups precisam de um comitê de segurança?

AUTOR ORIGINAL: PATRICK MCCORRY

Compilação original: Luffy, Foresight News

Qualquer banco de dados que interaja com criptoativos um dia escolherá o Rollup como a pilha de tecnologia. Há uma série de boas razões para os desenvolvedores tomarem essa decisão:

• Auditoria em tempo real
• Certificado de solvência por defeito
• A garantia de fundos do usuário é opcional
• Um participante honesto protege todo o sistema

Mais importante ainda, todos os esforços de design e implementação do Rollup estão focados em proteger os usuários, seus fundos e todas as suas interações de operadores de sistema potencialmente desconhecidos e poderosos.

Mesmo que todo o sistema esteja offline, os usuários podem recuperar seus fundos por conta própria.

Se os Rollups puderem ser amplamente implantados como uma pilha de tecnologia, então poderemos ter a capacidade de quebrar barreiras de confiança e permitir interações financeiras para qualquer pessoa na comunidade global, levando a uma nova era de comércio eletrônico global, contratação remota e prestação de serviços sem atrito.

É preciso muito esforço para que um rollup funcione corretamente.

E os multisigs?

Isso parece bom, mas todo o sistema é controlado por multisig. Se o signatário estiver comprometido ou mal-intencionado, então eles podem facilmente roubar todos os fundos.

Então, quem se importa com Rollups? em algum lugar no CT.

É verdade que todos os rollups atuais têm multisig e têm o direito de atualizar o contrato inteligente subjacente, mas como veremos, é um mecanismo conservador que protege os fundos do usuário e faz parte de uma arquitetura de sistema mais ampla.

Responsabilidades do Comité de Segurança

Multisig é um termo técnico que se refere a um sistema que requer vários signatários para autorizar uma ação. Por exemplo, K dos signatários N concluem a assinatura digital para que a transação seja permitida.

No contexto de rollups, o multisig é muitas vezes referido como um comitê de segurança, onde os signatários recebem o poder de atualizar todos os contratos inteligentes relacionados.

Vamos dar uma olhada no Conselho de Segurança em Arbitrum (como eu estou muito familiarizado com ele) para ter uma ideia dos tipos de responsabilidades que esta organização pode ter:

*Veto. Se o Comitê de Segurança acreditar que uma proposta aprovada pelo Arbitrum DAO viola a carta do Arbitrum e pode prejudicar o ecossistema do Arbitrum, ele pode cancelar a proposta. Por exemplo, cancelar uma proposta que passou devido a um ataque de governança. *Manutenção. Atualize o pacote de contratos inteligentes da Arbitrum para fazer pequenas alterações que sejam menos impactantes e não exijam o envolvimento da Arbitrum DAO.

• Emergências. Responda rapidamente em caso de emergência e, se eles acreditarem que os fundos do usuário estão em risco iminente, eles podem atualizar urgentemente o contrato inteligente.

Naturalmente, o mais importante é que o primeiro dever do comité de segurança é responder a emergências e agir rapidamente para proteger os fundos dos utilizadores.

Os membros do comité de segurança têm de ser pessoas muito fiáveis.

Há uma confiança nos signatários para serem capazes de reagir rapidamente, para serem capazes de atualizar o contrato inteligente no caso de uma emergência e para fazer o seu melhor para manter os fundos no contrato inteligente seguros.

Selecione o limite multisig correto

Há dois fatores importantes a ter em conta ao decidir criar um comité de segurança:

• Quantos signatários existem?
• Qual é o número mínimo de subscritores necessário para aprovar uma ação?
• Esta pode parecer uma pergunta trivial, afinal, são apenas dois números, mas há um equilíbrio que deve ser considerado:
• Violação de segurança: os membros K podem conspirar para alterar contratos inteligentes e roubar fundos do usuário.
• Violação ativa: Os membros do N-K+ 1 entram em conluio para evitar quaisquer alterações ao contrato inteligente, especialmente se for encontrada uma vulnerabilidade crítica.

O desafio consiste em estabelecer um limiar que mantenha os fundos seguros em tempo de paz e aja rapidamente em caso de emergência quando os fundos dos utilizadores estiverem ameaçados.

Vamos considerar um exemplo específico. Digamos que o limite é definido como 9/10, onde 9 signatários devem coassinar uma mensagem. Este é um limite de segurança rigoroso, pois 9 signatários devem se conluiar para roubar os fundos. A desvantagem, no entanto, é que quaisquer dois signatários podem bloquear qualquer ação em caso de emergência. Por exemplo, se dois signatários viajarem para longe num voo transatlântico, o Comité de Segurança não poderá cumprir as suas obrigações.

Claro, se o limite de segurança for baixo, digamos 2/10, basta que dois signatários entrem em conluio (ou a chave privada seja comprometida) para que os fundos do usuário sejam roubados.

É provável que a perceção da integridade de uma pessoa mude ao longo do tempo

Escolher o limiar adequado é mais uma questão social do que técnica, e acho que é mais uma arte do que uma ciência. A segurança depende muito da integridade do signatário individual. Como veremos em breve, existem maneiras de reduzir a confiança no multisig, mas isso vem com uma série de compensações.

Membro do Comité de Segurança

O pacote cumulativo principal atualiza instantaneamente o limite multisig necessário para todos os contratos inteligentes

A maioria dos Rollups tem um grupo de signatários anônimos em seus comitês de segurança. Suspeitamos que isso possa ser devido a:

• A fase de desenvolvimento do rollup,
• Para proteger a segurança pessoal dos membros,
• Acredite que o anonimato é a melhor opção para proteger os fundos dos utilizadores.
• Por outro lado, existem três projetos Rollup que anunciaram publicamente sua participação no comitê de segurança:
• Arbitrum: Os signatários são eleitos publicamente, e a lista atual pode ser vista em Tally. Apenas três signatários estão associados ao projeto Arbitrum (dois da Offchain Labs e um da Arbitrum Foundation).
• Base: 2/2 multisig, um controlado pela Base e o outro controlado pela Optimism.
• Polygon zkEVM: Ainda não implementado, mas eles anunciaram que atualizarão seu multisig para 13/10, que inclui dois membros da Polygon Labs e um consultor da Polygon Labs.
• zkSync Lite: zkSync Lite deve ser distinguido do ZkSync Era, cujo comitê de segurança é anunciado publicamente e não inclui afiliados diretos do projeto Rollup (exceto para investidores no zkSync).

No Arbitrum, e no próximo Polygon, apenas um punhado de signatários está diretamente associado ao projeto Rollup, e o número é pequeno o suficiente para garantir que os afiliados não possam entrar em conluio para bloquear as ações tomadas pelo Comitê de Segurança. No zkSync Lite, além dos investidores do zkSync, eles nomeiam signatários que são independentes do projeto.

Em todos os casos, o Rollup atribui um alto valor aos signatários que não estão diretamente relacionados ao projeto.

No entanto, parece haver uma falta de consenso sobre o que constitui um bom multisig, o que nos leva a várias questões de design:

• Devem ser permitidos membros anónimos?
• Os membros devem ser de diferentes geografias?
• Os membros devem ser pessoas físicas ou jurídicas?
• Os membros devem ser nomeados ou eleitos?
• Quantos membros da mesma empresa (ou país) devem ser permitidos?
• Existe uma dimensão e um limiar mínimos considerados adequados?

A regra geral deve ser a escolha de membros com um elevado grau de integridade, de modo a que o público tenha confiança na segurança do sistema. Pelo menos, acredito que a maioria dos projetos provavelmente o faz, mesmo que isso nem sempre seja publicamente verificável.

P.S. Seis membros do Comité de Segurança do Arbitrum estão atualmente pré-nomeados, mas serão substituídos nas eleições de março.

Enfraquecer os poderes da Comissão

Até agora, consideramos apenas um comitê que tem o poder de atualizar o contrato inteligente imediatamente, mas há maneiras de limitar os poderes do comitê:

Atraso. Todas as ações autorizadas pela Comissão não serão realizadas e produzirão efeitos até ao termo do tempo T.

Somente pausa. Todos os ativos detidos pela ponte de cadeia cruzada nativa podem ser congelados pelo comitê. Isso pode suspender os seguintes recursos:

• Entregar a mensagem de L2 para L1 (ou seja, retirar dinheiro),
• Concluir a classificação de transações pendentes,
• Completar novos pontos de verificação / certificados,
• Aceitar novos dados de rollup (ou seja, transações pendentes).

Bypass Commission (Removido). Abandone o comitê e conte com outro mecanismo de governança, como uma DAO, para aprovar a atualização.

Isto, evidentemente, limita a capacidade da Comissão para agir rapidamente e a sua capacidade de responder eficazmente a emergências que ameacem os fundos dos utilizadores.

Se a vulnerabilidade tiver sido divulgada ao comitê de forma privada, mas ainda não tiver sido explorada por hackers, o comitê de segurança tem a opção de atualizar o contrato inteligente e corrigir o bug. Adicionar um atraso de tempo a uma atualização aumenta o risco de que um invasor pesquise uma atualização divulgada publicamente, encontre uma vulnerabilidade e a explore.

Por exemplo, CVE-2018-17144 no BTC foi inicialmente anunciado como uma vulnerabilidade DDoS em uma tentativa de esconder uma vulnerabilidade mais séria de inflação de tokens. A velocidade da atualização é fundamental para evitar que ela seja explorada.

Avalie as defesas do mecanismo somente pausa

Vamos considerar um cenário potencial para um invasor explorar ativamente uma vulnerabilidade:

• Mensagens L2 → L1 maliciosas. Um invasor pode criar mensagens arbitrárias originadas de um contrato inteligente em um rollup e encaminhar a mensagem para o contrato inteligente no ETH por meio de uma ponte de cadeia cruzada nativa.
• Transições de estado inválidas. Um invasor pode executar uma transação em um pacote cumulativo que viola as regras da função de transição de estado e geralmente deve ser considerado inválido.
• Lacunas em matéria de retirada. Um invasor pode retirar fundos da ponte de cadeia cruzada nativa simplesmente emitindo uma transação no ETH Fang (Camada 1).

Nos três casos, o atraso apenas dá ao atacante mais tempo para continuar roubando os fundos e reduz a janela de oportunidade para o comitê defender o sistema. O recurso de lapso de tempo não protege contra ataques ativos e só pode ser usado para manutenção de rotina e tarefas não urgentes.

Avaliaremos apenas a capacidade de pausar o sistema e até que ponto o sistema pode ser suspenso.

No caso de mensagens L2 → L1 maliciosas, o recurso de pausa pode mitigar o ataque sem interferir nas atividades de negociação. O comitê deve suspender as mensagens e/ou finalizar a funcionalidade de novos pontos de controle. Há um argumento de que deve haver um atraso antes que a mensagem L2 → L1 seja executada para que o comitê tenha tempo para detetar erros e reagir a emergências.

A defesa contra transições de estado inválidas é mais complicada porque a finalidade da transação tem diferentes camadas em rollups. Se considerarmos apenas as transações cumulativas sem considerar quaisquer efeitos colaterais, a melhor defesa para o comitê de segurança seria interromper a capacidade de finalização do ponto de verificação, mas continuar a permitir que as transações sejam classificadas. Isso dá tempo para corrigir bugs, reativar a conclusão do ponto de verificação e simplesmente ignorar transações inválidas.

No entanto, se a atividade de negociação no Rollup não estiver desativada, a experiência do usuário será caótica e o Rollup poderá parecer estar gravemente quebrado até que o software cliente seja atualizado.

Isso nos leva ao próximo cenário. Como a comissão deve reagir se considerarmos como transações inválidas em rollups podem afetar outros sistemas? A melhor linha de defesa é congelar a capacidade da ponte de cadeia cruzada nativa de finalizar a ordem das transações, ou desligar totalmente o sequenciador.

Isso ocorre porque certos sistemas, como pontes rápidas de cadeia cruzada que transferem fundos de um pacote cumulativo para outro, podem autorizar a transferência de fundos quando acreditarem que as transações do pacote cumulativo (incluindo transações inválidas) são classificadas. Neste exemplo, ele pode permitir que um invasor explore um protocolo DeFi em um Rollup e, em seguida, transfira fundos rapidamente transferindo-os para outro Rollup por meio de uma ponte rápida entre cadeias.

No momento em que a comissão corrige a violação e restabelece a transação inválida, o dano pode já ter sido feito. LPs em protocolos DeFi e pontes de cadeia cruzada podem suportar o custo de um ataque.

Finalmente, se a vulnerabilidade permitir que um invasor retire fundos diretamente da ponte de cadeia cruzada nativa, semelhante ao Nomad Hack, o comitê de segurança pode ser impotente para detê-la.

Em última análise, existe um problema global com o mecanismo de suspensão. Temos que assumir que existe um sistema de governança mais amplo que pode aprovar atualizações e reativar rollups. Se assumirmos que o sistema de governança é uma DAO com um sistema de votação on-chain rodando no Rollup, então surgem problemas de implementação complicados.

Por exemplo, se a ponte de cadeia cruzada de mensagens L2→L1 estiver pausada, os resultados de votação da DAO não poderão ser passados do rollup para a ponte de cadeia cruzada nativa na ETH, e deve haver uma maneira alternativa para a DAO enviar a aprovação e executar a atualização.

Extinção progressiva do Conselho de Segurança

Há pessoas na comunidade que acreditam que o comité de segurança deve ser gradualmente eliminado, mas, na minha opinião, isto levanta dois problemas:

Falsa sensação de segurança. Os atacantes que estão cientes da exploração esperam até que o comitê de segurança seja eliminado antes de executar o ataque. Com o tempo, isso pode minar a nossa confiança na segurança dos nossos sistemas.

As opções de recuperação são limitadas. Sem um comitê de segurança, a comunidade não pode lutar contra os agressores. A única opção disponível é executar um hack paralelo white hat e, esperançosamente, recuperar alguns dos fundos.

Na minha opinião, os comités de segurança serão sempre necessários, mas os poderes que lhes são conferidos devem ser gradualmente reduzidos.

Com isso em mente, a questão do design deve ser:

Como podemos fazer com que o comitê de segurança suspenda o sistema com impacto mínimo para os usuários, permitindo que a comunidade em geral participe da decisão de como corrigir bugs e reativar o sistema?

Em outras palavras, precisamos de um programa que realmente permita que a comunidade intervenha e restaure o sistema e, em seguida, limite o poder de suspensão do Conselho de Segurança.

No espaço blockchain da Camada 1, a comunidade pode realmente ser alcançada diretamente usando forks ativados pelo usuário, mas esse método não funciona para contratos inteligentes em quadrados ETH (como Rollups) porque não há necessidade de bifurcar todo o ETH. Em alguns casos, a comunidade ETH pode decidir coletivamente salvar o Rollup, como o TheDAO em 2016, mas o Rollup nunca deve confiar ou esperar tal resultado.

Outra ideia interessante nesse sentido é implementar um ETH para que a Suprema Corte decida sobre atualizações de contratos inteligentes e habilite bifurcações semelhantes à ativação do usuário.

Como mencionado anteriormente, se o Rollup delegar sua segurança ao DAO, então deve haver uma implementação que permita que o DAO vote diretamente no ETH. Isso é muito complicado, especialmente se o protocolo de votação existir no Rollup.

Por último, penso que é necessária uma revisão abrangente dos tipos de situações que podem exigir uma resposta do Conselho, a fim de facilitar a discussão em torno da sua necessidade.

Por que se preocupar com rollups se você tem multisigs?

Passamos um bom tempo entendendo as responsabilidades, o design e as necessidades do comitê de segurança, mas é importante voltar à pergunta original deste artigo:

O Rollup é apenas um multisig?

A resposta é não.

Para ajudar a entender o porquê, é melhor dar um passo atrás e entender o que o sistema blockchain realmente quer fazer.

Um protocolo blockchain é uma ferramenta que permite aos usuários calcular uma cópia de um banco de dados e ter certeza de que eles têm o mesmo banco de dados que todos os outros.

Com isso em mente, existem dois componentes para qualquer sistema blockchain:

• Protocolo Blockchain. A combinação de software, criptografia e sistemas distribuídos dá a qualquer pessoa confiança na integridade de um banco de dados.
• Sistema de governação. Um mecanismo de coordenação que permite que todas as partes interessadas trabalhem em conjunto e cheguem a acordo sobre as alterações ao protocolo blockchain.

O objetivo de qualquer sistema blockchain, incluindo o Rollup, é garantir que o protocolo blockchain seja sempre executado com um tempo de atividade extremamente confiável de 99,9999%. Um operador de rede de confiança deve ter pouca ou nenhuma interferência com o funcionamento quotidiano do sistema. Em última análise, é o software, a criptografia e os sistemas distribuídos que, em última análise, são responsáveis por proteger os equilíbrios do usuário, o código do contrato inteligente e o estado.

Às vezes é necessário mudar o protocolo blockchain para melhorar os interesses dos usuários. A comunidade pode querer corrigir problemas de configuração, adicionar novos recursos ou reagir a vulnerabilidades críticas que ameaçam a integridade do sistema. Isso requer intervenção humana e só pode ser chamado de 0,0001% do tempo.

Os sistemas de governação são responsáveis pela implementação da intervenção humana, tendo surgido várias abordagens ao longo dos anos:

• Partidos políticos totalitários: Os partidos unilaterais podem decidir individualmente como atualizar o sistema (muitos projetos, incluindo o BTC, começaram desta forma).
• Consenso aproximado: A maioria dos participantes disse que estava pronta para implantar a atualização, determinar o dia da marca e, em seguida, executar a atualização no dia da marca (BTC / ETH).
• Acordo de votação: Todos os partidos participam da eleição e votam explicitamente se aprovam a escalada.
• Sem interferência: Os contratos inteligentes podem ser imutáveis e o sistema nunca pode ser alterado.

Além disso, a comunidade também pode decidir nomear um comitê de segurança como uma opção complementar à governança para agir rapidamente em uma emergência.

O Conselho de Segurança não impede o ataque. Este é um mecanismo passivo que funciona em conjunto com a governança quando os fundos do usuário de um protocolo blockchain ou a confiabilidade/desempenho do sistema são atacados.

Finalmente

Todas as discussões em torno de protocolos blockchain, governança e comitês de segurança são cruciais. A existência dessa discussão é o que torna as criptomoedas tão especiais.

Este é um bom exemplo de engenharia de confiança: uma disciplina de engenharia que se concentra em identificar, medir e reduzir/eliminar elementos de confiança em um sistema.

Em criptomoedas, nos concentramos na construção de sistemas que não apenas protejam os usuários de poderosos operadores de sistema, mas também permitam que eles operem de forma confiável (com segurança) sob as condições mais adversas.

É por isso que é saudável que os membros da comunidade sejam céticos sobre o papel do comitê de segurança, mas eles têm a responsabilidade de encontrar melhores soluções durante emergências para proteger os fundos dos usuários de forma reativa.

Espero que este artigo deixe claro por que os comitês de segurança são úteis, eles são necessários hoje, mas são apenas uma pequena parte da arquitetura mais ampla dos sistemas de contratos inteligentes.