Algumas duras verdades sobre blockchain: a privacidade não é compatível com EVM. Contratos inteligentes não são compatíveis com ZKP. Business não é compatível com ERC-20. Então, onde isso deixa você como um negócio ou empresa querendo aproveitar as oportunidades que o blockchain apresenta?

A empresa precisa de privacidade

Esta primeira dura verdade é totalmente compreendida pela comunidade blockchain. Anteriormente, escrevi um artigo dedicado a explicar por que precisamos de privacidade . Se você quiser ler mais sobre por que as empresas precisam de privacidade, posso recomendar essa postagem, bem como as fontes mencionadas lá, que abordam o assunto de forma concisa:

• Katie Haun e Fred Wilson na Web3 "Blockchains como foram originalmente arquitetados são públicos por padrão. Isso não é adequado para a maioria dos aplicativos. Imagine se seu e-mail, banco e dados sociais fossem públicos para todos verem em um blockchain."

• Vitalik Buterin sobre o futuro do Ethereum "O grande desafio futuro para este ecossistema é a privacidade. O status quo envolve colocar grandes quantidades de informações na cadeia, o que é algo que é "bom até que não seja", e eventualmente se tornará intragável se não for totalmente arriscado para mais e mais pessoas."

  
  

Mas a evidência ainda melhor de como a privacidade é crítica para a adoção corporativa do blockchain é a corrida contínua para resolver o problema de privacidade do blockchain. Para citar apenas alguns projetos neste espaço: Aztec . Aleo . Meia-noite . Anoitecer . Oásis . Obscuro . Polígono Miden . Segredo . Luz das estrelas . Zocrates .

Ao longo das minhas declarações iniciais, argumento que nenhum desses projetos está em uma trajetória para resolver os desafios de privacidade do blockchain de uma forma que se adapte à adoção corporativa em um futuro próximo.

A privacidade não é compatível com EVM

Crédito onde o crédito é devido: A declaração “privacidade não é compatível com EVM” vem do Aztec Noir , e eles estão absolutamente certos. A memória e o modelo de execução da Ethereum Virtual Machine (EVM) são todos projetados em torno de um blockchain totalmente público, onde o EVM tem acesso total a todo o estado do blockchain. Canais ou cadeias laterais não resolvem esse problema, ou pelo menos introduzem novos problemas que são pelo menos tão desafiadores quanto a falta de privacidade.

Outra abordagem para evitar a inerente falta de privacidade é executar todo o EVM em um contexto onde ninguém possa acessá-lo - em um ambiente de execução enferrujado (TEE) . A ideia dos TEEs é que você confie nos fabricantes de hardware (fabricantes de CPUs em particular) para manter um canto das CPUs seguro, mesmo dos operadores que têm acesso físico a essas CPUs. Um pouco como os mecanismos de proteção contra cópia para mídia e consoles, ou as prevenções de jailbreak em telefones celulares. Você confia nos fabricantes de hardware para garantir essa segurança? você . Provavelmente . Não deveria .

Acha que as redes blockchain que usam SGX não estão expostas a isso? Pense novamente . Os autores afirmam ter extraído a chave mestra de descriptografia para toda a rede secreta usando esse método. O mundo das criptomoedas não parece se importar; o preço do SCRT mal reagiu a essa notícia. Mas você, como uma empresa responsável, provavelmente deveria. TEEs não são a solução. Eles são desmascarados como um meio eficaz de preservar a privacidade em ambientes de alto risco.

Oasis e Obscuro também usam TEEs, então podem estar no mesmo barco. O Oasis escreveu um post defensivo de sua segurança em relação aos exploits TEE conhecidos, mas os redditors têm suas dúvidas . DYOR.

O ponto principal é: os TEEs já foram violados várias vezes e serão violados novamente. É o esporte sangrento da comunidade de segurança do momento. Se os dados que você confia aos TEEs em máquinas não confiáveis de terceiros forem valiosos o suficiente, é apenas uma questão de tempo até que alguém os extraia.

