1. Todos o Querem, Poucos o Conseguem Empunhar

1.1 A Terra das Oportunidades: Bitcoin

(Fonte: companiesmarketcap)

Bitcoin, criado em 2008 por um desenvolvedor anônimo, cresceu para se tornar um ativo massivo, ocupando o 7º lugar em capitalização de mercado entre todas as classes de ativos. Agora é reconhecido não apenas por instituições financeiras, mas até mesmo pelo Presidente dos EUA. Atualmente, a capitalização de mercado do Bitcoin é semelhante à da prata. Considerando que a adoção do Bitcoin ainda é relativamente baixa e que sua capitalização de mercado é apenas um décimo da do ouro, seu potencial futuro de crescimento permanece altamente promissor.

Apesar do crescimento imenso do Bitcoin como ativo, ainda existe uma grande falha - o seu nível de utilização. Ativos tradicionais como ações e obrigações podem ser usados numa vasta gama de produtos financeiros, mas as aplicações financeiras do Bitcoin ainda são muito limitadas, tanto tecnicamente quanto na prática. Semelhante aos dias da fronteira do Oeste Americano, o Bitcoin representa uma terra inexplorada de oportunidades.

1.2 Tentativas de Utilizar BTC

Devido à sua enorme capitalização de mercado, inúmeras empresas e protocolos procuraram aproveitar o Bitcoin para a criação adicional de crédito. As principais tentativas de utilizar BTC até agora incluem:

• Finanças Centralizadas: As instituições financeiras tradicionais oferecem vários produtos financeiros baseados em Bitcoin. A CME fornece futuros e opções de Bitcoin, a Coinbase oferece empréstimos garantidos por BTC e várias instituições lançaram ETFs baseados em BTC para investidores.
• Custódia de Pontes: Serviços como WBTC e cbBTC envolvem BTC de forma centralizada, permitindo que seja usado em outras redes. Ao depositar BTC com custodiantes como BitGo ou Coinbase, os utilizadores recebem uma quantidade equivalente de WBTC ou cbBTC emitida na rede Ethereum.
• Ponte On-chain: Para eliminar a dependência de custódios centralizados, vários protocolos tentaram bridgear o BTC de forma segura para outras redes. No entanto, alcançar um mecanismo de bridging BTC completamente descentralizado continua a ser um desafio elevado, uma vez que algum nível de pressupostos de confiança é inevitável.
• Soluções de Escalonamento: Os esforços para usar BTC em sidechains e soluções Bitcoin L2 têm aumentado recentemente. No entanto, essas abordagens ainda envolvem pressupostos de confiança adicionais. A equipe Taproot Wizards está a trabalhar na mitigação deste problema usando OP_CAT.
• Stablecoins baseadas em BTC: Protocolos como Yala e Avalon surgiram, emitindo stablecoins garantidas por BTC de forma semelhante ao MakerDAO. No entanto, essas soluções também enfrentam o problema fundamental de exigir pressupostos de confiança ao conectar BTC.

Ao examinar essas tentativas de utilizar BTC, revela-se um desafio comum - é difícil usar o Bitcoin de forma nativa. Uma das maiores forças do Bitcoin é a sua segurança, mas se suposições de confiança adicionais enfraquecerem essa segurança, cria uma barreira de entrada significativa para os detentores de BTC. Esta é a principal razão pela qual o nível de utilização do Bitcoin permanece relativamente baixo.

1.3 Babilônia: Utilização nativa de BTC

Aqui é onde@babylonlabs_iofoca-se. A Babilónia permite aos detentores de BTC apostar o seu Bitcoin nativamente na rede Bitcoin e participar na validação de outros protocolos PoS, ganhando recompensas adicionais.

Graças à vantagem de utilizar BTC sem suposições adicionais de confiança, Babylon atingiu rapidamente mais de $5 mil milhões em TVL. O TVL poderia ter sido ainda maior se não existissem limites de staking no BTC.

Mas espere, a linguagem de script do Bitcoin não é completa de Turing, o que significa que não pode suportar facilmente contratos inteligentes complexos. Então, como é que o Babylon consegue alcançar esta funcionalidade? Neste artigo, iremos explorar os mecanismos específicos por trás da operação do Babylon.

2. Babilônia

Como construir a Torre de Babel, poderemos alguma vez alcançar uma verdadeira utilização nativa de BTC?

