Google lançará plataforma de custódia cripto institucional em 2027: Como sua tecnologia MPC funciona

Google lançará plataforma de custódia cripto institucional em 2027: Como sua tecnologia MPC funciona

Imagem personalizada
O Google Cloud introduziu o Google Multi-Party Compute (MPC), uma solução especializada de gerenciamento e custódia de chaves para ativos digitais projetada para bancos globais, gestores de ativos e instituições financeiras regulamentadas. Atualmente operando em uma pré-visualização privada por convite exclusivo, o provedor de nuvem visa a disponibilidade geral comercial (GA) no início de 2027. Antes da ampla implantação comercial, o Google validou a arquitetura em ambientes de produção internos que suportam grandes ecossistemas de blockchain, incluindo Ethereum e Solana.
 
Esta iniciativa representa uma expansão significativa na infraestrutura em nuvem institucional Web3. Por vários anos, grandes provedores de nuvem concentraram seus serviços de ativos digitais principalmente em hospedar nodes de chamada de procedimento remoto (RPC), indexar conjuntos de dados de blockchain públicos no BigQuery e explorar redes de liquidação empresarial.
 
Ao introduzir infraestrutura MPC nativa, o Google Cloud está se aprofundando na pilha de segurança da finança digital institucional: a geração distribuída, a verificação de políticas e a assinatura com limiar de chaves criptográficas. À medida que instituições financeiras regulamentadas ampliam sua participação em depósitos tokenizados, produtos negociados à vista (ETPs) e liquidação de ativos do mundo real (RWA), o MPC integrado à nuvem oferece uma base técnica modular ao lado de provedores tradicionais de custódia e cofres de hardware legados.
 

Compromisso de chave e trade-offs de custódia institucional

O crescimento da participação institucional em ativos digitais destacou a importância de sistemas resilientes de gerenciamento de chaves. O rastreamento de segurança da indústria de plataformas como a DeFiLlama mostra consistentemente que credenciais comprometidas e explorações de chaves privadas representam um dos maiores vetores de perda de capital no setor de criptomoedas, responsáveis por bilhões de dólares em perdas acumuladas da indústria ao longo dos recentes ciclos de mercado.
 
Historicamente, o armazenamento institucional de ativos digitais dependeu de dois modelos arquiteturais principais, cada um apresentando trade-offs operacionais distintos para instituições financeiras comerciais.
 

  1. Módulos de Segurança de Hardware Legacy e Riscos de Ponto Único

A gestão de chaves financeiras tradicionais depende fortemente de Módulos de Segurança de Hardware (HSMs) físicos e ambientes de armazenamento a frio isolados. Embora os HSMs isolem chaves criptográficas dentro de hardware resistente a adulterações, configurações padrão de chave única ainda podem introduzir um ponto único de falha estrutural (SPOF).
 
Para autorizar uma transação de blockchain de assinatura única convencional, a chave privada completa deve existir dentro dos limites da memória de um único módulo durante a geração da assinatura. Se um atacante comprometer a camada de gerenciamento do host, explorar uma vulnerabilidade de firmware ou contornar controles de acesso administrativos, os ativos controlados por essa chave única enfrentam exposição imediata.
 

  1. Limitações de Assinatura Múltipla On-Chain

Para evitar dependências de chave única, muitos protocolos Web3 utilizam contratos inteligentes de assinatura múltipla (Multi-Sig) em cadeia, como o Safe. Em uma estrutura padrão M de N Multi-Sig, várias chaves privadas independentes devem enviar aprovações separadas para satisfazer as regras de execução do contrato inteligente.
 
Embora altamente eficaz para tesourarias descentralizadas, o Multi-Sig on-chain apresenta três obstáculos práticos para fluxos de trabalho bancários tradicionais:
 
Incompatibilidade entre blockchains: A lógica Multi-Sig de contrato inteligente não é uniforme em blockchains heterogêneas de Layer-1. Embora amplamente padronizada em redes da Máquina Virtual Ethereum (EVM), implementar governança de contrato inteligente idêntica em blockchains não-EVM (como Bitcoin ou Solana) exige scripts nativos diferentes e pipelines operacionais separados.
 
Custos mais altos de transação na rede: Como múltiplas assinaturas criptográficas ou chamadas de contrato são verificadas diretamente na cadeia, as transações Multi-Sig consomem espaço adicional no bloco e taxas de gás em comparação com transferências padrão de assinatura única.
 
