Autor: STANFORD BLOCKCHAIN ​​​​CLUB. Traduzido por: Cointime: QDD.

introdução

O futuro é multi-cadeia. A busca por escalabilidade levou o Ethereum a uma solução contínua. A mudança para blockchains modulares reacendeu o interesse em cadeias de aplicativos. No horizonte, ouvimos rumores de soluções de laminação específicas para aplicações, soluções de terceira camada e cadeias soberanas. Mas tudo isso tem o custo da fragmentação, com as pontes atuais muitas vezes limitadas em funcionalidade e dependendo de partes signatárias confiáveis ​​para fornecer segurança.

Como será a forma final de interconexão na Internet 3.0? Acreditamos que as pontes acabarão evoluindo para protocolos de mensagens entre cadeias ou “Passagem Arbitrária de Mensagens” (AMP) para desbloquear novos casos de uso, permitindo que os aplicativos passem mensagens arbitrárias entre as cadeias de origem e de destino. Também veremos o surgimento de um “cenário de mecanismos de confiança”, onde os construtores fazem várias compensações entre facilidade de uso, complexidade e segurança.

Cada solução AMP requer dois recursos principais:

1. Verificação: Verifique a validade da mensagem da cadeia de origem na cadeia de destino.

2. Sobrevivência: capacidade de transferir informações da cadeia de origem para a cadeia de destino.

Infelizmente, a verificação 100% confiável não é realista e os usuários precisam confiar em código, teoria dos jogos, humanos (ou entidades) ou uma combinação destes, dependendo se a verificação é feita na cadeia ou fora dela.

Neste artigo, dividiremos o cenário geral de interoperabilidade vertical e horizontalmente com base nos mecanismos de confiança e arquiteturas de integração usados.

Mecanismo de confiança:

1. Confie no código e na matemática: para essas soluções, há provas na cadeia que podem ser verificadas por qualquer pessoa. Essas soluções normalmente dependem de clientes leves para verificar o consenso da cadeia de origem na cadeia de destino ou para verificar a validade da transição de estado da cadeia de origem na cadeia de destino. Provas de conhecimento zero podem tornar a verificação leve do cliente mais eficiente, comprimindo cálculos offline arbitrariamente longos e fornecendo verificação simples na cadeia para provar o cálculo.

2. Teoria dos Jogos de Confiança: Quando um usuário/aplicativo precisa confiar em um terceiro ou em um grupo de terceiros para garantir a autenticidade de uma transação, há suposições de confiança adicionais. Esses mecanismos podem se tornar mais seguros combinando incentivos econômicos e teoria dos jogos, como segurança otimista por meio de redes sem permissão.

3. Confiança nos humanos: Essas soluções dependem da honestidade da maioria dos validadores ou da independência das entidades que repassam diferentes informações. Além de confiar no consenso das duas cadeias que interagem, também é necessária confiança em uma terceira parte. Somente a reputação das entidades participantes está envolvida aqui. Se um número suficiente de entidades participantes considerar uma transação válida, ela será considerada válida.

É importante observar que todas as soluções exigem confiança tanto no código quanto nos humanos até certo ponto. Qualquer solução de código defeituosa pode ser explorada por hackers, e cada solução tem um certo elemento humano na configuração, atualização ou manutenção da base de código.

Arquitetura integrada:

1. Modelo ponto a ponto: Um canal de comunicação dedicado precisa ser estabelecido entre cada cadeia de origem e cada cadeia de destino.

2. Modelo de hub central: um canal de comunicação precisa ser estabelecido com um hub central que conecte todos os outros blockchains conectados ao hub.

O modelo ponto a ponto é relativamente difícil de escalar porque cada blockchain conectado requer um canal de comunicação em pares. O desenvolvimento desses canais pode ser desafiador para blockchains com diferentes consensos e estruturas. No entanto, se desejado, uma abordagem híbrida pode ser adotada, como usar o protocolo de comunicação Inter-Blockchain (IBC) para roteamento multi-hop por meio de um hub central, o que elimina a necessidade de comunicação direta ponto a ponto, mas introduz mais complexidade em termos de segurança, latência e custo.

Confie em código e matemática

