Pular para o conteúdo principal

2 postagens marcadas com "Criptografia"

Ver todas os Marcadores

Rede MPC Ika Apoiada pela Sui – Avaliação Técnica e de Investimento Abrangente

· Leitura de 45 minutos

Introdução

A Ika é uma rede de Computação Multi-Partes (MPC) paralela estrategicamente apoiada pela Fundação Sui. Anteriormente conhecida como dWallet Network, a Ika foi projetada para permitir interoperabilidade cross-chain zero-trust em alta velocidade e escala. Permite que smart contracts (especialmente na blockchain Sui) controlem e coordenam ativos noutras blockchains de forma segura, sem as bridges tradicionais. Este relatório fornece uma análise aprofundada da arquitetura técnica e do design criptográfico da Ika da perspetiva de um fundador, bem como uma análise de negócios e investimento que abrange a equipa, financiamento, tokenomics, adoção e concorrência. Uma tabela de comparação resumida da Ika com outras redes baseadas em MPC (Lit Protocol, Threshold Network e Zama) também está incluída para contextualização.

Rede Ika

Arquitetura Técnica e Funcionalidades (Perspetiva do Fundador)

Arquitetura e Primitivas Criptográficas

A inovação central da Ika é um novo esquema criptográfico “2PC-MPC” – uma computação de duas partes dentro de uma estrutura de computação multi-partes. Em termos simples, o processo de assinatura envolve sempre duas partes: (1) o utilizador e (2) a rede Ika. O utilizador retém uma parte da chave privada, e a rede – composta por muitos nós independentes – detém a outra parte. Uma assinatura só pode ser produzida com a participação de ambos, garantindo que a rede por si só nunca pode forjar uma assinatura sem o utilizador. O lado da rede não é uma única entidade, mas um MPC distribuído entre N validadores que atuam coletivamente como a segunda parte. Um limiar de pelo menos dois terços desses nós deve concordar (semelhante ao consenso de Tolerância a Falhas Bizantinas) para gerar a parte da assinatura da rede. Esta estrutura de MPC aninhado (utilizador + rede) torna a Ika não-colusiva: mesmo que todos os nós da Ika conspirem, eles não podem roubar os ativos do utilizador porque a participação do utilizador (a sua parte da chave) é sempre criptograficamente necessária. Por outras palavras, a Ika permite segurança “zero-trust”, defendendo os princípios de descentralização e propriedade do utilizador da Web3 – nenhuma entidade única ou pequeno grupo pode comprometer unilateralmente os ativos.

Figura: Esquema da arquitetura 2PC-MPC da Ika – o utilizador atua como uma parte (detendo uma parte da chave privada) e a rede Ika de N validadores forma a outra parte através de um protocolo de limiar MPC (t-de-N). Isto garante que tanto o utilizador como uma supermaioria de nós descentralizados devem cooperar para produzir uma assinatura válida.

Tecnicamente, a Ika é implementada como uma rede blockchain autónoma, um fork do código-fonte da Sui. Executa a sua própria instância do motor de consenso de alto desempenho da Sui (Mysticeti, um protocolo BFT baseado em DAG) para coordenar os nós MPC. Notavelmente, a versão da Sui da Ika tem os smart contracts desativados (a chain da Ika existe apenas para executar o protocolo MPC) e inclui módulos personalizados para o algoritmo de assinatura 2PC-MPC. O Mysticeti fornece um canal de broadcast fiável entre os nós, substituindo a complexa malha de mensagens peer-to-peer que os protocolos MPC tradicionais usam. Ao alavancar um consenso baseado em DAG para comunicação, a Ika evita a sobrecarga de comunicação exponencial dos esquemas de assinatura de limiar anteriores, que exigiam que cada uma das n partes enviasse mensagens a todas as outras. Em vez disso, os nós da Ika transmitem mensagens através do consenso, alcançando uma complexidade de comunicação linear O(n), e usando técnicas de batching e agregação para manter os custos por nó quase constantes, mesmo quando N cresce muito. Isto representa um avanço significativo na criptografia de limiar: a equipa da Ika substituiu a comunicação ponto-a-ponto “unicast” por broadcast e agregação eficientes, permitindo que o protocolo suporte centenas ou milhares de participantes sem abrandar.

Integrações de conhecimento zero: Atualmente, a segurança da Ika é alcançada através de criptografia de limiar e consenso BFT, em vez de provas de conhecimento zero explícitas. O sistema não depende de zk-SNARKs ou zk-STARKs no seu processo de assinatura principal. No entanto, a Ika usa provas de estado on-chain (provas de light client) para verificar eventos de outras chains, o que é uma forma de verificação criptográfica (por exemplo, verificar provas de Merkle de cabeçalhos de bloco ou estado). O design deixa espaço para integrar técnicas de conhecimento zero no futuro – por exemplo, para validar o estado ou condições cross-chain sem revelar dados sensíveis – mas, a partir de 2025, nenhum módulo zk-SNARK específico faz parte da arquitetura publicada da Ika. A ênfase está, em vez disso, no princípio “zero-trust” (significando sem pressupostos de confiança) através do esquema 2PC-MPC, em vez de sistemas de prova de conhecimento zero.

Desempenho e Escalabilidade

Um objetivo principal da Ika é superar os estrangulamentos de desempenho das redes MPC anteriores. Os protocolos de assinatura de limiar legados (como o 2PC ECDSA de Lindell ou o GG20) tinham dificuldade em suportar mais do que um punhado de participantes, muitas vezes demorando muitos segundos ou minutos para produzir uma única assinatura. Em contraste, o protocolo otimizado da Ika alcança latência abaixo de um segundo para assinatura e pode lidar com um throughput muito alto de pedidos de assinatura em paralelo. As alegações de benchmark indicam que a Ika pode escalar para cerca de 10.000 assinaturas por segundo, mantendo a segurança num grande cluster de nós. Isto é possível graças à comunicação linear mencionada e ao uso intensivo de batching: muitas assinaturas podem ser geradas simultaneamente pela rede numa única ronda do protocolo, amortizando drasticamente os custos. Segundo a equipa, a Ika pode ser “10.000× mais rápida” do que as redes MPC existentes sob carga. Em termos práticos, isto significa que transações de alta frequência em tempo real (como trading ou operações DeFi cross-chain) podem ser suportadas sem os atrasos habituais da assinatura de limiar. A latência está na ordem da finalidade abaixo de um segundo, o que significa que uma assinatura (e a operação cross-chain correspondente) pode ser concluída quase instantaneamente após o pedido de um utilizador.

Igualmente importante, a Ika faz isto enquanto aumenta o número de signatários para melhorar a descentralização. As configurações MPC tradicionais usavam frequentemente um comité fixo de talvez 10–20 nós para evitar o colapso do desempenho. A arquitetura da Ika pode expandir-se para centenas ou mesmo milhares de validadores a participar no processo de assinatura sem abrandamento significativo. Esta descentralização massiva melhora a segurança (mais difícil para um atacante corromper uma maioria) e a robustez da rede. O consenso subjacente é tolerante a falhas bizantinas, pelo que a rede pode tolerar até um terço dos nós comprometidos ou offline e ainda funcionar corretamente. Em qualquer operação de assinatura, apenas um limiar t-de-N de nós (por exemplo, 67% de N) precisa de participar ativamente; por design, se demasiados nós estiverem em baixo, a assinatura pode ser atrasada, mas o sistema é projetado para lidar com cenários de falha típicos de forma graciosa (semelhante às propriedades de liveness e safety do consenso de uma blockchain). Em resumo, a Ika alcança tanto alto throughput como um elevado número de validadores, uma combinação que a distingue das soluções MPC anteriores que tinham de trocar descentralização por velocidade.

Ferramentas de Desenvolvimento e Integração

A rede Ika foi construída para ser amigável para programadores, especialmente para aqueles que já constroem na Sui. Os programadores não escrevem smart contracts na Ika em si (uma vez que a chain da Ika não executa contratos definidos pelo utilizador), mas interagem com a Ika a partir de outras chains. Por exemplo, um contrato Move na Sui pode invocar a funcionalidade da Ika para assinar transações em chains externas. Para facilitar isto, a Ika fornece ferramentas robustas e SDKs:

  • SDK TypeScript: A Ika oferece um SDK TypeScript (biblioteca Node.js) que espelha o estilo do SDK da Sui. Este SDK permite que os construtores criem e giram dWallets (carteiras descentralizadas) e emitam pedidos de assinatura para a Ika a partir das suas aplicações. Usando o SDK TS, os programadores podem gerar pares de chaves, registar partes de utilizador e chamar o RPC da Ika para coordenar assinaturas de limiar – tudo com padrões familiares da API da Sui. O SDK abstrai a complexidade do protocolo MPC, tornando-o tão simples como chamar uma função para solicitar (por exemplo) uma assinatura de transação Bitcoin, dado o contexto apropriado e a aprovação do utilizador.

  • CLI e Rede Local: Para uma interação mais direta, está disponível uma interface de linha de comandos (CLI) chamada dWallet CLI. Os programadores podem executar um nó Ika local ou mesmo uma rede de teste local fazendo um fork do repositório de código aberto. Isto é valioso para testes e integração num ambiente de desenvolvimento. A documentação orienta na configuração de uma devnet local, obtenção de tokens de testnet (DWLT – o token da testnet) e criação de um primeiro endereço dWallet.

  • Documentação e Exemplos: A documentação da Ika inclui tutoriais passo a passo para cenários comuns, como “A Sua Primeira dWallet”. Estes mostram como estabelecer uma dWallet que corresponde a um endereço noutra chain (por exemplo, um endereço Bitcoin controlado pelas chaves da Ika), como encriptar a parte da chave do utilizador para segurança e como iniciar transações cross-chain. O código de exemplo abrange casos de uso como transferir BTC através de uma chamada de smart contract na Sui, ou agendar transações futuras (uma funcionalidade que a Ika suporta, onde uma transação pode ser pré-assinada sob certas condições).

  • Integração com a Sui (Light Clients): De raiz, a Ika está firmemente integrada com a blockchain Sui. A rede Ika executa um light client da Sui internamente para ler dados on-chain da Sui de forma trustless. Isto significa que um smart contract na Sui pode emitir um evento ou chamada que a Ika reconhecerá (através de uma prova de estado) como um gatilho para realizar uma ação. Por exemplo, um contrato na Sui pode instruir a Ika: “quando o evento X ocorrer, assine e transmita uma transação na Ethereum”. Os nós da Ika verificarão o evento da Sui usando a prova do light client e, em seguida, produzirão coletivamente a assinatura para a transação Ethereum. A carga assinada pode então ser entregue à chain de destino (possivelmente por um relayer off-chain ou pelo utilizador) para executar a ação desejada. Atualmente, a Sui é a primeira chain controladora totalmente suportada (dadas as origens da Ika na Sui), mas a arquitetura é multi-chain por design. O suporte para provas de estado e integrações de outras chains está no roadmap – por exemplo, a equipa mencionou estender a Ika para trabalhar com rollups no ecossistema Polygon Avail (fornecendo capacidades de dWallet em rollups com a Avail como camada de dados) e outras Layer-1s no futuro.

  • Algoritmos Criptográficos Suportados: A rede da Ika pode gerar chaves/assinaturas para praticamente qualquer esquema de assinatura de blockchain. Inicialmente, suporta ECDSA (o algoritmo de curva elíptica usado pelo Bitcoin, contas ECDSA da Ethereum, BNB Chain, etc.). A curto prazo, está planeado suportar EdDSA (Ed25519, usado por chains como Solana e algumas chains Cosmos) e assinaturas Schnorr (por exemplo, as chaves Schnorr do Taproot do Bitcoin). Este amplo suporte significa que uma dWallet da Ika pode ter um endereço no Bitcoin, um endereço na Ethereum, na Solana, e assim por diante – todos controlados pela mesma chave distribuída subjacente. Os programadores na Sui ou noutras plataformas podem, assim, integrar qualquer uma destas chains nas suas dApps através de uma estrutura unificada (Ika), em vez de lidar com bridges ou custodiantes específicos de cada chain.

Em resumo, a Ika oferece uma experiência de programador semelhante à interação com um nó de blockchain ou carteira, abstraindo a criptografia pesada. Seja através do SDK TypeScript ou diretamente através de contratos Move e light clients, esforça-se por tornar a lógica cross-chain “plug-and-play” para os construtores.

Segurança, Descentralização e Tolerância a Falhas

A segurança é primordial no design da Ika. O modelo zero-trust significa que nenhum utilizador tem de confiar na rede Ika com o controlo unilateral de ativos em nenhum momento. Se um utilizador criar uma dWallet (digamos, um endereço BTC gerido pela Ika), a chave privada desse endereço nunca é detida por uma única parte – nem mesmo pelo utilizador sozinho. Em vez disso, o utilizador detém uma parte secreta e a rede detém coletivamente a outra parte. Ambas são necessárias para assinar qualquer transação. Assim, mesmo que o pior cenário ocorresse (por exemplo, muitos nós da Ika fossem comprometidos por um atacante), eles ainda não poderiam mover fundos sem a parte da chave secreta do utilizador. Esta propriedade aborda um grande risco nas bridges convencionais, onde um quórum de validadores poderia conspirar para roubar ativos bloqueados. A Ika elimina esse risco ao mudar fundamentalmente a estrutura de acesso (o limiar é definido de tal forma que a rede sozinha nunca é suficiente – o limiar efetivamente inclui o utilizador). Na literatura, este é um novo paradigma: uma rede MPC não-colusiva onde o proprietário do ativo permanece parte do quórum de assinatura por design.

Do lado da rede, a Ika usa um modelo de Proof-of-Stake delegado (herdado do design da Sui) para selecionar e incentivar validadores. Os detentores de tokens IKA podem delegar stake a nós validadores; os principais validadores (ponderados pelo stake) tornam-se as autoridades para uma época, e são tolerantes a falhas bizantinas (2/3 honestos) em cada época. Isto significa que o sistema assume que <33% do stake é malicioso para manter a segurança. Se um validador se comportar mal (por exemplo, tentar produzir uma parte de assinatura incorreta ou censurar transações), o consenso e o protocolo MPC irão detetá-lo – partes de assinatura incorretas podem ser identificadas (não se combinarão para uma assinatura válida), e um nó malicioso pode ser registado e potencialmente sofrer slashing ou ser removido em épocas futuras. Entretanto, a liveness é mantida enquanto nós suficientes (>67%) participarem; o consenso pode continuar a finalizar operações mesmo que muitos nós falhem ou fiquem offline inesperadamente. Esta tolerância a falhas garante que o serviço é robusto – não existe um ponto único de falha, uma vez que centenas de operadores independentes em diferentes jurisdições estão a participar. A descentralização é ainda reforçada pelo grande número de participantes: a Ika não se limita a um pequeno comité fixo, pelo que pode integrar mais validadores para aumentar a segurança sem sacrificar muito desempenho. De facto, o protocolo da Ika foi explicitamente projetado para “transcender o limite de nós das redes MPC” e permitir uma descentralização massiva.

