1. Todos Querem, Poucos Podem Empunhar

1.1 A Terra das Oportunidades: Bitcoin

(Fonte: companiesmarketcap)

O Bitcoin, criado em 2008 por um desenvolvedor anônimo, tornou-se um ativo enorme, 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 de crescimento futuro permanece altamente promissor.

Apesar do crescimento imenso do Bitcoin como um ativo, ainda há uma falha significativa - seu nível de utilização. Ativos tradicionais como ações e títulos podem ser usados em uma ampla 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 buscaram alavancar o Bitcoin para a criação de crédito adicional. As principais tentativas de utilizar BTC até o momento incluem:

• Centralized Finance: As instituições financeiras tradicionais oferecem vários produtos financeiros baseados em Bitcoin. A CME oferece 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 Ponte: Serviços como WBTC e cbBTC envolvem BTC de forma centralizada, permitindo seu uso em outras redes. Ao depositar BTC com custódias como BitGo ou Coinbase, os usuários recebem uma quantidade equivalente de WBTC ou cbBTC emitida na rede Ethereum.
• Ponte On-chain: Para eliminar a dependência de custodiantes centralizados, vários protocolos tentaram conectar de forma segura o BTC a outras redes. No entanto, alcançar um mecanismo de ponte BTC completamente sem confiança continua sendo um desafio muito grande, pois 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 aumentaram recentemente. No entanto, essas abordagens ainda envolvem pressupostos de confiança adicionais. A equipe Taproot Wizards está trabalhando para mitigar esse problema usando OP_CAT.
• Stablecoins baseadas em BTC: Protocolos como Yala e Avalon surgiram, emitindo stablecoins lastreadas em BTC de forma semelhante ao MakerDAO. No entanto, essas soluções também enfrentam o problema fundamental de exigir suposições de confiança ao fazer a ponte com BTC.

Examinar essas tentativas de utilizar BTC revela um desafio comum - é difícil usar o Bitcoin de maneira nativa. Uma das maiores forças do Bitcoin é sua segurança, mas se suposições adicionais de confiança enfraquecem essa segurança, cria uma barreira de entrada significativa para os detentores de BTC. Esta é a razão principal 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_ioentra em foco. A Babylon permite que os detentores de BTC apostem seus Bitcoins nativamente na rede Bitcoin e participem da validação de outros protocolos PoS, ganhando recompensas adicionais.

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

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

2. Babilônia

Assim como a construção da Torre de Babel, podemos realmente alcançar a verdadeira utilização nativa do BTC?

2.1 Visão Geral da Babilônia

A missão da Babilônia é escalar 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 do Bitcoin, formando um conjunto de protocolos de compartilhamento de segurança do BTC.

Babilônia é composta por dois protocolos principais:

• Timestamp do Bitcoin: Isso permite que as cadeias de PoS façam checkpoint de seus dados de bloco na rede Bitcoin. Ao fazer isso, as cadeias de PoS podem mitigar ataques de longo alcance, reduzir períodos de desvinculação de participação, proteger transações críticas e se beneficiar da resistência à censura do Bitcoin ao nível da rede.
• Staking de Bitcoin: Isso permite que os detentores de BTC congelem seu BTC nativamente na rede do Bitcoin e participem da validação de outros protocolos de PoS, ganhando recompensas adicionais no processo.

2.2 Arquitetura da Babilônia

(Fonte: Babilônia)

A arquitetura fundamental de Babilônia é 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, diversos programas periféricos facilitam o staking de BTC e a comunicação com Bitcoin e outras Zonas de Consumidores. As Zonas de Consumidores referem-se a cadeias de PoS que registram checkpoints na rede Bitcoin através de Babilônia.

A Cadeia de Babilônia consiste em vários módulos que realizam funções essenciais dentro do ecossistema, incluindo gerenciar o conjunto de validadores, rastrear cabeçalhos de blocos do Bitcoin, enviar checkpoints para a rede Bitcoin e gerenciar o conjunto de provedores de finalidade ativos relacionados ao staking de BTC. Para referência, um provedor de finalidade é semelhante a um operador AVS no EigenLayer, o que significa que ele participa na validação de outros protocolos PoS.

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