Os TEEs são uma tecnologia valiosa e podem adicionar muita segurança a um design holístico de segurança em camadas. O CCF da Microsoft ou os serviços de computação confidenciais da IBM são exemplos em que os TEEs são usados em combinação com outras tecnologias de segurança e implantados em hardware de nuvem operado por provedores de serviços confiáveis. Nesse contexto, incentivos, riscos e impactos são mitigados a ponto de os TEEs agregarem muita privacidade genuína e segura.

Simplesmente colocar o EVM em um TEE para um blockchain público não é suficiente. Privacidade não é compatível com EVM.

Contratos inteligentes não são compatíveis com ZKP

As provas de conhecimento zero (ZKP) são uma das áreas mais empolgantes da pesquisa criptográfica atualmente. Sua premissa é atraente. Nos casos em que funcionam, eles realmente parecem funcionar no sentido de preservar a privacidade. O anonimato é um assunto diferente , mas não é o tema deste post.

A primeira coisa a estar ciente é que a grande maioria dos projetos que usam provas de conhecimento zero no mundo blockchain não são focadas na privacidade, mas sim em soluções de escalabilidade. A privacidade é estritamente mais difícil, então quaisquer desafios que você precise resolver para escalabilidade, você também precisa resolver para privacidade, mas há muito mais. É por isso que, na frente de escalabilidade, a corrida é construir o melhor zkEVM, uma versão do EVM capaz de calcular os circuitos e provas necessários para fazer rollups de ZK para a rede principal Ethereum em tempo real. Leia tudo sobre isso no blog de Vitalik Buterin ou neste post da Alchemy .

No entanto, esses projetos “ZK” de escalabilidade podem nos dar uma ideia do principal desafio dessa abordagem: escalabilidade e desempenho. Vamos pegar os números de desempenho do Polygon zkEVM :

"Polygon zkEVM Prover é capaz de validar 500.000 unidades de gás em um único servidor de CPU (64 núcleos) em cerca de 5 minutos."

Uma simples transferência de ETH custa 21.000 gás. Portanto, 64 CPUs podem fazer a prova por cerca de 0,08 TPS. Imagine como isso seria para um contrato inteligente interessante que faz parte de um aplicativo de negócios. Como a privacidade é ainda mais difícil, até onde eu sei, ninguém está tentando fazer zkEVM para privacidade. Privacidade não é compatível com EVM, lembra?

A abordagem adotada por Aztec , Aleo , Polygon Miden , Starlight e outros projetos de privacidade ZKP para contratos inteligentes é projetar linguagens, trans-compiladores e tempos de execução especificamente projetados para gerar circuitos ZKP: Aztec Noir , Aleo's Leo , Miden Assembly , Zocrates .

Todas essas linguagens têm algo em comum:

• Sistemas de tipo nativo restritivo que consistem em números inteiros, booleanos, matrizes de largura fixa e structs
• Semântica surpreendente ou impactos significativos no desempenho até mesmo do fluxo de controle mais simples (if-else)
• Muitos operadores aritméticos e booleanos
• Armadilhas de segurança
• Impossibilidade de auditar se os bugs de segurança foram explorados

A razão para isso é simples. O mecanismo central de transformar uma computação de propósito geral em um contrato inteligente em uma prova de conhecimento zero é convertê-lo em um polinômio que serve como um circuito aritmético. Aqui está uma explicação simples de circuitos aritméticos . As estruturas acima são muito mais sofisticadas do que as descritas naquele explicador, mas ilustram o básico:

1. Converta seu programa em um circuito aritmético - um polinômio
2. O processo de prova fica mais complexo na complexidade do polinômio

Os frameworks ZKP focados na privacidade fazem você desenvolver em linguagens muito mais próximas da aritmética para que os circuitos aritméticos sejam mais simples. O resultado: você, o desenvolvedor, precisa aritmetizar seu aplicativo. O exemplo do navio de guerra de Leo ilustra apropriadamente a ioga de programação necessária. E mesmo com esse esforço extra, a escalabilidade está muito longe de onde deveria estar para aplicativos corporativos complexos.

Então, onde estamos com provas de conhecimento zero e contratos inteligentes?