Finalmente, a equipa da Ika submeteu a sua criptografia a uma revisão externa. Publicaram um whitepaper abrangente em 2024 detalhando o protocolo 2PC-MPC, e já passaram por pelo menos uma auditoria de segurança de terceiros. Por exemplo, em junho de 2024, uma auditoria da Symbolic Software examinou a implementação em Rust do protocolo 2PC-MPC da Ika e bibliotecas de criptografia relacionadas. A auditoria teria focado em validar a correção dos protocolos criptográficos (garantindo que não há falhas no esquema ECDSA de limiar, geração de chaves ou agregação de partes) e em verificar potenciais vulnerabilidades. O código-fonte é aberto (no GitHub da dWallet Labs), permitindo que a comunidade inspecione e contribua para a sua segurança. Na fase de testnet alfa, a equipa também alertou que o software ainda era experimental e não estava auditado para produção, mas auditorias contínuas e melhorias de segurança eram uma prioridade máxima antes do lançamento da mainnet. Em resumo, o modelo de segurança da Ika é uma combinação de garantias criptográficas comprováveis (de esquemas de limiar) e descentralização de nível de blockchain (do consenso PoS e do grande conjunto de validadores), revisto por especialistas, para fornecer fortes garantias contra atacantes externos e conluio interno.

Compatibilidade e Interoperabilidade do Ecossistema

A Ika foi construída propositadamente para ser uma camada de interoperabilidade, inicialmente para a Sui, mas extensível a muitos ecossistemas. No primeiro dia, a sua integração mais próxima é com a blockchain Sui: atua efetivamente como um módulo adicional para a Sui, capacitando as dApps da Sui com capacidades multi-chain. Este alinhamento apertado é por design – os contratos Move da Sui e o modelo centrado em objetos tornam-na um bom “controlador” para as dWallets da Ika. Por exemplo, uma aplicação DeFi na Sui pode usar a Ika para obter liquidez da Ethereum ou Bitcoin em tempo real, tornando a Sui um hub para liquidez multi-chain. O apoio da Fundação Sui à Ika indica uma estratégia para posicionar a Sui como “a chain base para todas as chains”, alavancando a Ika para se conectar a ativos externos. Na prática, quando a mainnet da Ika estiver ativa, um construtor na Sui poderá criar um contrato Move que, digamos, aceita depósitos de BTC: nos bastidores, esse contrato criaria uma dWallet Bitcoin (um endereço) através da Ika e emitiria instruções para mover BTC quando necessário. O utilizador final experiencia isto como se o Bitcoin fosse apenas mais um ativo gerido dentro da app da Sui, embora o BTC permaneça nativo no Bitcoin até que uma transação assinada por limiar o mova.

Além da Sui, a arquitetura da Ika suporta outras blockchains Layer-1, Layer-2s e até sistemas off-chain. A rede pode hospedar múltiplos light clients simultaneamente, pelo que pode validar o estado da Ethereum, Solana, Avalanche ou outras – permitindo que os smart contracts nessas chains (ou os seus utilizadores) também aproveitem a rede MPC da Ika. Embora tais capacidades possam ser lançadas gradualmente, o objetivo do design é ser agnóstico em relação à chain. Entretanto, mesmo sem uma integração on-chain profunda, a Ika pode ser usada de uma forma mais manual: por exemplo, uma aplicação na Ethereum poderia chamar uma API da Ika (através de um Oráculo ou serviço off-chain) para solicitar uma assinatura para uma transação Ethereum ou uma mensagem. Como a Ika suporta ECDSA, poderia até ser usada para gerir a chave de uma conta Ethereum de forma descentralizada, de forma semelhante a como funcionam os PKPs do Lit Protocol (discutimos o Lit mais tarde). A Ika também demonstrou casos de uso como controlar Bitcoin em rollups – um exemplo é a integração com a framework Polygon Avail para permitir que os utilizadores de rollups giram BTC sem confiar num custodiante centralizado. Isto sugere que a Ika pode colaborar com vários ecossistemas (Polygon/Avail, rollups Celestia, etc.) como um fornecedor de infraestrutura de chaves descentralizada.

Em resumo, do ponto de vista técnico, a Ika é compatível com qualquer sistema que dependa de assinaturas digitais – o que é essencialmente todas as blockchains. A sua implementação inicial na Sui é apenas o começo; a visão a longo prazo é uma camada MPC universal à qual qualquer chain ou dApp pode ligar-se para operações cross-chain seguras. Ao suportar padrões criptográficos comuns (ECDSA, Ed25519, Schnorr) e fornecer as verificações de light client necessárias, a Ika poderia tornar-se uma espécie de rede “MPC-as-a-service” para toda a Web3, ligando ativos e ações de uma forma com confiança minimizada.

Perspetiva de Negócios e Investimento

Equipa Fundadora e Histórico

A Ika foi fundada por uma equipa de especialistas experientes em criptografia e blockchain, principalmente baseados em Israel. O criador e CEO do projeto é Omer Sadika, um empreendedor com um forte historial no espaço de segurança cripto. Omer co-fundou anteriormente a Odsy Network, outro projeto centrado em infraestrutura de carteiras descentralizadas, e é o Fundador/CEO da dWallet Labs, a empresa por trás da Ika. O seu percurso inclui formação na Y Combinator (aluno da YC) e um foco em cibersegurança e sistemas distribuídos. A experiência de Omer com a Odsy e a dWallet Labs informou diretamente a visão da Ika – em essência, a Ika pode ser vista como uma evolução do conceito de “carteira descentralizada dinâmica” em que a Odsy trabalhou, agora implementado como uma rede MPC na Sui.

O CTO e co-fundador da Ika é Yehonatan Cohen Scaly, um especialista em criptografia que co-escreveu o protocolo 2PC-MPC. Yehonatan lidera a I&D dos algoritmos criptográficos inovadores da Ika e já tinha trabalhado em cibersegurança (possivelmente com investigação académica em criptografia). Ele foi citado a discutir as limitações dos esquemas de limiar existentes e como a abordagem da Ika as supera, refletindo uma profunda especialização em MPC e protocolos criptográficos distribuídos. Outro co-fundador é David Lachmish, que supervisiona o desenvolvimento de produtos. O papel de David é traduzir a tecnologia central em produtos amigáveis para programadores e casos de uso do mundo real. O trio de Omer, Yehonatan e David – juntamente com outros investigadores como o Dr. Dolev Mutzari (VP de Investigação na dWallet Labs) – ancora a liderança da Ika. Coletivamente, as credenciais da equipa incluem startups anteriores, contribuições de investigação académica e experiência na interseção de cripto, segurança e blockchain. Esta profundidade é a razão pela qual a Ika é descrita como sendo criada por “alguns dos maiores especialistas em criptografia do mundo”.

Além dos fundadores, a equipa mais ampla e os conselheiros da Ika provavelmente incluem indivíduos com fortes antecedentes em criptografia. Por exemplo, Dolev Mutzari (mencionado acima) é co-autor do artigo técnico e fundamental no design do protocolo. A presença de tal talento dá aos investidores confiança de que a tecnologia complexa da Ika está em mãos capazes. Além disso, ter um fundador (Omer) que já angariou fundos com sucesso e construiu uma comunidade em torno dos conceitos Odsy/dWallet significa que a Ika beneficia das lições aprendidas em iterações anteriores da ideia. A base da equipa em Israel – um país conhecido pelo seu setor de criptografia e cibersegurança – também os situa num rico viveiro de talentos para contratar programadores e investigadores.

Rondas de Financiamento e Principais Apoiantes

A Ika (e a sua empresa-mãe, dWallet Labs) atraiu um financiamento de risco significativo e investimento estratégico desde a sua criação. Até à data, angariou mais de **21milho~esemvaˊriasrondas.Arondaseedinicialdoprojetoemagostode2022foide21 milhões** em várias rondas. A **ronda seed inicial do projeto em agosto de 2022** foi de 5M, o que foi notável dadas as condições de mercado em baixa na altura. Essa ronda seed incluiu uma vasta gama de investidores e anjos de cripto bem conhecidos. Participantes notáveis incluíram Node Capital (líder), Lemniscap, Collider Ventures, Dispersion Capital, Lightshift Capital, Tykhe Block Ventures, Liquid2 Ventures, Zero Knowledge Ventures, e outros. Investidores individuais proeminentes também se juntaram, como Naval Ravikant (co-fundador da AngelList e proeminente investidor em tecnologia), Marc Bhargava (co-fundador da Tagomi), Rene Reinsberg (co-fundador da Celo), e várias outras figuras da indústria. Tal lista de apoiantes sublinhou uma forte confiança na abordagem da Ika à custódia descentralizada, mesmo na fase de ideia.

Em maio de 2023, a Ika angariou um adicional de ~7.5MnoquepareceserumaSeˊrieAourondaestrateˊgica,alegadamentecomumaavaliac\ca~oemtornode7.5M no que parece ser uma **Série A ou ronda estratégica**, alegadamente com uma avaliação em torno de 250M. Esta ronda foi liderada pela Blockchange Ventures e Node Capital (novamente), com a participação da Insignius Capital, Rubik Ventures, e outros. Nesta altura, a tese das redes MPC escaláveis tinha ganho tração, e o progresso da Ika provavelmente atraiu estes investidores a apostar mais forte. A avaliação de $250M para uma rede em fase relativamente inicial refletia a expectativa do mercado de que a Ika poderia tornar-se uma infraestrutura fundamental na web3 (ao nível das blockchains L1 ou dos principais protocolos DeFi em termos de valor).

O investimento de maior destaque veio em abril de 2025, quando a Fundação Sui anunciou um investimento estratégico na Ika. Esta parceria com o fundo do ecossistema da Sui elevou o financiamento total da Ika para mais de 21MecimentouumalinhamentoproˊximocomablockchainSui.EmboraomontanteexatoqueaFundac\ca~oSuiinvestiuna~otenhasidodivulgadopublicamente,eˊclaroqueestefoiumendossosignificativoprovavelmentenaordemdevaˊriosmilho~esdeUSD.OapoiodaFundac\ca~oSuina~oeˊapenasfinanceiro;tambeˊmsignificaqueaIkaobteˊmumforteapoiodegotomarketdentrodoecossistemaSui(divulgac\ca~oaprogramadores,suportedeintegrac\ca~o,marketing,etc.).Deacordocomoscomunicadosdeimprensa,AIkaanunciouuminvestimentoestrateˊgicodaFundac\ca~oSui,elevandooseufinanciamentototalparamaisde21M e cimentou um alinhamento próximo com a blockchain Sui. Embora o montante exato que a Fundação Sui investiu não tenha sido divulgado publicamente, é claro que este foi um endosso significativo – provavelmente na ordem de vários milhões de USD. O apoio da Fundação Sui não é apenas financeiro; também significa que a Ika obtém um forte apoio de go-to-market dentro do ecossistema Sui (divulgação a programadores, suporte de integração, marketing, etc.). De acordo com os comunicados de imprensa, **“A Ika… anunciou um investimento estratégico da Fundação Sui, elevando o seu financiamento total para mais de 21 milhões.”** Esta ronda estratégica, em vez de uma ronda de capital de risco tradicional, destaca que a Sui vê a Ika como uma infraestrutura crítica para o futuro da sua blockchain (semelhante a como a Fundação Ethereum poderia apoiar diretamente um projeto de Layer-2 ou de interoperabilidade que beneficia a Ethereum).

Além da Sui, outros apoiantes dignos de nota são a Node Capital (um fundo de cripto sediado na China conhecido por investimentos iniciais em infraestrutura), a Lemniscap (uma VC de cripto focada em inovação de protocolos em fase inicial), e a Collider Ventures (VC sediada em Israel, provavelmente fornecendo apoio local). A Blockchange Ventures a liderar a ronda de 2023 é notável; a Blockchange é uma VC que apoiou várias apostas em infraestrutura de cripto e a sua liderança sugere que viram a tecnologia da Ika como potencialmente definidora de categoria. Adicionalmente, o Digital Currency Group (DCG) e a Node Capital lideraram uma angariação de fundos de $5M para a dWallet Labs antes do rebranding da Ika (de acordo com uma publicação no LinkedIn de Omer) – o envolvimento do DCG (através de uma ronda anterior para a empresa) indica ainda mais apoio nos bastidores.

Em resumo, o percurso de financiamento da Ika mostra uma mistura de VCs tradicionais e parceiros estratégicos. O envolvimento da Fundação Sui destaca-se particularmente, pois não só fornece capital, mas também um ecossistema integrado para implementar a tecnologia da Ika. Os investidores estão essencialmente a apostar que a Ika se tornará a solução de referência para gestão de chaves descentralizada e bridging em muitas redes, e avaliaram o projeto em conformidade.

Tokenomics e Modelo Económico

A Ika terá um token de utilidade nativo chamado $IKA, que é central para a economia e modelo de segurança da rede. De forma única, o token IKA está a ser lançado na blockchain Sui (como um ativo nativo SUI), embora a própria rede Ika seja uma chain separada. Isto significa que o IKA existirá como uma moeda que pode ser detida e transferida na Sui como qualquer outro ativo Sui, e será usado de forma dupla: dentro da rede Ika para staking e taxas, e na Sui para governação ou acesso em dApps. A tokenomics pode ser delineada da seguinte forma:

  • Taxas de Gas: Assim como o ETH é o gas na Ethereum ou o SUI é o gas na Sui, o IKA serve como o gas/pagamento para operações MPC na rede Ika. Quando um utilizador ou uma dApp solicita uma assinatura ou operação de dWallet, uma taxa em IKA é paga à rede. Estas taxas compensam os validadores pelo trabalho de computação e comunicação de executar o protocolo de assinatura de limiar. O whitepaper faz uma analogia do papel do IKA com o gas da Sui, confirmando que todas as transações cross-chain facilitadas pela Ika incorrerão numa pequena taxa de IKA. A tabela de taxas é provavelmente proporcional à complexidade da operação (por exemplo, uma única assinatura pode custar uma taxa base, enquanto fluxos de trabalho mais complexos de múltiplos passos podem custar mais).

  • Staking e Segurança: O IKA é também um token de staking. Os nós validadores na rede Ika devem ter um stake de IKA delegado para participar no consenso e na assinatura. O consenso segue um modelo de proof-of-stake delegado semelhante ao da Sui: os detentores de tokens delegam IKA aos validadores, e o peso de cada validador no consenso (e, portanto, nos processos de assinatura de limiar) é determinado pelo stake. Em cada época, os validadores são escolhidos e o seu poder de voto é uma função do stake, com o conjunto geral a ser tolerante a falhas bizantinas (o que significa que se um conjunto de validadores tiver um stake total de X,ateˊ X, até ~X/3 de stake poderia ser malicioso sem quebrar as garantias da rede). Os stakers (delegadores) são incentivados por recompensas de staking: o modelo da Ika provavelmente inclui a distribuição das taxas recolhidas (e possivelmente recompensas inflacionárias) aos validadores e seus delegadores no final das épocas. De facto, a documentação nota que todas as taxas de transação recolhidas são distribuídas às autoridades, que podem partilhar uma porção com os seus delegadores como recompensas. Isto espelha o modelo da Sui de recompensar os fornecedores de serviços pelo throughput.

  • Fornecimento e Distribuição: A partir de agora (Q2 2025), os detalhes sobre o fornecimento total, distribuição inicial e inflação do IKA não são totalmente públicos. No entanto, dadas as rondas de financiamento, podemos inferir alguma estrutura. Provavelmente, uma porção do IKA é alocada aos investidores iniciais (rondas seed e de séries) e à equipa, com uma grande parte reservada para a comunidade e incentivos futuros. Pode haver uma venda para a comunidade ou airdrop planeado, especialmente porque a Ika realizou uma notável campanha de NFT que angariou 1.4M SUI, como mencionado nas notícias (esta foi uma campanha de arte NFT na Sui que estabeleceu um recorde; é possível que os participantes nessa campanha possam receber recompensas em IKA ou acesso antecipado). A campanha de NFT sugere uma estratégia para envolver a comunidade e iniciar a distribuição de tokens aos utilizadores, não apenas a VCs.

  • Calendário de Lançamento do Token: O anúncio da Fundação Sui em outubro de 2024 indicava que “O token IKA será lançado nativamente na Sui, desbloqueando novas funcionalidades e utilidade em segurança descentralizada”. A mainnet estava prevista para dezembro de 2024, pelo que presumivelmente o evento de geração de token (TGE) coincidiria ou seguir-se-ia em breve. Se a mainnet foi lançada dentro do prazo, os tokens IKA podem ter começado a ser distribuídos no final de 2024 ou início de 2025. O token começaria então a ser usado para gas na rede Ika e para staking. Antes disso, na testnet, um token temporário (DWLT na testnet) era usado para gas, que não tinha valor real.

  • Casos de Uso e Acumulação de Valor: O valor do IKA como investimento depende do uso da rede Ika. À medida que mais transações cross-chain fluem através da Ika, mais taxas são pagas em IKA, criando procura. Adicionalmente, se muitos quiserem executar validadores ou proteger a rede, devem adquirir e fazer stake de IKA, o que bloqueia o fornecimento (reduzindo a circulação). Assim, o IKA tem uma natureza de utilidade mais governação – utilidade no pagamento de serviços e staking, e provavelmente governação na direção do futuro do protocolo (embora a governação não seja explicitamente mencionada ainda, é comum que tais redes eventualmente descentralizem o controlo através de votação com tokens). Pode-se imaginar os detentores de tokens IKA a votar na adição de suporte para novas chains, ajuste de parâmetros de taxas ou outras atualizações do protocolo no futuro.