Para confiar apenas em código/matemática para suposições de confiança, um cliente leve pode ser usado para verificar o consenso da cadeia de origem na cadeia de destino. Um cliente/nó leve é ​​um pedaço de software que se conecta a um nó completo para interagir com o blockchain. Clientes leves na cadeia de destino normalmente armazenam os cabeçalhos de bloco da cadeia de origem (em ordem), o que é suficiente para verificar transações. Da mesma forma, agentes off-chain (como retransmissores) na cadeia de origem monitoram eventos, geram provas de inclusão criptográfica e as encaminham junto com cabeçalhos de bloco para clientes light na cadeia de destino. Como os clientes leves armazenam os cabeçalhos de bloco em ordem, eles conseguem verificar as transações porque cada cabeçalho de bloco contém um hash raiz Merkle que comprova o estado. A seguir, uma visão geral dos principais recursos dessa abordagem:

Segurança

Suposições de confiança são introduzidas durante o processo de inicialização leve do cliente. Quando um novo cliente light é criado, ele é inicializado com um cabeçalho de bloco em uma altura específica. Entretanto, os cabeçalhos de bloco fornecidos podem estar errados, e é possível enganar clientes leves falsificando cabeçalhos de bloco. Depois que o cliente leve é ​​inicializado, nenhuma outra suposição de confiança é introduzida. No entanto, vale ressaltar que esse processo de inicialização depende de uma suposição de confiança mais fraca, pois qualquer pessoa pode verificá-lo. Além disso, a continuidade do repetidor também é uma suposição de confiança, pois ele é responsável por transmitir as informações.

concluir

A implementação de clientes leves depende da disponibilidade dos primitivos criptográficos necessários para autenticação. Se as cadeias conectadas forem do mesmo tipo, ou seja, se compartilharem a mesma estrutura de aplicação e algoritmo de consenso, então as implementações do cliente leve em ambos os lados serão as mesmas. Por exemplo, todas as cadeias baseadas no Cosmos SDK usam o protocolo Inter-Blockchain Communication (IBC). Por outro lado, se você estiver conectando dois tipos diferentes de cadeias, como diferentes estruturas de aplicativos ou tipos de consenso, a implementação do cliente leve será diferente. Um exemplo é a Composable Finance, que está trabalhando para conectar a cadeia Cosmos SDK ao Substrate do ecossistema Polkadot via IBC. Isso requer adicionar um cliente leve Tendermint na cadeia Substrate e um cliente leve "poderoso" na cadeia Cosmos SDK. Recentemente, eles estabeleceram a primeira conexão entre Polkadot e Kusama via IBC.

desafio

A intensidade dos recursos é um grande desafio. Executar pares de clientes leves em todas as cadeias pode ser caro porque as gravações no blockchain são caras. Além disso, não é possível executar clientes leves em cadeias com conjuntos de validadores dinâmicos, como Ethereum.

Escalabilidade é outro desafio. As implementações de clientes leves variam com base na arquitetura da cadeia, o que dificulta o dimensionamento e a conexão de diferentes ecossistemas.

A exploração de código é um risco potencial porque erros no código podem levar a vulnerabilidades. Um exemplo é a vulnerabilidade da cadeia BNB em outubro de 2022, que revelou uma vulnerabilidade crítica de segurança que afeta todas as cadeias habilitadas para IBC[1].

Para abordar o custo e a praticidade de executar pares de clientes leves em todas as cadeias, alternativas como provas de conhecimento zero (ZK) oferecem uma maneira de eliminar a necessidade de confiança em terceiros.

Prova de conhecimento zero como solução para a confiança de terceiros

As provas ZK podem ser usadas para verificar a validade das transições de estado na cadeia de origem na cadeia de destino. Em vez de executar toda a computação na cadeia, é melhor executar apenas a verificação da computação na cadeia, enquanto o processo de computação real é executado fora da cadeia. Essa abordagem pode ser mais rápida e mais eficiente em termos de energia do que reexecutar os cálculos originais. Alguns exemplos incluem o Polymer ZK-IBC da Polymer Labs e o Telepathy da Succinct Labs. A Polymer está desenvolvendo IBC com suporte para multi-hop para melhorar a conectividade e reduzir o número de conexões em pares 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. Os zk-SNARKs podem exigir um processo de configuração confiável em que chaves iniciais são criadas para as provas usadas na verificação. É fundamental que as chaves que destroem o evento de configuração permaneçam confidenciais para evitar que transações sejam conduzidas por meio de verificação falsificada. Depois que a configuração confiável estiver concluída, nenhuma outra suposição de confiança será introduzida. Além disso, novas estruturas ZK, como Halo e Halo2, eliminam completamente a necessidade de uma configuração confiável.