Visibilidade Pública das Regras de Governança: Como as regras de Multi-Sig são executadas por contratos inteligentes públicos, os limiares de quórum, os endereços dos signatários e os padrões de aprovação organizacional de uma instituição são visíveis no livro-razão público.
 
Essas restrições impulsionaram a demanda institucional por criptografia de limiar off-chain que unifica políticas de segurança em múltiplas blockchains.
 

Como funciona o cálculo multipartidário do Google

O Google Cloud Multi-Party Compute aborda riscos de chave única implementando Esquemas de Assinatura de Limiar (TSS) baseados em Computação Multi-Parte (MPC). Sob este modelo criptográfico, uma chave privada completa nunca é montada em qualquer dispositivo único, memória do servidor ou centro de dados em nenhuma etapa da geração, armazenamento ou assinatura de transações.
 

O Protocolo de Assinatura de Limiar DKLs23 Endurecido

De acordo com as especificações técnicas da plataforma, o mecanismo de assinatura ECDSA do Google incorpora uma implementação fortalecida do protocolo DKLs23. Nomeado em homenagem aos criptógrafos Döttling, Komargodski, Lai e Shen, o DKLs23 é um protocolo moderno de assinatura de limiar projetado para calcular assinaturas de curva elíptica com segurança entre partes distribuídas com sobrecarga de comunicação mínima.
 
A implementação do Google se concentra em três prioridades operacionais:
 
  1. Resiliência contra adversários maliciosos: O protocolo é projetado para manter a não-falsificabilidade mesmo se um atacante comprometer um subconjunto dos nós participantes abaixo do limiar de assinatura. Verificações de consistência integradas detectam compartilhamentos criptográficos malformados durante a cerimônia de assinatura e abortam automaticamente a sessão antes que uma assinatura inválida possa ser produzida.
 
  1. Otimização de rodada de baixa latência: Implementações iniciais de MPC frequentemente sofriam com tempos de assinatura lentos devido a múltiplas rodadas de comunicação de ida e volta pela rede. Ao utilizar a estrutura de rodada simplificada do DKLs23, os cálculos criptográficos locais são concluídos em milissegundos, permitindo fluxos de assinatura ponto a ponto abaixo de um segundo após a aprovação das verificações de política institucional.
 
  1. Suporte a múltiplas curvas blockchain: a arquitetura suporta nativamente o Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA) sobre a curva secp256k1 — o padrão para Bitcoin, Ethereum e redes Layer-2 compatíveis com EVM — além de suporte de preparação para o Algoritmo de Assinatura Digital de Curva de Edwards (EdDSA) sobre Ed25519 para cobrir redes de alto desempenho como Solana.
 

Divisão Heterogênea de Chaves: O Modelo de Quórum 2-de-3

Em vez de gerar uma chave privada em um único local e dividi-la posteriormente, a plataforma utiliza a Geração Distribuída de Chaves (DKG), onde nós independentes calculam matematicamente suas respectivas partes da chave sem que qualquer nó veja a chave completa.
 
Para evitar a concentração de risco em um único fornecedor de nuvem, implantações institucionais normalmente utilizam uma estrutura de quórum heterogênea 2-de-3:
 
  • Compartilhar 1 (Ambiente controlado pelo cliente): Hospedado diretamente no centro de dados local da instituição financeira ou em ambiente HSM dedicado.
 
  • Compartilhar 2 (Google Cloud Enclave): Hospedado no ambiente isolado por hardware do Confidential Space do Google Cloud.
 
  • Compartilhar 3 (Recuperação Independente ou Nuvem de Terceiros): Hospedado em um ambiente de nuvem externo (como AWS ou Azure) ou armazenado offline por um fiduciário de recuperação independente.
 
Nesta estrutura de limiar 2 de 3, quaisquer duas partes autorizadas podem colaborar fora da blockchain para produzir uma assinatura criptográfica padrão. Para a blockchain subjacente, a transação resultante parece idêntica a uma transferência normal de chave única.
 
Se um atacante conseguisse invadir um único ambiente, obteria apenas uma parte isolada da chave — que, matematicamente, não revela nada sobre a chave privada completa e não pode autorizar transações por conta própria. Por outro lado, se a estação de trabalho local de uma instituição for comprometida, o atacante ainda assim não consegue mover fundos unilateralmente, a menos que o enclave do Google Cloud verifique independentemente que a transação está em conformidade com as políticas de segurança pré-definidas.
 