No geral, a tokenomics da IKA visa equilibrar a segurança da rede com a usabilidade. Ao lançar na Sui, facilitam a obtenção e uso do IKA pelos utilizadores do ecossistema Sui (não é necessário onboarding numa chain separada para o próprio token), o que pode impulsionar a adoção. Os investidores estarão atentos a métricas como a porção do fornecimento em stake (indicando segurança), a receita de taxas (indicando uso) e parcerias que impulsionam transações (indicando procura pelo token).

Modelo de Negócios e Estratégia Go-to-Market

O modelo de negócios da Ika é o de um fornecedor de infraestrutura no ecossistema blockchain. Não oferece um produto voltado para o consumidor; em vez disso, oferece um serviço de protocolo (gestão de chaves descentralizada e execução de transações) que outros projetos integram. Como tal, o principal mecanismo de receita (ou captura de valor) é a taxa por serviço – ou seja, as taxas de gas em IKA pelo uso da rede. Pode-se comparar a Ika a uma AWS descentralizada para assinatura de chaves: qualquer programador pode ligar-se e usá-la, pagando por uso. A longo prazo, à medida que a rede se descentraliza, a dWallet Labs (a empresa fundadora) pode capturar valor detendo uma participação na rede e através da apreciação do token, em vez de cobrar taxas ao estilo SaaS off-chain.

Estratégia Go-to-Market (GTM): No início, a Ika está a visar programadores de blockchain e projetos que necessitam de funcionalidade cross-chain ou soluções de custódia. O alinhamento com a Sui oferece um conjunto pronto de tais programadores. A própria Sui, sendo uma L1 mais recente, precisa de funcionalidades únicas para atrair utilizadores – e a Ika oferece DeFi cross-chain, acesso ao Bitcoin e mais na Sui, que são funcionalidades atraentes. Assim, a GTM da Ika aproveita o ecossistema crescente da Sui. Notavelmente, mesmo antes da mainnet, vários projetos da Sui anunciaram que estão a integrar a Ika:

  • Projetos como Full Sail, Rhei, Aeon, Human Tech, Covault, Lucky Kat, Native, Nativerse, Atoma e Ekko (todos construtores na Sui) “anunciaram os seus próximos lançamentos utilizando a Ika”, cobrindo casos de uso desde DeFi a jogos. Por exemplo, a Full Sail pode estar a construir uma exchange que pode negociar BTC via Ika; a Lucky Kat (um estúdio de jogos) poderia usar a Ika para permitir ativos no jogo que residem em múltiplas chains; a Covault provavelmente envolve soluções de custódia, etc. Ao garantir estas parcerias cedo, a Ika assegura que, no lançamento, haverá volume de transações imediato e aplicações reais a demonstrar as suas capacidades.

  • A Ika também está a enfatizar casos de uso institucionais, como custódia descentralizada para instituições. Em comunicados de imprensa, destacam “segurança inigualável para utilizadores institucionais e individuais” na custódia via Ika. Isto sugere que a Ika poderia ser comercializada para custodiantes de cripto, exchanges, ou mesmo players de TradFi que queiram uma forma mais segura de gerir chaves privadas (talvez como uma alternativa ou complemento à Fireblocks ou Copper, que usam MPC mas num ambiente empresarial centralizado). De facto, por ser uma rede descentralizada, a Ika poderia permitir que concorrentes na custódia confiassem todos na mesma rede de assinatura robusta, em vez de cada um construir a sua própria. Este modelo cooperativo poderia atrair instituições que preferem um custodiante neutro e descentralizado para certos ativos.

  • Outro ângulo são as integrações de IA: a Ika menciona “guardrails para Agentes de IA” como um caso de uso. Isto é visionário, jogando com a tendência da autonomia da IA (por exemplo, agentes de IA a executar na blockchain). A Ika pode garantir que um agente de IA (digamos, um agente económico autónomo com controlo de alguns fundos) não pode fugir com os fundos porque o próprio agente não é o único detentor da chave – ainda precisaria da parte do utilizador ou de cumprir as condições na Ika. Marketing da Ika como fornecedora de barreiras de segurança para IA na Web3 é um ângulo inovador para captar o interesse desse setor.

Geograficamente, a presença da Node Capital e outros sugere também um foco na Ásia, além do mercado ocidental. A Sui tem uma forte comunidade asiática (especialmente na China). A campanha de NFT da Ika na Sui (a campanha de arte que angariou 1.4M SUI) indica um esforço de construção de comunidade – possivelmente envolvendo utilizadores chineses que são ávidos no espaço de NFTs da Sui. Ao fazer vendas de NFTs ou airdrops para a comunidade, a Ika pode cultivar uma base de utilizadores de base que detêm tokens IKA e são incentivados a promover a sua adoção.

Com o tempo, o modelo de negócios poderia estender-se para oferecer funcionalidades premium ou integrações empresariais. Por exemplo, enquanto a rede pública da Ika é sem permissão, a dWallet Labs poderia criar instâncias privadas ou versões de consórcio para certos clientes, ou fornecer serviços de consultoria a projetos que integram a Ika. Eles também poderiam ganhar através da execução de alguns dos validadores no início (fase de bootstrap) e, assim, recolher parte das taxas.

Em resumo, a GTM da Ika está fortemente ligada a parcerias de ecossistema. Ao incorporar-se profundamente no roadmap da Sui (onde os objetivos da Sui para 2025 incluem liquidez cross-chain e casos de uso únicos), a Ika garante que irá acompanhar o crescimento dessa L1. Simultaneamente, posiciona-se como uma solução generalizada para coordenação multi-chain, que pode então ser apresentada a projetos noutras chains assim que o sucesso na Sui for demonstrado. O apoio da Fundação Sui e os anúncios de integração precoce dão à Ika uma vantagem significativa em credibilidade e adoção em comparação com se fosse lançada isoladamente.

Adoção pelo Ecossistema, Parcerias e Roadmap

Mesmo na sua fase inicial, a Ika construiu uma lista impressionante de envolvimentos no ecossistema:

  • Adoção pelo Ecossistema Sui: Como mencionado, múltiplos projetos baseados na Sui estão a integrar a Ika. Isto significa que, no lançamento da mainnet da Ika, esperamos ver dApps da Sui a ativar funcionalidades como “Powered by Ika” – por exemplo, um protocolo de empréstimo na Sui que permite aos utilizadores depositar BTC, ou uma DAO na Sui que usa a Ika para deter o seu tesouro em múltiplas chains. O facto de nomes como Rhei, Atoma, Nativerse (provavelmente projetos DeFi) e Lucky Kat (jogos/NFT) estarem a bordo mostra que a aplicabilidade da Ika abrange vários verticais.

  • Parcerias Estratégicas: A parceria mais importante da Ika é com a própria Fundação Sui, que é tanto um investidor como um promotor. Os canais oficiais da Sui (blog, etc.) têm destacado a Ika proeminentemente, endossando-a efetivamente como a solução de interoperabilidade para a Sui. Adicionalmente, a Ika provavelmente tem trabalhado com outros fornecedores de infraestrutura. Por exemplo, dada a menção do zkLogin (a funcionalidade de login Web2 da Sui) juntamente com a Ika, poderia haver um caso de uso combinado onde o zkLogin lida com a autenticação do utilizador e a Ika lida com as transações cross-chain, proporcionando em conjunto uma UX fluida. Além disso, a menção da Ika à Avail (Polygon) nos seus blogs sugere uma parceria ou piloto nesse ecossistema: talvez com a Polygon Labs ou equipas a construir rollups na Avail para usar a Ika para fazer a ponte do Bitcoin para esses rollups. Outro domínio de parceria potencial é com custodiantes – por exemplo, integrar a Ika com fornecedores de carteiras como a Zengo (notável, uma vez que o co-fundador da ZenGo estava no projeto anterior de Omer) ou com tecnologia de custódia institucional como a Fireblocks. Embora não confirmado, estes seriam alvos lógicos (de facto, a Fireblocks fez parceria com a Sui noutros contextos; poder-se-ia imaginar a Fireblocks a alavancar a Ika para MPC na Sui).

  • Envolvimento da Comunidade e Programadores: A Ika mantém um Discord e provavelmente organiza hackathons para levar os programadores a construir com dWallets. A tecnologia é nova, por isso evangelizá-la através da educação é fundamental. A presença das secções “Casos de Uso” e “Construtores” no seu site, além de publicações de blog a explicar conceitos centrais, indica um esforço para que os programadores se sintam confortáveis com o conceito de dWallets. Quanto mais programadores entenderem que podem construir lógica cross-chain sem bridges (e sem comprometer a segurança), mais a adoção orgânica crescerá.

  • Roadmap: A partir de 2025, o roadmap da Ika incluía:

    • Alfa e Testnet (2023–2024): A testnet alfa foi lançada em 2024 na Sui, permitindo que os programadores experimentassem as dWallets e fornecessem feedback. Esta fase foi usada para refinar o protocolo, corrigir bugs e realizar auditorias internas.
    • Lançamento da Mainnet (Dez 2024): A Ika planeava entrar em funcionamento na mainnet até ao final de 2024. Se alcançado, até agora (meados de 2025) a mainnet da Ika deverá estar operacional. O lançamento provavelmente incluiu suporte inicial para um conjunto de chains: pelo menos Bitcoin e Ethereum (chains ECDSA) de imediato, dado que foram muito mencionadas no marketing.
    • Objetivos Pós-Lançamento para 2025: Em 2025, esperamos que o foco seja em escalar o uso (através de apps da Sui e possivelmente expandindo para outras chains). A equipa trabalhará na adição de suporte a Ed25519 e Schnorr logo após o lançamento, permitindo a integração com Solana, Polkadot e outros ecossistemas. Eles também implementarão mais light clients (talvez um light client da Ethereum para a Ika, um light client da Solana, etc.) para ampliar o controlo trustless. Outro item do roadmap é provavelmente a expansão de validadores sem permissão – incentivando mais validadores independentes a juntarem-se e descentralizando ainda mais a rede. Como o código é um fork da Sui, executar um validador Ika é semelhante a executar um nó Sui, o que muitos operadores podem fazer.
    • Melhorias de Funcionalidades: Duas funcionalidades interessantes sugeridas nos blogs são Partes de Utilizador Encriptadas e Assinatura de Transações Futuras. A parte de utilizador encriptada significa que os utilizadores podem opcionalmente encriptar a sua parte privada e armazená-la on-chain (talvez na Ika ou noutro lugar) de uma forma que só eles podem desencriptar, simplificando a recuperação. A assinatura de transações futuras implica a capacidade de ter a Ika a pré-assinar uma transação que é executada mais tarde quando as condições são cumpridas. Estas funcionalidades aumentam a usabilidade (os utilizadores não precisarão de estar online para cada ação se pré-aprovarem certas lógicas, tudo enquanto mantêm a segurança não-custodial). Entregar estas funcionalidades em 2025 diferenciaria ainda mais a oferta da Ika.
    • Crescimento do Ecossistema: Até ao final de 2025, a Ika provavelmente pretende ter múltiplos ecossistemas de chains a usá-la ativamente. Poderemos ver, por exemplo, um projeto Ethereum a usar a Ika através de um oráculo (se a integração on-chain direta ainda não existir) ou colaborações com projetos interchain como Wormhole ou LayerZero, onde a Ika poderia servir como o mecanismo de assinatura para mensagens seguras.

O cenário competitivo também moldará a estratégia da Ika. Não está sozinha a oferecer gestão de chaves descentralizada, pelo que parte do seu roadmap envolverá destacar a sua vantagem de desempenho e o modelo de segurança único de duas partes em contraste com outros. Na próxima secção, comparamos a Ika com os seus concorrentes notáveis Lit Protocol, Threshold Network e Zama.

Análise Competitiva: Ika vs. Outras Redes MPC/Threshold

A Ika opera numa arena de vanguarda de redes criptográficas, onde alguns projetos perseguem objetivos semelhantes com abordagens variadas. Abaixo está uma comparação resumida da Ika com o Lit Protocol, a Threshold Network e a Zama (cada um um concorrente representativo em infraestrutura de chaves descentralizada ou computação de privacidade):