2.1 Visão Geral da Babilônia

A missão da Babilônia é dimensionar o Bitcoin para garantir o mundo descentralizado. Embora seja amplamente conhecida como um protocolo de staking de BTC, a Babilônia também oferece serviços de timestamping de Bitcoin, formando um conjunto de protocolos de compartilhamento de segurança BTC.

Babilônia é composta por dois protocolos principais:

• Timestamping do Bitcoin: Isso permite que as cadeias PoS registem os seus dados de bloco na rede Bitcoin. Ao fazê-lo, as cadeias PoS podem mitigar ataques de longo alcance, reduzir os períodos de desvinculação de stake, proteger transações críticas e beneficiar da resistência à censura do Bitcoin ao nível da rede.
• Staking de Bitcoin: Isso permite aos detentores de BTC congelar os seus BTC nativamente na rede Bitcoin e participar na validação de outros protocolos de PoS, ganhando recompensas adicionais no processo.

2.2 Arquitetura da Babilônia

(Fonte: Babilônia)

A arquitetura fundamental da Babilônia está ilustrada no diagrama acima, com a Cadeia de Babilônia, construída no Cosmos SDK, no seu núcleo. Além da Cadeia de Babilônia, vários programas periféricos facilitam o BTC staking e a comunicação com o Bitcoin e outras Zonas de Consumidores. As Zonas de Consumidores referem-se às cadeias PoS que registam checkpoints na rede Bitcoin através da Babilônia.

A Babylon Chain é composta por vários módulos que desempenham funções essenciais dentro do ecossistema, incluindo a gestão do conjunto de validadores, o rastreamento dos cabeçalhos de bloco do Bitcoin, a submissão de checkpoints à rede Bitcoin e a gestão do conjunto ativo de fornecedores de finalidade relacionados com o staking de BTC. Para referência, um fornecedor de finalidade é semelhante a um operador AVS na EigenLayer, ou seja, participa na validação de outros protocolos PoS.

Além disso, Babylon implementou vários programas de apoio para facilitar a comunicação suave entre a rede Bitcoin e a Babylon Chain:

• Vigilantes: Um conjunto de programas que atua como um retransmissor de dados entre Bitcoin e Babilônia.
• Monitores: Um conjunto de programas que garante a consistência entre a Babylon Chain e a rede Bitcoin.

Através deste ecossistema, a Babilónia permite à indústria cripto aproveitar a segurança forte do Bitcoin e a sua liquidez profunda. Agora, vamos explorar com mais detalhe as duas funcionalidades principais da Babilónia: Carimbo Temporal do Bitcoin e Staking do Bitcoin.

3. Como funciona o carimbo de data/hora do Bitcoin

3.1 Por que é a Desvinculação de Stake Lenta?

Qualquer pessoa que tenha apostado tokens antes saberia que desfazer normalmente requer um período de espera de 1 a 2 semanas. Durante este tempo, os tokens não podem ser usados ou render juros, causando ineficiências. Mas por que é que desfazer requer um período de espera? Por que não permitir retiradas instantâneas?

A razão mais simples é a segurança da rede. Se o desbloqueio fosse instantâneo, grandes quantidades de tokens poderiam ser desbloqueadas em resposta às flutuações do mercado, enfraquecendo significativamente a segurança da rede. No entanto, para além da segurança, há outra razão fundamental: prevenir ataques de longo alcance.

3.2 Ataque de Longo Alcance

(Fonte: AP)

Um ataque de longo alcance refere-se a um ataque no qual validadores maliciosos criam um novo fork a partir de blocos passados, tentando substituir a cadeia canónica atual. Se a cadeia bifurcada maliciosa se tornar tão longa quanto ou mais longa do que a cadeia canónica, os novos nós que se juntam à rede podem ficar confusos sobre qual cadeia é a legítima, levando a possíveis problemas. Mas espere—será que isso é mesmo possível?

Numa rede PoW, um ataque de longo alcance é quase impossível. Para acompanhar a cadeia canónica atual, os atacantes precisariam recriar novos blocos do passado, ultrapassando o poder computacional da rede existente, o que é praticamente inviável.

Da mesma forma, numa rede PoS em funcionamento adequado, este ataque também é impossível. Criar um novo fork requer que os validadores maliciosos assinem múltiplos blocos conflituosos, o que é considerado dupla assinatura - uma violação do protocolo que resulta em penalidades de slashing.

