Cold storage vs multisig vs MPC para RWA tokenizados

O que muda quando o ativo é um RWA tokenizado, e não simples ETH

A questão da custódia parece idêntica à primeira vista: tem uma chave privada, quer mantê-la segura, quer assinar transações. Ativos do mundo real tokenizados (RWA), como o OUSG da ONDO, o BUIDL da BlackRock, ou os produtos de tesouraria denominados em MNT da Mantle, não alteram a criptografia. O que alteram é a carga de trabalho que assenta sobre ela.

Um fundo tokenizado do mercado monetário ou de tesouraria costuma emitir e resgatar segundo um calendário. O OUSG, por exemplo, liquida resgates em T+1. O BUIDL distribui rendimento continuamente e suporta transferências ao nível do token, além de resgate através do emitente. Essa cadência significa que uma equipa de tesouraria não pode ficar uma semana com uma única transação por assinar, como um detentor de BTC de longo prazo pode fazer. A fila de assinatura tem de ser escoada dentro de um dia útil, muitas vezes dentro de uma hora se uma janela de resgate estiver a fechar.

A segunda mudança é a auditabilidade. Com ETH simples, o registo on-chain costuma ser suficiente para uma equipa financeira interna. Com um RWA regulado, o lado off-chain envolve auditores, agentes de transferência e, por vezes, um regulador que exigirá prova de que um resgate foi autorizado por pessoas identificadas ao abrigo de uma política documentada. Esse requisito remodela a custódia, porque "quem assinou" importa tanto como "a assinatura é válida".

A terceira mudança é que a chave operacional raramente é a única chave. A maioria dos produtos RWA separa uma chave de política, uma chave de operações diárias e uma chave guardiã, e cada uma vive sob controlos diferentes. Tratá-las como um único problema de assinatura é onde muitos desenhos de tesouraria correm mal.

A latência operacional face ao compromisso do custo para o atacante

A custódia não é uma única decisão, é um compromisso entre dois números. O primeiro é quanto tempo demora a produzir uma assinatura válida quando a empresa precisa de uma. O segundo é quanto um atacante tem de gastar, ou quantas falhas independentes tem de provocar, antes de conseguir produzir uma assinatura fraudulenta.

O armazenamento a frio, em sentido estrito, eleva muito o custo para o atacante e leva a latência consigo. A chave vive num dispositivo que nunca tocou na internet, idealmente num cofre, e assinar significa recuperá-lo fisicamente. Isso é excelente para uma tesouraria de BTC de longo prazo, e péssimo para um fundo que tem de resgatar ONDO ou BUIDL todos os dias úteis. O custo de ser lento não é abstrato: janelas de resgate falhadas podem desencadear comissões de penalização, colocá-lo na fila para o ciclo seguinte ou, em casos extremos, bloquear a posição até ao próximo corte do emitente.

A multisig altera o compromisso ao distribuir a confiança por signatários e dispositivos. Uma configuração 3-de-5 significa que um atacante precisa de comprometer três signatários independentes, o que é significativamente mais difícil do que comprometer um, enquanto a latência é a velocidade dos seus três signatários mais rápidos. O problema é que "independentes" faz muito trabalho. Se três dos seus signatários forem geridos pela mesma pessoa, no mesmo sistema operativo, com o mesmo esquema de cópia de segurança, a multisig não lhe comprou uma dificuldade equivalente a três atacantes. Comprou-lhe uma.

A MPC, ou seja, esquemas de assinatura por limiar como GG20, GG20+, Lindell17, ou as implementações FROST mais recentes, desloca o cálculo do custo para o atacante para o próprio protocolo. A chave de assinatura nunca existe num único local. Cada participante detém uma parte, e um limiar deles produz conjuntamente uma assinatura sem nunca reconstruir a chave completa. A latência pode ser muito baixa, comparável à de uma carteira quente com um único signatário, e o atacante tem de comprometer um limiar de participantes dentro de uma janela de assinatura estreita.

O que a MPC também faz, e esta é a parte que não recebe atenção suficiente, é reduzir o custo dos erros operacionais. Com multisig, perder um signatário é incómodo, mas recuperável desde que continue acima do limiar. Com MPC, a história de recuperação depende inteiramente de como as partes foram geradas, de quem as detém e de se o custodiante ainda existe. Se apagar um portátil e a parte estava apenas nesse portátil, a política pode simplesmente tornar-se irrecuperável, e o ativo fica efetivamente congelado até que a cerimónia subjacente das partes da chave possa ser repetida com os participantes restantes.

Porque os custodiantes institucionais de RWA usam HSMs, não carteiras de hardware de consumo

Uma carteira de hardware de consumo, seja Ledger, Trezor, GridPlus ou Keystone, é um pequeno dispositivo com elemento seguro que armazena uma seed e assina transações offline. Para uma posição pessoal em BTC ou uma posição de cinco dígitos em ETH, é excelente. Para uma tesouraria que assina operacionalmente resgates numa carteira institucional de RWA, as lacunas começam a acumular-se.