AspetoIka (Rede MPC Paralela)Lit Protocol (PKI & Computação)Threshold Network (tBTC & TSS)Zama (Rede FHE)
Lançamento e EstadoFundada em 2022; Testnet em 2024; Mainnet lançada na Sui em Dez 2024 (início de 2025). Token $IKA ativo na Sui.Lançado em 2021; rede de nós Lit ativa. Token $LIT (lançado em 2021). A construir o rollup “Chronicle” para escalar.Rede ativa em 2022 após a fusão Keep/NuCypher. Token $T governa a DAO. tBTC v2 lançado para bridging de Bitcoin.Em desenvolvimento (sem rede pública até 2025). Angariou grandes rondas de VC para I&D. Sem token ainda (ferramentas FHE em fase alfa).
Foco Principal/Caso de UsoInteroperabilidade cross-chain e custódia: assinatura de limiar para controlar ativos nativos em várias chains (ex. BTC, ETH) via dWallets. Permite DeFi, dApps multi-chain, etc.Gestão de chaves descentralizada e controlo de acesso: encriptação/desencriptação de limiar e assinatura condicional via PKPs (Pares de Chaves Programáveis). Popular para restringir conteúdo, automação cross-chain com “Lit Actions” em JavaScript.Serviços de criptografia de limiar: ex. tBTC, uma ponte descentralizada de Bitcoin para Ethereum; ECDSA de limiar para custódia de ativos digitais; recodificação de proxy de limiar (PRE) para privacidade de dados.Computação com preservação de privacidade: Criptografia Totalmente Homomórfica (FHE) para permitir o processamento de dados encriptados e smart contracts privados. Foco na confidencialidade (ex. DeFi privado, ML on-chain) em vez de controlo cross-chain.
ArquiteturaFork da blockchain Sui (consenso DAG Mysticeti) modificado para MPC. Sem smart contracts de utilizador na Ika; usa protocolo 2PC-MPC off-chain entre ~N validadores + parte do utilizador. Design de alto throughput (10k TPS).Rede descentralizada + L2: Nós Lit executam MPC e também um runtime JS baseado em TEE. Rollup Arbitrum “Chronicle” usado para ancorar o estado e coordenar os nós. Usa limiar de 2/3 para consenso em operações de chave.Rede descentralizada na Ethereum: Operadores de nós fazem stake com $T e são selecionados aleatoriamente para grupos de assinatura (ex. 100 nós para tBTC). Usa protocolos off-chain (GG18, etc.) com contratos Ethereum on-chain para coordenação e gestão de depósitos.Toolkits FHE sobre chains existentes: A tecnologia da Zama (ex. Concrete, bibliotecas TFHE) permite FHE na Ethereum (fhEVM). Planos para um sistema de gestão de chaves de limiar (TKMS) para chaves FHE. Provavelmente integrará com L1s ou funcionará como Layer-2 para computações privadas.
Modelo de Segurança2PC-MPC, não-colusivo: Parte da chave do utilizador + limiar de N validadores (2/3 BFT) necessários para qualquer assinatura. Nenhuma entidade única detém a chave completa. Consenso BFT tolera <33% maliciosos. Auditado pela Symbolic (2024).Limiar + TEE: Requer 2/3 dos nós Lit para assinar/desencriptar. Usa Ambientes de Execução Confiáveis (TEE) em cada nó para executar código fornecido pelo utilizador (Lit Actions) de forma segura. A segurança depende da honestidade dos nós e da segurança do hardware.Multi-partes de limiar: ex. para tBTC, um grupo selecionado aleatoriamente de ~100 nós deve atingir um limiar (ex. 51) para assinar transações BTC. Incentivos económicos (staking de $T, slashing) para manter a maioria honesta. Governado por DAO; incidentes de segurança seriam tratados via governação.Baseado em FHE: A segurança depende da dureza criptográfica do FHE (learning with errors, etc.) – os dados permanecem encriptados em todos os momentos. O TKMS da Zama indica o uso de criptografia de limiar para gerir também as chaves FHE. Ainda não é uma rede ativa; segurança sob revisão por académicos.
DesempenhoLatência abaixo de um segundo, ~10.000 assinaturas/segundo em teoria. Escala para centenas ou milhares de nós sem grande perda de desempenho (abordagem de broadcast e batching). Adequado para uso em dApps em tempo real (trading, jogos).Latência moderada (mais pesada devido à sobrecarga de TEE e consenso). O Lit tem ~50 nós; usa “shadow splicing” para escalar, mas um grande número de nós pode degradar o desempenho. Bom para tarefas de frequência moderada (abrir acesso, assinatura ocasional de tx). O Chronicle L2 ajuda no batching.Throughput mais baixo, latência mais alta: A cunhagem de tBTC pode demorar minutos (à espera de confirmações do Bitcoin + assinatura de limiar) e usa pequenos grupos para assinar. O foco do Threshold é qualidade (segurança) em vez de quantidade – bom para transações de bridging e controlo de acesso, não projetado para milhares de TPS.Latência de computação pesada: O FHE é atualmente muito mais lento do que a computação em texto simples (ordens de magnitude). A Zama está a otimizar, mas executar contratos privados será mais lento e mais caro do que os normais. Não se destina a tarefas de alta frequência; direcionado para computações complexas onde a privacidade é primordial.
DescentralizaçãoAlta – conjunto de validadores sem permissão, centenas de validadores possíveis. PoS delegado (estilo Sui) garante participação aberta e governação descentralizada ao longo do tempo. O utilizador está sempre no ciclo (não pode ser contornado).Média – atualmente ~30-50 nós centrais geridos pela equipa Lit e parceiros. Planos para descentralizar mais. Os nós executam tarefas pesadas (MPC + TEE), pelo que escalar não é trivial. Governação ainda não totalmente descentralizada (Lit DAO existe, mas é inicial).Alta – grande pool de stakers; no entanto, a assinatura real é feita por grupos selecionados (não por toda a rede de uma vez). A rede é tão descentralizada quanto a sua distribuição de stake. Governada pela Threshold DAO (votos dos detentores de tokens) – descentralização madura na governação.N/A (para a rede) – A Zama é mais um projeto impulsionado por uma empresa agora. Se a fhEVM ou redes forem lançadas, inicialmente serão provavelmente centralizadas ou com um conjunto limitado de nós (dada a complexidade). Com o tempo, poderia descentralizar a execução de transações FHE, mas isso é território inexplorado em 2025.
Token e Incentivos$IKA (baseado na Sui) para taxas de gas, staking e potencialmente governação. Incentivo: ganhar taxas por executar validadores; o token aprecia com o uso da rede. O apoio da Fundação Sui confere-lhe valor de ecossistema.**Token LITusadoparagovernac\ca~oetalveztaxasparaservic\cosavanc\cados.AsLitActionssa~oatualmentegratuitasparaprogramadores(semgas);alongoprazo,podeintroduzirummodelodetaxas.OLIT** – usado para governação e talvez taxas para serviços avançados. As Lit Actions são atualmente gratuitas para programadores (sem gas); a longo prazo, pode introduzir um modelo de taxas. O LIT incentiva a operação de nós (stakers), mas a tokenomics exata está em evolução.**Token Temstakepornoˊs,governaotesourodaDAOeasatualizac\co~esdoprotocolo.OsnoˊsganhamemT** – em stake por nós, governa o tesouro da DAO e as atualizações do protocolo. Os nós ganham em T e taxas (em ETH ou taxas de tBTC). O $T protege a rede (slashing por mau comportamento). Também usado em programas de liquidez para adoção do tBTC.Sem token (ainda) – A Zama é financiada por VC; pode introduzir um token se lançar um serviço de rede (poderia ser usado para pagar por computação privada ou staking para proteger redes que executam contratos FHE). Atualmente, os programadores usam as ferramentas da Zama sem um token.
Principais ApoiantesFundação Sui (investidor estratégico); VCs: Node Capital, Blockchange, Lemniscap, Collider; anjos como Naval Ravikant. Forte apoio do ecossistema Sui.Apoiado por 1kx, Pantera, Coinbase Ventures, Framework, etc. (Angariou $13M em 2022). Tem uma comunidade de programadores crescente via Lit DAO. Parcerias com Ceramic, projetos de NFT para controlo de acesso.Surgiu das comunidades Keep & NuCypher (apoiadas por a16z, Polychain no passado). A Threshold é gerida por uma DAO; sem novo financiamento de VC pós-fusão (subsídios do Ethereum Community Fund, etc.). Parcerias: trabalha com Curve, Aave (integrações tBTC).Apoiado por a16z, SoftBank, Multicoin Capital (angariou $73M na Série A). Laços estreitos com a investigação da Fundação Ethereum (Rand Hindi, CEO, é um defensor declarado do FHE na Ethereum). A colaborar com projetos como a Optalysys para aceleração de hardware.

Vantagem Competitiva da Ika: Os diferenciadores da Ika residem no seu desempenho em escala e modelo de segurança único. Comparada com o Lit Protocol, a Ika pode suportar muito mais signatários e um throughput muito maior, tornando-a adequada para casos de uso (como trading de alto volume ou jogos) com os quais a rede do Lit teria dificuldades. A Ika também não depende de Ambientes de Execução Confiáveis, dos quais alguns programadores desconfiam (devido a potenciais exploits no SGX); em vez disso, a Ika alcança a ausência de confiança puramente com criptografia e consenso. Contra a Threshold Network, a Ika oferece uma plataforma de propósito mais geral. A Threshold está largamente focada na ponte Bitcoin↔Ethereum (tBTC) e alguns serviços criptográficos como recodificação de proxy, enquanto a Ika é uma camada de interoperabilidade flexível que pode funcionar com qualquer chain e ativo de raiz. Além disso, o modelo da Ika com o utilizador no ciclo significa que não requer sobrecolateralização ou seguro para depósitos (o tBTC v2 usa um modelo económico robusto mas complexo para proteger os depósitos de BTC, enquanto na Ika o utilizador nunca abdica do controlo em primeiro lugar). Comparada com a Zama, a Ika aborda um problema diferente – a Zama visa a privacidade, enquanto a Ika visa a interoperabilidade. No entanto, é concebível que no futuro as duas se possam complementar (por exemplo, usando FHE em ativos armazenados na Ika). Por agora, a Ika tem a vantagem de estar operacional mais cedo num nicho com procura imediata (bridges e redes MPC são necessárias hoje, enquanto o FHE ainda está a amadurecer).

Um desafio potencial para a Ika é a educação do mercado e a confiança. Está a introduzir uma nova forma de fazer interações cross-chain (dWallets em vez das tradicionais bridges de lock-and-mint). Precisará de demonstrar a sua segurança na prática ao longo do tempo para ganhar o mesmo nível de confiança que, por exemplo, a Threshold Network gradualmente conquistou (a Threshold teve de provar o tBTC depois de uma versão anterior ter sido pausada devido a riscos). Se a tecnologia da Ika funcionar como anunciado, ela efetivamente ultrapassa a concorrência ao resolver o trilema de descentralização, segurança e velocidade no espaço MPC. O forte apoio da Sui e as extensas auditorias/artigos conferem credibilidade.

Em conclusão, a Ika destaca-se entre as redes MPC pela sua escalabilidade ambiciosa e modelo de segurança centrado no utilizador. Os investidores veem-na como uma aposta no futuro da coordenação cross-chain – uma onde os utilizadores podem mover valor e lógica de forma fluida através de muitas blockchains sem nunca abdicarem do controlo das suas chaves. Se a Ika alcançar uma ampla adoção, poderá tornar-se tão integral para a infraestrutura Web3 como os protocolos de mensagens cross-chain ou as principais blockchains Layer-1. O próximo ano (2025) será crítico, à medida que a mainnet da Ika e os primeiros casos de uso entram em funcionamento, provando se esta criptografia de vanguarda pode cumprir as suas promessas em condições reais de mercado. Os sinais iniciais – fundamentos técnicos sólidos, um pipeline ativo de integrações e um apoio substancial de investidores – sugerem que a Ika tem uma oportunidade real de redefinir a interoperabilidade de blockchain com MPC.

Fontes: As informações principais foram recolhidas da documentação oficial e do whitepaper da Ika, anúncios da Fundação Sui, comunicados de imprensa e notícias de financiamento, bem como documentos técnicos e análises de concorrentes para contextualização (relatório Messari do Lit Protocol, documentação da Threshold Network e descrições FHE da Zama). Todas as informações estão atualizadas até 2025.

Privacidade Programável em Blockchain: Computação Off-Chain com Verificação On-Chain

· Leitura de 53 minutos
Dora Noda
Software Engineer

Blockchains públicas oferecem transparência e integridade ao custo da privacidade – cada transação e estado de contrato são expostos a todos os participantes. Essa abertura cria problemas como ataques de MEV (Miner Extractable Value), copy-trading e vazamento de lógica de negócios sensível. A privacidade programável visa resolver esses problemas permitindo computações em dados privados sem revelar os próprios dados. Dois paradigmas criptográficos emergentes estão tornando isso possível: Máquinas Virtuais de Criptografia Totalmente Homomórfica (FHE-VM) e Coprocessadores de Conhecimento Zero (ZK). Essas abordagens permitem computação off-chain ou criptografada com verificação on-chain, preservando a confidencialidade enquanto mantêm a correção trustless. Neste relatório, mergulhamos fundo nas arquiteturas FHE-VM e ZK-coprocessor, comparamos seus trade-offs e exploramos casos de uso em finanças, identidade, saúde, mercados de dados e aprendizado de máquina descentralizado.

Máquina Virtual de Criptografia Totalmente Homomórfica (FHE-VM)

A Criptografia Totalmente Homomórfica (FHE) permite computações arbitrárias em dados criptografados sem nunca descriptografá-los. Uma Máquina Virtual FHE integra essa capacidade em contratos inteligentes de blockchain, permitindo estado e lógica de contrato criptografados. Em uma blockchain habilitada para FHE (frequentemente chamada de fhEVM para designs compatíveis com EVM), todas as entradas, armazenamento de contrato e saídas permanecem criptografados durante toda a execução. Isso significa que os validadores podem processar transações e atualizar o estado sem aprender nenhum valor sensível, alcançando a execução on-chain com confidencialidade de dados.

Arquitetura e Design da FHE-VM

Uma FHE-VM típica estende um tempo de execução de contrato inteligente padrão (como a Ethereum Virtual Machine) com suporte nativo para tipos de dados e operações criptografadas. Por exemplo, a FHEVM da Zama introduz inteiros criptografados (euint8, euint32, etc.), booleanos criptografados (ebool) e até mesmo arrays criptografados como tipos de primeira classe. Linguagens de contrato inteligente como Solidity são aumentadas por meio de bibliotecas ou novos opcodes para que os desenvolvedores possam realizar operações aritméticas (add, mul, etc.), lógicas e comparações diretamente em textos cifrados. Nos bastidores, essas operações invocam primitivas FHE (por exemplo, usando a biblioteca TFHE) para manipular bits criptografados e produzir resultados criptografados.

O armazenamento de estado criptografado é suportado para que as variáveis do contrato permaneçam criptografadas no estado da blockchain. O fluxo de execução é tipicamente:

  1. Criptografia do Lado do Cliente: Os usuários criptografam suas entradas localmente usando a chave FHE pública antes de enviar transações. A chave de criptografia é pública (para criptografia e avaliação), enquanto a chave de descriptografia permanece secreta. Em alguns designs, cada usuário gerencia sua própria chave; em outros, uma única chave FHE global é usada (discutido abaixo).
  2. Computação Homomórfica On-Chain: Mineradores/validadores executam o contrato com opcodes criptografados. Eles realizam as mesmas operações homomórficas determinísticas nos textos cifrados, para que o consenso possa ser alcançado sobre o novo estado criptografado. Crucialmente, os validadores nunca veem dados em texto claro – eles apenas veem texto cifrado "sem sentido", mas ainda podem processá-lo de forma consistente.
  3. Descriptografia (Opcional): Se um resultado precisar ser revelado ou usado off-chain, uma parte autorizada com a chave privada pode descriptografar o texto cifrado de saída. Caso contrário, os resultados permanecem criptografados e podem ser usados como entradas para transações futuras (permitindo computações consecutivas em estado criptografado persistente).

Uma consideração de design importante é o gerenciamento de chaves. Uma abordagem é de chaves por usuário, onde cada usuário detém sua chave secreta e apenas eles podem descriptografar saídas relevantes para eles. Isso maximiza a privacidade (ninguém mais pode descriptografar seus dados), mas as operações homomórficas não podem misturar dados criptografados sob chaves diferentes sem protocolos complexos de múltiplas chaves. Outra abordagem, usada pela FHEVM da Zama, é uma chave FHE global: uma única chave pública criptografa todos os dados do contrato e um conjunto distribuído de validadores detém partes da chave de descriptografia de limiar. As chaves públicas de criptografia e avaliação são publicadas on-chain, para que qualquer pessoa possa criptografar dados para a rede; a chave privada é dividida entre os validadores que podem descriptografar coletivamente, se necessário, sob um esquema de limiar. Para evitar que a conivência de validadores comprometa a privacidade, a Zama emprega um protocolo FHE de limiar (baseado em sua pesquisa Noah’s Ark) com "inundação de ruído" para tornar as descriptografias parciais seguras. Apenas se um quórum suficiente de validadores cooperar, um texto claro pode ser recuperado, por exemplo, para atender a uma solicitação de leitura. Em operação normal, no entanto, nenhum nó único jamais vê o texto claro – os dados permanecem criptografados on-chain o tempo todo.