No entanto, e se o desbloqueio fosse permitido imediatamente?

Ao contrário das redes PoW, as redes PoS não exigem uma enorme potência computacional para gerar blocos. Isso significa que se os validadores maliciosos retirarem os seus ativos da cadeia existente e depois criarem uma nova cadeia bifurcada a partir de um bloco passado onde as suas chaves de validação ainda eram válidas, poderiam potencialmente alcançar a cadeia canônica atual. Neste cenário, os novos nós que se juntarem à rede podem ter dificuldade em determinar qual é a cadeia legítima, o que pode levar a confusão e riscos de segurança.

(Fonte: Babilónia)

Se um ataque de longo alcance for bem-sucedido, os validadores maliciosos podem explorar mecanismos de ponte para roubar fundos. Por exemplo, suponhamos que um atacante malicioso chamado John transfira 1M de tokens RUG da cadeia RugPull para a Osmose e os troque por tokens OSMO. Esta transferência ocorre através do IBC, que funciona bloqueando os tokens RUG originais na cadeia RugPull enquanto cunha uma quantidade equivalente de tokens RUG na cadeia da Osmose.

(Fonte: Babilônia)

Se assumirmos que John executa com sucesso um ataque de longo alcance na cadeia RugPull, ele pode omitir maliciosamente a transação que bloqueou os tokens RUG para enviá-los à cadeia Osmosis na nova cadeia bifurcada. Como resultado, John adquiriria efetivamente tokens OSMO gratuitamente.

Para evitar ataques de longo alcance, é necessário um período de desvinculação de participação de certa duração. Os atores maliciosos não podem executar um ataque de longo alcance durante o período de desvinculação (se o tentarem, enfrentarão penalidades de redução). Além disso, durante este período, os participantes da rede podem chegar a um consenso social sobre qual cadeia é a cadeia canônica. Como resultado, mesmo que ocorra um ataque de longo alcance posteriormente, é improvável que a cadeia bifurcada maliciosa seja aceite pela rede.

3.3 Vamos Reduzir o Tempo de Desconexão da Participação com BTC Timestamping

O período de desvinculação da participação é um método eficaz para prevenir ataques de longo alcance, mas tem algumas desvantagens.

O primeiro problema é que ele depende do consenso social para contrariar ataques. Embora a comunicação off-chain entre os participantes ao longo de um período suficientemente longo possa desempenhar um papel crucial, não é uma solução 100% infalível.

A segunda questão é que, como mencionado anteriormente, um período de desbloqueio mais longo afeta negativamente a experiência do usuário e a liquidez.

A Babilónia introduz uma solução chamada Bitcoin Timestamping, que permite às cadeias PoS reduzir significativamente os períodos de desbloqueio para apenas algumas horas. Isso permite que as cadeias PoS gravem dados do bloco da cadeia canónica na rede Bitcoin.

Com a marcação de data e hora, mesmo que os validadores maliciosos tentem um ataque de longo alcance e afirmem que sua cadeia bifurcada é a cadeia canônica, seu ataque não terá sucesso, porque os dados da cadeia canônica original já estão registrados com segurança na rede Bitcoin. Desde que a segurança do Bitcoin permaneça intacta, o ataque está garantido a falhar. Uma vez que este enfoque elimina a necessidade de consenso social, permite uma redução drástica no período de desvinculação necessário.

(Fonte: Babilônia)

Aqui, o carimbo de data/hora do Bitcoin é registado utilizando o opcode OP_RETURN na rede Bitcoin. OP_RETURN é uma instrução que permite armazenar até 80 bytes de dados arbitrários na rede Bitcoin. Ao contrário das transações regulares de Bitcoin, o OP_RETURN não pode ser utilizado para transferências de fundos e não gera UTXOs.

Uma consideração chave é se todas as cadeias PoS podem criar diretamente checkpoints na rede Bitcoin. Os blocos de Bitcoin são pequenos em tamanho, têm um tempo de bloco de 10 minutos e o OP_RETURN só pode armazenar um máximo de 80 bytes de dados. Se várias cadeias PoS enviassem transações de checkpoint frequentes, a rede Bitcoin não seria capaz de lidar com a carga.