concluir

Existem vários esquemas de prova de ZK, como SNARK, STARK, VPD e SNARG, sendo o SNARK o mais amplamente adotado atualmente. Diferentes estruturas de comprovação SNARK, como Groth16, Plonk, Marlin, Halo e Halo2, têm compensações em tamanho de prova, tempo de comprovação, tempo de verificação, requisitos de memória e a necessidade de uma configuração confiável. Provas ZK recursivas também surgiram, permitindo que a carga de trabalho de prova seja distribuída entre vários computadores em vez de apenas um. Para gerar uma prova de validade, as seguintes primitivas principais devem ser implementadas: verificar o esquema de assinatura usado pelo validador, incluindo a prova da chave pública do validador no compromisso do conjunto do validador armazenado na cadeia, e manter o controle do 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 de curvas elípticas complexas, o que não é trivial e pode exigir implementações diferentes para cada cadeia, dependendo da estrutura e do consenso da cadeia. Auditar circuitos ZK é uma tarefa desafiadora e propensa a erros. Os desenvolvedores precisam se familiarizar com linguagens específicas de domínio, como Circom, Cairo e Noir, ou simplesmente implementar os circuitos eles mesmos, o que pode ser desafiador e retardar a adoção. Isso pode levar à centralização se o tempo e a carga de trabalho forem muito altos, o que somente uma equipe dedicada com hardware especializado pode ser capaz de lidar. Tempos maiores de geração de provas também podem causar atrasos. Técnicas como Computação Incremental Verificável (IVC) podem melhorar 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.

Teoria dos jogos de confiança

Os protocolos de interoperabilidade da teoria dos jogos podem ser amplamente divididos em duas categorias com base em como eles incentivam o comportamento honesto entre as entidades participantes:

O primeiro é a segurança econômica, onde vários atores externos (como validadores) colaboram para chegar a um consenso sobre o estado atualizado da cadeia de origem. Para se tornar um validador, os participantes precisam apostar uma certa quantia de tokens, que pode ser reduzida em caso de atividade maliciosa. Em um ambiente sem permissão, qualquer um pode acumular uma participação e se tornar um validador. Além disso, incentivos financeiros para que os validadores sigam o protocolo são fornecidos na forma de recompensas em bloco, garantindo incentivos financeiros para comportamento honesto. No entanto, se o valor potencialmente roubável exceder o valor apostado, os participantes podem conspirar para roubar fundos. Exemplos de protocolos que utilizam mecanismos de segurança econômica são Axelar e Celer IM.

A segunda categoria é a segurança otimista, onde a solução se baseia na suposição de que apenas uma minoria dos participantes do blockchain são honestos e seguem as regras do protocolo. Nessa abordagem, um único participante honesto pode atuar como garantia. Por exemplo, uma solução ideal permitiria que qualquer pessoa apresentasse evidências de fraude. Embora haja um incentivo financeiro, observadores honestos podem não perceber transações fraudulentas. O Optimistic Roll-up também adota esse mecanismo. Nomad e ChainLink CCIP são exemplos de protocolos que usam segurança otimista. No caso do Nomad, os observadores conseguiram provar a fraude, apesar de seu status de lista de permissões no momento da redação deste artigo. O ChainLink CCIP planeja utilizar uma rede antifraude que consiste em uma rede oracle descentralizada para monitorar atividades maliciosas, embora a implementação da rede antifraude do CCIP ainda não tenha sido determinada.

Segurança

Em termos de segurança, ambos os mecanismos dependem da participação sem permissão de validadores e observadores para garantir a validade da teoria dos jogos. Em um mecanismo de segurança econômica, se o valor apostado for menor que o valor potencialmente roubável, os fundos ficam mais vulneráveis ​​a ataques. Por outro lado, em mecanismos de segurança otimistas, a suposição de confiança minoritária pode ser explorável se ninguém apresentar provas de fraude ou se o observador de autoridade for comprometido ou removido. 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 das transações quando uma chamada é detectada. Uma vez alcançado o consenso, eles fornecem provas sobre a cadeia alvo. Os validadores geralmente são obrigados a apostar uma certa quantia de tokens e podem ser eliminados se alguma atividade maliciosa for detectada. Exemplos de protocolos que usam essa implementação incluem Axelar Network e Celer IM.