O controle de acesso é outro componente crucial. As implementações de FHE-VM incluem controles refinados para gerenciar quem (se houver alguém) pode acionar descriptografias ou acessar certos campos criptografados. Por exemplo, a fhEVM da Cypher suporta Listas de Controle de Acesso em textos cifrados, permitindo que os desenvolvedores especifiquem quais endereços ou contratos podem interagir ou recriptografar certos dados. Alguns frameworks suportam recriptografia: a capacidade de transferir um valor criptografado da chave de um usuário para a de outro sem expor o texto claro. Isso é útil para coisas como mercados de dados, onde um proprietário de dados pode criptografar um conjunto de dados com sua chave e, após a compra, recriptografá-lo para a chave do comprador – tudo on-chain, sem nunca descriptografar publicamente.

Garantindo Correção e Privacidade

Alguém pode perguntar: se todos os dados são criptografados, como garantimos a correção da lógica do contrato? Como a cadeia pode impedir operações inválidas se não consegue "ver" os valores? A FHE por si só não fornece uma prova de correção – os validadores podem realizar os passos homomórficos, mas não podem inerentemente dizer se a entrada criptografada de um usuário era válida ou se um desvio condicional deveria ser tomado, etc., sem descriptografar. Provas de conhecimento zero (ZKPs) podem complementar a FHE para resolver essa lacuna. Em uma FHE-VM, tipicamente os usuários devem fornecer uma prova ZK atestando certas condições de texto claro sempre que necessário. O design da Zama, por exemplo, usa uma Prova ZK de Conhecimento de Texto Claro (ZKPoK) para acompanhar cada entrada criptografada. Isso prova que o usuário conhece o texto claro correspondente ao seu texto cifrado e que ele atende aos critérios esperados, sem revelar o próprio texto claro. Tais "textos cifrados certificados" impedem que um usuário mal-intencionado envie uma criptografia malformada ou um valor fora do intervalo. Da mesma forma, para operações que exigem uma decisão (por exemplo, garantir que o saldo da conta ≥ valor do saque), o usuário pode fornecer uma prova ZK de que essa condição é verdadeira nos textos claros antes que a operação criptografada seja executada. Dessa forma, a cadeia não descriptografa ou vê os valores, mas ganha confiança de que as transações criptografadas seguem as regras.

Outra abordagem em rollups FHE é realizar validação off-chain com ZKPs. A Fhenix (um rollup L2 usando FHE) opta por um modelo otimista onde um componente de rede separado chamado Rede de Serviço de Limiar pode descriptografar ou verificar resultados criptografados, e qualquer computação incorreta pode ser contestada com uma prova de fraude. Em geral, combinar FHE + ZK ou provas de fraude garante que a execução criptografada permaneça trustless. Os validadores ou descriptografam coletivamente apenas quando autorizados, ou verificam provas de que cada transição de estado criptografada foi válida sem precisar ver o texto claro.

Considerações de desempenho: As operações FHE são computacionalmente pesadas – muitas ordens de magnitude mais lentas que a aritmética normal. Por exemplo, uma simples adição de 64 bits no Ethereum custa ~3 gas, enquanto uma adição em um inteiro criptografado de 64 bits (euint64) na FHEVM da Zama custa aproximadamente 188.000 gas. Mesmo uma adição de 8 bits pode custar ~94k gas. Essa enorme sobrecarga significa que uma implementação direta em nós existentes seria impraticavelmente lenta e cara. Projetos de FHE-VM enfrentam isso com bibliotecas criptográficas otimizadas (como a biblioteca TFHE-rs da Zama para bootstrapping de portões binários) e modificações personalizadas na EVM para desempenho. Por exemplo, o cliente Geth modificado da Cypher adiciona novos opcodes e otimiza a execução de instruções homomórficas em C++/assembly para minimizar a sobrecarga. No entanto, alcançar uma taxa de transferência utilizável requer aceleração. O trabalho em andamento inclui o uso de GPUs, FPGAs e até mesmo chips fotônicos especializados para acelerar as computações FHE. A Zama relata que seu desempenho FHE melhorou 100x desde 2024 e está visando milhares de TPS com aceleração de GPU/FPGA. Servidores coprocessadores FHE dedicados (como o LightLocker Node da Optalysys) podem ser conectados a nós validadores para descarregar operações criptografadas para hardware, suportando >100 transferências ERC-20 criptografadas por segundo por nó. À medida que o hardware e os algoritmos melhoram, a lacuna entre FHE e computação em texto claro diminuirá, permitindo que contratos privados se aproximem de velocidades mais práticas.

Compatibilidade: Um objetivo chave dos designs de FHE-VM é permanecer compatível com os fluxos de trabalho de desenvolvimento existentes. As implementações fhEVM da Cypher e da Zama permitem que os desenvolvedores escrevam contratos em Solidity com mudanças mínimas – usando uma biblioteca para declarar tipos e operações criptografadas. O resto do conjunto de ferramentas do Ethereum (Remix, Hardhat, etc.) ainda pode ser usado, pois as modificações subjacentes estão principalmente no nível do cliente/nó. Isso diminui a barreira de entrada: os desenvolvedores não precisam ser especialistas em criptografia para escrever um contrato inteligente confidencial. Por exemplo, uma simples adição de dois números pode ser escrita como euint32 c = a + b; e a FHEVM cuidará dos detalhes específicos da criptografia nos bastidores. Os contratos podem até interoperar com contratos normais – por exemplo, um contrato criptografado poderia produzir um resultado descriptografado para um contrato padrão, se desejado, permitindo uma mistura de partes privadas e públicas em um ecossistema.

Projetos FHE-VM Atuais: Vários projetos são pioneiros neste espaço. A Zama (uma startup de FHE sediada em Paris) desenvolveu o conceito central da FHEVM e bibliotecas (TFHE-rs e uma biblioteca fhevm-solidity). Eles não pretendem lançar sua própria cadeia, mas sim fornecer infraestrutura para outros. A Inco é uma blockchain L1 (construída no Cosmos SDK com Evmos) que integrou a FHEVM da Zama para criar uma cadeia confidencial modular. Suas testnets (chamadas Gentry e Paillier) demonstram transferências ERC-20 criptografadas e outras primitivas DeFi privadas. A Fhenix é um rollup otimista de Camada 2 do Ethereum usando FHE para privacidade. Ela decidiu por uma abordagem otimista (prova de fraude) em vez de ZK-rollup devido ao alto custo de fazer FHE e ZK juntos para cada bloco. A Fhenix usa a mesma biblioteca TFHE-rs (com algumas modificações) e introduz uma Rede de Serviço de Limiar para lidar com descriptografias de forma descentralizada. Existem também equipes independentes como a Fhenix (agora rebatizada) e startups explorando híbridos MPC + FHE. Além disso, a Cypher (da Z1 Labs) está construindo uma rede de Camada 3 focada em IA e privacidade, usando uma fhEVM com recursos como cofres secretos e suporte a aprendizado federado. O ecossistema é nascente, mas está crescendo rapidamente, impulsionado por financiamento significativo – por exemplo, a Zama se tornou um "unicórnio" com mais de US$ 130 milhões arrecadados até 2025 para avançar a tecnologia FHE.

Em resumo, uma FHE-VM permite contratos inteligentes que preservam a privacidade ao executar toda a lógica em dados criptografados on-chain. Este paradigma garante confidencialidade máxima – nada sensível é exposto em transações ou estado – enquanto aproveita o consenso de blockchain existente para integridade. O custo é o aumento da carga computacional sobre os validadores e a complexidade no gerenciamento de chaves e na integração de provas. A seguir, exploramos um paradigma alternativo que descarrega a computação totalmente off-chain e usa a cadeia apenas para verificação: o coprocessador de conhecimento zero.

Coprocessadores de Conhecimento Zero (ZK-Coprocessors)

Um coprocessador ZK é um novo padrão de arquitetura de blockchain onde computações caras são realizadas off-chain, e uma prova de conhecimento zero sucinta de sua correção é verificada on-chain. Isso permite que contratos inteligentes aproveitem um poder computacional e dados muito maiores do que a execução on-chain permitiria, sem sacrificar a natureza trustless. O termo coprocessador é usado por analogia aos coprocessadores de hardware (como um coprocessador matemático ou GPU) que lidam com tarefas especializadas para uma CPU. Aqui, a "CPU" da blockchain (a VM nativa como a EVM) delega certas tarefas a um sistema de prova de conhecimento zero que atua como um coprocessador criptográfico. O coprocessador ZK retorna um resultado e uma prova de que o resultado foi calculado corretamente, que o contrato on-chain pode verificar e então usar.

Arquitetura e Fluxo de Trabalho

Em uma configuração típica, um desenvolvedor de dApp identifica partes da lógica de sua aplicação que são muito caras ou complexas para execução on-chain (por exemplo, grandes computações sobre dados históricos, algoritmos pesados, inferência de modelos de ML, etc.). Eles implementam essas partes como um programa off-chain (em uma linguagem de alto nível ou DSL de circuito) que pode produzir uma prova de conhecimento zero de sua execução. O componente on-chain é um contrato inteligente verificador que verifica as provas e disponibiliza os resultados para o resto do sistema. O fluxo pode ser resumido como:

  1. Requisição – O contrato on-chain aciona uma requisição para que uma certa computação seja feita off-chain. Isso pode ser iniciado por uma transação de usuário ou por um contrato chamando a interface do coprocessador ZK. Por exemplo, um contrato DeFi pode chamar “provarTaxaDeJuros(estadoAtual)” ou um usuário chama “consultarDadosHistoricos(consulta)”.
  2. Execução e Prova Off-Chain – Um serviço off-chain (que pode ser uma rede descentralizada de provadores ou um serviço confiável, dependendo do design) pega a requisição. Ele reúne todos os dados necessários (estado on-chain, entradas off-chain, etc.) e executa a computação em uma Máquina Virtual ZK (ZKVM) especial ou circuito. Durante a execução, um traço de prova é gerado. No final, o serviço produz uma prova sucinta (por exemplo, um SNARK ou STARK) atestando que “Computar a função F na entrada X resulta na saída Y” e, opcionalmente, atestando a integridade dos dados (mais sobre isso abaixo).
  3. Verificação On-Chain – A prova e o resultado são retornados para a blockchain (geralmente por meio de uma função de callback). O contrato verificador verifica a validade da prova usando verificação criptográfica eficiente (verificações de emparelhamento, etc.). Se válida, o contrato pode agora confiar na saída Y como correta. O resultado pode ser armazenado no estado, emitido como um evento ou alimentado em lógica de contrato adicional. Se a prova for inválida ou não for fornecida dentro de algum tempo, a requisição pode ser considerada falha (e potencialmente alguma lógica de fallback ou timeout é acionada).

Figura 1: Arquitetura de um Coprocessador ZK (exemplo do RISC Zero Bonsai). Off-chain, um programa é executado em uma ZKVM com entradas da chamada do contrato inteligente. Uma prova de execução é retornada on-chain por meio de um contrato de retransmissão, que invoca um callback com os resultados verificados.

Criticamente, o custo de gas on-chain para verificação é constante (ou cresce muito lentamente), independentemente de quão complexa foi a computação off-chain. Verificar uma prova sucinta pode custar na ordem de algumas centenas de milhares de gas (uma fração de um bloco do Ethereum), mas essa prova pode representar milhões de passos computacionais feitos off-chain. Como um desenvolvedor brincou, “Quer provar uma assinatura digital? ~15.Querprovarummilha~odeassinaturas?Tambeˊm 15. Quer provar um milhão de assinaturas? Também ~15.”. Essa escalabilidade é uma grande vitória: dApps podem oferecer funcionalidades complexas (análise de big data, modelos financeiros elaborados, etc.) sem sobrecarregar a blockchain.

Os principais componentes de um sistema de coprocessador ZK são:

  • Ambiente de Geração de Prova: Pode ser uma ZKVM de propósito geral (capaz de executar programas arbitrários) ou circuitos personalizados adaptados a computações específicas. As abordagens variam:

    • Alguns projetos usam circuitos feitos à mão para cada consulta ou função suportada (maximizando a eficiência para essa função).
    • Outros fornecem uma Linguagem Específica de Domínio (DSL) ou uma DSL Embutida que os desenvolvedores usam para escrever sua lógica off-chain, que é então compilada em circuitos (equilibrando facilidade de uso e desempenho).
    • A abordagem mais flexível é uma zkVM: uma máquina virtual (geralmente baseada em arquiteturas RISC) onde programas podem ser escritos em linguagens padrão (Rust, C, etc.) e automaticamente provados. Isso sacrifica o desempenho (simular uma CPU em um circuito adiciona sobrecarga) pela máxima experiência do desenvolvedor.
  • Acesso e Integridade de Dados: Um desafio único é alimentar a computação off-chain com os dados corretos, especialmente se esses dados residem na blockchain (blocos passados, estados de contrato, etc.). Uma solução ingênua é fazer com que o provador leia de um nó de arquivo e confie nele – mas isso introduz suposições de confiança. Em vez disso, os coprocessadores ZK normalmente provam que quaisquer dados on-chain usados eram de fato autênticos, vinculando-se a provas de Merkle ou compromissos de estado. Por exemplo, o programa de consulta pode pegar um número de bloco e uma prova de Merkle de um slot de armazenamento ou transação, e o circuito verificará essa prova contra um hash de cabeçalho de bloco conhecido. Existem três padrões:

    1. Dados Inline: Colocar os dados necessários on-chain (como entrada para o verificador) para que possam ser verificados diretamente. Isso é muito caro para grandes volumes de dados e mina todo o propósito.
    2. Confiar em um Oráculo: Ter um serviço de oráculo alimentando os dados para a prova e atestando por eles. Isso é mais simples, mas reintroduz a confiança em um terceiro.
    3. Provar a Inclusão de Dados via ZK: Incorporar provas de inclusão de dados no histórico da cadeia dentro do próprio circuito de conhecimento zero. Isso aproveita o fato de que cada cabeçalho de bloco do Ethereum se compromete com todo o estado anterior (via raiz de estado) e histórico de transações. Ao verificar provas de Merkle Patricia dos dados dentro do circuito, a prova de saída garante ao contrato que “esta computação usou dados genuínos da blockchain do bloco N” sem necessidade de confiança adicional.

    A terceira abordagem é a mais trustless e é usada por coprocessadores ZK avançados como Axiom e Xpansion (aumenta o custo de prova, mas é preferível por segurança). Por exemplo, o sistema da Axiom modela a estrutura de blocos do Ethereum, a trie de estado e a trie de transações dentro de seus circuitos, para que possa provar declarações como “a conta X tinha saldo Y no bloco N ou “uma transação com certas propriedades ocorreu no bloco N”. Ele aproveita o fato de que, dado um hash de bloco confiável recente, pode-se provar recursivamente a inclusão de dados históricos sem confiar em nenhuma parte externa.

  • Contrato Verificador: Este contrato on-chain contém a chave de verificação e a lógica para aceitar ou rejeitar provas. Para SNARKs como Groth16 ou PLONK, o verificador pode fazer alguns emparelhamentos de curva elíptica; para STARKs, pode fazer alguns cálculos de hash. Otimizações de desempenho como agregação e recursão podem minimizar a carga on-chain. Por exemplo, o Bonsai da RISC Zero usa um wrapper STARK-para-SNARK: ele executa uma VM baseada em STARK off-chain para velocidade, mas depois gera uma pequena prova SNARK atestando a validade do STARK. Isso reduz o tamanho da prova de centenas de kilobytes para algumas centenas de bytes, tornando a verificação on-chain viável e barata. O verificador Solidity então apenas verifica o SNARK (que é uma operação de tempo constante).