Para resolver este problema, a Babylon introduz a Babylon Chain, que agrega pontos de verificação de várias cadeias PoS via IBC e depois submete um único ponto de verificação agregado à rede Bitcoin.

Um componente chave deste processo é o Vigilante Relayer, uma entidade responsável por ler checkpoints de um nó de Babilônia, embalá-los em transações OP_RETURN e depois submetê-los à rede Bitcoin. O sistema requer pelo menos um Vigilante Relayer honesto e ativo para funcionar corretamente.

(Fonte: Babilônia)

A marcação de tempo BTC ocorre da seguinte forma: as cadeias PoS enviam checkpoints contendo informações de bloco para a cadeia de Babilônia. A cadeia de Babilônia então envia um checkpoint dos blocos de Babilônia para a rede Bitcoin no bloco final de cada época.

(Fonte: Babilónia)

Mesmo que ocorra um ataque de longo alcance, o checkpoint da cadeia bifurcada maliciosa sempre terá um timestamp posterior ao checkpoint da cadeia canônica. Isso significa que os participantes da rede podem simplesmente verificar o checkpoint da rede Bitcoin para identificar facilmente forks maliciosos. Uma vez que esta abordagem elimina a necessidade de consenso social, o período de desvinculação da participação pode ser reduzido de várias semanas para apenas algumas horas.

3.4 Mais do que Rápido Stake Unbonding

A marcação temporal do Bitcoin da Babilónia faz mais do que apenas melhorar a UX e a eficiência da liquidez ao reduzir os períodos de desbloqueio das PoS chain - também oferece vários benefícios adicionais.

3.4.1 Lentidão na Finalização de Transações Importantes

Ao adotar a finalidade lenta através de Babilônia, as cadeias PoS podem alcançar um nível de segurança comparável ao do Bitcoin. Quando um bloco PoS contendo uma transação específica é registrado na rede Bitcoin e confirmado por seis blocos de Bitcoin, a transação se torna irreversível - desde que a segurança do Bitcoin permaneça intacta.

Este mecanismo é útil para processar transações de alto valor, como compras de imóveis, onde a segurança absoluta é necessária. Além disso, para as zonas recém-lançadas do Cosmos, que podem ter uma segurança mais fraca, implementar uma finalização lenta pode fornecer uma camada extra de proteção para o processamento seguro de transações.

3.4.2 Resistência à Censura ao Nível do Bitcoin

A marcação de tempo do Bitcoin também pode ajudar a restaurar a vivacidade no caso de um ataque de censura a uma cadeia PoS. Para resolver isso, Babilônia introduz um conceito especial chamado modo de rollup.

Num blockchain PoS tradicional, pelo menos dois terços (2/3) dos validadores devem ser honestos para manter a resistência à censura. No entanto, com o modo de rollup do Babylon, apenas metade (1/2) dos validadores precisa ser honesta para alcançar resistência à censura, melhorando significativamente a resiliência da cadeia contra ataques.

(Fonte: Babilónia)

Se um utilizador da cadeia PoS acredita que uma transação específica está a ser censurada, pode apresentar uma queixa de censura (a secção vermelha no diagrama) à cadeia de Babilónia, iniciando o processo de entrar no modo de rollup. A queixa de censura contém o hash da transação censurada.

Se, após seis confirmações de bloco Bitcoin, a transação censurada suspeita ainda não tiver sido incluída na cadeia PoS, os validadores honestos enviarão suas opiniões sobre a cadeia PoS para Babilónia. Se, após mais seis confirmações de bloco Bitcoin, nenhum ponto de verificação relacionado com a transação censurada for detetado em qualquer bloco Bitcoin, os validadores honestos e os utilizadores entrarão no modo de agrupamento.

Em modo de rollup, qualquer validador pode propor um conjunto de transações PoS e, se os validadores detentores de pelo menos metade (1/2) da participação total assinarem o conjunto, a transação será finalizada na rede Bitcoin, impedindo efetivamente a censura.

4. Como funciona o Bitcoin Staking

4.1 Visão Geral do Bitcoin Staking

A marcação temporal do Bitcoin permite que as cadeias PoS aproveitem a segurança do Bitcoin para reduzir os períodos de desvinculação de participação e aumentar a resistência à censura, mas isso apenas utiliza parcialmente a segurança do Bitcoin.