• 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, Babylon permite à indústria de criptomoedas alavancar a segurança robusta e a liquidez profunda do Bitcoin. Agora, vamos explorar mais detalhadamente as duas principais características da Babylon: Timestamping do Bitcoin e Staking do Bitcoin.

3. Como o Bitcoin Timestamping Funciona

3.1 Por que a desvinculação da Stake é lenta?

Qualquer pessoa que tenha apostado tokens antes saberia que desbloquear 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 desbloquear requer um período de espera? Por que não permitir saques instantâneos?

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, 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 em que validadores maliciosos criam um novo garfo começando a partir de blocos passados, tentando substituir a cadeia canônica atual. Se a cadeia maliciosa bifurcada 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—isso é mesmo possível?

Em uma rede PoW, um ataque de longo alcance é praticamente impossível. Para alcançar 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, em uma rede PoS que funciona corretamente, esse ataque também é impossível. Criar um novo fork exigiria que validadores maliciosos assinassem vários blocos conflitantes, o que é considerado dupla assinatura - uma violação do protocolo que resulta em penalidades de corte.

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 validadores maliciosos retirarem suas participações da cadeia existente e criarem uma nova cadeia bifurcada a partir de um bloco anterior onde suas chaves de validação ainda eram válidas, eles poderiam potencialmente alcançar a cadeia canônica atual. Neste cenário, os novos nós que se juntam à rede podem ter dificuldade em determinar qual cadeia é a legítima, levando a potenciais confusões e riscos de segurança.

(Fonte: Babilônia)

Se um ataque de longo alcance tiver sucesso, validadores maliciosos podem explorar mecanismos de ponte para roubar fundos. Por exemplo, suponha que um atacante malicioso chamado John transfira 1M de tokens RUG da cadeia RugPull para a Osmose e os troque por tokens OSMO. Essa transferência acontece através do IBC, que funciona bloqueando os tokens RUG originais na cadeia RugPull enquanto cunha uma quantidade equivalente de tokens RUG na cadeia 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 para a cadeia Osmosis na nova cadeia bifurcada. Como resultado, John adquiriria efetivamente tokens OSMO de graça.

Para evitar ataques de longo alcance, é necessário um período de desvinculação de apostas de determinado comprimento. Os atores maliciosos não podem executar um ataque de longo alcance durante o período de desvinculação (se tentarem, enfrentarão penalidades de slashing). Além disso, durante esse 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 aceita pela rede.

3.3 Vamos Reduzir o Tempo de Desvinculaçã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 vem com algumas desvantagens.

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

O segundo problema é que, como mencionado anteriormente, um período de desbloqueio mais longo afeta negativamente a experiência do usuário e a liquidez.

Babilônia apresenta uma solução chamada Bitcoin Timestamping, que permite que as cadeias de PoS reduzam significativamente os períodos de desbloqueio para apenas algumas horas. Isso permite que as cadeias de PoS gravem dados de blocos da cadeia canônica na rede Bitcoin.

Com a marcação de data e hora, mesmo que 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 de forma segura na rede Bitcoin. Desde que a segurança do Bitcoin permaneça intacta, o ataque está garantido a falhar. Como essa abordagem elimina a necessidade de consenso social, ela 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 é registrado usando 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 do Bitcoin, OP_RETURN não pode ser usado 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 do Bitcoin têm um tamanho pequeno, um tempo de bloco de 10 minutos e o OP_RETURN só pode armazenar um máximo de 80 bytes de dados. Se inúmeras cadeias PoS enviassem transações frequentes de checkpoint, a rede do Bitcoin não seria capaz de lidar com a carga.

Para resolver esta questão, Babylon introduz a Babylon Chain, que agrega checkpoints de várias cadeias PoS via IBC e depois envia um único checkpoint agregado para a rede Bitcoin.

Um componente chave deste processo é o Vigilante Relayer, uma entidade responsável por ler checkpoints de um nó de Babilônia, empacotá-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 do 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 ponto de verificação da cadeia bifurcada maliciosa sempre terá um carimbo de data/hora posterior ao ponto de verificação da cadeia canônica. Isso significa que os participantes da rede podem simplesmente verificar o ponto de verificação da rede Bitcoin para identificar facilmente bifurcações maliciosas. Como essa 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 desvinculação rápida de participação