A primeira lacuna é a exportação e clonagem de chaves. As carteiras de hardware são concebidas para que o utilizador, e não o fabricante do dispositivo, controle a seed. Do ponto de vista institucional, isso é uma responsabilidade: um colaborador que sai com a frase-semente e uma cópia de segurança num cofre bancário é um risco de pessoa-chave que não é fácil de remediar. Os custodiantes institucionais querem chaves que possam rodar, colocar em escrow ou destruir de acordo com uma política escrita, e querem que esse processo seja auditável de ponta a ponta.

É para isso que servem os HSMs, módulos de segurança de hardware. Dispositivos como AWS CloudHSM, Thales Luna, Utimaco ou YubiHSM 2 são validados por FIPS, suportam acesso baseado em funções e integram-se com motores de políticas que registam cada tentativa de assinatura, quem a iniciou e ao abrigo de que regra. As chaves nunca saem do dispositivo em texto claro, a rotação de chaves é um fluxo de trabalho documentado e um auditor consegue ver um rasto limpo.

A segunda lacuna está relacionada com o que é assinado. Uma carteira de hardware de consumo mostra-lhe uma transação num ecrã minúsculo e pede-lhe que a aprove. Uma equipa de tesouraria que opera com OUSG ou BUIDL precisa de aplicar a política antes de o signatário sequer ver a transação: limites por ativo, contrapartes em allowlist, limites diários de resgate, controlo duplo em tudo o que ultrapasse um limiar. Essa lógica pertence a um motor de políticas de transação ou a uma camada de conta inteligente como Safe (anteriormente Gnosis Safe) com módulos, não a uma pessoa a olhar para um ecrã de 128x64 píxeis.

A terceira lacuna é o volume operacional. Uma carteira de hardware é feita para uso ocasional, não para as dezenas de aprovações que um fluxo diário de RWA pode produzir quando se incluem varrimentos de rendimento, pagamentos de comissões, atestações de oráculos e lançamentos de reconciliação. A ergonomia falha muito antes da segurança.

Armadilhas de recuperação multisig que parecem aceitáveis até deixarem de o ser

Multisig em ETH é mais frequentemente implementado como uma carteira Safe (anteriormente Gnosis Safe), com signatários mantidos em carteiras de hardware e uma narrativa de recuperação documentada. Em teoria, é robusto. Na prática, há três armadilhas que surgem repetidamente.

A primeira é a homogeneidade dos signatários. Um 5-de-9 parece seguro até perceber que todos os nove signatários usam o mesmo software de carteira, a mesma versão de firmware, o mesmo procedimento de cópia de segurança, e que três deles foram configurados pela mesma pessoa na mesma tarde. A segurança do multisig aumenta com a independência dos signatários. O número 9 é decorativo. O número que importa é a contagem de vetores de compromisso verdadeiramente independentes.

A segunda é a disponibilidade dos signatários. Um multisig só funciona se for possível atingir o limiar. Se os seus signatários forem uma mistura de contratados em três fusos horários, um executivo que viaja e uma carteira que fica num cofre que exige dois dias para aceder, pode descobrir que não consegue assinar um resgate de ONDO sensível ao tempo porque três dos seus cinco signatários mais rápidos estão em aviões. A solução costuma ser uma combinação de signatários frios e mornos, com uma política que diz que os signatários quentes só podem aprovar pequenos montantes. Isso funciona, mas acrescenta outro multisig para gerir, e volta ao problema da recursão.

A terceira é a custódia da chave de recuperação. Cada Safe tem uma narrativa de recuperação, normalmente em função de como os signatários foram gerados. Se a recuperação depender de uma frase-semente escrita em papel num cofre, passa a ter um único pedaço de papel cujo comprometimento dá a um atacante um signatário funcional. Se a recuperação depender de recuperação social através de guardiões, transferiu a confiança para os guardiões, que podem não ser quem pensa que são dentro de cinco anos. Nada disto é impeditivo, mas cada um destes pontos é um lugar onde o 3-de-5 aparentemente arrumado se transforma silenciosamente num 2-de-5 com um signatário numa gaveta.

Risco de desaparecimento de partilhas de chave em MPC, em termos simples

A característica definidora de MPC, o facto de a chave completa nunca existir num único lugar, é também o seu risco definidor. A política de assinatura vive nos participantes, e os participantes podem desaparecer.

O desaparecimento do fornecedor é o risco mais citado. Se fizer custódia com Fireblocks, Anchorage, BitGo, Fordefi ou um fornecedor MPC semelhante, as suas partilhas ficam divididas entre si e eles. Se o fornecedor for adquirido, sair do mercado, sofrer uma interrupção grave ou simplesmente descontinuar o seu nível de serviço, poderá conseguir migrar os seus ativos, mas apenas se as ferramentas de migração estiverem disponíveis e tiver tempo. No pior dos casos, detém uma partilha, o fornecedor detém uma partilha e o limiar deixa de ser alcançável porque o lado do fornecedor está offline ou não está disposto a cooperar.