Isolamento em Nível de Hardware: Google Cloud Confidential Space (TEE)

Uma preocupação histórica com a gestão de chaves hospedadas na nuvem é a escalada de privilégios no nível do host: se o sistema operacional ou o hipervisor de um servidor na nuvem fosse comprometido, um administrador com privilégios poderia tentar inspecionar o material criptográfico armazenado na memória do sistema (RAM).
 
O Google mitiga esse risco executando seus nós de assinatura MPC dentro do Google Cloud Confidential Space, um Ambiente de Execução Confiável (TEE) suportado por hardware de computação confidencial:
 
Criptografia de Memória de Hardware: o Confidential Space utiliza criptografia de memória ao nível do processador (como AMD SEV-SNP), garantindo que as partes da chave e os cálculos intermediários de assinatura permaneçam criptografados na RAM usando chaves de hardware inacessíveis ao sistema operacional host.
 
Atestação Criptográfica: Antes que uma parte da chave seja acessada ou um ciclo de assinatura comece, a enclave gera um token de atestação baseado em hardware que verifica o hash criptográfico exato da imagem do contêiner e da base de firmware. Se a imagem de software for alterada de qualquer forma, a verificação de atestação falha e o processo de assinatura é bloqueado.
 
Acesso administrativo restrito: o Confidential Space impõe isolamento rigoroso de cargas de trabalho que remove o acesso root padrão ou capacidades de depuração interativa, impedindo até mesmo administradores de infraestrutura em nuvem de visualizar dados dentro de um enclave ativo.
 

Aplicação da Política de Transação e Mecanismos de Atualização da Chave Compartilhada

Proteger as partes da chave contra extração resolve apenas parte do desafio de custódia. Na prática, muitos incidentes de segurança institucional decorrem de credenciais de API comprometidas, ataques de phishing ou aprovações internas não autorizadas que enganam sistemas válidos a assinar transações maliciosas.
 

Motores de Verificação de Política de Pré-Assinatura

Para se proteger contra transferências não autorizadas na camada de aplicação, o Google Cloud incorpora um mecanismo de verificação de política determinística diretamente dentro do enclave Confidential Space. Antes de o nó MPC da Google participar de uma rodada de assinatura de limiar, a carga útil da transação proposta é verificada em relação às regras de governança definidas pela instituição — como endereços de destino autorizados, limites máximos de valor de transação, limites de velocidade, janelas de horário e assinaturas de quórum com múltiplos aprovadores.
 
Se um terminal de ponto comprometido tentar solicitar uma transferência para um endereço não aprovado ou acima dos limites permitidos, o enclave rejeita a solicitação de assinatura antes de qualquer cálculo de compartilhamento criptográfico ocorrer.
 

Compartilhamento Proativo de Segredos (Atualização da Chave Compartilhada)

Para reduzir o risco de um atacante sofisticado comprometer gradualmente múltiplos nodes ao longo de um longo período, a arquitetura suporta Proactive Secret Sharing (PSS), comumente referido como rotação ou atualização de partes da chave.
 
Em uma base programada ou após alterações de pessoal, os nós participantes executam um protocolo de atualização matemática:
 
  • Os nodes calculam colaborativamente um novo conjunto de compartilhamentos criptográficos.
 
  • As chaves anteriores foram permanentemente invalidadas e substituídas.
 
  • A chave pública mestre subjacente e o endereço da carteira na cadeia permanecem completamente inalterados.
 
Isso significa que, mesmo que um atacante tenha conseguido roubar uma única parte da chave em um mês, esse fragmento se torna inútil assim que ocorrer a próxima atualização programada da parte—permitindo que instituições girem regularmente seu material de segurança subjacente sem precisar mover fundos para um novo endereço na blockchain ou pagar taxas de gás on-chain.
 

Agilidade Pós-Quântica e Prontidão Comercial para 2027

À medida que as instituições financeiras avaliam infraestruturas de custódia com horizontes de vários anos, a agilidade criptográfica de longo prazo, incluindo a preparação para computação quântica, tornou-se uma consideração arquitetônica importante. Esquemas padrão de curvas elípticas (secp256k1 e Ed25519) dependem de problemas matemáticos que eventualmente poderão ser vulneráveis a computadores quânticos suficientemente poderosos e tolerantes a falhas.
 
