Da mesma forma, a Babilônia permite aos utilizadores de Bitcoin apostar BTC para melhorar a segurança das redes PoS, melhorar a segurança da rede enquanto ganham recompensas e manter a auto-guarda do Bitcoin. Uma vez que a mainnet do Bitcoin não pode suportar contratos inteligentes completos, o design de arquitetura e os cenários de aplicação da Babilônia diferem significativamente do EigenLayer. Anurag Arjun, ex-cofundador da Polygon e fundador da Avail, também afirmou nas redes sociais que, comparado a projetos como Eigenlayer, a Babilônia parece ser mais subestimada. Isso irá ganhar impulso de desenvolvimento, o que poderá ser um grande impulso para o ecossistema BTC.

Este artigo tem como objetivo fornecer uma compreensão mais profunda das semelhanças e diferenças entre os dois projetos, comparando-os a partir de vários aspectos.
Primeiro, vamos olhar para a estrutura do protocolo de carimbo de data/hora do Bitcoin:

A arquitetura da Babilónia é mostrada no diagrama acima. É composta por três partes, com dois níveis de pontos de controlo:
Bitcoin, como a camada de serviço de carimbo de data.- A cadeia de Babilónia (uma cadeia construída na Cosmos SDK), é a camada intermédia.- A blockchain PoS (por exemplo, outras zonas Cosmos) é o consumidor de segurança.Uma consideração de design importante é que o Bitcoin tem uma capacidade muito limitada para transportar dados. Neste caso, a cadeia de Babilônia serve múltiplas funções:
Agrega fluxos de checkpoints de muitas cadeias de consumidores PoS, para que apenas um fluxo de checkpoint precise ser inserido na rede Bitcoin para registar eventos em todas as cadeias de consumidores PoS.- Os seus checkpoints na rede Bitcoin podem ser compactados usando técnicas criptográficas (por exemplo, assinaturas agregadas).- Recebe checkpoints das cadeias de PoS do consumidor através do protocolo IBC.- Verifica a disponibilidade de dados de checkpoints das cadeias do consumidor PoS, para que os atacantes não consigam carimbar dados indisponíveis.Esta estrutura ajuda as cadeias PoS a melhorar a sua segurança, por exemplo, contra ataques de longo alcance.

Para proteger uma cadeia PoS de ataques de longo alcance, podemos enviar os checkpoints de bloco da cadeia PoS para o BTC e escolher o fork com um timestamp BTC anterior como o fork válido. Isso deixa apenas duas possibilidades:
Para além de abordar ataques de longo alcance, o timestamp BTC irreversível para blocos PoS fornece outras vantagens de segurança para cadeias PoS:
Aqui está um exemplo de Bitcoin staking:
Alice tem um Bitcoin e quer apostá-lo numa cadeia PoS. Primeiro, ela entra num pacto de aposta ao enviar uma transação de aposta para a cadeia Bitcoin. Esta transação é uma transação Bitcoin que bloqueia o seu Bitcoin num cofre autogerido. O Bitcoin bloqueado só pode ser desbloqueado pela chave privada de Alice através de um dos dois seguintes caminhos:
(1) Alice inicia uma "transação de desbloqueio", caso em que o Bitcoin será desbloqueado e devolvido a Alice dentro de três dias.
(2) Alice inicia uma "transação de corte", enviando o Bitcoin para um endereço de gravação.
Assim que esta transação de staking entrar na cadeia de Bitcoin, Alice pode começar a assinar blocos com a sua chave para validar a cadeia de PoS.
Durante o seu dever de verificação, existem dois caminhos possíveis.

Origem: https://docs.babylonchain.io/papers/btc_staking_litepaper(CN).pdf
O “caminho feliz” (figura (a)) é onde Alice segue honestamente o protocolo e, quando ela quer retirar suas Bitcoins, ela inicia um pedido de desvinculação enviando uma transação de desvinculação para a cadeia de Bitcoins (figura (b)). Assim que a transação de desvinculação entra na cadeia de Bitcoins, o dever de validação de Alice na cadeia de PoS termina e, após três dias, Alice pode retirar e recuperar suas Bitcoins. A cadeia de PoS também recompensará Alice com prêmios.
O “caminho infeliz” (figura (b)) é onde Alice se torna maliciosa e participa num ataque de gasto duplo na cadeia PoS. Neste caso, o pacto de stake assegura que a chave privada de Alice será divulgada. Então, qualquer um pode enviar uma transação de slashing para a cadeia Bitcoin como Alice e queimar o seu Bitcoin. A existência deste caminho infeliz garante que um atacante será penalizado, o que dissuade todos de se comportarem mal - todos se comportam normalmente no “caminho feliz”.
Para a redução do mau comportamento, Babilónia utiliza assinaturas únicas extraíveis (EOTS). A ideia principal é que um utilizador pode assinar uma mensagem uma vez, semelhante a um esquema de assinatura normal. EOTS requer um parâmetro de rótulo extra (a altura do bloco é o parâmetro extra ao assinar um bloco durante a validação). Se o utilizador tentar assinar a mesma mensagem duas vezes com o mesmo rótulo (assinando dois blocos na mesma altura), a chave privada do utilizador pode ser extraída dessas duas assinaturas.
Babilónia:

Diagrama da estrutura do protocolo de Babilónia
EigenLayer:

Diagrama da estrutura da EigenLayer
Babilónia é composta pelo protocolo de carimbo de data/hora do Bitcoin e pelo protocolo de Staking, e uma vez que o Bitcoin não é Turing-completo, grande parte do trabalho de processamento precisa ser feito por uma cadeia separada, razão pela qual o protocolo de Babilónia tem a sua cadeia construída no Cosmos SDK, com o seu próprio conjunto de nodos de validação correspondentes. Inclui também componentes independentes como o Gerenciador EOTS e o Provedor de Finalidade.
Por outro lado, EigenLayer é essencialmente um conjunto de contratos inteligentes que podem aceitar participações de usuários e gerenciar contratos AVS, com a rede Ethereum subjacente executando e garantindo segurança.
Em segundo lugar, os dois protocolos diferem na implementação do corte.
Uma vez que o Ethereum suporta a funcionalidade de contratos inteligentes, a lógica de corte da EigenLayer é implementada nos contratos, permitindo condições de corte mais complexas adaptadas a diferentes AVSs. Entretanto, se surgir uma situação que não possa ser resolvida pelas condições de corte predefinidas, haverá um comitê de veto fora da cadeia para resolvê-la através de votação.
Constrangido pela funcionalidade da mainnet do Bitcoin, Babylon implementa a lógica de slashing através do EOTS. Tem mais limitações e só pode implementar uma lógica de slashing relativamente simples para o caso de assinar repetidamente a mesma altura de bloco.
Devido às diferentes implementações de corte, os dois protocolos também diferem nos seus serviços alvo.
A capacidade da EigenLayer de implementar lógica de penalização complexa permite-lhe fornecer serviços de segurança para uma ampla gama de AVSs. Para a EigenLayer, a sua vantagem reside na sua consistência com o Ethereum. O Ethereum tem o maior ecossistema no espaço das criptomoedas, o que significa mais utilizadores e maior procura. A solução da EigenLayer tem o potencial para resolver as limitações do Ethereum, como a necessidade de pontes seguras e descentralizadas, soluções de disponibilidade de dados e camadas de sequenciador descentralizadas para soluções de Camada 2. Dentro do ecossistema Ethereum, usar o ETH como ativo de participação é considerado a abordagem “politicamente correta”. Assim, as aplicações construídas em torno da EigenLayer servirão principalmente o ecossistema Ethereum.
Por outro lado, Babylon serve principalmente cadeias PoS, especialmente aquelas no ecossistema Cosmos, porque o serviço de carimbo de data/hora do Bitcoin precisa passar mensagens entre a cadeia Babylon e as cadeias Cosmos via o protocolo IBC, o que limita sua aplicabilidade. Todas essas cadeias PoS requerem seus próprios conjuntos separados de nós de validação. Sua vantagem pode ser que o ecossistema Cosmos já cresceu para uma escala considerável e produziu muitas excelentes cadeias PoS, como Celestia, Osmosis, Axelar, dYdX e mais, que podem facilmente integrar-se com a cadeia Babylon e beneficiar da segurança do Bitcoin. Em contraste, o desenvolvimento da EigenLayer exigiria um número significativo de projetos para se re-desenvolver e adaptar-se às AVSs, colocando-o em uma desvantagem inicial. Além disso, a abordagem de construir cadeias de aplicativos usando o Cosmos SDK foi extensivamente validada e pode ser mais amigável para os desenvolvedores, dando a Babylon uma vantagem em termos de trazer o ecossistema Cosmos sob o guarda-chuva de segurança do Bitcoin.
Isto também está relacionado com as direções de desenvolvimento dos ecossistemas Ethereum e Cosmos. O ecossistema Ethereum primeiro construiu um núcleo de segurança massivo, a mainnet Ethereum, e depois formou muitas soluções de Camada 2 em cima dele, mas a interoperabilidade entre as Camadas 2 ainda não foi resolvida. Em contraste, o ecossistema Cosmos abordou primeiro a interoperabilidade entre diferentes zonas, mas carece de um núcleo de segurança poderoso, uma vez que a capitalização de mercado do Cosmos Hub é demasiado baixa para suportar esta responsabilidade. Portanto, há uma necessidade natural de encontrar um núcleo de segurança, e é aqui que entra o Babylon, com o objetivo de trazer a segurança do Bitcoin para o ecossistema. Ao mesmo tempo, a EigenLayer também espera trazer a segurança do Ethereum para o ecossistema Cosmos através da colaboração. Do ponto de vista arquitetural, a abordagem do Babylon pode ser mais adequada ao ecossistema Cosmos.
Artigos de referência
Aviso legal: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
As versões traduzidas deste artigo pela equipa Gate Learn não podem ser copiadas, disseminadas ou plagiadas sem mencionar Gate.com.





