O cofundador da Rootstock, Sergio Lerner, pediu que as pontes Bitcoin adotem atrasos obrigatórios de saque depois que cerca de 4.000 BTC deixaram a carteira da federação da Liquid Network por meio de um peg-out não autorizado.
Resumo
- Um bloqueio de atraso temporal poderia dar aos operadores da ponte várias horas para identificar e impedir saques não autorizados.
- Os PowHSMs da Rootstock aguardam 4.000 blocos, ou cerca de 36 horas, antes de assinar um peg-out.
- Lerner disse que funcionários comprometidos da Rootstock poderiam interromper o peg, mas não poderiam forçar um saque antecipado.
- O rascunho de proposta Bitcoin BIP-443 poderia apoiar designs de cofres que colocam controles de saque nas regras de consenso.
Sergio Lerner, cientista-chefe e cofundador da RootstockLabs, disse ao crypto.news que a liquidação imediata pode transformar um único erro de validação em uma perda antes que os operadores da ponte tenham tempo de responder.
“Sem um bloqueio de atraso temporal, um único bug de validação e uma perda total se tornam exatamente o mesmo evento, porque os fundos se movem no momento em que o software diz ‘sim’”, disse Lerner.
Seus comentários seguiram um incidente no qual atores criaram L-BTC sem lastro e usaram o serviço de peg-out da SideSwap para sacar quase 4.000 BTC da carteira da Liquid Federation. A Liquid descreveu os atores como supostos hackers white-hat, enquanto a SideSwap disse que seu serviço processou a solicitação porque o L-BTC parecia válido.
Os atores posteriormente devolveram 3.400 BTC depois que a Blockstream confirmou que os nós de ponte afetados haviam sido corrigidos. Cerca de 598 BTC permaneceram pendentes, enquanto a Liquid retomou a produção de blocos sem restaurar transações ou operações de peg em 10 de setembro.
Um bloqueio de atraso temporal poderia ter criado uma janela de intervenção
Lerner disse que um atraso obrigatório entre a criação do L-BTC sem lastro e a liberação de BTC real poderia ter reduzido o dano.
Sob tal sistema, a aprovação do software iniciaria um período de espera em vez de concluir o saque. Ferramentas de monitoramento automatizadas poderiam comparar o peg-out solicitado com o BTC que lastreia o L-BTC e sinalizar qualquer desequilíbrio antes da liquidação.
“Se a Liquid tivesse possuído um bloqueio de atraso temporal — onde os fundos não podem se mover por um período especificado, independentemente do que o software ou os operadores digam — o bug teria resultado em um incidente gerenciável em vez de uma catástrofe imediata e em larga escala.”
De acordo com Lerner, o atraso teria dado aos operadores uma janela de resposta de várias horas após a criação dos tokens sem lastro. Sistemas de monitoramento funcionando 24 horas por dia poderiam ter detectado que o peg-out passou pelas primeiras verificações de software apesar de não ter garantia correspondente.
Funcionários poderiam então ter pausado o peg antes que o hardware assinasse a transação ou liberasse BTC da carteira da federação, acrescentou ele.
O sistema da Liquid não relatou uma Chave de Autorização de Peg-out roubada. A SideSwap disse que um cliente enviou 4.000 L-BTC para seu serviço de peg-out, que processou a solicitação sob seu processo normal porque os tokens não podiam ser distinguidos de L-BTC lastreado. A federação pagou 3.996 BTC para o endereço Bitcoin fornecido cerca de 23 minutos depois.
A proposta de Lerner colocaria um controle adicional após o primeiro estágio de validação. Mesmo se o software aprovasse erroneamente um saque, o atraso impediria que o BTC correspondente saísse imediatamente.
Rootstock impõe um atraso de 4.000 blocos para saques de Bitcoin
A Rootstock já usa um mecanismo de atraso para saques de BTC por meio de seu peg bidirecional, embora as regras de consenso do Bitcoin não imponham o período de espera.
O sistema depende de módulos de segurança de hardware especializados chamados PowHSMs. Antes de assinar um peg-out, os dispositivos verificam independentemente que 4.000 blocos da Rootstock se passaram, representando cerca de 36 horas de prova de trabalho acumulada.
As chaves privadas permanecem dentro dos dispositivos, de acordo com Lerner, e os funcionários não podem instruir o hardware a ignorar o período exigido. A Rootstock combina as regras do HSM com merge-mining, por meio do qual mineradores de Bitcoin contribuem com prova de trabalho para a sidechain.
“Mesmo uma maioria conivente de pegnatories não pode roubar os fundos, porque as chaves privadas nunca saem dos PowHSMs, e os HSMs verificam independentemente que 4.000 blocos da Rootstock se passaram antes de assinarem”, disse Lerner.
O modelo da Rootstock pressupõe que a maioria da taxa de hash do Bitcoin participando por meio de merge-mining e os funcionários da federação não trabalharão juntos para paralisar a rede. Lerner disse que funcionários comprometidos poderiam interromper as operações de peg, criando um problema de vivacidade, mas as regras do HSM os impediriam de forçar uma retirada antecipada não autorizada.
Quando ferramentas de monitoramento identificam atividade suspeita, os funcionários podem desligar seus HSMs para que a peg-out pendente não receba nenhuma assinatura. Lerner descreveu a pausa como uma forma de proteger o BTC subjacente enquanto os operadores examinam o problema e decidem como proceder.
“Uma maioria conivente pode, na pior das hipóteses, paralisar o peg, mas não pode forçar uma retirada não autorizada”, disse ele.
Controles de revogação distribuídos podem limitar poderes de congelamento
Interromper uma retirada pendente introduz outro risco porque o mesmo poder poderia ser usado para atrasar usuários legítimos. Lerner disse que nenhuma empresa, operador ou administrador individual deveria controlar o mecanismo de revogação.
Em vez disso, funcionários independentes deveriam compartilhar a autoridade por meio de uma estrutura multipartidária, com regras de hardware limitando o que podem fazer. Sob seu modelo proposto, os funcionários poderiam pausar o processamento, mas não poderiam redirecionar o BTC para outro endereço ou confiscá-lo.
“Para evitar pontos únicos de falha ou censura centralizada, os controles de revogação devem ser distribuídos entre funcionários independentes e multipartidários usando regras impostas por hardware em vez de chaves administrativas centralizadas.”
Tais controles ainda permitiriam que um grupo de funcionários interrompesse retiradas se participantes suficientes agissem em conjunto. A distinção de Lerner baseia-se no escopo dessa autoridade: os operadores poderiam temporariamente retter assinaturas enquanto uma anomalia é revisada, mas não poderiam criar uma transação válida que transfira o colateral para si mesmos.
Atrasos de tempo também precisariam levar em conta o valor e o propósito de cada transação. Uma espera de 36 horas pode ser inadequada para pagamentos rotineiros, enquanto uma ponte que detém grandes quantidades de BTC tem um perfil de risco diferente.
Lerner disse que sistemas de liquidação de alto valor deveriam tratar o tempo como um controle de segurança, semelhante aos mecanismos de atraso usados por cofres bancários físicos. Os períodos de retirada poderiam variar conforme o tamanho da transação ou exigir diferentes limites cumulativos de prova de trabalho de acordo com o colateral em risco.
Um período mais curto poderia se aplicar a transferências menores, enquanto um atraso mais longo poderia dar a sistemas automatizados e respondedores humanos mais tempo para inspecionar uma solicitação excepcionalmente grande. Lerner não prescreveu um único atraso para todas as pontes, mas citou o requisito de 4.000 blocos da Rootstock como um período eficaz para infraestrutura que protege grandes saldos de BTC.
Cofres nativos de Bitcoin poderiam colocar salvaguardas no consenso
A proteção atual da Rootstock depende de seus HSMs e da federação, em vez de regras impostas pela rede Bitcoin. Lerner disse que cofres nativos de Bitcoin e chaves de revogação poderiam mover controles comparáveis para o protocolo base.
Um possível bloco de construção é o BIP-443, uma proposta preliminar para um opcode chamado OP_CHECKCONTRACTVERIFY, ou OP_CCV. A proposta permitiria que uma saída de Bitcoin carregasse dados e restringisse como seus fundos podem se mover por transações futuras.
O BIP-443 descreve o OP_CCV como uma mudança de consenso que requer um soft fork. Seus usos listados incluem saídas de Bitcoin que carregam estado, sidechains e estruturas de retirada em duas etapas que permitem segurança reativa. A proposta permanece em status de rascunho, e seu processo de ativação não foi determinado.
Lerner citou o OP_CCV e o BIP-443 como exemplos de como cofres nativos poderiam dar aos usuários ou partes designadas tempo para cancelar uma retirada após detectar credenciais roubadas, software alterado ou outro evento anormal.
Mover o mecanismo para o consenso do Bitcoin reduziria a dependência de políticas de HSM específicas de pontes, de acordo com Lerner. Mineradores, funcionários ou administradores teriam que seguir as condições de gasto anexadas à saída de Bitcoin em vez de aplicar uma pausa discricionária depois que os fundos já tivessem se movido.
Para grandes retiradas de pontes, Lerner disse que o atraso deveria durar o suficiente para que alertas automatizados e operadores humanos identificassem o problema, interrompessem o processamento e examinassem o software afetado antes que o BTC se torne permanentemente gastável pelo destinatário.
