O que uma "chave de operador RWA" realmente controla
Num ativo do mundo real tokenizado (RWA), o token on-chain é apenas a superfície. Por baixo está um contrato inteligente atualizável, e por cima estão uma ou mais chaves de assinatura detidas pelo emissor, pelo administrador do fundo ou por um fornecedor de tecnologia especializado. Estas chaves, por vezes chamadas de chave de operador, chave de conformidade ou chave de atualização, são o que torna o token legal, e não apenas técnico.
O que faz, na verdade, essa chave? Na maioria dos contratos de ativos tokenizados modelados segundo as normas ERC-1404 ou ERC-3643, a chave de operador pode adicionar ou remover endereços de uma lista de permissão KYC, congelar saldos de detentores sinalizados, atualizar a própria lógica do contrato, pausar todas as transferências durante um incidente e, em alguns casos, cunhar ou queimar tokens. É muita autoridade assente numa única assinatura criptográfica.
Para uma tesouraria que avalia um fundo tokenizado do mercado monetário, como o BUIDL, um produto tokenizado do Tesouro dos EUA, a chave de operador é o que garante que apenas investidores verificados possam deter o token. A chave é também o que permitiria ao emissor congelar o seu saldo se reguladores aparecessem ou se uma sanção atingisse a sua carteira. É o braço executor da estrutura legal, e é precisamente por isso que comprometê-la é tão perigoso.
Deve pensar na chave de operador como análoga à chave-mestra de um cofre que guarda instrumentos ao portador. Se o instrumento ao portador é o token, a chave-mestra é o que permite a alguém alterar quem tem autorização para entrar. Se a chave-mestra se perder, o atacante não precisa de roubar os instrumentos ao portador; pode simplesmente reescrever a lista de convidados.
Porque é que uma chave de operador comprometida é o pior cenário possível para uma RWA
A maioria dos leitores subestima o quão catastrófico pode ser um comprometimento da chave de operador num sistema de ativos tokenizados. Para perceber porquê, compare-o com os modos de falha que as pessoas já compreendem.
Num protocolo DeFi comum, um comprometimento de chave privada frequentemente permite ao atacante drenar uma pool. A perda é grande, mas está limitada ao valor total bloqueado do protocolo. Numa RWA, a perda é potencialmente ilimitada em duas direções. Primeiro, o atacante pode usar a função de atualização para redefinir o que é o token, o que pode fazer e quem tem autorização para o deter. Segundo, porque as RWAs tipicamente reivindicam uma cobertura 1:1 contra ativos off-chain, uma perda de confiança dos investidores pode desencadear uma corrida aos resgates que o fundo subjacente não consegue honrar atempadamente.
Incidentes históricos tornam isto concreto. O comprometimento da bridge Ronin em 2022 viu um atacante obter cinco das nove chaves de validador numa bridge que protegia ativos de jogos play-to-earn, drenando cerca de 625 milhões de dólares. A bridge Harmony Horizon sofreu um comprometimento semelhante de multisig de dois em cinco mais tarde nesse ano, perdendo cerca de 100 milhões de dólares. No exploit da Wormhole, um atacante utilizou um caminho de assinatura descontinuado para cunhar ativos wrapped sem colateral, extraindo cerca de 320 milhões de dólares. Cada um destes envolveu chaves, e não falhas na lógica pura do token.
O padrão que deve preocupar um alocador de RWA não é o protocolo que perdeu fundos num ataque. É o protocolo que perdeu a chave de atualização sem que ninguém se apercebesse durante horas ou dias. O abuso de chaves de administrador é um dos vetores de ataque mais comuns no espaço cripto em geral, e não há razão para esperar que os contratos de ativos tokenizados sejam imunes. Na verdade, podem ser alvos ainda mais atrativos porque as pretensões legais off-chain frequentemente se traduzem em dólares mais fáceis de branquear através de venues regulados.
Como se desenrolaria um compromisso realista
A maioria dos operadores não guarda uma única chave num único portátil. O design padrão é uma multisig, como uma Safe (antiga Gnosis Safe) 3-de-5 ou 4-de-7, frequentemente com carteiras de hardware, signers distribuídos geograficamente e, por vezes, um módulo de segurança por hardware (HSM) para operações de elevado valor. Ainda assim, compromissos realistas continuam a acontecer. Eis um exemplo prático de como um compromisso pode ocorrer num contexto de ativos tokenizados.
O atacante ganha posição através de uma de várias vias bem conhecidas. Pode fazer phishing a um signer que aprova transações por rotina. Pode comprometer um serviço externo de que os signers dependem, como uma plataforma de custódia, um fornecedor de KYC ou um dashboard jurídico-operacional que, por acaso, detém uma chave de API com privilégios de assinatura. Pode explorar uma vulnerabilidade no próprio software da multisig, como aconteceu nos incidentes da Wintermute e da Parity. Ou pode enganar a equipa do operador através de engenharia social durante um momento de alta pressão, quando está a ser apressada a implementação de uma correção crítica.
Assim que o atacante controla signers suficientes, submete uma transação que invoca a função de upgrade do contrato. A nova implementação pode ser qualquer coisa, incluindo uma versão que simplesmente permita ao atacante transferir o saldo de qualquer titular para si próprio, ou uma que desative totalmente a verificação da allowlist. Com a allowlist desativada, o atacante pode branquear o token através de qualquer DEX que o liste, porque o código on-chain deixou de impor KYC.
A janela de defesa é o atraso do timelock, caso exista. Um timelock obriga qualquer upgrade proposto a esperar um período fixo, frequentemente entre 24 e 72 horas, antes de poder ser executado. Esse atraso supostamente dá à comunidade tempo para detetar um upgrade malicioso e coordenar uma resposta. Na prática, o timelock só ajuda se o upgrade for observável, se os operadores off-chain puderem ser contactados rapidamente e se existir uma opção credível de fork e redesenho do sistema. Nada disso está garantido para ativos tokenizados, em que a contraparte jurídica é, muitas vezes, uma entidade regulada que não pode participar legalmente num fork no próprio dia.
Mitigações: o que timelocks, multisigs e interruptores de pausa realmente fazem
As mitigações padrão são amplamente discutidas e amplamente mal compreendidas. Cada uma tem trade-offs que só se tornam visíveis quando algo corre mal.
As multisigs aumentam o custo de um compromisso ao exigir que múltiplos signers independentes coludam. Uma multisig 4-de-7 é significativamente mais segura do que uma 2-de-3, mas também significa que um upgrade requer que sete pessoas se coordenem. Num incidente real, esse atraso de coordenação pode ser uma vantagem ou uma desvantagem. É uma vantagem quando impede o atacante. É uma desvantagem quando a equipa legítima precisa de pausar o contrato com urgência e não consegue reunir signers suficientes a tempo.
Os timelocks convertem uma exploração imediata numa exploração atrasada. O atacante tem de transmitir a transação maliciosa e esperar que o atraso decorra, período durante o qual os defensores podem preparar-se. A desvantagem é que o timelock também atrasa upgrades legítimos, o que significa que os operadores são, por vezes, tentados a usar atrasos mais curtos, overrides de administrador ou funções de "emergência" que contornam o timelock. Esses overrides são, eles próprios, uma superfície de ataque e já foram abusados no passado.
As funções de pausa de emergência permitem que uma chave designada congele todas as transferências instantaneamente. Esta é a ferramenta mais útil para travar uma exploração em curso, mas concentra poder exatamente na chave que mais preocupa. Se a chave de pausa for comprometida, o atacante pode pausar o sistema e extorquir o emissor, ou pior, pausá-lo enquanto executa uma via de ataque diferente. A autoridade de pausa também cria risco jurídico: titulares que não consigam movimentar tokens durante uma pausa podem ter fundamento legal de ação contra o emissor.
Signers de hardware e HSMs reduzem a hipótese de uma chave ser extraída de um dispositivo, mas não fazem nada se o utilizador junto ao dispositivo for enganado a assinar a transação errada. Vários incidentes importantes nos últimos anos começaram com um frontend comprometido que mostrava detalhes legítimos da transação enquanto pedia ao utilizador que assinasse uma transação maliciosa. A carteira de hardware não consegue distinguir a diferença.
Monitores independentes e watchtowers são uma camada subestimada. Um serviço de monitorização externo pode observar cada transação de upgrade, alertar partes interessadas off-chain e desencadear respostas coordenadas. Isto está mais próximo de um modelo de "detetar e responder" do que de um modelo de "prevenção", e escala mal para a longa cauda de contratos de ativos tokenizados. Os produtos RWA maiores e mais líquidos, como BUIDL, JAAA (um produto tokenizado de mercado monetário da Janus Henderson) e instrumentos semelhantes, podem suportá-lo; emissões mais pequenas, geralmente, não.
Como as cadeias RWA diferem na governação de chaves
Nem todas as cadeias RWA tratam as chaves do operador da mesma forma. As diferenças são mais importantes do que a maioria dos allocators imagina.
A Canton Network (CC) é construída sobre a Digital Asset Modeling Language (Daml) e foi concebida para fluxos de trabalho institucionais. O seu modelo é fundamentalmente diferente de um ERC-20 público. A maioria dos ativos em Canton é governada através de uma sub-rede preservadora de privacidade, onde os validadores aplicam regras de transferência na camada de consenso e não num único contrato atualizável. O trade-off é que a confiança no operador se transfere para os validadores, e os validadores de Canton são entidades permissionadas, não stakers anónimos. A exposição de um investidor a um compromisso de chave é, portanto, uma função de quantos validadores ele confia, e não de quantos signers detêm uma multisig.
A Provenance Blockchain (HASH) acolhe a família Figure de produtos de empréstimo e titularização. A Provenance usa uma arquitetura ao estilo Cosmos, em que os validadores são permissionados e conhecidos. As chaves de operador que importam são as detidas pela entidade emissora, normalmente a Figure, e por prestadores de serviços independentes, como fornecedores de KYC e agentes de transferência. A Provenance tem historicamente privilegiado controlos de conformidade em detrimento da minimização descentralizada da confiança, o que é apropriado para uma cadeia de titularização regulada, mas deve ser compreendido explicitamente pelos allocators.
Tokens RWA baseados em Ethereum, incluindo produtos como BUIDL e EUTBL (o produto de Treasury de curta duração da Hashnote), correm em Ethereum pública sob contratos atualizáveis. A vantagem é o maior conjunto de validadores em cripto e a liquidez mais profunda para cobertura ou saída. A desvantagem é que todo o modelo de governação está encapsulado num único endereço de contrato, com uma chave de upgrade controlada por uma multisig pequena. Se comprar um destes tokens, está a assumir exposição direta à qualidade da segurança operacional dessa multisig.
Outras cadeias focadas em RWA, como Plume, MANTRA e várias redes Layer-1 e Layer-2 mais recentes, seguiram abordagens variadas, mas geralmente enquadram-se num de dois campos: delegam a governação a uma multisig de fundação ou delegam-na a um conjunto permissionado de validadores. Nenhuma elimina o risco do operador; apenas o desloca.
O que isto significa para tesoureiros e allocators
Se está a alocar para ativos tokenizados, a questão não é se o risco do operador existe. Existe em todas as plataformas de ativos tokenizados que irá encontrar. A questão é se o design torna um compromisso sobrevivível.
Teste sob pressão os seguintes pontos antes de dimensionar uma alocação. Quantos signers estão na multisig de upgrade e qual é o limiar? Onde estão guardadas as chaves e qual é a distribuição geográfica? Existe um timelock nos upgrades e qual é a sua duração? Existe uma chave de pausa independente detida por uma parte diferente? Existe um monitor externo? O projeto já exerceu o caminho de pausa ou upgrade num incidente real e como correu? Existe um plano de resposta a incidentes publicado, incluindo uma opção de fork?
Para emissões mais pequenas, a resposta a várias destas perguntas é, frequentemente, "não pensámos nisso." Isso é um dado, não um impeditivo, mas deve definir o tamanho da sua posição em conformidade. Para emissões maiores, como BUIDL e JAAA, a resposta é, em regra, mais tranquilizadora, mas deve mesmo assim ser verificada diretamente com o emissor e não aceite de forma acrítica a partir de materiais de marketing.
Deve também considerar a camada jurídica. O compromisso on-chain é apenas metade da história. A outra metade é se o emissor off-chain, o administrador do fundo e o custodiante têm obrigações contratuais que sobrevivem a um ataque. Se o contrato inteligente for drenado mas o emissor permanecer solvente e disposto a honrar resgates contra o registo off-chain, os titulares podem ser integralmente ressarcidos. Se o emissor depender do contrato como única fonte de verdade, um compromisso pode traduzir-se numa perda total.
Como monitorizar a governança de chaves RWA de forma inteligente
As falhas na gestão de chaves RWA raramente chegam às manchetes antes de a perda já estar registada. O sinal interessante está nos detalhes operacionais: uma rotação de signatários que acontece silenciosamente, um atraso de timelock que é reduzido, uma função de pausa adicionada a um contrato que antes não a tinha. O Zippfeed apresenta notícias sobre RWA com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa acompanhar as alterações de governança em paralelo com os movimentos do mercado e reagir antes de um risco estrutural se tornar numa perda noticiada.
CoinDesk
Crypto Rank News
CryptoSlate
