Multi-chain é a tendência de desenvolvimento futuro, e a busca por escalabilidade levou a Ethereum à construção da tecnologia Rollup. Na mudança para blockchains modulares, a atenção voltou a ser dada à Lisk. E em um futuro não muito distante, ouvimos rumores sobre Rollups, L3s e cadeias soberanas específicas de aplicativos. Mas tudo isso terá o custo da fragmentação, e as pontes entre cadeias atuais geralmente têm funcionalidade limitada e dependem de signatários confiáveis para segurança.
Então, como será o Web3 conectado? Acreditamos que as pontes entre cadeias acabarão por evoluir para mensagens entre cadeias ou protocolos "Arbitrary Messaging" (AMP) para desbloquear novos cenários de aplicativos, permitindo que os aplicativos passem mensagens arbitrárias entre a cadeia de origem e a cadeia de destino. Também testemunharemos o surgimento de um "paisagem de mecanismo de confiança", onde os construtores farão várias compensações entre usabilidade, complexidade e segurança.
Toda solução AMP precisa implementar duas funções principais:
Verificação: Capacidade de verificar a validade das mensagens da cadeia de origem na cadeia de destino
Vivacidade: a capacidade de passar informações da cadeia de origem para a cadeia de destino
Infelizmente, a verificação 100% sem confiança não é realista, os usuários devem optar por confiar no código, na teoria dos jogos, em humanos (ou entidades) ou em uma combinação deles, dependendo se a verificação é on-chain ou off-chain.
Neste artigo, dividimos verticalmente o domínio geral da interoperabilidade em mecanismos baseados em confiança e arquiteturas baseadas em integração.
Mecanismo de confiança:
Código de confiança e matemática: para essas soluções, há uma prova na cadeia que qualquer pessoa pode verificar. Essas soluções geralmente dependem de clientes leves para verificar o consenso da cadeia de origem na cadeia de destino ou verificar a validade da transição de estado da cadeia de origem na cadeia de destino. A verificação por meio de clientes leves pode melhorar a eficiência por meio de provas de conhecimento zero, comprimindo cálculos arbitrariamente longos para serem executados offline, ao mesmo tempo em que fornece verificação simples na cadeia para comprovar os resultados do cálculo.
Teoria dos jogos de confiança: quando um usuário/aplicativo precisa confiar em um terceiro ou em uma rede de terceiros para garantir a autenticidade de uma transação, suposições adicionais de confiança estão envolvidas. A segurança desses mecanismos pode ser melhorada pelo emprego de redes sem permissão e teoria dos jogos, como incentivos econômicos e segurança otimista.
Confiança em humanos: Estas soluções contam com a honestidade ou independência de uma maioria de validadores, que comunicam diferentes informações. Além de confiar no consenso das duas cadeias interativas, você também precisa confiar em um terceiro. Neste caso, o único risco é a reputação das entidades participantes. Uma transação é considerada válida se um número suficiente de entidades participantes concordar que ela é válida.
Vale a pena notar que todas as soluções requerem confiança no código e nos humanos até certo ponto. Qualquer solução com código bugado pode ser explorada por hackers, e toda solução tem algum elemento humano na configuração, atualizações ou manutenção da base de código.
Arquitetura de integração:
Modelo ponto a ponto: Um canal de comunicação dedicado precisa ser estabelecido entre cada cadeia de origem e cadeia de destino.
Modelo de hub central: Um canal de comunicação com o hub central precisa ser estabelecido para alcançar a interconexão com todos os outros blockchains conectados ao hub.
O modelo peer-to-peer é relativamente difícil de escalar porque cada blockchain conectado requer um canal de comunicação emparelhado. Desenvolver esses canais pode ser um desafio para blockchains com diferentes consensos e estruturas. No entanto, as pontes emparelhadas oferecem mais flexibilidade para personalizar a configuração, se desejado. Abordagens híbridas também são possíveis, como roteamento multi-hop através de relés usando o protocolo Inter-Blockchain Communication (IBC), que elimina a necessidade de comunicação direta ponto a ponto, mas apresenta mais complexidades em termos de segurança, latência e custo.
Código de confiança e matemática
Para confiar apenas no código/matemática para suposições de confiança, os clientes leves podem ser usados para verificar o consenso da cadeia de origem na cadeia de destino. Clientes/nós leves são softwares que se conectam a nós completos para interagir com o blockchain. Os clientes leves na cadeia de destino geralmente armazenam um histórico (em ordem) dos cabeçalhos dos blocos da cadeia de origem, o que é suficiente para verificar as transações. Um proxy fora da cadeia (como um relé) monitora eventos na cadeia de origem, gera provas criptográficas de inclusão e as encaminha junto com cabeçalhos de bloco para clientes leves na cadeia de destino. Como os clientes leves armazenam cabeçalhos de bloco sequencialmente, cada um contendo um hash raiz Merkle que pode ser usado para provar o estado, eles são capazes de verificar as transações. Aqui está uma visão geral das principais características desta abordagem:
segurança
As suposições de confiança são introduzidas durante a inicialização de clientes leves. Ao criar um novo light client, ele será inicializado em um cabeçalho de bloco de uma altura específica na outra cadeia. No entanto, existe a possibilidade de que os cabeçalhos de bloco fornecidos possam estar incorretos, tornando possível enganar clientes leves com cabeçalhos de bloco forjados. Depois que um cliente leve é inicializado, nenhuma outra suposição de confiança é introduzida. No entanto, vale a pena notar que esse processo de inicialização depende de uma suposição de confiança fraca, pois pode ser verificada por qualquer pessoa. Além disso, há uma suposição de vivacidade para a transmissão contínua de informações do relé.
implementação
A implementação de light clients depende da disponibilidade das primitivas criptográficas necessárias para autenticação. Se o mesmo tipo de cadeia estiver conectado, o que significa que eles compartilham a mesma estrutura de aplicativo e algoritmo de consenso, as implementações de cliente leve em ambas as extremidades serão as mesmas. Por exemplo, todas as cadeias baseadas no Cosmos SDK usam o protocolo Inter-Blockchain Communication (IBC). Por outro lado, implementações como light clients dependem do suporte para as primitivas criptográficas necessárias para autenticação. Se o mesmo tipo de cadeia estiver conectado, ou seja, eles compartilham a mesma estrutura de aplicativo e algoritmo de consenso, as implementações de cliente leve em ambos os lados serão as mesmas. Por exemplo, o protocolo Inter-Blockchain Communication (IBC) é usado para todas as cadeias baseadas em SDK do Cosmos. Por outro lado, se dois tipos diferentes de cadeias estiverem conectados, como diferentes estruturas de aplicativos ou tipos de consenso, a implementação do light client será diferente. Um exemplo é a Composable Finance, que está trabalhando para conectar a cadeia Cosmos SDK à estrutura de aplicativos Substrate do ecossistema Polkadot via IBC. Isso requer um cliente light Tendermint na cadeia Substrate e um cliente light "beefy" na cadeia Cosmos SDK. Recentemente, eles estabeleceram a primeira conexão entre Polkadot e Kusama via IBC.
desafio
A intensidade de recursos é um desafio importante. A execução de pares de clientes leves em todas as cadeias pode ser cara porque as gravações no blockchain são caras. Além disso, a intensidade de recursos com verificadores dinâmicos é um desafio importante. Pode ser caro executar clientes leves emparelhados em todas as cadeias porque as gravações no blockchain são caras. Além disso, para cadeias com conjuntos de validadores dinâmicos (como Ethereum), não é viável executar clientes leves.
A escalabilidade é outro desafio. A implementação de light clients varia de acordo com a arquitetura da cadeia, o que dificulta escalar e conectar diferentes ecossistemas.
Vulnerabilidades de código são um risco potencial porque bugs no código podem levar a vulnerabilidades. Por exemplo, a violação da cadeia BNB em outubro de 2022 revelou uma falha crítica de segurança que afeta todas as cadeias habilitadas para IBC.
Para abordar o custo e a praticidade de executar clientes leves emparelhados em todas as cadeias, soluções alternativas, como provas de conhecimento zero (ZK), podem ser empregadas para remover a necessidade de confiança de terceiros.
Provas de conhecimento zero como solução para a confiança de terceiros
As provas de conhecimento zero podem ser usadas para verificar a validade das transições de estado da cadeia de origem na cadeia de destino. Em comparação com a execução de toda a computação na cadeia, as provas do ZK executam apenas a parte de verificação da computação na cadeia, enquanto a computação real ocorre fora da cadeia. Essa abordagem permite uma verificação mais rápida e eficiente do que executar novamente a computação original. Alguns exemplos incluem Polymer ZK-IBC da Polymer Labs e Telepathy da Sucinct Labs. A Polymer está desenvolvendo IBCs multi-hop para aprimorar a conectividade e reduzir o número de conexões emparelhadas necessárias.
Os principais aspectos do mecanismo incluem:
segurança
A segurança dos zk-SNARKs depende de curvas elípticas, enquanto os zk-STARKs dependem de funções hash. zk-SNARKs podem exigir uma configuração confiável, incluindo a criação de chaves iniciais usadas para gerar provas usadas na verificação. A chave é destruir o segredo do evento de configuração para evitar que as transações sejam autenticadas por falsificação. Depois que a configuração confiável estiver concluída, nenhuma outra suposição de confiança será introduzida. Além disso, estruturas ZK mais recentes, como Halo e Halo2, eliminam completamente a necessidade de uma configuração confiável.
implementação
Há uma variedade de esquemas de comprovação de ZK, como SNARK, STARK, VPD e SNARG, e SNARK é atualmente o mais amplamente utilizado. Diferentes estruturas de prova do SNARK, como Groth16, Plonk, Marlin, Halo e Halo2, oferecem compensações em termos de tamanho da prova, tempo de prova, tempo de verificação, requisitos de memória e requisitos de configuração confiáveis. As provas ZK recursivas também surgiram, permitindo que a carga de trabalho da prova seja distribuída em vários computadores em vez de um único. Para gerar provas de validade, as seguintes primitivas principais devem ser implementadas: verificar o esquema de assinatura usado por um validador, armazenar provas da chave pública do validador no compromisso do conjunto de validadores armazenado na cadeia e rastrear o conjunto do validador, que pode mudar com frequência.
desafio
A implementação de vários esquemas de assinatura em zkSNARKs requer a implementação de operações aritméticas fora do domínio e curvas elípticas complexas, o que não é trivial e pode exigir diferentes implementações, dependendo da estrutura e do consenso de diferentes cadeias. A auditoria de circuitos ZK é uma tarefa desafiadora e propensa a erros. Os desenvolvedores precisam estar familiarizados com linguagens específicas de domínio, como Circom, Cairo e Noir, ou implementar circuitos diretamente, os quais podem ser desafiadores e podem retardar a adoção. Se o tempo e o esforço forem muito elevados, podem ser tratados apenas por equipes dedicadas e hardware dedicado, levando potencialmente à centralização. Tempos de geração de prova mais longos também causam atrasos. Técnicas como a Computação Incremental Verificável (IVC) podem otimizar os tempos de prova, mas muitas delas ainda estão em fase de pesquisa, aguardando implementação. Tempos de verificação e cargas de trabalho mais longos aumentarão os custos na cadeia.
Confie na Teoria dos Jogos
Os protocolos de interoperabilidade baseados na teoria dos jogos podem ser amplamente divididos em duas categorias, de acordo com a forma como incentivam o comportamento honesto das entidades participantes:
A primeira categoria é um mecanismo de segurança econômica no qual vários atores externos (como validadores) cooperam para chegar a um consenso para determinar o estado atualizado da cadeia de origem. Para se tornar um validador, os participantes precisam apostar uma certa quantidade de tokens, que podem ser reduzidos em caso de atividade maliciosa. Em uma configuração sem permissão, qualquer pessoa pode acumular participação e se tornar um validador. Além disso, incentivos econômicos, como recompensas em bloco, são fornecidos aos validadores que seguem o protocolo para garantir incentivos econômicos por comportamento honesto. No entanto, se o valor potencialmente roubado exceder o valor apostado, os participantes podem conspirar para roubar fundos. Exemplos de protocolos que usam mecanismos de segurança econômicos incluem Axelar e Celer IM.
A segunda categoria são os mecanismos de segurança otimistas, onde a solução se baseia na suposição de que apenas um pequeno número de participantes da blockchain é honesto e obedece às regras do protocolo. Nessa abordagem, um participante honesto atua como uma garantia. Por exemplo, uma solução ótima permite que qualquer pessoa envie provas de fraude. Embora haja um incentivo financeiro, um observador honesto pode perder uma transação fraudulenta. Rollups otimistas também usam esse mecanismo. Nomad e ChainLink CCIP são exemplos de protocolos que utilizam mecanismos de segurança otimistas. No caso do Nomad, os observadores conseguiram provar a fraude, embora estejam na lista de permissões no momento da redação. ChainLink CCIP planeja utilizar uma rede antifraude que consiste em uma rede distribuída de oráculos para detectar atividades maliciosas, embora a implementação da rede antifraude do CCIP seja desconhecida.
segurança
Em termos de segurança, ambos os mecanismos contam com a participação sem permissão de verificadores e observadores para garantir a validade da teoria dos jogos. Em um mecanismo de segurança econômica, os fundos ficam mais vulneráveis se o valor apostado for menor do que o valor que poderia ser roubado. Por outro lado, em mecanismos de segurança otimistas, a suposição de confiança minoritária pode ser explorada se ninguém apresentar uma prova de fraude ou se os observadores de permissão forem comprometidos ou removidos. Em contraste, os mecanismos de segurança econômica são menos dependentes da vitalidade para manter a segurança.
implementação
Em termos de implementação, uma abordagem envolve uma cadeia intermediária com seus próprios validadores. Nessa configuração, um grupo de validadores externos monitora a cadeia de origem e chega a um consenso sobre a validade de uma transação quando uma invocação é detectada. Uma vez alcançado o consenso, eles fornecem provas na cadeia-alvo. Os validadores geralmente precisam apostar uma certa quantidade de tokens, que podem ser reduzidos se uma atividade maliciosa for detectada. Exemplos de protocolos que usam esse método de implementação incluem Axelar Network e Celer IM.
Outro método de implementação envolve o uso de proxies off-chain. Proxies off-chain são usados para implementar soluções otimistas do tipo Rollups. Dentro de uma janela de tempo predefinida, esses proxies off-chain podem enviar provas de fraude e reverter transações, se necessário. Por exemplo, o Nomad depende de proxies off-chain independentes para retransmitir cabeçalhos e provas criptográficas. Por outro lado, a ChainLink CCIP planeja alavancar sua rede existente de oráculos para monitorar e atestar transações entre cadeias.
Vantagens e Desafios
Uma das principais vantagens das soluções AMP com teoria de jogo é a otimização de recursos, já que o processo de verificação geralmente é fora da cadeia, reduzindo os requisitos de recursos. Além disso, esses mecanismos são escaláveis, pois o mecanismo de consenso permanece o mesmo para vários tipos de cadeias e pode ser facilmente estendido para blockchains heterogêneos.
Existem também vários desafios associados a esses mecanismos. Se a maioria dos validadores conspirar, as suposições de confiança podem ser exploradas para roubar fundos, exigindo contramedidas como votação quadrática e provas de fraude. Além disso, soluções baseadas em segurança otimista apresentam complexidades em termos de finalidade e vivacidade, pois usuários e aplicativos precisam aguardar janelas fraudulentas para garantir a validade das transações.
Confie nos Humanos
As soluções que exigem confiança em entidades humanas também podem ser amplamente divididas em duas categorias:
Segurança reputacional: essas soluções dependem de implementações de assinatura múltipla, em que várias entidades verificam e assinam transações. Uma vez atingido o limite mínimo, a transação é considerada válida. A suposição aqui é que a maioria das entidades é honesta e, se a maioria dessas entidades assinar uma transação específica, essa transação é válida. A única coisa em risco aqui é a reputação das entidades envolvidas. Alguns exemplos incluem Multichain (Anycall V6) e Wormhole. Ainda podem existir vulnerabilidades devido a vulnerabilidades de contratos inteligentes, conforme demonstrado pelo hack do Wormhole no início de 2022.
Independência: Essas soluções dividem todo o processo de mensagens em duas partes e dependem de diferentes entidades independentes para gerenciar os dois processos. A suposição aqui é que essas duas entidades são independentes uma da outra e não podem entrar em conluio. LayerZero é um exemplo. Os cabeçalhos de bloco são transmitidos sob demanda por meio de oráculos distribuídos e as provas de transação são enviadas por retransmissores. Se a prova corresponder ao cabeçalho, a transação é considerada válida. Embora provar uma correspondência dependa de código/matemática, os participantes precisam confiar que essas entidades permanecem independentes e não têm intenções maliciosas. Os aplicativos construídos no LayerZero podem escolher seus oráculos e retransmissores (ou hospedar seus próprios oráculos/retransmissores), limitando assim o risco a oráculos/retransmissores individuais. Os usuários finais precisam confiar que o LayerZero, terceiros ou o próprio aplicativo estão executando oráculos e retransmissores de forma independente, sem intenção maliciosa.
Em ambas as abordagens, a reputação das entidades terceirizadas participantes impede o comportamento malicioso. Geralmente, essas entidades são respeitadas na comunidade de validadores e oráculos e, se se comportarem maliciosamente, correm o risco de causar danos à reputação e causar impacto negativo em outras atividades comerciais.
Considerações adicionais para soluções AMP
Ao considerar a segurança e a usabilidade de uma solução AMP, também precisamos considerar detalhes além da mecânica básica. Como esses são componentes que podem mudar com o tempo, não os incluímos na comparação geral.
Integridade do código
Hacks recentes exploraram erros de código, destacando a necessidade de auditoria robusta, recompensas de bugs e diversas implementações de cliente. Se todos os verificadores (em segurança econômica/otimista/reputacional) executarem o mesmo cliente (software para verificação), isso aumentará a dependência de uma única base de código e reduzirá a diversidade de clientes. Por exemplo, Ethereum depende de vários clientes de execução, como geth, netermind, erigon, besu, akula. Várias implementações em vários idiomas podem aumentar a diversidade, sem que nenhum cliente domine a rede, eliminando um possível ponto único de falha. Ter vários clientes também pode ajudar a manter a atividade no caso de um pequeno número de validadores/signatários/clientes light falhar devido a um bug/ataque em uma implementação específica.
Configuração e capacidade de atualização
Os usuários e desenvolvedores precisam saber se os validadores/observadores podem ingressar na rede sem permissão, caso contrário, a confiança será ocultada pelas entidades que escolherem a permissão. As atualizações para contratos inteligentes também podem introduzir vulnerabilidades que podem levar a ataques e possivelmente até alterar as suposições de confiança. Diferentes soluções podem ser implementadas para mitigar esses riscos. Por exemplo, na instanciação atual, o gateway Axelar pode ser atualizado, mas requer aprovação do comitê off-line (limite de 4/8). Os principais contratos do Wormhole são atualizáveis e gerenciados por meio do sistema de governança on-chain do Wormhole. LayerZero depende de contratos inteligentes imutáveis e bibliotecas imutáveis para evitar atualizações, mas novas bibliotecas podem ser enviadas, dapps que definem configurações padrão obterão versões mais recentes, dapps que definem manualmente a versão precisam defini-la para a nova versão.
Valor Máximo Extraível (MEV)
Diferentes blockchains não são sincronizados por um relógio comum e têm diferentes tempos de finalidade. Portanto, a ordem de execução e o tempo na cadeia de destino podem variar de cadeia para cadeia. Em um mundo de cadeia cruzada, MEV é difícil de definir claramente. Ele introduz uma troca entre vivacidade e ordem de execução. Um canal ordenado garantirá a entrega de mensagens em ordem, mas se uma mensagem expirar, o canal será fechado. Outro aplicativo pode preferir não solicitar, mas a entrega de outras mensagens não é afetada.
Certeza da cadeia de origem
Idealmente, as soluções AMP devem esperar que a cadeia de origem atinja a finalidade antes de transmitir as informações de estado da cadeia de origem para uma ou mais cadeias de destino. Isso garantirá que os blocos na cadeia de origem dificilmente possam ser revertidos ou alterados. No entanto, muitas soluções fornecem mensagens instantâneas e fazem suposições de confiança sobre a finalidade para fornecer a melhor experiência ao usuário. Nesse caso, se a cadeia de origem sofrer uma reversão de estado após a entrega da mensagem e a passagem do ativo ponte, isso pode levar a situações como o gasto duplo dos fundos ponte. As soluções AMP podem gerenciar esse risco de várias maneiras, como definindo diferentes suposições de finalidade para diferentes cadeias, dependendo de quão descentralizada é a cadeia ou fazendo compensações entre velocidade e segurança. As pontes que utilizam soluções AMP podem definir limites na quantidade de ativos interligados antes que a cadeia de origem atinja a finalidade.
Tendências e perspectivas futuras Segurança personalizável e anexável
Para atender melhor a diversos casos de uso, as soluções AMP são incentivadas a fornecer mais flexibilidade aos desenvolvedores. A Axelar apresenta um método para permitir escalabilidade de mensagens e validação sem alterar a lógica da camada de aplicativos. O HyperLane V2 apresenta módulos que permitem aos desenvolvedores escolher entre várias opções, como segurança econômica, segurança otimista, segurança dinâmica e segurança híbrida. O CelerIM fornece segurança otimista adicional além da segurança econômica. Muitas soluções esperam por um número mínimo predefinido de confirmações de bloco na cadeia de origem antes de entregar uma mensagem. LayerZero permite que os desenvolvedores atualizem esses parâmetros. Esperamos que algumas soluções AMP continuem a oferecer mais flexibilidade, mas essas opções de design requerem alguma discussão. Os aplicativos devem ser capazes de configurar sua segurança, até que ponto e o que acontece se os aplicativos forem arquitetados com um design abaixo do ideal? A conscientização do usuário sobre os conceitos fundamentais por trás da segurança provavelmente se tornará cada vez mais importante. Em última análise, prevemos agregação e abstração de soluções AMP, possivelmente na forma de alguma forma de composição ou segurança "add-on".
A maturidade do mecanismo "código de confiança e matemática"
Em um estágio final ideal, todas as mensagens de cadeia cruzada serão minimizadas pela confiança por meio do uso de provas de conhecimento zero (ZK). Vimos projetos semelhantes como o Polymer Labs e o Sucinct Labs surgirem. A Multichain também publicou um white paper do zkRouter sobre interoperabilidade por meio de provas do ZK. Com a recém-anunciada Axelar Virtual Machine, os desenvolvedores podem aproveitar o Interchain Amplifier para estabelecer novas conexões com a rede Axelar sem permissão. Por exemplo, uma vez que os clientes leves fortes e as provas ZK são desenvolvidas para o estado do Ethereum, os desenvolvedores podem integrá-los facilmente à rede Axelar para substituir ou aprimorar as conexões existentes. A Celer Network anunciou o Brevis, uma plataforma de prova de dados de cadeia cruzada ZK que permite que dApps e contratos inteligentes acessem, calculem e utilizem dados arbitrários em vários blockchains. A Celer implementou um ativo zkBridge orientado ao usuário usando o circuito ZK light client para cross-chain entre a rede de teste Ethereum Goerli e a rede de teste BNB Chain. LayerZero discute em sua documentação a possibilidade de adicionar novas bibliotecas de mensagens de prova otimizadas no futuro. Projetos mais recentes, como o Lagrange, estão explorando a agregação de várias provas de várias cadeias de origem, enquanto o Herodotus possibilita o armazenamento de provas com as provas ZK. No entanto, essa transição levará tempo, pois é difícil escalar essa abordagem em blockchains que dependem de diferentes mecanismos e estruturas de consenso.
ZK é uma tecnologia relativamente nova e complexa que é difícil de auditar, e os custos atuais de verificação e geração de provas não são ideais. Acreditamos que, a longo prazo, para oferecer suporte a aplicativos de cadeia cruzada altamente escaláveis em blockchains, muitas soluções AMP provavelmente combinarão software verificável com pessoas e entidades confiáveis porque:
Por meio de auditoria e recompensas de bugs, a possibilidade de exploração de código pode ser minimizada. Com o tempo, ficará mais fácil confiar nesses sistemas, pois seu histórico se torna uma prova de sua segurança.
O custo de geração de provas ZK será reduzido. Com mais pesquisa e desenvolvimento em ZKPs, ZKPs recursivos, agregação de provas, esquemas de dobragem e hardware especializado, esperamos que o custo de geração e verificação de provas diminua substancialmente, tornando-o uma abordagem mais econômica.
O blockchain se tornará mais favorável ao ZK. No futuro, o zkEVM será capaz de fornecer provas sucintas da validade da execução, e soluções leves baseadas em cliente poderão verificar facilmente a execução e o consenso da cadeia de origem. Na fase final do Ethereum, também está planejado "zk-SNARK tudo", incluindo o mecanismo de consenso.
Prova Humana, Reputação e Identidade
A segurança de um sistema complexo como uma solução AMP não pode ser encapsulada apenas por uma única estrutura e requer uma solução multicamadas. Por exemplo, além dos incentivos econômicos, a Axelar implementa um mecanismo de votação quadrática para evitar a concentração do poder de voto entre um subconjunto de nós e promover a descentralização. Outras provas humanas, reputações e identidades também podem complementar os mecanismos de configuração e permissão.
para concluir
No espírito aberto da Web3, podemos vislumbrar um futuro pluralista onde coexistem múltiplas abordagens. Na verdade, um aplicativo pode optar por usar várias soluções de interoperabilidade, seja de maneira redundante ou para que o usuário escolha uma combinação baseada em compensações. Entre as rotas de "alto tráfego", as soluções ponto a ponto podem ser priorizadas, enquanto os modelos hub-and-spoke podem dominar a cauda longa da cadeia. Por fim, nós, como uma comunidade de usuários, construtores e colaboradores, moldaremos a forma básica da Internet Web3.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Como uma interpretação aprofundada de protocolos de mensagens arbitrárias resolve o problema de confiança de interoperabilidade?
Autor: Shi Khai Wei, Raghav Agarwal
Compilação: Kxp, BlockBeats
Introdução
Multi-chain é a tendência de desenvolvimento futuro, e a busca por escalabilidade levou a Ethereum à construção da tecnologia Rollup. Na mudança para blockchains modulares, a atenção voltou a ser dada à Lisk. E em um futuro não muito distante, ouvimos rumores sobre Rollups, L3s e cadeias soberanas específicas de aplicativos. Mas tudo isso terá o custo da fragmentação, e as pontes entre cadeias atuais geralmente têm funcionalidade limitada e dependem de signatários confiáveis para segurança.
Então, como será o Web3 conectado? Acreditamos que as pontes entre cadeias acabarão por evoluir para mensagens entre cadeias ou protocolos "Arbitrary Messaging" (AMP) para desbloquear novos cenários de aplicativos, permitindo que os aplicativos passem mensagens arbitrárias entre a cadeia de origem e a cadeia de destino. Também testemunharemos o surgimento de um "paisagem de mecanismo de confiança", onde os construtores farão várias compensações entre usabilidade, complexidade e segurança.
Toda solução AMP precisa implementar duas funções principais:
Infelizmente, a verificação 100% sem confiança não é realista, os usuários devem optar por confiar no código, na teoria dos jogos, em humanos (ou entidades) ou em uma combinação deles, dependendo se a verificação é on-chain ou off-chain.
Neste artigo, dividimos verticalmente o domínio geral da interoperabilidade em mecanismos baseados em confiança e arquiteturas baseadas em integração.
Mecanismo de confiança:
Código de confiança e matemática: para essas soluções, há uma prova na cadeia que qualquer pessoa pode verificar. Essas soluções geralmente dependem de clientes leves para verificar o consenso da cadeia de origem na cadeia de destino ou verificar a validade da transição de estado da cadeia de origem na cadeia de destino. A verificação por meio de clientes leves pode melhorar a eficiência por meio de provas de conhecimento zero, comprimindo cálculos arbitrariamente longos para serem executados offline, ao mesmo tempo em que fornece verificação simples na cadeia para comprovar os resultados do cálculo.
Teoria dos jogos de confiança: quando um usuário/aplicativo precisa confiar em um terceiro ou em uma rede de terceiros para garantir a autenticidade de uma transação, suposições adicionais de confiança estão envolvidas. A segurança desses mecanismos pode ser melhorada pelo emprego de redes sem permissão e teoria dos jogos, como incentivos econômicos e segurança otimista.
Confiança em humanos: Estas soluções contam com a honestidade ou independência de uma maioria de validadores, que comunicam diferentes informações. Além de confiar no consenso das duas cadeias interativas, você também precisa confiar em um terceiro. Neste caso, o único risco é a reputação das entidades participantes. Uma transação é considerada válida se um número suficiente de entidades participantes concordar que ela é válida.
Vale a pena notar que todas as soluções requerem confiança no código e nos humanos até certo ponto. Qualquer solução com código bugado pode ser explorada por hackers, e toda solução tem algum elemento humano na configuração, atualizações ou manutenção da base de código.
Arquitetura de integração:
Modelo ponto a ponto: Um canal de comunicação dedicado precisa ser estabelecido entre cada cadeia de origem e cadeia de destino.
Modelo de hub central: Um canal de comunicação com o hub central precisa ser estabelecido para alcançar a interconexão com todos os outros blockchains conectados ao hub.
O modelo peer-to-peer é relativamente difícil de escalar porque cada blockchain conectado requer um canal de comunicação emparelhado. Desenvolver esses canais pode ser um desafio para blockchains com diferentes consensos e estruturas. No entanto, as pontes emparelhadas oferecem mais flexibilidade para personalizar a configuração, se desejado. Abordagens híbridas também são possíveis, como roteamento multi-hop através de relés usando o protocolo Inter-Blockchain Communication (IBC), que elimina a necessidade de comunicação direta ponto a ponto, mas apresenta mais complexidades em termos de segurança, latência e custo.
Código de confiança e matemática
Para confiar apenas no código/matemática para suposições de confiança, os clientes leves podem ser usados para verificar o consenso da cadeia de origem na cadeia de destino. Clientes/nós leves são softwares que se conectam a nós completos para interagir com o blockchain. Os clientes leves na cadeia de destino geralmente armazenam um histórico (em ordem) dos cabeçalhos dos blocos da cadeia de origem, o que é suficiente para verificar as transações. Um proxy fora da cadeia (como um relé) monitora eventos na cadeia de origem, gera provas criptográficas de inclusão e as encaminha junto com cabeçalhos de bloco para clientes leves na cadeia de destino. Como os clientes leves armazenam cabeçalhos de bloco sequencialmente, cada um contendo um hash raiz Merkle que pode ser usado para provar o estado, eles são capazes de verificar as transações. Aqui está uma visão geral das principais características desta abordagem:
segurança
As suposições de confiança são introduzidas durante a inicialização de clientes leves. Ao criar um novo light client, ele será inicializado em um cabeçalho de bloco de uma altura específica na outra cadeia. No entanto, existe a possibilidade de que os cabeçalhos de bloco fornecidos possam estar incorretos, tornando possível enganar clientes leves com cabeçalhos de bloco forjados. Depois que um cliente leve é inicializado, nenhuma outra suposição de confiança é introduzida. No entanto, vale a pena notar que esse processo de inicialização depende de uma suposição de confiança fraca, pois pode ser verificada por qualquer pessoa. Além disso, há uma suposição de vivacidade para a transmissão contínua de informações do relé.
implementação
A implementação de light clients depende da disponibilidade das primitivas criptográficas necessárias para autenticação. Se o mesmo tipo de cadeia estiver conectado, o que significa que eles compartilham a mesma estrutura de aplicativo e algoritmo de consenso, as implementações de cliente leve em ambas as extremidades serão as mesmas. Por exemplo, todas as cadeias baseadas no Cosmos SDK usam o protocolo Inter-Blockchain Communication (IBC). Por outro lado, implementações como light clients dependem do suporte para as primitivas criptográficas necessárias para autenticação. Se o mesmo tipo de cadeia estiver conectado, ou seja, eles compartilham a mesma estrutura de aplicativo e algoritmo de consenso, as implementações de cliente leve em ambos os lados serão as mesmas. Por exemplo, o protocolo Inter-Blockchain Communication (IBC) é usado para todas as cadeias baseadas em SDK do Cosmos. Por outro lado, se dois tipos diferentes de cadeias estiverem conectados, como diferentes estruturas de aplicativos ou tipos de consenso, a implementação do light client será diferente. Um exemplo é a Composable Finance, que está trabalhando para conectar a cadeia Cosmos SDK à estrutura de aplicativos Substrate do ecossistema Polkadot via IBC. Isso requer um cliente light Tendermint na cadeia Substrate e um cliente light "beefy" na cadeia Cosmos SDK. Recentemente, eles estabeleceram a primeira conexão entre Polkadot e Kusama via IBC.
desafio
A intensidade de recursos é um desafio importante. A execução de pares de clientes leves em todas as cadeias pode ser cara porque as gravações no blockchain são caras. Além disso, a intensidade de recursos com verificadores dinâmicos é um desafio importante. Pode ser caro executar clientes leves emparelhados em todas as cadeias porque as gravações no blockchain são caras. Além disso, para cadeias com conjuntos de validadores dinâmicos (como Ethereum), não é viável executar clientes leves.
A escalabilidade é outro desafio. A implementação de light clients varia de acordo com a arquitetura da cadeia, o que dificulta escalar e conectar diferentes ecossistemas.
Vulnerabilidades de código são um risco potencial porque bugs no código podem levar a vulnerabilidades. Por exemplo, a violação da cadeia BNB em outubro de 2022 revelou uma falha crítica de segurança que afeta todas as cadeias habilitadas para IBC.
Para abordar o custo e a praticidade de executar clientes leves emparelhados em todas as cadeias, soluções alternativas, como provas de conhecimento zero (ZK), podem ser empregadas para remover a necessidade de confiança de terceiros.
Provas de conhecimento zero como solução para a confiança de terceiros
As provas de conhecimento zero podem ser usadas para verificar a validade das transições de estado da cadeia de origem na cadeia de destino. Em comparação com a execução de toda a computação na cadeia, as provas do ZK executam apenas a parte de verificação da computação na cadeia, enquanto a computação real ocorre fora da cadeia. Essa abordagem permite uma verificação mais rápida e eficiente do que executar novamente a computação original. Alguns exemplos incluem Polymer ZK-IBC da Polymer Labs e Telepathy da Sucinct Labs. A Polymer está desenvolvendo IBCs multi-hop para aprimorar a conectividade e reduzir o número de conexões emparelhadas necessárias.
Os principais aspectos do mecanismo incluem:
segurança
A segurança dos zk-SNARKs depende de curvas elípticas, enquanto os zk-STARKs dependem de funções hash. zk-SNARKs podem exigir uma configuração confiável, incluindo a criação de chaves iniciais usadas para gerar provas usadas na verificação. A chave é destruir o segredo do evento de configuração para evitar que as transações sejam autenticadas por falsificação. Depois que a configuração confiável estiver concluída, nenhuma outra suposição de confiança será introduzida. Além disso, estruturas ZK mais recentes, como Halo e Halo2, eliminam completamente a necessidade de uma configuração confiável.
implementação
Há uma variedade de esquemas de comprovação de ZK, como SNARK, STARK, VPD e SNARG, e SNARK é atualmente o mais amplamente utilizado. Diferentes estruturas de prova do SNARK, como Groth16, Plonk, Marlin, Halo e Halo2, oferecem compensações em termos de tamanho da prova, tempo de prova, tempo de verificação, requisitos de memória e requisitos de configuração confiáveis. As provas ZK recursivas também surgiram, permitindo que a carga de trabalho da prova seja distribuída em vários computadores em vez de um único. Para gerar provas de validade, as seguintes primitivas principais devem ser implementadas: verificar o esquema de assinatura usado por um validador, armazenar provas da chave pública do validador no compromisso do conjunto de validadores armazenado na cadeia e rastrear o conjunto do validador, que pode mudar com frequência.
desafio
A implementação de vários esquemas de assinatura em zkSNARKs requer a implementação de operações aritméticas fora do domínio e curvas elípticas complexas, o que não é trivial e pode exigir diferentes implementações, dependendo da estrutura e do consenso de diferentes cadeias. A auditoria de circuitos ZK é uma tarefa desafiadora e propensa a erros. Os desenvolvedores precisam estar familiarizados com linguagens específicas de domínio, como Circom, Cairo e Noir, ou implementar circuitos diretamente, os quais podem ser desafiadores e podem retardar a adoção. Se o tempo e o esforço forem muito elevados, podem ser tratados apenas por equipes dedicadas e hardware dedicado, levando potencialmente à centralização. Tempos de geração de prova mais longos também causam atrasos. Técnicas como a Computação Incremental Verificável (IVC) podem otimizar os tempos de prova, mas muitas delas ainda estão em fase de pesquisa, aguardando implementação. Tempos de verificação e cargas de trabalho mais longos aumentarão os custos na cadeia.
Confie na Teoria dos Jogos
Os protocolos de interoperabilidade baseados na teoria dos jogos podem ser amplamente divididos em duas categorias, de acordo com a forma como incentivam o comportamento honesto das entidades participantes:
A primeira categoria é um mecanismo de segurança econômica no qual vários atores externos (como validadores) cooperam para chegar a um consenso para determinar o estado atualizado da cadeia de origem. Para se tornar um validador, os participantes precisam apostar uma certa quantidade de tokens, que podem ser reduzidos em caso de atividade maliciosa. Em uma configuração sem permissão, qualquer pessoa pode acumular participação e se tornar um validador. Além disso, incentivos econômicos, como recompensas em bloco, são fornecidos aos validadores que seguem o protocolo para garantir incentivos econômicos por comportamento honesto. No entanto, se o valor potencialmente roubado exceder o valor apostado, os participantes podem conspirar para roubar fundos. Exemplos de protocolos que usam mecanismos de segurança econômicos incluem Axelar e Celer IM.
A segunda categoria são os mecanismos de segurança otimistas, onde a solução se baseia na suposição de que apenas um pequeno número de participantes da blockchain é honesto e obedece às regras do protocolo. Nessa abordagem, um participante honesto atua como uma garantia. Por exemplo, uma solução ótima permite que qualquer pessoa envie provas de fraude. Embora haja um incentivo financeiro, um observador honesto pode perder uma transação fraudulenta. Rollups otimistas também usam esse mecanismo. Nomad e ChainLink CCIP são exemplos de protocolos que utilizam mecanismos de segurança otimistas. No caso do Nomad, os observadores conseguiram provar a fraude, embora estejam na lista de permissões no momento da redação. ChainLink CCIP planeja utilizar uma rede antifraude que consiste em uma rede distribuída de oráculos para detectar atividades maliciosas, embora a implementação da rede antifraude do CCIP seja desconhecida.
segurança
Em termos de segurança, ambos os mecanismos contam com a participação sem permissão de verificadores e observadores para garantir a validade da teoria dos jogos. Em um mecanismo de segurança econômica, os fundos ficam mais vulneráveis se o valor apostado for menor do que o valor que poderia ser roubado. Por outro lado, em mecanismos de segurança otimistas, a suposição de confiança minoritária pode ser explorada se ninguém apresentar uma prova de fraude ou se os observadores de permissão forem comprometidos ou removidos. Em contraste, os mecanismos de segurança econômica são menos dependentes da vitalidade para manter a segurança.
implementação
Em termos de implementação, uma abordagem envolve uma cadeia intermediária com seus próprios validadores. Nessa configuração, um grupo de validadores externos monitora a cadeia de origem e chega a um consenso sobre a validade de uma transação quando uma invocação é detectada. Uma vez alcançado o consenso, eles fornecem provas na cadeia-alvo. Os validadores geralmente precisam apostar uma certa quantidade de tokens, que podem ser reduzidos se uma atividade maliciosa for detectada. Exemplos de protocolos que usam esse método de implementação incluem Axelar Network e Celer IM.
Outro método de implementação envolve o uso de proxies off-chain. Proxies off-chain são usados para implementar soluções otimistas do tipo Rollups. Dentro de uma janela de tempo predefinida, esses proxies off-chain podem enviar provas de fraude e reverter transações, se necessário. Por exemplo, o Nomad depende de proxies off-chain independentes para retransmitir cabeçalhos e provas criptográficas. Por outro lado, a ChainLink CCIP planeja alavancar sua rede existente de oráculos para monitorar e atestar transações entre cadeias.
Vantagens e Desafios
Uma das principais vantagens das soluções AMP com teoria de jogo é a otimização de recursos, já que o processo de verificação geralmente é fora da cadeia, reduzindo os requisitos de recursos. Além disso, esses mecanismos são escaláveis, pois o mecanismo de consenso permanece o mesmo para vários tipos de cadeias e pode ser facilmente estendido para blockchains heterogêneos.
Existem também vários desafios associados a esses mecanismos. Se a maioria dos validadores conspirar, as suposições de confiança podem ser exploradas para roubar fundos, exigindo contramedidas como votação quadrática e provas de fraude. Além disso, soluções baseadas em segurança otimista apresentam complexidades em termos de finalidade e vivacidade, pois usuários e aplicativos precisam aguardar janelas fraudulentas para garantir a validade das transações.
Confie nos Humanos
As soluções que exigem confiança em entidades humanas também podem ser amplamente divididas em duas categorias:
Segurança reputacional: essas soluções dependem de implementações de assinatura múltipla, em que várias entidades verificam e assinam transações. Uma vez atingido o limite mínimo, a transação é considerada válida. A suposição aqui é que a maioria das entidades é honesta e, se a maioria dessas entidades assinar uma transação específica, essa transação é válida. A única coisa em risco aqui é a reputação das entidades envolvidas. Alguns exemplos incluem Multichain (Anycall V6) e Wormhole. Ainda podem existir vulnerabilidades devido a vulnerabilidades de contratos inteligentes, conforme demonstrado pelo hack do Wormhole no início de 2022.
Independência: Essas soluções dividem todo o processo de mensagens em duas partes e dependem de diferentes entidades independentes para gerenciar os dois processos. A suposição aqui é que essas duas entidades são independentes uma da outra e não podem entrar em conluio. LayerZero é um exemplo. Os cabeçalhos de bloco são transmitidos sob demanda por meio de oráculos distribuídos e as provas de transação são enviadas por retransmissores. Se a prova corresponder ao cabeçalho, a transação é considerada válida. Embora provar uma correspondência dependa de código/matemática, os participantes precisam confiar que essas entidades permanecem independentes e não têm intenções maliciosas. Os aplicativos construídos no LayerZero podem escolher seus oráculos e retransmissores (ou hospedar seus próprios oráculos/retransmissores), limitando assim o risco a oráculos/retransmissores individuais. Os usuários finais precisam confiar que o LayerZero, terceiros ou o próprio aplicativo estão executando oráculos e retransmissores de forma independente, sem intenção maliciosa.
Em ambas as abordagens, a reputação das entidades terceirizadas participantes impede o comportamento malicioso. Geralmente, essas entidades são respeitadas na comunidade de validadores e oráculos e, se se comportarem maliciosamente, correm o risco de causar danos à reputação e causar impacto negativo em outras atividades comerciais.
Considerações adicionais para soluções AMP
Ao considerar a segurança e a usabilidade de uma solução AMP, também precisamos considerar detalhes além da mecânica básica. Como esses são componentes que podem mudar com o tempo, não os incluímos na comparação geral.
Integridade do código
Hacks recentes exploraram erros de código, destacando a necessidade de auditoria robusta, recompensas de bugs e diversas implementações de cliente. Se todos os verificadores (em segurança econômica/otimista/reputacional) executarem o mesmo cliente (software para verificação), isso aumentará a dependência de uma única base de código e reduzirá a diversidade de clientes. Por exemplo, Ethereum depende de vários clientes de execução, como geth, netermind, erigon, besu, akula. Várias implementações em vários idiomas podem aumentar a diversidade, sem que nenhum cliente domine a rede, eliminando um possível ponto único de falha. Ter vários clientes também pode ajudar a manter a atividade no caso de um pequeno número de validadores/signatários/clientes light falhar devido a um bug/ataque em uma implementação específica.
Configuração e capacidade de atualização
Os usuários e desenvolvedores precisam saber se os validadores/observadores podem ingressar na rede sem permissão, caso contrário, a confiança será ocultada pelas entidades que escolherem a permissão. As atualizações para contratos inteligentes também podem introduzir vulnerabilidades que podem levar a ataques e possivelmente até alterar as suposições de confiança. Diferentes soluções podem ser implementadas para mitigar esses riscos. Por exemplo, na instanciação atual, o gateway Axelar pode ser atualizado, mas requer aprovação do comitê off-line (limite de 4/8). Os principais contratos do Wormhole são atualizáveis e gerenciados por meio do sistema de governança on-chain do Wormhole. LayerZero depende de contratos inteligentes imutáveis e bibliotecas imutáveis para evitar atualizações, mas novas bibliotecas podem ser enviadas, dapps que definem configurações padrão obterão versões mais recentes, dapps que definem manualmente a versão precisam defini-la para a nova versão.
Valor Máximo Extraível (MEV)
Diferentes blockchains não são sincronizados por um relógio comum e têm diferentes tempos de finalidade. Portanto, a ordem de execução e o tempo na cadeia de destino podem variar de cadeia para cadeia. Em um mundo de cadeia cruzada, MEV é difícil de definir claramente. Ele introduz uma troca entre vivacidade e ordem de execução. Um canal ordenado garantirá a entrega de mensagens em ordem, mas se uma mensagem expirar, o canal será fechado. Outro aplicativo pode preferir não solicitar, mas a entrega de outras mensagens não é afetada.
Certeza da cadeia de origem
Idealmente, as soluções AMP devem esperar que a cadeia de origem atinja a finalidade antes de transmitir as informações de estado da cadeia de origem para uma ou mais cadeias de destino. Isso garantirá que os blocos na cadeia de origem dificilmente possam ser revertidos ou alterados. No entanto, muitas soluções fornecem mensagens instantâneas e fazem suposições de confiança sobre a finalidade para fornecer a melhor experiência ao usuário. Nesse caso, se a cadeia de origem sofrer uma reversão de estado após a entrega da mensagem e a passagem do ativo ponte, isso pode levar a situações como o gasto duplo dos fundos ponte. As soluções AMP podem gerenciar esse risco de várias maneiras, como definindo diferentes suposições de finalidade para diferentes cadeias, dependendo de quão descentralizada é a cadeia ou fazendo compensações entre velocidade e segurança. As pontes que utilizam soluções AMP podem definir limites na quantidade de ativos interligados antes que a cadeia de origem atinja a finalidade.
Tendências e perspectivas futuras Segurança personalizável e anexável
Para atender melhor a diversos casos de uso, as soluções AMP são incentivadas a fornecer mais flexibilidade aos desenvolvedores. A Axelar apresenta um método para permitir escalabilidade de mensagens e validação sem alterar a lógica da camada de aplicativos. O HyperLane V2 apresenta módulos que permitem aos desenvolvedores escolher entre várias opções, como segurança econômica, segurança otimista, segurança dinâmica e segurança híbrida. O CelerIM fornece segurança otimista adicional além da segurança econômica. Muitas soluções esperam por um número mínimo predefinido de confirmações de bloco na cadeia de origem antes de entregar uma mensagem. LayerZero permite que os desenvolvedores atualizem esses parâmetros. Esperamos que algumas soluções AMP continuem a oferecer mais flexibilidade, mas essas opções de design requerem alguma discussão. Os aplicativos devem ser capazes de configurar sua segurança, até que ponto e o que acontece se os aplicativos forem arquitetados com um design abaixo do ideal? A conscientização do usuário sobre os conceitos fundamentais por trás da segurança provavelmente se tornará cada vez mais importante. Em última análise, prevemos agregação e abstração de soluções AMP, possivelmente na forma de alguma forma de composição ou segurança "add-on".
A maturidade do mecanismo "código de confiança e matemática"
Em um estágio final ideal, todas as mensagens de cadeia cruzada serão minimizadas pela confiança por meio do uso de provas de conhecimento zero (ZK). Vimos projetos semelhantes como o Polymer Labs e o Sucinct Labs surgirem. A Multichain também publicou um white paper do zkRouter sobre interoperabilidade por meio de provas do ZK. Com a recém-anunciada Axelar Virtual Machine, os desenvolvedores podem aproveitar o Interchain Amplifier para estabelecer novas conexões com a rede Axelar sem permissão. Por exemplo, uma vez que os clientes leves fortes e as provas ZK são desenvolvidas para o estado do Ethereum, os desenvolvedores podem integrá-los facilmente à rede Axelar para substituir ou aprimorar as conexões existentes. A Celer Network anunciou o Brevis, uma plataforma de prova de dados de cadeia cruzada ZK que permite que dApps e contratos inteligentes acessem, calculem e utilizem dados arbitrários em vários blockchains. A Celer implementou um ativo zkBridge orientado ao usuário usando o circuito ZK light client para cross-chain entre a rede de teste Ethereum Goerli e a rede de teste BNB Chain. LayerZero discute em sua documentação a possibilidade de adicionar novas bibliotecas de mensagens de prova otimizadas no futuro. Projetos mais recentes, como o Lagrange, estão explorando a agregação de várias provas de várias cadeias de origem, enquanto o Herodotus possibilita o armazenamento de provas com as provas ZK. No entanto, essa transição levará tempo, pois é difícil escalar essa abordagem em blockchains que dependem de diferentes mecanismos e estruturas de consenso.
ZK é uma tecnologia relativamente nova e complexa que é difícil de auditar, e os custos atuais de verificação e geração de provas não são ideais. Acreditamos que, a longo prazo, para oferecer suporte a aplicativos de cadeia cruzada altamente escaláveis em blockchains, muitas soluções AMP provavelmente combinarão software verificável com pessoas e entidades confiáveis porque:
Por meio de auditoria e recompensas de bugs, a possibilidade de exploração de código pode ser minimizada. Com o tempo, ficará mais fácil confiar nesses sistemas, pois seu histórico se torna uma prova de sua segurança.
O custo de geração de provas ZK será reduzido. Com mais pesquisa e desenvolvimento em ZKPs, ZKPs recursivos, agregação de provas, esquemas de dobragem e hardware especializado, esperamos que o custo de geração e verificação de provas diminua substancialmente, tornando-o uma abordagem mais econômica.
O blockchain se tornará mais favorável ao ZK. No futuro, o zkEVM será capaz de fornecer provas sucintas da validade da execução, e soluções leves baseadas em cliente poderão verificar facilmente a execução e o consenso da cadeia de origem. Na fase final do Ethereum, também está planejado "zk-SNARK tudo", incluindo o mecanismo de consenso.
Prova Humana, Reputação e Identidade
A segurança de um sistema complexo como uma solução AMP não pode ser encapsulada apenas por uma única estrutura e requer uma solução multicamadas. Por exemplo, além dos incentivos econômicos, a Axelar implementa um mecanismo de votação quadrática para evitar a concentração do poder de voto entre um subconjunto de nós e promover a descentralização. Outras provas humanas, reputações e identidades também podem complementar os mecanismos de configuração e permissão.
para concluir
No espírito aberto da Web3, podemos vislumbrar um futuro pluralista onde coexistem múltiplas abordagens. Na verdade, um aplicativo pode optar por usar várias soluções de interoperabilidade, seja de maneira redundante ou para que o usuário escolha uma combinação baseada em compensações. Entre as rotas de "alto tráfego", as soluções ponto a ponto podem ser priorizadas, enquanto os modelos hub-and-spoke podem dominar a cauda longa da cadeia. Por fim, nós, como uma comunidade de usuários, construtores e colaboradores, moldaremos a forma básica da Internet Web3.