Além da Marcação de Tempo do Bitcoin, o Babylon apresenta o Bitcoin Staking, que implementa nativamente o staking de BTC usando a linguagem de script do Bitcoin. Isso permite que outros protocolos PoS se beneficiem da segurança criptoeconômica do BTC em staking. O protocolo de staking é projetado como um plug-in modular, tornando-o facilmente adaptável para vários protocolos de consenso PoS.

Para os detentores de BTC, o Bitcoin Staking da Babilónia é uma oportunidade de investimento atrativa, uma vez que podem apostar BTC ao nível de segurança do Bitcoin sem depender de entidades externas, ao mesmo tempo que recebem recompensas de protocolos externos.

Vamos definir alguns termos-chave:

• Protocolos que aproveitam a segurança criptoeconômica do BTC apostado através do Babylon's Bitcoin Staking são chamados de BSNs (Bitcoin Secured Networks) - análogos a @eigenlayerconceito de AVS (Actively Validated Services) de .
• Entidades que recebem BTC delegado de stakers e participam na validação de BSNs são chamadas de Provedores de Finalidade — semelhante aos operadores AVS da EigenLayer.

Mas espere—ao contrário do Ethereum, a rede Bitcoin não é Turing-completa, o que torna difícil implementar contratos complexos de staking. Então, como é que o Babylon consegue isso?

Vamos explorar os detalhes com um exemplo do blog da Babilônia.

4.2 Como o Contrato de Staking é Implementado

4.2.1 Bloqueio

// Contrato V0: adicionar uma condição de bloqueio ao UTXO de apostas de Alice

condição-1 (travamento): time_lock = 1000 & alice_public_key

Vamos supor que a Alice aposte BTC e também atue como um Fornecedor de Finalidade. Para implementar a aposta em BTC, é necessário um mecanismo para bloquear BTC. Isso é alcançado configurando uma das condições de gastos UTXO para que apenas a Alice (a proprietária do BTC) possa retirar os fundos após um certo período de tempo (time_lock = 1000) usando sua chave pública da Alice.

4.2.2 Slashing

// Contrato V1: adição de corte ingênuo

condição-1 (bloqueio): time_lock = 1000 & alice_public_key; OU

condição-2 (corte): alice_eots_public_key

Um dos componentes essenciais que deve ser implementado no staking é o slashing. Se ocorrer uma ação maliciosa, um mecanismo de incentivo pode ser aplicado queimando o BTC apostado. Para conseguir isso, é definida uma segunda condição de gasto UTXO para que o slashing possa ocorrer se alguém possuir a chave EOTS de Alice.

Aqui, o EOTS (Extractable One-Time Signature) é uma assinatura implementada usando assinaturas Schnorr, que foi introduzida após a atualização Taproot do Bitcoin. Em termos simples, é um algoritmo que garante que, se um ator malicioso assinar duas vezes dois blocos diferentes na mesma altura usando a mesma chave, a chave secreta deles é publicamente revelada.

Olhando para isto com mais detalhes, uma assinatura Schnorr consiste numa chave privada x, uma chave pública P=xG, e um nonce aleatório k. O processo de assinatura é o seguinte: um nonce aleatório k é gerado, e o valor público R=kG é calculado a partir do nonce. Em seguida, um valor de hash e é calculado a partir da mensagem M e R, e o valor de assinatura s é calculado com base no nonce e e, onde s = k + ex. A assinatura final de Schnorr consiste em (s, R).

A ideia central do EOTS é que se a mesma chave for usada duas vezes para assinar, a chave privada é exposta. Se Alice assinar duas mensagens diferentes usando o mesmo nonce k, então a primeira assinatura é s1= k + e_1x e a segunda assinatura é s2= k + e_2x. Como s1, s2, e1, e2 são publicamente conhecidos, qualquer um pode resolver a chave privada de Alice x usando a equação x=(s1 - s2)/(e1 - e2).

Usando este mecanismo, se Alice assinar maliciosamente duas mensagens diferentes usando a mesma chave EOTS durante o processo de validação do BSN, quem detectar isso pode extrair a chave secreta EOTS de Alice. Uma vez revelada a chave secreta EOTS, o atacante pode roubar os BTC apostados por Alice ou queimar os BTC apostados por Alice como penalidade.

4.2.3 Aplicação de Queima

// Contrato V2