Enquanto a implementação inicial do MPC do Google Cloud se concentra em resolver ameaças operacionais imediatas, como roubo de credenciais, pontos únicos de falha e colusão interna, a plataforma foi projetada com modularidade criptográfica em mente. Ao separar as camadas de orquestração de políticas e API dos primitivos de assinatura subjacentes, a arquitetura é estruturada para acomodar futuras criptografias pós-quânticas (PQC) e padrões de transporte seguros contra quantum, à medida que as redes blockchain e órgãos internacionais de padronização (como o NIST) finalizarem as especificações de assinatura pós-quântica.
 

Conclusão

A implementação da infraestrutura de Computação Multi-Partidária institucional da Google Cloud destaca a contínua maturação da segurança de ativos digitais empresariais. Ao combinar o protocolo de assinatura de limiar DKLs23 com enclaves Confidential Space atestados por hardware e distribuição heterogênea de chaves 2-de-3, a plataforma ajuda instituições financeiras a mitigar vulnerabilidades de chave única sem sacrificar a velocidade de assinatura ou a flexibilidade multi-cadeia. À medida que o serviço avança em direção à disponibilidade comercial em 2027, a MPC integrada à nuvem está preparada para desempenhar um papel crescente na forma como bancos e gestores de ativos garantem ativos tokenizados em escala.
 

Perguntas frequentes

O que é o Google Cloud Multi-Party Compute?

O Google Cloud Multi-Party Compute (MPC) é uma plataforma de infraestrutura de gerenciamento e assinatura de chaves para ativos digitais institucionais, atualmente em pré-visualização privada, antes do lançamento comercial planejado para início de 2027. Ele utiliza criptografia de limiar para dividir o controle da chave privada entre ambientes separados, eliminando pontos únicos de falha durante a assinatura de transações na blockchain.

Por que o Google está direcionando a disponibilidade comercial para 2027?

A execução de uma pré-visualização privada por convite apenas no final de 2026 permite que bancos parceiros e gestores institucionais de ativos realizem auditorias de segurança, integração de políticas e testes de conformidade. O alvo de Disponibilidade Geral no início de 2027 alinha-se à crescente adoção institucional dentro de quadros regulatórios maduros, como o regime MiCA da UE e as normas em evolução do Comitê de Basileia sobre exposições bancárias a ativos criptográficos.

Como o MPC do Google difere do multi-sig em cadeia?

Contratos inteligentes multi-sig on-chain verificam múltiplas assinaturas separadas diretamente em uma blockchain, o que aumenta os custos de gas, expõe publicamente as estruturas de aprovação e exige suporte a contratos inteligentes específicos da cadeia. O MPC do Google realiza a aprovação multi-partes e os cálculos de limiar off-chain usando o protocolo DKLs23 aprimorado, gerando uma única assinatura padrão que funciona em diferentes blockchains com taxas mais baixas e regras de governança privadas.

A tecnologia MPC elimina todos os riscos de custódia de criptomoedas?

Nenhuma arquitetura de segurança pode eliminar todos os riscos. Embora o MPC elimine o ponto único de falha associado ao armazenamento de uma chave privada completa em um único local, as instituições ainda devem se proteger contra phishing, comprometimento de endpoint e governança interna defeituosa. O design do Google ajuda a reduzir esses riscos operacionais combinando compartilhamentos de chave heterogeneamente divididos com enclaves Confidential Space isolados por hardware e verificações de política pré-assinatura.
 
 

Aviso

Essas informações gerais de mercado, possivelmente provenientes de fontes terceirizadas, comerciais ou patrocinadas, são fornecidas apenas para referência e fins educacionais e não constituem aconselhamento financeiro ou de investimento, oferta, solicitação ou garantia. Renunciamos à responsabilidade por sua precisão, completude, confiabilidade e quaisquer perdas decorrentes. Investimentos/operações envolvem riscos; desempenho passado não garante resultados futuros. Os usuários devem pesquisar, julgar com prudência e assumir total responsabilidade. Para mais detalhes, consulte os Termos de Uso e Divulgação de Riscos da KuCoin.

Aviso legal: Esta página foi traduzida usando tecnologia de IA para sua conveniência. Para informações mais precisas, consulte a versão original em inglês.