A perda do dispositivo do participante é o risco seguinte. As partilhas MPC são normalmente mantidas em HSMs, nós de assinatura dedicados ou portáteis reforçados. Cada dispositivo tem a sua própria história de custódia de chaves, incluindo como e onde as partilhas são salvaguardadas. Perder dois desses dispositivos cria um problema de recuperação, não apenas um incómodo. A mitigação é a cópia de segurança das partilhas, mas essa cópia de segurança é ela própria uma decisão de custódia: onde ficam as partilhas de backup, quem as pode desencriptar e como prova a um auditor que nenhuma pessoa isolada consegue reconstituir a chave a partir dos backups?

O risco de protocolo e implementação é o terceiro risco. Os esquemas de assinatura com limiar são criptografia complexa, e as implementações já tiveram erros. A divulgação de 2022 sobre uma vulnerabilidade em certas implementações GG20, as descobertas mais recentes sobre threshold EdDSA e um fluxo constante de problemas em SDKs de carteiras lembram que "a chave nunca existe" é uma afirmação mais forte do que "a chave nunca existe e o código de assinatura não tem erros". Para uma operação de tesouraria de RWA, a decisão certa é exigir auditorias de segurança independentes à stack do fornecedor MPC e manter a opção de migrar para um esquema diferente, mesmo que seja caro.

Uma nuance que vale a pena nomear: a segurança de MPC aplica-se por evento de assinatura. Assim que um limiar de participantes assina, a assinatura é válida para sempre, mesmo que as partilhas dos participantes sejam destruídas mais tarde. Portanto, o risco de desaparecimento diz respeito à capacidade futura de assinar, não a assinaturas passadas. Esse é o enquadramento certo para levar a um conselho: não estamos em risco de uma transação passada ser forjada, estamos em risco de não conseguir operar a posição.

Uma stack de custódia prática para RWA com resgates diários

Dada a carga de trabalho, uma configuração viável para um fundo ou tesouraria de protocolo que detenha RWA tokenizados tende a ser por camadas, não pura.

A camada de base é um custodiante institucional com HSMs validados por FIPS para a reserva de longo prazo. É aqui que fica a maior parte da posição, sob assinatura controlada por políticas com separação de funções. Para uma alocação em OUSG ou BUIDL que não precisa de se mover com frequência, este é o lugar certo, porque o custo de latência de entrar num cofre é pago raramente e o custo para o atacante é muito elevado.

A camada de trabalho é um Safe multisig ou um cluster MPC usado para operações de rotina: pequenos resgates, varrimentos de rendimento, pagamentos de comissões, atestações de oráculos. A escolha entre multisig e MPC aqui depende do volume de assinaturas, da distribuição dos signatários e da tolerância da equipa ao risco operacional. Multisig é mais fácil de auditar e mais fácil de recuperar. MPC é mais rápido e lida melhor com volumes elevados de assinatura. Muitas equipas usam ambos: um Safe para governação e um cluster MPC mais pequeno para execução.

A camada de políticas fica acima de ambas. Um motor de políticas de transação aplica limites por ativo, contratos em allowlist, limites diários e regras de controlo duplo. Os signatários não veem transações em bruto; veem intenções pré-aprovadas, e o motor constrói e submete as transações reais. É aqui que a maior parte do risco operacional é realmente controlada, e é aqui que as carteiras de hardware de consumo ficam aquém para uso institucional, uma vez que não conseguem aplicar essa política antes do signatário.

A camada de reserva fria é um multisig air-gapped para governação e alterações de políticas: alterar signatários, rodar chaves, atualizar o motor de políticas, retirar grandes montantes da camada de trabalho. A latência aqui é aceitável porque estes eventos são raros, e o custo para o atacante é muito elevado porque as chaves vivem num cofre.

O resumo honesto é que "cold storage vs multisig vs MPC" é o enquadramento errado para RWA institucional. O enquadramento certo é que carga de trabalho vai para que camada, e qual é a narrativa de recuperação quando uma partilha, um signatário ou um fornecedor desaparece.

Como acompanhar os desenvolvimentos de custódia de RWA de forma inteligente

A custódia de RWA evolui rapidamente porque os produtos, os custodiantes e os reguladores estão todos a mudar ao mesmo tempo. Acompanhar manualmente os resgates de OUSG, os mecanismos de distribuição de BUIDL, as migrações de fornecedores de MPC e os avisos de firmware de HSM é uma batalha perdida. O Zippfeed destaca manchetes sobre RWA tokenizados com classificação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa concentrar-se nos acontecimentos que realmente afetam o seu desenho de custódia em vez de se afogar em ruído.