Em termos de implantação, os coprocessadores ZK podem funcionar como redes semelhantes a camada-2 ou como serviços puramente off-chain. Alguns, como a Axiom, começaram como um serviço especializado para o Ethereum (com o apoio da Paradigm), onde os desenvolvedores enviam consultas para a rede de provadores da Axiom e obtêm provas on-chain. O slogan da Axiom era fornecer aos contratos do Ethereum “acesso trustless a todos os dados on-chain e computação expressiva arbitrária sobre eles.” Ele efetivamente atua como um oráculo de consulta onde as respostas são verificadas por ZKPs em vez de confiança. Outros, como o Bonsai da RISC Zero, oferecem uma plataforma mais aberta: qualquer desenvolvedor pode enviar um programa (compilado para uma ZKVM compatível com RISC-V) e usar o serviço de prova do Bonsai por meio de um contrato de retransmissão. O padrão de retransmissão, como ilustrado na Figura 1, envolve um contrato que media requisições e respostas: o contrato do dApp chama o retransmissor para pedir uma prova, o serviço off-chain escuta isso (por exemplo, via evento ou chamada direta), computa a prova, e então o retransmissor invoca uma função de callback no contrato do dApp com o resultado e a prova. Este modelo assíncrono é necessário porque a prova pode levar de segundos a minutos, dependendo da complexidade. Ele introduz uma latência (e uma suposição de liveness de que o provador responderá), enquanto as computações FHE-VM acontecem sincronicamente dentro de um bloco. Projetar a aplicação para lidar com esse fluxo de trabalho assíncrono (possivelmente semelhante às respostas de Oráculo) faz parte do uso de um coprocessador ZK.

Projetos Notáveis de Coprocessador ZK

  • Axiom: A Axiom é um coprocessador ZK adaptado para o Ethereum, focado originalmente em provar consultas de dados on-chain históricos. Ele usa o framework de prova Halo2 (um SNARK do tipo Plonk) para criar provas que incorporam as estruturas criptográficas do Ethereum. No sistema da Axiom, um desenvolvedor pode consultar coisas como “qual era o estado do contrato X no bloco N?” ou realizar uma computação sobre todas as transações em um intervalo. Nos bastidores, os circuitos da Axiom tiveram que implementar a lógica de estado/trie do Ethereum, até mesmo realizando operações de curva elíptica e verificação de SNARK dentro do circuito para suportar recursão. A Trail of Bits, em uma auditoria, notou a complexidade dos circuitos Halo2 da Axiom modelando blocos e estados inteiros. Após a auditoria, a Axiom generalizou sua tecnologia em uma OpenVM, permitindo que código Rust arbitrário fosse provado com a mesma infraestrutura baseada em Halo2. (Isso reflete a tendência de passar de circuitos específicos de domínio para uma abordagem ZKVM mais geral.) A equipe da Axiom demonstrou consultas ZK que o Ethereum nativamente não pode fazer, permitindo acesso sem estado a quaisquer dados históricos com integridade criptográfica. Eles também enfatizaram a segurança, capturando e corrigindo bugs de circuito sub-restringidos e garantindo a solidez. Embora o produto inicial da Axiom tenha sido descontinuado durante sua mudança de foco, sua abordagem permanece um marco nos coprocessadores ZK.

  • RISC Zero Bonsai: A RISC Zero é uma ZKVM baseada na arquitetura RISC-V. Sua zkVM pode executar programas arbitrários (escritos em Rust, C++ e outras linguagens compiladas para RISC-V) e produzir uma prova STARK de execução. O Bonsai é o serviço em nuvem da RISC Zero que fornece essa prova sob demanda, atuando como um coprocessador para contratos inteligentes. Para usá-lo, um desenvolvedor escreve um programa (digamos, uma função que realiza matemática complexa ou verifica uma resposta de API off-chain), o envia para o serviço Bonsai e implanta um contrato verificador correspondente. Quando o contrato precisa dessa computação, ele chama o retransmissor Bonsai, que aciona a geração da prova e retorna o resultado via callback. Uma aplicação de exemplo demonstrada foi a computação de governança off-chain: a RISC Zero mostrou uma DAO usando o Bonsai para contar votos e computar métricas de votação complexas off-chain, e então postar uma prova para que o contrato Governor on-chain pudesse confiar no resultado com custo mínimo de gas. A tecnologia da RISC Zero enfatiza que os desenvolvedores podem usar paradigmas de programação familiares – por exemplo, escrever uma função em Rust para computar algo – e o trabalho pesado de criação de circuitos é tratado pela zkVM. No entanto, as provas podem ser grandes, então, como observado anteriormente, eles implementaram uma compressão SNARK para verificação on-chain. Em agosto de 2023, eles verificaram com sucesso provas da RISC Zero na testnet Sepolia do Ethereum, custando na ordem de 300k de gas por prova. Isso abre as portas para que dApps do Ethereum usem o Bonsai hoje como uma solução de escalabilidade e privacidade. (O Bonsai ainda está em alfa, não pronto para produção, e usa uma configuração SNARK temporária sem uma cerimônia.)

  • Outros: Existem vários outros players e iniciativas de pesquisa. A Expansion/Xpansion (como mencionado em um blog) usa uma abordagem de DSL embutida, onde os desenvolvedores podem escrever consultas sobre dados on-chain com uma linguagem especializada, e ela lida com a geração de provas internamente. O Cairo da StarkWare e o zkEVM da Polygon são VMs de ZK-rollup mais gerais, mas sua tecnologia poderia ser reaproveitada para uso semelhante a coprocessadores, verificando provas dentro de contratos L1. Também vemos projetos no domínio ZKML (ZK Machine Learning), que efetivamente atuam como coprocessadores para verificar a inferência de modelos de ML ou resultados de treinamento on-chain. Por exemplo, uma configuração zkML pode provar que “uma inferência de rede neural em entradas privadas produziu a classificação X” sem revelar as entradas ou fazer a computação on-chain. Estes são casos especiais do conceito de coprocessador aplicado à IA.

Suposições de confiança: Os coprocessadores ZK dependem da solidez das provas criptográficas. Se o sistema de prova for seguro (e qualquer configuração confiável for feita honestamente), então uma prova aceita garante que a computação foi correta. Nenhuma confiança adicional no provador é necessária – mesmo um provador mal-intencionado não pode convencer o verificador de uma declaração falsa. No entanto, existe uma suposição de liveness: alguém deve realmente realizar a computação off-chain e produzir a prova. Na prática, isso pode ser uma rede descentralizada (com incentivos ou taxas para fazer o trabalho) ou um único operador de serviço. Se ninguém fornecer a prova, a requisição on-chain pode permanecer não resolvida. Outro aspecto sutil de confiança é a disponibilidade de dados para entradas off-chain que não estão na blockchain. Se a computação depende de alguns dados privados ou externos, o verificador não pode saber se esses dados foram fornecidos honestamente, a menos que medidas adicionais (como compromissos de dados ou assinaturas de oráculo) sejam usadas. Mas para computações de dados puramente on-chain, os mecanismos descritos garantem uma natureza trustless equivalente à própria cadeia (a Axiom argumentou que suas provas oferecem "segurança criptograficamente equivalente ao Ethereum" para consultas históricas).

Privacidade: Provas de conhecimento zero também suportam inerentemente a privacidade – o provador pode manter as entradas ocultas enquanto prova declarações sobre elas. Em um contexto de coprocessador, isso significa que uma prova pode permitir que um contrato use um resultado que foi derivado de dados privados. Por exemplo, uma prova pode mostrar “a pontuação de crédito do usuário > 700, então aprove o empréstimo” sem revelar a pontuação de crédito real ou os dados brutos. O caso de uso da Axiom era mais sobre dados publicamente conhecidos (histórico da blockchain), então a privacidade não era o foco lá. Mas a zkVM da RISC Zero poderia ser usada para provar asserções sobre dados secretos fornecidos por um usuário: os dados permanecem off-chain e apenas o resultado necessário vai para on-chain. Vale a pena notar que, ao contrário da FHE, uma prova ZK geralmente não fornece confidencialidade contínua do estado – é uma prova única. Se um fluxo de trabalho precisa manter um estado secreto entre transações, pode-se construí-lo fazendo com que o contrato armazene um compromisso com o estado e cada prova mostrando uma transição de estado válida do compromisso antigo para o novo, com os segredos ocultos. É essencialmente assim que os zk-rollups para transações privadas (como Aztec ou Zcash) funcionam. Portanto, os coprocessadores ZK podem facilitar máquinas de estado totalmente privadas, mas a implementação não é trivial; muitas vezes eles são usados para computações únicas onde a entrada ou a saída (ou ambas) podem ser privadas conforme necessário.

Experiência do desenvolvedor: Usar um coprocessador ZK geralmente requer o aprendizado de novas ferramentas. Escrever circuitos personalizados (opção (1) acima) é bastante complexo e geralmente feito apenas para fins específicos. Opções de nível superior como DSLs ou zkVMs facilitam a vida, mas ainda adicionam sobrecarga: o desenvolvedor deve escrever e implantar código off-chain e gerenciar a interação. Em contraste com a FHE-VM, onde a criptografia é principalmente tratada nos bastidores e o desenvolvedor escreve código de contrato inteligente normal, aqui o desenvolvedor precisa particionar sua lógica e possivelmente escrever em uma linguagem diferente (Rust, etc.) para a parte off-chain. No entanto, iniciativas como as DSLs Noir, Leo, Circom ou a abordagem da RISC Zero estão melhorando rapidamente a acessibilidade. Por exemplo, a RISC Zero fornece modelos e integração com o Foundry para que um desenvolvedor possa simular seu código off-chain localmente (para correção) e depois conectá-lo perfeitamente a testes em Solidity por meio do callback do Bonsai. Com o tempo, podemos esperar frameworks de desenvolvimento que abstraiam se uma parte da lógica é executada via prova ZK ou on-chain – o compilador ou as ferramentas podem decidir com base no custo.

FHE-VM vs Coprocessador ZK: Comparação

Tanto as FHE-VMs quanto os coprocessadores ZK permitem uma forma de “computação em dados privados com garantia on-chain”, mas diferem fundamentalmente em arquitetura. A tabela abaixo resume as principais diferenças:

AspectoFHE-VM (Execução Criptografada On-Chain) -Coprocessador ZK (Prova Off-Chain) -
Onde a computação aconteceDiretamente on-chain (todos os nós executam operações homomórficas em textos cifrados). -Off-chain (um provador ou rede executa o programa; apenas uma prova é verificada on-chain). -
Confidencialidade dos dadosCriptografia total: os dados permanecem criptografados o tempo todo on-chain; os validadores nunca veem o texto claro. Apenas os detentores das chaves de descriptografia podem descriptografar as saídas. -Conhecimento zero: as entradas privadas do provador nunca são reveladas on-chain; a prova não revela segredos além do que está nas saídas públicas. No entanto, quaisquer dados usados na computação que devam afetar o estado on-chain devem ser codificados na saída ou no compromisso. Os segredos permanecem off-chain por padrão. -
Modelo de confiançaConfiança na execução por consenso e na criptografia: se a maioria dos validadores seguir o protocolo, a execução criptografada é determinística e correta. Nenhuma confiança externa é necessária para a correção da computação (todos os nós a recomputam). Deve-se confiar na segurança do esquema FHE (geralmente baseada na dificuldade de problemas de reticulado) para a privacidade. Em alguns designs, também se confia que não ocorrerá conluio de validadores suficientes para usar indevidamente as chaves de limiar. -Confiança na segurança do sistema de prova (solidez do SNARK/STARK). Se a prova for verificada, o resultado é correto com certeza criptográfica. Os provadores off-chain não podem enganar a matemática. Há uma suposição de liveness sobre os provadores para realmente fazerem o trabalho. Se estiver usando uma configuração confiável (por exemplo, SRS de SNARK), deve-se confiar que ela foi gerada honestamente ou usar sistemas transparentes/sem configuração. -
Custo on-chain e escalabilidadeAlto custo por transação: As operações homomórficas são extremamente caras computacionalmente, e cada nó deve realizá-las. Os custos de gas são altos (por exemplo, mais de 100k de gas para uma única adição de 8 bits). Contratos complexos são limitados pelo que cada validador pode computar em um bloco. A taxa de transferência é muito menor do que a de contratos inteligentes normais, a menos que hardware especializado seja empregado. A escalabilidade é melhorada por criptografia mais rápida e aceleração de hardware, mas fundamentalmente cada operação aumenta a carga de trabalho da cadeia. -Baixo custo de verificação: Verificar uma prova sucinta é eficiente e de tamanho constante, então o gas on-chain é modesto (centenas de milhares de gas para qualquer tamanho de computação). Isso desvincula a complexidade dos limites de recursos on-chain – grandes computações não têm custo extra on-chain. Assim, ele escala em termos de carga on-chain. Off-chain, o tempo de prova pode ser significativo (minutos ou mais para tarefas enormes) e pode exigir máquinas poderosas, mas isso não desacelera diretamente a blockchain. A taxa de transferência geral pode ser alta, desde que as provas possam ser geradas a tempo (potenciais redes de provadores paralelas). -
LatênciaOs resultados estão disponíveis imediatamente na mesma transação/bloco, já que a computação ocorre durante a execução. Sem viagens de ida e volta adicionais – operação síncrona. No entanto, um tempo de processamento de bloco mais longo pode aumentar a latência da blockchain se as operações FHE forem lentas. -Inerentemente assíncrono. Geralmente requer uma transação para solicitar e uma transação posterior (ou callback) para fornecer a prova/resultado. Isso introduz um atraso (possivelmente de segundos a horas, dependendo da complexidade da prova e do hardware de prova). Não é adequado para finalidade instantânea de uma única transação – mais como um modelo de trabalho assíncrono. -
Garantias de privacidadeForte: Tudo (entradas, saídas, estado intermediário) pode permanecer criptografado on-chain. Você pode ter um estado criptografado de longa duração que várias transações atualizam sem nunca revelá-lo. Apenas ações de descriptografia autorizadas (se houver) revelam saídas, e estas podem ser controladas por chaves/ACLs. No entanto, considerações de canal lateral como uso de gas ou logs de eventos devem ser gerenciadas para que não vazem padrões (designs de fhEVM buscam execução alheia aos dados com gas constante para operações para evitar vazamentos). -Seletiva: A prova revela o que quer que esteja nas saídas públicas ou seja necessário para verificar (por exemplo, um compromisso com o estado inicial). Os designers podem garantir que apenas o resultado pretendido seja revelado, e todas as outras entradas permaneçam ocultas com conhecimento zero. Mas, ao contrário da FHE, a blockchain normalmente não armazena o estado oculto – a privacidade é alcançada mantendo os dados totalmente off-chain. Se um estado privado persistente for necessário, o contrato pode armazenar um compromisso criptográfico com ele (para que as atualizações de estado ainda revelem um novo compromisso a cada vez). A privacidade é limitada pelo que você escolhe provar; você tem flexibilidade para provar, por exemplo, que um limiar foi atingido sem revelar valores exatos. -
Aplicação da integridadePor design, todos os validadores recomputam o próximo estado homomorficamente, então se um ator mal-intencionado fornecer um resultado de texto cifrado errado, outros detectarão uma incompatibilidade – o consenso falha a menos que todos obtenham o mesmo resultado. Assim, a integridade é aplicada por execução redundante (como na blockchain normal, apenas em dados criptografados). Provas ZK adicionais são frequentemente usadas para aplicar regras de negócio (por exemplo, o usuário não pôde violar uma restrição) porque os validadores não podem verificar diretamente as condições de texto claro. -A integridade é aplicada pelo contrato verificador que verifica a prova ZK. Desde que a prova seja verificada, o resultado é garantido como consistente com alguma execução válida do programa off-chain. Nenhuma suposição de maioria honesta é necessária para a correção – mesmo um único verificador honesto (o próprio código do contrato) é suficiente. O contrato on-chain simplesmente rejeitará qualquer prova falsa ou ausente (semelhante a como rejeitaria uma assinatura inválida). Uma consideração: se o provador abortar ou atrasar, o contrato pode precisar de lógica de fallback (ou os usuários podem precisar tentar novamente mais tarde), mas não aceitará resultados incorretos. -
Experiência do desenvolvedorPrós: Pode usar em grande parte linguagens de contrato inteligente familiares (Solidity, etc.) com extensões. A confidencialidade é tratada pela plataforma – os desenvolvedores se preocupam principalmente com o que criptografar e quem detém as chaves. A composição de contratos criptografados e normais é possível, mantendo a composabilidade do DeFi (apenas com variáveis criptografadas). Contras: Deve entender as limitações da FHE – por exemplo, sem saltos condicionais diretos em dados secretos sem tratamento especial, profundidade de circuito limitada (embora o bootstrapping em TFHE permita computação de comprimento arbitrário ao custo de tempo). Depurar lógica criptografada pode ser complicado, pois não se pode inspecionar facilmente os valores em tempo de execução sem a chave. Além disso, o gerenciamento de chaves e permissões adiciona complexidade ao design do contrato.Prós: Potencialmente usar qualquer linguagem de programação para a parte off-chain (especialmente com uma zkVM). Aproveitar código/bibliotecas existentes no programa off-chain (com ressalvas para compatibilidade com ZK). Nenhuma criptografia personalizada necessária pelo desenvolvedor se estiver usando uma ZKVM geral – eles escrevem código normal e obtêm uma prova. Além disso, a computação pesada pode usar bibliotecas (por exemplo, código de aprendizado de máquina) que nunca seriam executadas on-chain. Contras: Os desenvolvedores devem orquestrar a infraestrutura off-chain ou usar um serviço de prova. Lidar com fluxos de trabalho assíncronos e integrá-los com a lógica on-chain requer mais trabalho de design (por exemplo, armazenar um estado pendente, esperar por um callback). Escrever circuitos eficientes ou código zkVM pode exigir o aprendizado de novas restrições (por exemplo, sem ponto flutuante, usar ponto fixo ou primitivas especiais; evitar ramificações pesadas que aumentam o tempo de prova; otimizar para contagem de restrições). Há também o fardo de lidar com falhas de prova, timeouts, etc., que não são preocupações no Solidity regular. O ecossistema de ferramentas está crescendo, mas é um novo paradigma para muitos.