O carimbo de data/hora do Bitcoin da Babilônia faz mais do que apenas melhorar a UX e a eficiência de liquidez, reduzindo os períodos de desbloqueio de PoS - também oferece vários benefícios adicionais.

3.4.1 Finalidade Lenta para Transações Importantes

Ao adotar a finalidade lenta através de Babilônia, as cadeias PoS podem atingir um nível de segurança comparável ao 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.

Esse 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 zonas recém-lançadas do Cosmos, que podem ter segurança mais fraca, implementar 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 abordar isso, Babilônia introduz um conceito especial chamado modo de rollup.

Em uma cadeia 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 de Babylon, apenas metade (1/2) dos validadores precisa ser honesta para alcançar a resistência à censura, melhorando significativamente a resiliência da cadeia contra ataques.

(Fonte: Babilônia)

Se um usuário da cadeia PoS acredita que uma transação específica está sendo censurada, ele pode enviar uma reclamação de censura (a seção vermelha no diagrama) para a cadeia de Babilônia, iniciando o processo de entrar no modo de rollup. A reclamação de censura contém o hash da transação censurada.

Se, após seis confirmações de bloco do 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 do Bitcoin, nenhum checkpoint relacionado à transação censurada for detectado em nenhum bloco do Bitcoin, validadores e usuários honestos entrarão no modo de rollup.

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

4. Como o Bitcoin Staking Funciona

4.1 Visão Geral do Bitcoin Staking

O carimbo de data/hora do Bitcoin permite que as cadeias de PoS aproveitem a segurança do Bitcoin para reduzir os períodos de desvinculação da participação e aumentar a resistência à censura, mas isso só utiliza parcialmente a segurança do Bitcoin.

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

Para os detentores de BTC, o Bitcoin Staking da Babilônia é uma oportunidade de investimento atrativa, pois eles podem apostar BTC no nível de segurança do Bitcoin sem depender de entidades externas, ao mesmo tempo em que também ganham recompensas de protocolos externos.

Vamos definir alguns termos-chave:

• Protocolos que aproveitam a segurança criptoeconômica do BTC apostado através do Bitcoin Staking da Babilônia são chamados de BSNs (Bitcoin Secured Networks) - análogos a@eigenlayerconceito de Serviços Validados Ativamente (AVS)
• Entidades que recebem BTC delegado de stakers e participam da validação de BSNs são chamadas de Provedores de Finalidade - semelhantes aos operadores AVS da EigenLayer.

Mas espere—ao contrário do Ethereum, a rede Bitcoin não é Turing-completa, tornando difícil implementar contratos complexos de staking. Então, como o Babilônia 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: adicionando uma condição de bloqueio ao UTXO de staking de Alice

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

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

4.2.2 Redução de ganhos

// Contrato V1: adicionando slashing 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 devem ser implementados no staking é o slashing. Se ocorrer uma ação maliciosa, um mecanismo de incentivo pode ser aplicado queimando o BTC apostado. Para alcançar isso, uma segunda condição de gasto UTXO é definida para que o slashing possa ocorrer se alguém tiver a chave EOTS da Alice.

Aqui, 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, sua chave secreta é publicamente revelada.

Olhando para isso com mais detalhes, uma assinatura Schnorr consiste em uma 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 é computado 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 da 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. Uma vez que s1, s2, e1, e2 são publicamente conhecidos, qualquer um pode resolver a chave privada x de Alice usando a equação x=(s1 - s2)/(e1 - e2).

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

4.2.3 Executando a 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 punição V0

entradas:

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

saídas:

• saída-1: valor = 0,99 Bitcoin, proprietário = 0000...0000

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

O comitê da aliança pré-assina a tx de redução acima como sua pré-aprovação

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

Para evitar isso, a redução deve ser implementada de forma que transfira à força o BTC para um endereço de queima pré-definido (0000…0000). Para alcançar isso, a segunda condição de gasto de UTXO inclui um Quórum do Comitê do Pacto. O Comitê do Pacto é responsável por verificar se a redução é legítima. Ao incorporar um esquema de múltiplas assinaturas (M-de-N), o sistema garante que Alice não pode retirar unilateralmente seu BTC para sua própria carteira antes que a redução seja executada.

