Uma breve história da cadeia cruzada: explicando nove soluções diferentes de cadeia cruzada

As soluções de cadeia cruzada foram o tópico mais falado no ano passado. Com o surgimento de infraestruturas de cadeias públicas, tem havido um grande interesse em como as diferentes cadeias falam e se comunicam. Soluções foram propostas e implementadas, mas nenhuma delas resolve os problemas fundamentais sem trocas drásticas. Agora examinamos as diferentes abordagens de cadeia cruzada e divulgamos por que e como elas moldarão o futuro da infraestrutura de cadeia cruzada.

Primeiro, vamos discutir o que é tecnologia de cadeia cruzada e por que ela é necessária. Motivo do uso: as cadeias são heterogêneas e exigem que os desenvolvedores tenham um tempo significativo para acompanhar as diferenças e os desafios ao mover ativos. As pontes são menos seguras e não podem ser 100% confiáveis ​​porque geralmente pertencem às equipes do projeto blockchain e são altamente centralizadas (confusas sem coordenação de cada equipe). O objetivo do blockchain da camada 1 é padronizar, mas a segmentação das cadeias da camada 1 está levando à necessidade de uma camada de infraestrutura de cadeia cruzada que esteja mesmo abaixo das camadas 1.

A história dos mecanismos de cadeia cruzada deve ser apresentada e comparada para entender as soluções de cadeia cruzada e comparar suas diferenças e atributos.

Transferência Manual

 
A primeira solução cross-chain é uma transferência manual de ativos. O processo começa fazendo com que o usuário transfira ativos para uma carteira específica na cadeia A, e uma entidade centralizada monitora a carteira para transferências e as registra no Excel. Então, após um período de tempo finito (geralmente para fins de monitoramento), a entidade credita os ativos na cadeia B após a verificação. A vantagem dessa abordagem é a facilidade de implementação, mas é propensa a erros humanos e tem uma garantia de segurança muito baixa. Também não há descentralização nesta abordagem.

Transferência semiautomática

A próxima iteração melhora fazendo com que o usuário transfira ativos para uma carteira específica e/ou contrato inteligente na cadeia A. Em seguida, um programa centralizado monitora o endereço para transferências. Esse programa envia automaticamente ativos para a cadeia B após a verificação. A vantagem ainda é a facilidade de implementação sem muita complexidade ou codificação, e os registros podem ser mantidos na cadeia em vez de localmente. A desvantagem é que o programa centralizado pode apresentar bugs ou mau funcionamento. A conta de crédito central também pode ficar sem fundos. A garantia de segurança também é baixa e não há descentralização.

Troca Centralizada

Quando as soluções simples de cadeia cruzada não são escaláveis, as trocas centralizadas prosperam nas necessidades de cadeia cruzada. Eles funcionam fazendo com que os usuários transfiram ativos para sua bolsa centralizada e, em seguida, usando o swap “interno” da bolsa, transformem “ativos X” na cadeia A em “ativos Y” na cadeia B por meio de contabilidade de registro. A vantagem é óbvia – é a solução mais fácil de usar – nenhuma codificação é necessária e há alta confiabilidade nas trocas de nível 1. Mas o problema expõe a desvantagem oposta – controle centralizado de quando o depósito/retirada está disponível. A troca centralizada oferece alta segurança com a desvantagem da menor descentralização.

Ponte Centralizada

O próximo avanço melhora ao ter uma infraestrutura separada na transferência de ativos entre as cadeias – uma ponte. Uma ponte centralizada funciona fazendo com que o usuário transfira ativos e, em seguida, usando o recurso de transferência da ponte, inicie a transferência de ativos X na cadeia A para ativos Y na cadeia B. Um retransmissor centralizado (ou um conjunto de) é responsável pelo processo:

Bloqueie os ativos X na cadeia A
verificar
Ativos de cunhagem Y na cadeia B
A vantagem desta ponte é o processo totalmente automático sem qualquer interrupção manual. E a desvantagem ainda é o controle centralizado de quando o depósito/saque está disponível. Além disso, a ponte pode estar inoperante ou hackeada, tornando-a inoperante de tempos em tempos. Então a segurança é média, e ainda não há descentralização.

Ponte descentralizada com MPC

A próxima iteração está descentralizando o modelo de verificação em vez de uma ponte centralizada. Uma ponte MPC (Multi-Party Computation) começa fazendo com que os usuários transfiram ativos para ela. Usando o recurso de transferência da ponte, ele inicia a transferência de ativos X na cadeia A para ativos Y na cadeia B. Geralmente, há um conjunto descentralizado de retransmissores responsável pelo processo:

Bloqueie os ativos X na cadeia A usando MPC
Verificar usando MPC
Mint ativos Y na cadeia B usando MPC
A vantagem do MPC é o processo totalmente automático sem qualquer interrupção manual, e os nós de retransmissão não precisam ser centralizados. A desvantagem é o alto custo computacional e de comunicação do MPC. Além disso, os nós podem ser comprometidos ou em conluio. A segurança é média, enquanto a descentralização também é média.

Ponte de Swap Atômica com HTLC

Outra classe de pontes surge dependendo da tecnologia de troca atômica (Lightning Network). Ele funciona: o usuário transfere ativos para uma ponte de troca atômica e, em seguida, usando o recurso de transferência da ponte, inicia a transferência de ativos X na cadeia A para ativos Y na cadeia B:

Crie um novo HTLC - Contrato Temporizado de Bloqueio de Hash
Depositar os ativos X no contrato na cadeia A
Gerar chave de bloqueio de hash + criptografar um segredo para retirada final dentro do tempo T na cadeia B
Apresentar segredo criptografado para contratar na cadeia B para retirar ativos Y
OU o tempo T passou e recupere os ativos X do contrato na cadeia A com o segredo criptografado
A vantagem significativa é que não há nenhum nó/processo centralizado controlando a transferência da ponte. E a desvantagem é relativamente comum – um alto custo de implantação de HTLC e execução de chamadas HTLC. Devido à falta de confiança, manter a alta segurança e a trilha de auditoria é um desafio. A segurança dessa abordagem é alta e a descentralização também é alta, dadas as desvantagens acima.

Interoperabilidade entre cadeias com Light Client + Oracle

Após as abordagens de ponte de alto custo, mais implementações nascem para reduzir esse custo. A tecnologia de cliente leve tornou-se a norma mais recente para simplificar as verificações de cadeia cruzada. O processo é como se segue:

Primeiro, o usuário transfere os ativos X para um contrato de protocolo de interoperabilidade entre cadeias na cadeia A
Uma mensagem de transferência é definida em contrato e é captada por nós de retransmissão descentralizados
Os nós enviam provas para o contrato do protocolo na cadeia B
As atualizações do cabeçalho do bloco (cliente leve) são tratadas pela rede Oracle para garantir a entrega e a validade
O usuário retira os ativos Y do contrato do protocolo na cadeia B após a validação
A vantagem dessa abordagem é que nenhum token ou cadeia intermediária é necessária desde a transferência até a conclusão. A confirmação instantânea é possível após a atualização dos cabeçalhos dos blocos. Os contras são 1) riscos de conluio de Oracles, 2) devido à falta de confiança, mantendo alta segurança e a trilha de auditoria é desafiadora. A segurança dessa abordagem é média, enquanto a descentralização é alta.

Interoperabilidade entre cadeias com cadeia de relés

Com base nas lições da abordagem Oracle, uma solução de cadeia de retransmissão pura também está presente. O processo é um pouco diferente:

O usuário transfere os ativos X para um contrato de protocolo de interoperabilidade entre cadeias na cadeia A
Uma mensagem de transferência é definida em contrato e é captada por nós de retransmissão descentralizados
Os nós enviam provas para o contrato da cadeia de retransmissão
Os validadores de cadeia de retransmissão subjacentes lidam com atualizações de bloco para garantir a entrega e a validade
Após a validação, os nós retransmissores encaminham a mensagem de transferência para o contrato do protocolo na cadeia B
O usuário retira os ativos Y do contrato do protocolo na cadeia B
A vantagem dessa abordagem sobre a solução simples da Oracle são as taxas mais baratas das cadeias de retransmissão que consomem a maior parte dos custos. A confirmação instantânea é possível depois que os blocos são atualizados, o que é crucial para resolver tempos de atraso mais longos. O problema é que o próprio protocolo pode não suportar um ecossistema de todas as cadeias. A segurança é alta (dentro do ecossistema), e a descentralização também é alta.

Camada de infraestrutura de cadeia cruzada com cliente leve + cadeia de retransmissão

A solução de próxima geração está focada na camada de infraestrutura de cadeia cruzada, resolvendo todos os problemas fundamentais acima. Combina a tecnologia light client com uma cadeia de retransmissão para incorporar todas as cadeias:

O usuário transfere os ativos X para um contrato de interoperabilidade da camada de infraestrutura de cadeia cruzada na cadeia A
Uma mensagem de transferência é definida em contrato e é captada por nós de retransmissão descentralizados
Os nós enviam provas para o contrato de interoperabilidade da cadeia de retransmissão
As atualizações do cabeçalho do bloco (cliente leve) são tratadas por nós mantenedores descentralizados para garantir a entrega e a validade
Após a validação, os nós do retransmissor encaminham a mensagem de transferência para o contrato de interoperabilidade na cadeia B
O usuário retira os ativos Y do contrato de interoperabilidade na cadeia B
Esta solução garante a interoperabilidade com taxas muito baratas devido à implementação de uma cadeia de retransmissão. Ele também fornece uma confirmação instantânea depois que os cabeçalhos dos blocos são atualizados. O maior desafio é a alta complexidade de otimizar clientes leves na cadeia de retransmissão. Ao realizar pesquisas e engenharia suficientes, essas otimizações devem suportar os benefícios que os outros não podem resolver. A segurança é muito alta e a descentralização é alta.

Sobre o protocolo MAP

Das soluções de cadeia cruzada, ainda temos que ver uma que resolva todos os problemas acima. Até que o Protocolo MAP seja implementado. Após 3 anos de pesquisa e desenvolvimento complexos, o MAP Protocol finalmente alcançou a camada Omnichain com a tecnologia Light Client + relay chain sem compromisso. A MAP implementou os princípios Omnichain com as seguintes propriedades:

Pronto para Desenvolvedor
Cobertura de toda a cadeia
Custo Mínimo
Finalidade de segurança
Confirmação instantânea

O protocolo MAP é a camada de infraestrutura para dar suporte à construção de pontes, DEXes, protocolos de interoperabilidade e muito mais. Ele suporta a verificação por clientes leves na cadeia de retransmissão MAP diretamente – para reduzir custos. E fornece incentivos embutidos em cada componente para os desenvolvedores de dapp ganharem ou apresentarem aos usuários finais. O MAP suporta cadeias EVM e não EVM – a camada de protocolo é isomórfica com todas as cadeias.

Para o futuro, o MAP é a infraestrutura por trás de todas as cadeias que serão a nova camada base. Os desenvolvedores não são mais restritos por sua cadeia de escolha e podem se concentrar no próprio produto dapp. O futuro é Omnichain, e mais modularização e incentivo são o caminho a seguir.