Outro método de implementação envolve o uso de um proxy off-chain. Proxies off-chain são usados ​​para implementar soluções semelhantes a roll-ups otimistas. Dentro de uma janela de tempo predefinida, esses proxies off-chain têm permissão para enviar provas de fraude e reverter transações, se necessário. Por exemplo, o Nomad depende de proxies independentes fora da cadeia para retransmitir cabeçalhos e provas criptográficas. Por outro lado, a ChainLink CCIP planeja alavancar sua rede de oráculos existente para monitorar e comprovar transações entre cadeias.

Vantagens e Desafios

Uma vantagem importante do Game Theory AMP é a otimização de recursos, já que o processo de verificação normalmente não ocorre na 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.

Esses mecanismos também enfrentam alguns desafios. Se a maioria dos validadores entrar em conluio, a suposição de confiança pode ser explorada para roubar fundos, o que requer o uso de contramedidas, como votação quadrática e provas de fraude. Além disso, soluções baseadas em segurança otimista introduzem complexidade em termos de finalidade e atividade, pois usuários e aplicativos precisam esperar por uma janela de fraude para garantir a validade das transações.

Confiança nos humanos

Soluções que exigem confiança em uma entidade humana também podem ser amplamente divididas em duas categorias:

1. Segurança de reputação: essas soluções dependem de implementações de múltiplas assinaturas, nas quais diversas entidades verificam e assinam transações. Quando o limite mínimo é atingido, a transação é considerada válida. A suposição aqui é que a maioria das entidades é honesta e, se a maioria dessas entidades assina uma transação específica, então ela é válida. Alguns exemplos disso incluem Multichain (Anycall V6) e Wormhole. Vulnerabilidades de contratos inteligentes ainda podem ser exploradas, como demonstrado pelo hack do Wormhole no início de 2022.

2. Independência: Essas soluções dividem todo o processo de mensagens em duas partes e contam com diferentes entidades independentes para gerenciar os dois processos. A suposição aqui é que as duas entidades são independentes uma da outra e não entrarão em conluio. LayerZero é um exemplo. Cabeçalhos de bloco podem ser transmitidos sob demanda por oráculos descentralizados, e provas de transação são enviadas por meio de retransmissores. Se a prova corresponder ao cabeçalho do bloco, a transação será considerada válida. Embora provar uma correspondência dependa de código/matemática, os participantes precisam confiar que essas entidades permanecem independentes. Os aplicativos criados no LayerZero podem escolher seus oráculos e retransmissores (ou hospedar seus próprios oráculos/retransmissores), limitando o risco de conluio individual entre oráculos/retransmissores. Os usuários finais precisam confiar que a LayerZero, terceiros ou o próprio aplicativo estão operando o oráculo e o retransmissor de forma independente e sem intenção maliciosa.

Em ambas as abordagens, a reputação das entidades terceiras participantes reduz o incentivo para agir de forma maliciosa. Eles geralmente são entidades muito respeitadas nas comunidades de validadores e oráculos e enfrentam consequências reputacionais e impactos negativos em suas outras atividades comerciais se se comportarem de maneira maliciosa.

Além da suposição de confiança: 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 dos mecanismos básicos. Como essas são peças móveis que podem mudar ao longo do tempo, não as incluímos na comparação geral.

Integridade do código

Hacks recentes exploraram erros de codificação, destacando a necessidade de auditoria confiável, recompensas por bugs e implementações diversificadas de clientes. Se todos os validadores (em segurança econômica/otimista/reputacional) executarem o mesmo cliente (software usado para validação), isso aumentará a dependência de uma única base de código e reduzirá a diversidade do cliente. Por exemplo, o Ethereum depende de vários clientes de execução, como geth, nethermind, erigon, besu, akula. Múltiplas implementações em vários idiomas podem aumentar a diversidade sem que nenhum cliente domine a rede, eliminando potenciais pontos únicos de falha. Ter vários clientes também pode ajudar a melhorar a atividade. Se alguns validadores/assinantes/clientes leves ficarem inativos devido a um bug/ataque em uma implementação específica, os outros ainda estarão disponíveis.