A vantagem dessa abordagem é que, desde que Alice se comporte honestamente, sua assinatura EOTS nunca é exposta, o que significa que o Comitê do Pacto não pode apreender seus fundos. Portanto, Alice não precisa confiar no Comitê do Pacto, 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 & covenant_committee_quorum

// Transação de corte V0

entradas:

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

saídas:

• saída-1: valor = 0.99 Bitcoin, proprietário = 0000...0000

// Pré-aprovação V1

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

// Comitê do Pacto pré-assina a tx de redução de taxa como sua pré-aprovação.

Alice pode apostar diretamente BTC e participar da validação de outros protocolos de PoS como provedora de finalidade. No entanto, a maioria dos usuários escolherá delegar 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, a questão aqui é que, se o validador conspirar com o comitê do pacto, ele poderá roubar o BTC de Alice, forçando Alice a confiar no validador.

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

Para conseguir isso, Alice pré-assina uma transação afirmando que “se ocorrer o corte, BTC deve ser enviado para um endereço de queima”. Nesse caso, se o validador agir maliciosamente e sua chave EOTS for exposta, e se o comitê do pacto executar uma assinatura múltipla, o BTC será enviado para o endereço de queima, impondo o processo de corte.

4.2.5 Prevenção de Ataques Maliciosos com Aplicação de Penalização Atômica

/ 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 corte V0

entradas:

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

saídas:

• saída-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 do adaptador da transação de redução

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

// O comitê da aliança pré-assina a tx de redução, conforme sua pré-aprovação.

E se um validador malicioso visar apenas validadores específicos para penalização? Para evitar isso, Babilônia introduz Assinaturas de Adaptador.

Alice criptografa sua assinatura usando a chave pública EOTS do validador como uma assinatura adaptadora. Se o validador tentar punir apenas Alice, eles devem usar sua chave privada EOTS. Devido à natureza das Assinaturas Adaptadoras, 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 Implementando o corte parcial

// Contrato V3

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

condition-2 (slashing): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Transação de penalização V1: habilitando a penalização parcial

entradas:

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

Saídas:

• saída-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 adaptadora da transação de punição

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

// O comitê do Pacto pré-assina a tx de corte como sua pré-aprovação.

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

4.2.7 Restaking Mais!

// Contrato V4: Habilitando o restaking

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 da validação de vários protocolos PoS, não apenas um. Se um validador participar da validação de diferentes protocolos PoS usando a mesma chave EOTS, qualquer vazamento em um local poderá afetar os outros sistemas. Portanto, os provedores de finalidade do Babylon devem usar diferentes chaves EOTS para diferentes sistemas 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 opera em PoW, portanto, o conceito de staking não existe inerentemente. No entanto, a Babylon implementou recursos de bloqueio, corte e delegação de BTC necessários para fazer staking por meio 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 obtenham lucros adicionais nativamente utilizando o BTC, sem precisar de pontes ou serviços de custódia.

5. Liberando o Potencial do BTC para o Mundo Descentralizado

Além da Lightning Network, nenhum outro protocolo herda completamente a segurança da rede Bitcoin. No entanto, assim como a rede Bitcoin, a funcionalidade da Lightning Network é bastante limitada e é muito preciosa para desistir 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 do carimbo de data/hora do Bitcoin e da participação no Bitcoin. O primeiro usa o Bitcoin como um servidor de carimbo de data/hora para evitar reversões de transações ou bifurcações maliciosas, enquanto o segundo aproveita 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 Babilônia, o que está de acordo com um limite de depósito estabelecido por Babilônia. Cerca de 3,9% do fornecimento total de ETH é reestacado na EigenLayer. Levando isso em consideração, embora os detentores de BTC possam ser conservadores ao utilizar BTC, o potencial de crescimento de Babilônia, com apenas cerca de 0,2% do fornecimento total de BTC atualmente em jogo, vale a pena considerar.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [100y.eth]. Todos os direitos autorais pertencem ao autor original [100y.eth]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. A equipe do Gate Learn faz traduções do artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.