• Os ZKPs para escalabilidade de contrato inteligente são de pré-produção e mal escalam
• ZKPs para privacidade de contrato inteligente exigem programas expressos em aritmética
• ZKPs para contratos inteligentes não escalam em complexidade, o que é um empecilho para aplicativos não triviais

Contratos inteligentes não são compatíveis com ZKP. Pelo menos ainda não.

A empresa não é compatível com ERC-20

Voltando à afirmação anterior: nos casos em que os ZKPs funcionam, eles realmente parecem funcionar no sentido de preservar a privacidade. O ZCash é o exemplo mais proeminente em que as provas de conhecimento zero são usadas para “proteger” contas de token. A rede pode ver que algo está acontecendo, mas não pode ver quanto você tem em suas contas ou quanto está transferindo para outras contas blindadas. Legal para pagamentos.

A EY e a Polygon anunciaram recentemente o Nightfall 3 e o lançamento do Nightfall Mainnet Beta em maio de 2023. Seu argumento de venda é convincente: a empresa precisa de privacidade de blockchain e agora eles a têm. O blog de anúncios e os vídeos relacionados falam sobre a disrupção de mercados de US$ 50 trilhões, morangos na blockchain e…

• Rastreabilidade

• Prova de autenticidade

• garantia de proveniência

• Reconciliação de dados eficiente

• Pagamentos acessíveis e seguros com liquidação rápida

  
  

O que há realmente na caixa? O princípio é simplesmente explicado: contas blindadas ZCash para tokens ERC-20, 721 e 1155 em um rollup ZK. Paul Brody no vídeo vinculado acima está efetivamente dizendo que toda a indústria automotiva poderia ser rastreada em tokens ERC.

Você acredita nisso? Eu não. Não acredito que o valor do ecossistema criptográfico esteja nos próprios tokens. É nos aplicativos DeFi que vinculam os tokens. As DEXes, pools de liquidez, trocas e jogos. Está nos contratos inteligentes. E em termos de complexidade, todos os negócios que estão acontecendo em blockchains hoje empalidecem em comparação com as finanças tradicionais. Você não pode reduzir isso a tokens fungíveis e NFTs.

Já escrevi sobre por que acho que a tokenização praticada em blockchains hoje não representa os negócios do mundo real de maneira significativa.

Business não é compatível com ERC-20.

Então, onde isso nos deixa?

As empresas financeiras veem as oportunidades em mercados livres de reconciliação e baixa latência. Eles veem a demanda por propriedade direta de ativos e mobilidade de ativos. Eles sentem o fascínio das redes públicas de blockchain. Mas as empresas precisam de contratos inteligentes escaláveis com privacidade real para aproveitar essas oportunidades. Spoiler: aí vem o lance.

Na Digital Asset, trabalhamos incansavelmente para abordar o problema de um ângulo completamente diferente. Em vez de adicionar privacidade a UTXO existente ou modelos de contabilidade baseados em contas usando tecnologia sofisticada, mas comprometida (TEEs) ou criptografia de ponta, mas não escalável (ZKPs), desenvolvemos um modelo de contabilidade (o Daml Ledger Model), protocolo de consenso (Canton) , e linguagem de contrato inteligente (Daml) que trabalham lado a lado para oferecer contratos inteligentes de uso geral com privacidade incomparável, usando criptografia de chave privada completamente padrão e esquemas de assinatura. As empresas estão usando essa tecnologia hoje para resolver problemas do mundo real, movimentando mais valor em ativos TradFi todos os dias do que qualquer rede criptográfica - com privacidade . E sim, também podemos fazer jogos .

Você não precisa perder tempo com PoCs sem saída porque as redes não escalam. Você não precisa executar blockchain theater em cadeias públicas, sincronizando suas negociações em um token ERC-20 após o fato, porque as cadeias públicas não têm a privacidade e os controles necessários para mover seus livros reais para blockchain. Junte-se à crescente rede de organizações que constroem a infra-estrutura financeira escalonável e habilitada para privacidade do futuro em Daml e Canton .