Configuração e capacidade de atualização

Usuários e desenvolvedores precisam entender se validadores/observadores podem ingressar na rede sem permissão, caso contrário, a confiança será ocultada pelas entidades autorizadas escolhidas. Atualizações em contratos inteligentes também podem introduzir bugs que podem levar a ataques ou até mesmo alterar suposições de confiança. Diferentes soluções podem ser implementadas para mitigar esses riscos. Por exemplo, na instanciação atual, o Axelar Gateway pode ser atualizado com base na aprovação do comitê offline (limite de 4/8); no entanto, a Axelar planeja exigir que todos os validadores aprovem coletivamente qualquer atualização do Gateway em um futuro próximo. Os contratos principais da Wormhole são atualizáveis ​​e gerenciados por meio do sistema de governança on-chain da Wormhole. O LayerZero depende de contratos inteligentes imutáveis ​​e bibliotecas imutáveis ​​para evitar quaisquer atualizações, mas novas bibliotecas podem ser lançadas, e os dApps que usam as configurações padrão receberão a versão atualizada, e os dApps que definirem manualmente a versão precisarão defini-la para a nova versão.

Valor Máximo Extraível (MEV)

Diferentes blockchains são sincronizadas por meio de um relógio comum e têm diferentes tempos de finalização. Portanto, a ordem de execução e o tempo na cadeia de destino podem variar de cadeia para cadeia. No mundo cross-chain, uma definição clara de MEV é desafiadora. Ela introduz um trade-off entre vivacidade e ordem de execução. Um canal ordenado garantirá a entrega ordenada de mensagens, mas se o tempo limite de uma mensagem expirar, o canal será fechado. Outro aplicativo pode preferir não exigir ordenação, mas não afetar a entrega de outras mensagens.

Finalidade da cadeia de origem

O ideal é que uma solução AMP aguarde até que uma cadeia de origem atinja a finalidade antes de transferir informações de estado da cadeia de origem para uma ou mais cadeias de destino. Isso garantirá que os blocos na cadeia de origem sejam virtualmente impossíveis de reverter ou alterar. No entanto, para proporcionar a melhor experiência ao usuário, muitas soluções oferecem mensagens instantâneas e fazem suposições confiáveis ​​sobre a finalidade. Nesse caso, se a cadeia de origem for revertida após a entrega da mensagem e os fundos forem interligados, poderá ocorrer gasto duplo de fundos. As soluções AMP podem gerenciar esse risco de várias maneiras, como usar diferentes suposições de finalidade para diferentes cadeias, ponderando a velocidade e a segurança com base no nível de descentralização da cadeia. As pontes que aproveitam a solução AMP podem definir limites para o número de ativos que podem ser interligados antes que a cadeia de origem atinja a finalidade.

Tendências e perspectivas futuras

Personalizável e com maior segurança

Para atender melhor a diferentes casos de uso, as soluções AMP são incentivadas a fornecer mais flexibilidade de desenvolvimento. A Axelar apresenta um método para atualização de mensagens e autenticação sem alterar a lógica da camada de aplicação. O HyperLane V2 apresenta módulos que permitem aos desenvolvedores escolher entre diversas opções, incluindo segurança econômica, segurança otimista, segurança dinâmica e segurança híbrida. Além da segurança econômica, o CelerIM também oferece segurança otimista adicional. Muitas soluções aguardam um número mínimo predefinido de confirmações de blocos na cadeia de origem antes de transmitir uma mensagem. O LayerZero permite que os desenvolvedores atualizem esses parâmetros. Esperamos que algumas soluções AMP continuem a oferecer mais flexibilidade, mas essas escolhas de design exigem alguma discussão. Os aplicativos podem configurar sua segurança, até que ponto e o que acontece se o aplicativo for arquitetado de forma subótima? A conscientização do usuário sobre os conceitos básicos de segurança pode se tornar cada vez mais importante. Em última análise, prevemos agregação e abstração de soluções AMP, talvez em alguma forma de segurança combinada ou “adicionada”.

A maturidade do mecanismo de “confiança no código e na matemática”