condição-1 (bloqueio): time_lock = 1000 & alice_public_key; OU

condição-2 (slashing): alice_eots_public_key & covenant_committee_quorum

// Transação de corte V0

inputs:

• input-1: o UTXO de staking, gasto usando a condição-2 acima

resultados:

• output-1: valor = 0.99 Bitcoin, proprietário = 0000...0000

// Pré-aprovação V0: aplicando queima

// Comité de pacto assina previamente a referida tx de redução, como sua pré-aprovação

Uma vez que já discutimos anteriormente as condições em que o corte ocorre, vamos agora examinar como o corte é realmente aplicado. Impor o corte é crucial porque, se Alice se envolver em comportamento malicioso, ela pode tentar retirar seu BTC antes que alguém detete a má conduta, extraia sua chave secreta EOTS e queime seu BTC.

Para evitar isso, o corte deve ser implementado de forma a transferir à força o BTC para um endereço de queima predefinido (0000…0000). Para isso, a segunda condição de gasto UTXO inclui um Quorum do Comitê da Aliança. O Comitê da Aliança é responsável por verificar se o corte é legítimo. Ao incorporar um esquema de multi-assinatura (M-de-N), o sistema garante que Alice não pode retirar unilateralmente seu BTC para sua própria carteira antes que o corte seja executado.

A vantagem desta abordagem é que, desde que Alice se comporte de forma honesta, a sua assinatura EOTS nunca é exposta, o que significa que o Comitê da Aliança não pode apreender os seus fundos. Portanto, Alice não precisa confiar no Comitê da Aliança, pois eles não podem agir contra ela, a menos que ela se envolva em comportamento malicioso.

4.2.4 Delegação Segura

// Contrato V3: permitindo a delegação segura

condição-1 (bloqueio): time_lock = 1000 & alice_public_key; OU

condição-2 (corte): alice_public_key & validator_eots_public_key & comitê_do_pacto_comitiva

// Transação de corte V0

entradas:

• entrada-1: a estaca UTXO, gasta usando a condição-2 acima

outputs:

• output-1: valor = 0.99 Bitcoin, proprietário = 0000...0000

// Pré-aprovação V1

// Alice pré-assina a tx de slashing como sua pré-aprovação.

// Comité do Pacto pré-assina a transação de redução de penalização como sua pré-aprovação.

Alice pode apostar diretamente BTC e participar na validação de outros protocolos PoS como fornecedora de finalidade. No entanto, a maioria dos utilizadores optará por delegar a sua participação em BTC.

Para implementar isso, adicionar a chave EOTS do validador à segunda condição garante que, se o validador se envolver em comportamento malicioso, o BTC de Alice possa ser queimado. No entanto, o problema aqui é que se o validador conluir com o comitê do pacto, eles poderiam roubar o BTC de Alice, forçando Alice a confiar no validador.

Uma solução simples para este problema é incluir também a chave pública de Alice na segunda condição. Desta forma, queimar BTC exigiria também a assinatura de Alice, impedindo o roubo não autorizado de BTC.

Para conseguir isso, Alice assina previamente uma transação declarando que “se ocorrer uma punição, o BTC deve ser enviado para um endereço de queima”. Neste caso, se o validador agir de forma maliciosa e sua chave EOTS for exposta, e se o comitê de pacto executar uma multi-assinatura, o BTC será enviado para o endereço de queima, aplicando o processo de punição.

4.2.5 Prevenção de Ataque Malicioso com Aplicação de Penalização Atômica

/ Contrato V3

condição-1 (bloqueio): time_lock = 1000 & chave_pública_de_alice; OU

condição-2 (slashing): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Transação de redução V0

entradas:

• input-1: o UTXO de staking, gasto usando a condição-2 acima

outputs:

• output-1: valor = 0.99 Bitcoin, proprietário = 0000...0000

// Pré-aprovação V2: aplicação de penalização atômica ao delegado

// A pré-aprovação de Alice é uma assinatura de adaptador da transação de penalização

// ela gerada usando a chave pública EOTS do validador.

// O comité do pacto pré-assina a transação de corte como a sua pré-aprovação.

E se um validador mal-intencionado tiver como alvo apenas stakers específicos para corte? Para evitar isso, Babylon introduz Adaptor Signatures.