Ambas as abordagens estão sendo ativamente aprimoradas, e até vemos convergência: como observado, ZKPs são usados dentro de FHE-VMs para certas verificações e, inversamente, alguns pesquisadores propõem o uso de FHE para manter as entradas do provador privadas em ZK (para que um provador na nuvem não veja seus dados secretos). É concebível que sistemas futuros as combinem – por exemplo, realizando FHE off-chain e depois provando a correção disso para a cadeia, ou usando FHE on-chain, mas provando com ZK para clientes leves que as operações criptografadas foram feitas corretamente. Cada técnica tem seus pontos fortes: a FHE-VM oferece privacidade contínua e interação em tempo real ao custo de computação pesada, enquanto os coprocessadores ZK oferecem escalabilidade e flexibilidade ao custo de latência e complexidade.

Casos de Uso e Implicações

O advento da privacidade programável desbloqueia uma riqueza de novas aplicações de blockchain em várias indústrias. Abaixo, exploramos como FHE-VMs e coprocessadores ZK (ou híbridos) podem capacitar vários domínios, permitindo contratos inteligentes que preservam a privacidade e uma economia de dados segura.

DeFi Confidencial e Finanças

Em finanças descentralizadas, a privacidade pode mitigar o front-running, proteger estratégias de negociação e satisfazer a conformidade sem sacrificar a transparência onde necessário. O DeFi Confidencial poderia permitir que os usuários interagissem com protocolos sem revelar suas posições para o mundo.

  • Transações Privadas e Saldos Ocultos: Usando FHE, pode-se implementar transferências de tokens confidenciais (saldos e transações ERC-20 criptografados) ou pools blindados em uma L1 de blockchain. Nenhum observador pode ver quanto de um token você possui ou transferiu, eliminando o risco de ataques direcionados com base em participações. Provas ZK podem garantir que os saldos permaneçam sincronizados e que não ocorra gasto duplo (semelhante ao Zcash, mas em plataformas de contrato inteligente). Um exemplo é um AMM (Criador de Mercado Automatizado) confidencial onde as reservas do pool e as negociações são criptografadas on-chain. Arbitragistas ou front-runners não podem explorar o pool porque não conseguem observar o slippage de preço até que a negociação seja liquidada, reduzindo o MEV. Apenas após algum atraso ou por meio de um mecanismo de controle de acesso, alguns dados podem ser revelados para auditoria.

  • Leilões e Negociações Resistentes a MEV: Mineradores e bots exploram a transparência das transações para fazer front-run em negociações. Com criptografia, você poderia ter um mempool criptografado ou leilões em lote onde as ordens são enviadas em texto cifrado. Apenas depois que o leilão é concluído, as negociações são descriptografadas. Este conceito, às vezes chamado de Fluxo de Ordens Justo, pode ser alcançado com descriptografia de limiar (vários validadores descriptografam coletivamente o lote) ou provando os resultados do leilão via ZK sem revelar lances individuais. Por exemplo, um coprocessador ZK poderia pegar um lote de lances selados off-chain, computar o preço de compensação do leilão e produzir apenas esse preço e os vencedores com provas. Isso preserva a justiça e a privacidade dos lances perdedores.

  • Empréstimos e Derivativos Confidenciais: Em empréstimos DeFi, os usuários podem não querer revelar o tamanho de seus empréstimos ou garantias (isso pode afetar o sentimento do mercado ou convidar à exploração). Uma FHE-VM pode manter um livro de empréstimos criptografado onde os detalhes de cada empréstimo são criptografados. A lógica do contrato inteligente ainda pode aplicar regras como condições de liquidação, operando em fatores de saúde criptografados. Se a proporção de garantia de um empréstimo cair abaixo do limiar, o contrato (com a ajuda de provas ZK) pode sinalizá-lo para liquidação sem nunca expor valores exatos – ele pode apenas produzir um sinalizador sim/não em texto claro. Da mesma forma, posições secretas de derivativos ou opções poderiam ser gerenciadas on-chain, com apenas métricas de risco agregadas reveladas. Isso poderia impedir o copy trading e proteger estratégias proprietárias, incentivando mais participação institucional.

  • Privacidade em Conformidade: Nem todos os contextos financeiros desejam anonimato total; às vezes, a divulgação seletiva é necessária para regulamentação. Com essas ferramentas, podemos alcançar a privacidade regulamentada: por exemplo, as negociações são privadas para o público, mas uma bolsa regulamentada pode descriptografar ou receber provas sobre certas propriedades. Poder-se-ia provar via ZK que “esta negociação não envolveu um endereço na lista negra e ambas as partes são verificadas por KYC” sem revelar identidades para a cadeia. Esse equilíbrio poderia satisfazer as regras de Combate à Lavagem de Dinheiro (AML), mantendo as identidades e posições dos usuários confidenciais para todos os outros. A FHE poderia permitir que um contrato de oficial de conformidade on-chain examinasse transações criptografadas em busca de sinais de risco (com uma chave de descriptografia acessível apenas sob ordem judicial, por exemplo).

Identidade Digital e Dados Pessoais

Os sistemas de identidade têm muito a ganhar com a tecnologia de privacidade on-chain. Atualmente, colocar credenciais ou atributos pessoais em um livro-razão público é impraticável devido às leis de privacidade e à relutância do usuário. Com FHE e ZK, a identidade auto-soberana pode ser realizada de forma a preservar a privacidade:

  • Credenciais de Conhecimento Zero: Usando provas ZK (já comuns em alguns projetos de identidade), um usuário pode provar declarações como “Tenho mais de 18 anos”, “Tenho uma carteira de motorista válida” ou “Ganho acima de $50k (para pontuação de crédito)” sem revelar nenhuma outra informação pessoal. Os coprocessadores ZK podem aprimorar isso lidando com verificações mais complexas off-chain, por exemplo, provando que a pontuação de crédito de um usuário está acima de um limiar, consultando um banco de dados de crédito privado de maneira semelhante à Axiom, produzindo apenas um sim/não para a blockchain.

  • KYC Confidencial em DeFi: Imagine um protocolo DeFi que, por lei, deve garantir que os usuários sejam verificados por KYC. Com a FHE-VM, as credenciais de um usuário podem ser armazenadas criptografadas on-chain (ou referenciadas via DID), e um contrato inteligente pode realizar uma computação FHE para verificar se as informações de KYC atendem aos requisitos. Por exemplo, um contrato poderia verificar homomorficamente se nome e CPF em um perfil de usuário criptografado correspondem a uma lista de usuários sancionados (também criptografada), ou se o país do usuário não é restrito. O contrato obteria apenas um "aprovado/reprovado" criptografado que pode ser descriptografado por limiar pelos validadores da rede para um sinalizador booleano. Apenas o fato de o usuário ser permitido ou não é revelado, preservando a confidencialidade das PII e alinhando-se com os princípios do GDPR. Essa divulgação seletiva garante conformidade e privacidade.

  • Acesso Baseado em Atributos e Divulgação Seletiva: Os usuários poderiam manter um conjunto de credenciais verificáveis (idade, cidadania, habilidades, etc.) como atributos criptografados. Eles podem autorizar certos dApps a executar computações sobre eles sem divulgar tudo. Por exemplo, um DApp de recrutamento descentralizado poderia filtrar candidatos realizando pesquisas em currículos criptografados (usando FHE) – por exemplo, contar anos de experiência, verificar uma certificação – e somente se uma correspondência for encontrada, contatar o candidato off-chain. Os detalhes privados do candidato permanecem criptografados, a menos que ele escolha revelar. As provas ZK também podem permitir que os usuários provem seletivamente que possuem uma combinação de atributos (por exemplo, mais de 21 anos e dentro de um determinado CEP) sem revelar os valores reais.

  • Verificação de Identidade Multi-Partes: Às vezes, a identidade de um usuário precisa ser verificada por várias partes (digamos, verificação de antecedentes pela empresa A, verificação de crédito pela empresa B). Com ferramentas homomórficas e ZK, cada verificador poderia contribuir com uma pontuação ou aprovação criptografada, e um contrato inteligente pode agregá-las a uma decisão final sem expor as contribuições individuais. Por exemplo, três agências fornecem bits "aprovado/reprovado" criptografados, e o contrato produz uma aprovação se todos os três forem aprovados – o usuário ou a parte interessada só vê o resultado final, não qual agência específica pode tê-lo reprovado, preservando a privacidade do registro do usuário em cada agência. Isso pode reduzir o viés e o estigma associados, por exemplo, a uma verificação falha revelando um problema específico.

Saúde e Compartilhamento de Dados Sensíveis

Os dados de saúde são altamente sensíveis e regulamentados, mas a combinação de dados de várias fontes pode desbloquear um valor imenso (para pesquisa, seguros, medicina personalizada). A blockchain poderia fornecer uma camada de confiança para a troca de dados se a privacidade for resolvida. Contratos inteligentes confidenciais poderiam permitir novos ecossistemas de dados de saúde:

  • Troca Segura de Dados Médicos: Os pacientes poderiam armazenar referências a seus registros médicos on-chain de forma criptografada. Um contrato habilitado para FHE poderia permitir que uma instituição de pesquisa executasse análises em um coorte de dados de pacientes sem descriptografá-los. Por exemplo, um contrato poderia calcular a eficácia média de um medicamento em resultados de pacientes criptografados. Apenas resultados estatísticos agregados saem descriptografados (e talvez apenas se um número mínimo de pacientes for incluído, para evitar a reidentificação). Os pacientes poderiam receber micropagamentos por contribuir com seus dados criptografados para pesquisa, sabendo que sua privacidade é preservada porque até mesmo a blockchain e os pesquisadores só veem texto cifrado ou provas agregadas. Isso fomenta um mercado de dados para a saúde que respeita a privacidade.

  • Processamento de Sinistros de Seguro Preservando a Privacidade: O processamento de sinistros de seguro de saúde poderia ser automatizado por meio de contratos inteligentes que verificam condições em dados médicos sem expor os dados à seguradora. Um sinistro poderia incluir um código de diagnóstico criptografado e um custo de tratamento criptografado; o contrato, usando FHE, verifica as regras da apólice (por exemplo, cobertura, franquia) nesses dados criptografados. Ele poderia produzir uma aprovação e um valor de pagamento sem nunca revelar o diagnóstico real para a blockchain da seguradora (apenas o paciente e o médico tinham a chave). Provas ZK poderiam ser usadas para mostrar que os dados do paciente vieram dos registros de um hospital certificado (usando algo como a Axiom para verificar a assinatura ou a inclusão de registro de um hospital) sem revelar o registro em si. Isso garante a privacidade do paciente enquanto previne fraudes.

  • Computação de Dados Genômicos e Pessoais: Dados genômicos são extremamente sensíveis (são literalmente o projeto do DNA de uma pessoa). No entanto, a análise de genomas pode fornecer insights valiosos sobre a saúde. As empresas poderiam usar a FHE-VM para realizar computações em genomas criptografados enviados pelos usuários. Por exemplo, um contrato inteligente poderia executar um modelo de risco gene-ambiente em dados genômicos criptografados e dados ambientais criptografados (de wearables, talvez), produzindo uma pontuação de risco que apenas o usuário pode descriptografar. A lógica (talvez um algoritmo de pontuação de risco poligênico) é codificada no contrato e executada homomorficamente, para que os dados genômicos nunca apareçam em texto claro. Dessa forma, os usuários obtêm insights sem fornecer às empresas dados brutos de DNA – mitigando preocupações tanto de privacidade quanto de propriedade de dados.

  • Epidemiologia e Saúde Pública: Durante situações como pandemias, o compartilhamento de dados é vital para modelar a propagação de doenças, mas as leis de privacidade podem dificultar o compartilhamento de dados. Coprocessadores ZK poderiam permitir que autoridades de saúde pública enviassem consultas como “Quantas pessoas na região X testaram positivo nas últimas 24h?” para uma rede de dados de hospitais por meio de provas. Cada hospital mantém os registros de teste dos pacientes off-chain, mas pode provar ao contrato da autoridade a contagem de positivos sem revelar quem. Da mesma forma, o rastreamento de contatos poderia ser feito combinando trilhas de localização criptografadas: os contratos podem computar interseções de históricos de localização criptografados de pacientes para identificar focos, produzindo apenas as localizações dos focos (e talvez uma lista criptografada de IDs afetados que apenas o departamento de saúde pode descriptografar). As trilhas de localização brutas dos indivíduos permanecem privadas.