No objetivo final ideal, todas as mensagens entre cadeias minimizarão a confiança por meio do uso de provas de conhecimento zero. Já estamos vendo essa mudança surgir com projetos como Polymer Labs e Succinct Labs. A Multichain também publicou um white paper chamado zkRouter, que permite a interoperabilidade por meio de provas ZK. Com a recém-anunciada Máquina Virtual Axelar, os desenvolvedores podem aproveitar o Amplificador Interchain para estabelecer novas conexões com a Rede Axelar sem permissão. Por exemplo, uma vez que clientes leves robustos e provas ZK do estado do Ethereum são desenvolvidos, os desenvolvedores podem facilmente integrá-los à rede Axelar para substituir ou aprimorar as conexões existentes. A Celer Network anunciou uma plataforma de prova de dados entre cadeias ZK chamada Brevis, permitindo que dApps e contratos inteligentes acessem, calculem e utilizem dados arbitrários em vários blockchains. A Celer usa circuitos de cliente leves ZK para implementar um ativo visível ao usuário, o zkBridge, para conectar as redes de teste Ethereum Goerli e BNB Chain. O LayerZero fala em sua documentação sobre a possibilidade de adicionar novas bibliotecas de mensagens de prova otimizadas no futuro. Novos projetos como o Lagrange estão explorando a possibilidade de agregar múltiplas provas de múltiplas cadeias de origem, enquanto o Herodotus torna a prova de armazenamento possível por meio de provas ZK. No entanto, essa transição levará tempo, pois essa abordagem é difícil de ser dimensionada em blockchains que dependem de diferentes mecanismos e estruturas de consenso.

ZK é uma tecnologia relativamente nova e complexa, difícil de auditar, e os custos atuais de verificação e geração de provas são abaixo do ideal. Acreditamos que, a longo prazo, para dar suporte a aplicativos cross-chain altamente escaláveis ​​em blockchains, muitas soluções AMP provavelmente combinarão entidades humanas confiáveis ​​com software verificável pelos seguintes motivos:

1. Por meio de auditoria e recompensas por bugs, a possibilidade de exploração de código pode ser minimizada. Com o tempo, à medida que seu histórico servir como prova de segurança, ficará mais fácil confiar nesses sistemas.

2. O custo de geração de provas ZK será reduzido. Com mais P&D em ZKPs, ZK recursivo, agregação de provas, esquemas de dobramento e hardware especializado, esperamos que o tempo e o custo de geração e verificação de provas diminuam significativamente, tornando-a uma abordagem mais econômica.

3. O Blockchain será mais amigá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, há planos para “converter tudo para zk-SNARKs”, incluindo consenso.

Humanos, Reputação e Identidade

A segurança de um sistema complexo como a solução AMP não pode ser encapsulada por apenas uma estrutura e requer uma solução multicamadas. Por exemplo, além dos incentivos econômicos, a Axelar também implementa um mecanismo de votação quadrática para evitar a concentração do poder de voto em um subconjunto de nós e promover a descentralização. Outras provas humanas, de reputação e de identidade também podem complementar os mecanismos de configurações e permissões.

para concluir

Com base no espírito aberto da Web3, podemos ver um futuro onde múltiplas abordagens coexistem. Na prática, os aplicativos podem optar por usar diversas soluções de interoperabilidade, seja de forma redundante ou para permitir que os usuários as misturem e combinem com compensações. Soluções ponto a ponto podem ser priorizadas entre rotas de “alto tráfego”, enquanto modelos hub and spoke podem dominar na cauda longa da cadeia. Em última análise, cabe a nós, como uma comunidade de usuários, construtores e colaboradores, moldar o cenário de uma Web3 interconectada.

Referências

https://forum.cosmos.network/t/ibc-security-advisory-dragonberry/7702 

https://polymerlabs.medium.com/the-multi-hop-ibc-upgrade-will-take-ibc-to-ethereum-and-beyond-b4bee43523e 

https://cointelegraph.com/news/wormhole-hack-illustrates-danger-of-defi-cross-chain-bridges 

https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps 

https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725 

https://twitter.com/MultichainOrg/status/1613830754458533888?s=20&t=MoDGESqOdcjMQDMFQqzTyQ

https://axelar.network/blog/axelar-virtual-machine-future-of-interoperability 

https://twitter.com/CelerNetwork/status/1638330932603109379?s=20

https://axelar.network/blog/axelar-implements-quadratic-voting-with-maeve-upgrade