Alice criptografa sua assinatura usando a chave pública EOTS do validador como uma assinatura de adaptador. Se o validador tentar penalizar apenas Alice, eles devem usar sua chave privada EOTS. Devido à natureza das Assinaturas de Adaptador, isso resultaria na exposição da chave privada EOTS do validador, removendo qualquer incentivo para os validadores se envolverem em comportamento malicioso.

4.2.6 Implementação de Penalização Parcial

// Contrato V3

condição-1 (bloqueio): time_lock = 1000 & alice_public_key; OU

condição-2 (corte): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Transação de penalização V1: permitindo penalização parcial

entradas:

• entrada-1: a estaca UTXO, gasta usando a condição-2 acima

outputs:

• output-1: valor = 0,09 Bitcoin, proprietário = 0000...0000

• output-2: valor = 0.9 Bitcoin,

condições:

• condição-1: time_lock = 500 & alice_public_key

// Pré-aprovação V2

A pré-aprovação de Alice é uma assinatura de adaptador da transação de corte

ela gerou usando a chave pública EOTS do validador.

// O comité do pacto pré-assina a tx de redução, como sua pré-aprovação.

Mas você não acha que queimar todos os Bitcoins em caso de redução é muito extremo? Para resolver isso, apenas uma parte dos Bitcoins (por exemplo, queimando apenas 10% e devolvendo os restantes 90% após um certo período) pode ser queimada. Isso pode ser implementado dividindo as saídas da transação de redução em duas, como descrito acima.

4.2.7 Restaking Mais!

Contrato V4: Habilitando a retomada

condição-1 (bloqueio): time_lock = 1000 & alice_public_key; OU

condição-2 (corte): alice_public_key & qualquer assinatura da lista[validator_eots_public_key] & covenant_committee_quorum

O BTC delegado de Alice pode participar na validação de múltiplos protocolos de PoS, não apenas um. Se um validador participa na validação de diferentes protocolos de PoS usando a mesma chave EOTS, qualquer vazamento num local poderia afetar outros sistemas. Portanto, os fornecedores de finalidade de Babilónia devem usar chaves EOTS diferentes para diferentes sistemas de PoS, e uma lista de chaves EOTS é introduzida na segunda condição.

4.3 Resumo

Ao contrário das redes PoS como Ethereum ou Solana, a rede do Bitcoin funciona com PoW, por isso o conceito de staking não existe inherentemente. No entanto, a Babylon implementou o bloqueio de BTC, cortes, e funcionalidades de delegação necessárias para o staking através das características dos UTXOs, da linguagem de script do Bitcoin, e de vários algoritmos de assinatura. Isso permite que os detentores de BTC ganhem lucros adicionais nativamente ao utilizar BTC, sem necessidade de pontes ou serviços de custódia.

5. Libertar o Potencial do BTC para o Mundo Descentralizado

Para além da Lightning Network, nenhum outro protocolo herda totalmente a segurança da rede Bitcoin. No entanto, tal como a rede Bitcoin, a funcionalidade da Lightning Network é bastante limitada e é demasiado preciosa para abdicar da segurança robusta e da liquidez massiva do Bitcoin.

Babylon habilitou o uso da segurança do Bitcoin de duas maneiras diferentes através da Marcação de Tempo do Bitcoin e do Staking de Bitcoin. O primeiro usa o Bitcoin como um servidor de marcação de tempo para evitar reverter transações ou bifurcações maliciosas, enquanto o último alavanca a poderosa liquidez do BTC como segurança cripto-econômica, permitindo que os detentores de BTC ganhem lucros adicionais de forma nativa.

Atualmente, aproximadamente 55.000 BTC estão depositados em Babylon, o que está em linha com o limite de depósito estabelecido por Babylon. Cerca de 3,9% do fornecimento total de ETH é re-estacado em EigenLayer. Considerando isso, embora os detentores de BTC possam ser conservadores ao utilizar BTC, o potencial de crescimento de Babylon, com apenas cerca de 0,2% do fornecimento total de BTC atualmente em jogo, vale a pena considerar.

Declaração de exoneração de responsabilidade:

1. Este artigo é reproduzido a partir de [ 100y.eth]. Todos os direitos autorais pertencem ao autor original [100y.eth]. Se houver objeções a esta reedição, entre em contato com o Gate Learn equipe, e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipa Gate Learn faz traduções do artigo para outras línguas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que seja mencionado.