Mercados de Dados e Colaboração

A capacidade de computar dados sem revelá-los abre novos modelos de negócios em torno do compartilhamento de dados. Entidades podem colaborar em computações sabendo que seus dados proprietários não serão expostos:

  • Mercados de Dados Seguros: Vendedores podem disponibilizar dados de forma criptografada em um mercado de blockchain. Compradores podem pagar para executar análises específicas ou modelos de aprendizado de máquina no conjunto de dados criptografado por meio de um contrato inteligente, obtendo o modelo treinado ou resultados agregados. Os dados brutos do vendedor nunca são revelados ao comprador ou ao público – o comprador pode receber apenas um modelo (que ainda pode vazar algumas informações nos pesos, mas técnicas como privacidade diferencial ou controle da granularidade da saída podem mitigar isso). Provas ZK podem garantir ao comprador que a computação foi feita corretamente sobre o conjunto de dados prometido (por exemplo, o vendedor não pode trapacear executando o modelo em dados falsos porque a prova o vincula ao conjunto de dados criptografado comprometido). Este cenário incentiva o compartilhamento de dados: por exemplo, uma empresa poderia monetizar dados de comportamento do usuário permitindo que algoritmos aprovados sejam executados neles sob criptografia, sem entregar os próprios dados.

  • Aprendizado Federado e IA Descentralizada: No aprendizado de máquina descentralizado, várias partes (por exemplo, diferentes empresas ou dispositivos) querem treinar conjuntamente um modelo em seus dados combinados sem compartilhar dados entre si. As FHE-VMs se destacam aqui: elas podem permitir o aprendizado federado, onde as atualizações do modelo de cada parte são agregadas homomorficamente por um contrato. Como as atualizações são criptografadas, nenhum participante aprende as contribuições dos outros. O contrato poderia até mesmo realizar partes do ciclo de treinamento (como passos de descida de gradiente) on-chain sob criptografia, produzindo um modelo atualizado que apenas partes autorizadas podem descriptografar. O ZK pode complementar isso provando que a atualização de cada parte foi computada seguindo o algoritmo de treinamento (impedindo que um participante mal-intencionado envenene o modelo). Isso significa que um modelo global pode ser treinado com total auditabilidade on-chain, mas os dados de treinamento de cada contribuinte permanecem privados. Os casos de uso incluem o treinamento conjunto de modelos de detecção de fraude entre bancos ou a melhoria de assistentes de IA usando dados de muitos usuários sem centralizar os dados brutos.

  • Análises Interorganizacionais: Considere duas empresas que desejam encontrar sua interseção de clientes para uma campanha de parceria sem expor suas listas completas de clientes uma à outra. Elas poderiam criptografar suas listas de IDs de clientes e enviar um compromisso. Um contrato habilitado para FHE pode computar a interseção nos conjuntos criptografados (usando técnicas como interseção de conjuntos privados via FHE). O resultado poderia ser uma lista criptografada de IDs de clientes comuns que apenas um terceiro mutuamente confiável (ou os próprios clientes, por algum mecanismo) pode descriptografar. Alternativamente, uma abordagem ZK: uma parte prova à outra em conhecimento zero que “temos N clientes em comum e aqui está uma criptografia desses IDs” com uma prova de que a criptografia de fato corresponde a entradas comuns. Dessa forma, eles podem prosseguir com uma campanha para esses N clientes sem nunca trocar suas listas completas em texto claro. Cenários semelhantes: calcular métricas da cadeia de suprimentos entre concorrentes sem revelar detalhes de fornecedores individuais, ou bancos coletando informações de crédito sem compartilhar dados completos de clientes.

  • Computação Segura Multi-Partes (MPC) em Blockchain: FHE e ZK essencialmente trazem conceitos de MPC para on-chain. Lógicas de negócios complexas abrangendo várias organizações podem ser codificadas em um contrato inteligente de forma que as entradas de cada organização sejam compartilhadas secretamente ou criptografadas. O contrato (como um facilitador de MPC) produz saídas como divisões de lucro, cálculos de custo ou avaliações de risco conjuntas em que todos podem confiar. Por exemplo, suponha que várias empresas de energia queiram liquidar um mercado de negociação de energia. Elas poderiam alimentar seus lances e ofertas criptografados em um leilão de contrato inteligente; o contrato calcula os preços de compensação e as alocações em lances criptografados, e produz a alocação e o custo de cada empresa apenas para essa empresa (via criptografia para sua chave pública). Nenhuma empresa vê os lances das outras, protegendo informações competitivas, mas o resultado do leilão é justo e verificável. Essa combinação de transparência de blockchain e privacidade de MPC poderia revolucionar consórcios e consórcios empresariais que atualmente dependem de terceiros confiáveis.

Aprendizado de Máquina Descentralizado (ZKML e FHE-ML)

Trazer o aprendizado de máquina para blockchains de forma verificável e privada é uma fronteira emergente:

  • Inferência de ML Verificável: Usando provas ZK, pode-se provar que “um modelo de aprendizado de máquina f, quando recebe a entrada x, produz a saída y” sem revelar x (se forem dados privados) ou o funcionamento interno de f (se os pesos do modelo forem proprietários). Isso é crucial para serviços de IA em blockchain – por exemplo, um oráculo de IA descentralizado que fornece previsões ou classificações. Um coprocessador ZK pode executar o modelo off-chain (já que os modelos podem ser grandes e caros de avaliar) e postar uma prova do resultado. Por exemplo, um oráculo poderia provar a declaração “A imagem de satélite fornecida mostra pelo menos 50% de cobertura arbórea” para apoiar um contrato de crédito de carbono, sem revelar a imagem de satélite ou possivelmente até mesmo o modelo. Isso é conhecido como ZKML e projetos estão trabalhando na otimização de redes neurais amigáveis a circuitos. Isso garante a integridade das saídas de IA usadas em contratos inteligentes (sem trapaças ou saídas arbitrárias) e pode preservar a confidencialidade dos dados de entrada e dos parâmetros do modelo.

  • Treinamento com Privacidade e Auditabilidade: Treinar um modelo de ML é ainda mais intensivo em computação, mas se alcançável, permitiria mercados de modelos baseados em blockchain. Vários provedores de dados poderiam contribuir para o treinamento de um modelo sob FHE para que o algoritmo de treinamento seja executado em dados criptografados. O resultado pode ser um modelo criptografado que apenas o comprador pode descriptografar. Durante o treinamento, provas ZK poderiam ser fornecidas periodicamente para provar que o treinamento estava seguindo o protocolo (impedindo que um treinador mal-intencionado insira um backdoor, por exemplo). Embora o treinamento de ML totalmente on-chain esteja longe, dada os custos, uma abordagem híbrida poderia usar computação off-chain com provas ZK para partes críticas. Poder-se-ia imaginar uma competição descentralizada do tipo Kaggle, onde os participantes treinam modelos em conjuntos de dados privados e enviam provas ZK da precisão do modelo em dados de teste criptografados para determinar um vencedor – tudo sem revelar os conjuntos de dados ou os dados de teste.

  • IA Personalizada e Propriedade de Dados: Com essas tecnologias, os usuários poderiam manter a propriedade de seus dados pessoais e ainda se beneficiar da IA. Por exemplo, o dispositivo móvel de um usuário poderia usar FHE para criptografar seus dados de uso e enviá-los para um contrato de análise que computa um modelo de IA personalizado (como um modelo de recomendação) apenas para ele. O modelo é criptografado e apenas o dispositivo do usuário pode descriptografá-lo e usá-lo localmente. A plataforma (talvez uma rede social) nunca vê os dados brutos ou o modelo, mas o usuário obtém o benefício da IA. Se a plataforma quiser insights agregados, ela poderia solicitar provas ZK de certos padrões agregados do contrato sem acessar dados individuais.

Áreas Adicionais

  • Jogos: Jogos on-chain muitas vezes lutam para esconder informações secretas (por exemplo, mãos de cartas ocultas, névoa de guerra em jogos de estratégia). A FHE pode permitir jogos de estado oculto onde a lógica do jogo é executada em estado criptografado. Por exemplo, um contrato de jogo de pôquer poderia embaralhar e distribuir cartas criptografadas; os jogadores recebem as descriptografias de suas próprias cartas, mas o contrato e os outros só veem texto cifrado. A lógica de apostas pode usar provas ZK para garantir que um jogador não esteja blefando sobre uma ação (ou para revelar a mão vencedora no final de forma verificavelmente justa). Da mesma forma, sementes aleatórias para cunhagem de NFT ou resultados de jogos podem ser geradas e provadas justas sem expor a semente (impedindo manipulação). Isso pode aprimorar muito os jogos em blockchain, permitindo que suportem a mesma dinâmica dos jogos tradicionais.

  • Votação e Governança: DAOs poderiam usar tecnologia de privacidade para votações secretas on-chain, eliminando a compra de votos e a pressão. A FHE-VM poderia contar votos que são lançados de forma criptografada, e apenas os totais finais são descriptografados. Provas ZK podem garantir que cada voto foi válido (veio de um eleitor elegível, que não votou duas vezes) sem revelar quem votou em quê. Isso fornece verificabilidade (todos podem verificar as provas e a contagem) enquanto mantém os votos individuais secretos – crucial para uma governança imparcial.

  • Cadeia de Suprimentos Segura e IoT: Em cadeias de suprimentos, os parceiros podem querer compartilhar provas de certas propriedades (origem, métricas de qualidade) sem expor detalhes completos aos concorrentes. Por exemplo, um sensor IoT em uma remessa de alimentos poderia enviar continuamente dados de temperatura criptografados para uma blockchain. Um contrato poderia usar FHE para verificar se a temperatura permaneceu em uma faixa segura durante todo o trânsito. Se um limiar foi excedido, ele pode acionar um alerta ou penalidade, mas não precisa revelar todo o registro de temperatura publicamente – talvez apenas uma prova ou um agregado como “temperatura do 90º percentil”. Isso constrói confiança na automação da cadeia de suprimentos, respeitando a confidencialidade dos dados do processo.

Cada um desses casos de uso aproveita a capacidade central: computar ou verificar dados sem revelar os dados. Essa capacidade pode mudar fundamentalmente como lidamos com informações sensíveis em sistemas descentralizados. Ela reduz o trade-off entre transparência e privacidade que tem limitado a adoção da blockchain em áreas que lidam com dados privados.

Conclusão

A tecnologia blockchain está entrando em uma nova era de privacidade programável, onde a confidencialidade dos dados e a funcionalidade dos contratos inteligentes andam de mãos dadas. Os paradigmas de FHE-VM e coprocessadores ZK, embora tecnicamente distintos, ambos se esforçam para expandir o escopo das aplicações de blockchain, desvinculando o que podemos computar de o que devemos revelar.

As Máquinas Virtuais de Criptografia Totalmente Homomórfica mantêm as computações on-chain e criptografadas, preservando a descentralização e a composabilidade, mas exigindo avanços em eficiência. Os coprocessadores de Conhecimento Zero transferem o trabalho pesado para off-chain, permitindo computação virtualmente ilimitada sob garantias criptográficas, e já estão provando seu valor na escalabilidade e aprimoramento do Ethereum. A escolha entre eles (e seus híbridos) dependerá do caso de uso: se a interação em tempo real com estado privado for necessária, uma abordagem FHE pode ser mais adequada; se uma computação extremamente complexa ou integração com código existente for necessária, um coprocessador ZK pode ser o caminho a seguir. Em muitos casos, eles são complementares – de fato, vemos provas ZK reforçando a integridade da FHE, e a FHE potencialmente ajudando o ZK ao lidar com dados privados para provadores.

Para os desenvolvedores, essas tecnologias introduzirão novos padrões de design. Pensaremos em termos de variáveis criptografadas e verificação de provas como elementos de primeira classe da arquitetura de dApps. As ferramentas estão evoluindo rapidamente: linguagens de alto nível e SDKs estão abstraindo os detalhes criptográficos (por exemplo, as bibliotecas da Zama tornando os tipos FHE tão fáceis quanto os tipos nativos, ou os modelos da RISC Zero para solicitações de prova). Em alguns anos, escrever um contrato inteligente confidencial poderá parecer quase tão simples quanto escrever um regular, apenas com a privacidade "embutida" por padrão.

As implicações para a economia de dados são profundas. Indivíduos e empresas estarão mais dispostos a colocar dados ou lógica on-chain quando puderem controlar sua visibilidade. Isso pode desbloquear colaborações interorganizacionais, novos produtos financeiros e modelos de IA que antes eram inviáveis devido a preocupações com a privacidade. Os reguladores também podem vir a abraçar essas técnicas, pois permitem verificações de conformidade e auditorias por meios criptográficos (por exemplo, provar que os impostos são pagos corretamente on-chain sem expor todas as transações).

Ainda estamos nos primeiros dias – os protótipos atuais de FHE-VM têm limites de desempenho, e as provas ZK, embora muito mais rápidas do que antes, ainda podem ser um gargalo para tarefas extremamente complexas. Mas a pesquisa e os esforços de engenharia contínuos (incluindo hardware especializado, como evidenciado por empresas como a Optalysys impulsionando a aceleração óptica de FHE) estão rapidamente erodindo essas barreiras. O financiamento que está sendo injetado neste espaço (por exemplo, o status de unicórnio da Zama, o investimento da Paradigm na Axiom) ressalta uma forte crença de que os recursos de privacidade serão tão fundamentais para a Web3 quanto a transparência foi para a Web1/2.

Em conclusão, a privacidade programável via FHE-VMs e coprocessadores ZK anuncia uma nova classe de dApps que são trustless, descentralizadas e confidenciais. De negociações DeFi que não revelam detalhes, a pesquisas de saúde que protegem os dados dos pacientes, a modelos de aprendizado de máquina treinados em todo o mundo sem expor dados brutos – as possibilidades são vastas. À medida que essas tecnologias amadurecem, as plataformas de blockchain não mais forçarão o trade-off entre utilidade e privacidade, permitindo uma adoção mais ampla em indústrias que exigem confidencialidade. O futuro da Web3 é um onde usuários e organizações podem transacionar e computar com confiança dados sensíveis on-chain, sabendo que a blockchain verificará a integridade enquanto mantém seus segredos seguros.

Fontes: As informações neste relatório são extraídas da documentação técnica e de blogs de pesquisa recentes de projetos líderes neste espaço, incluindo a documentação da FHEVM da Cypher e da Zama, análises detalhadas da Trail of Bits sobre os circuitos da Axiom, guias de desenvolvedor e postagens de blog da RISC Zero, bem como artigos da indústria destacando casos de uso de tecnologia de blockchain confidencial. Essas e outras fontes foram citadas ao longo do texto para fornecer leitura adicional e evidências para as arquiteturas e aplicações descritas.