Então, foi apanhado de surpresa e agora tem BTC. Ainda bem para ti, mais vale tarde do que nunca.
Depois, ouviu o adágio sagrado deste sector: nem as suas chaves, nem as suas moedas. Com os horrores das várias fraudes e hacks da CEX, decidiu finalmente guardar as suas bitcoins.
Parabéns, agora é o responsável pelo seu próprio destino financeiro. Hurra, não?
Percebe que transacionar em Bitcoin é estupidamente caro, tão caro que envergonha as taxas de gás notoriamente elevadas do Ethereum. Porque, ao contrário dessas malditas baleias, não tem $1M de bitcoins para gastar - cada transação que fizer na cadeia principal vai ser muito cara para si.
E agora? De certeza que tem de haver uma forma melhor.
Deixar o ninho
Quando detém bitcoins (BTC, a moeda criptográfica) fora da Bitcoin (cadeia principal, a cadeia de blocos), não terá a segurança e a proteção da cadeia principal, o que exige que herde os pressupostos de confiança de qualquer cadeia ou camada em que se encontre, bem como o token representativo de BTC que detém (se aplicável).
Infelizmente, este é o compromisso inevitável do iBitnevit que vai ter de fazer - por enquanto.
Este artigo tem como objetivo fornecer uma visão geral sobre as várias abordagens de escalonamento e pontes que existem, bem como delinear os sacrifícios de confiança que terá de incorrer em cada uma delas. Além disso, vamos expor as deficiências de cada uma delas e por que ainda não existe uma solução adequada de escalonamento de Bitcoin que seja capaz de "exportar" BTC sem comprometer significativamente os usuários da segurança e proteção de sua cadeia principal.
Os termos Bitcoin e mainchain serão utilizados indistintamente ao longo do texto. Vamos começar.
Rede Lightning
Lançada em janeiro de 2018, a Lightning Network apresenta uma das primeiras tentativas feitas para escalar a Bitcoin. No seu núcleo, a Lightning Network é composta por uma rede de canais de pagamento, em que cada canal de pagamento é fundamentalmente um contrato multisig 2-de-2 (alavancando HTLCs) entre duas partes na Bitcoin.
O que faz a Lightning Network funcionar é o facto de existirem vários canais de pagamento que mantêm uma ligação ao par para o qual pretende enviar os seus bitcoins. Assim, mesmo que não tenha uma ligação direta com o Bob, desde que tenha uma ligação com a Alice (que tem uma ligação com o Bob), pode iniciar o pagamento a partir do seu nó Lightning e pagar ao Bob através da Alice.
Em teoria, pode efetuar transacções com qualquer pessoa, desde que a sua contraparte partilhe pelo menos um par mútuo (com liquidez suficiente). Daí o termo "rede" em Lightning Network.
tldr
Quando Bob quer abrir um canal de pagamento com Alice, eles combinam as suas chaves para gerar um contrato multisig 2-de-2, que actuará como o endereço do canal. Depois, Bob transmite duas transacções: a sua transação de compromisso (para gastar os seus fundos de volta à sua carteira de financiamento se Alice não responder) e a sua transação de financiamento (Bob deposita os seus bitcoins no contrato multisig 2-de-2). Da mesma forma, Alice também transmite a sua transação de compromisso e a sua transação de financiamento. Note-se que é importante que a primeira transação de compromisso seja assinada por ambas as partes antes de qualquer pessoa financiar o canal de pagamento. Isto é para garantir que os fundos não ficarão presos no multisig no caso de uma das partes ficar offline.
Uma vez estabelecido o canal de pagamento, Bob e Alice são livres para gastar os bitcoins dentro do multisig quantas vezes e como bem entenderem. Quando se "envia" fundos, está-se na verdade a atualizar a transação de compromisso partilhada que se tem com a outra parte para refletir o estado mais recente dos saldos, invalidando o compromisso anterior. A transação de compromisso nunca é submetida onchain quando o canal de pagamento ainda está ativo e é conhecida apenas por Bob e Alice. A transação de compromisso só é publicada após o encerramento do canal de pagamento.
Quando Bob quer fechar um canal (e levar seus bitcoins de volta para a mainchain), há duas maneiras de fazê-lo: cooperativamente com Alice, ou não cooperativamente (também conhecido como force close). Num fecho cooperativo (caminho feliz), tanto o Bob como a Alice concordam com a sua parte dos saldos do multisig, e ambos assinam uma nova transação que gasta os fundos de volta para as suas respectivas carteiras imediatamente.
No entanto, num cenário de encerramento forçado (caminho infeliz), Bob ou Alice podem não estar disponíveis ou não quererem assinar cooperativamente a transação de encerramento. Neste caso, a parte que inicia o fecho forçado gastará o seu saldo num contrato de arbitragem, permitindo que o seu par o conteste dentro do atraso do CSV (também conhecido como período de disputa). No caso de esta parte tentar "fazer batota" (publicando uma transação de compromisso mais antiga), o seu par publica simplesmente a transação de compromisso mais recente, reclamando para si os fundos da parte batoteira do contrato de arbitragem.
[lightning.engineering] ilustrado: A reivindicação falhada do Bob sobre o encerramento forçado de 8 BTC
Para ilustrar, vamos supor que Bob e Alice têm um saldo "verdadeiro" de 4 BTC e 6 BTC, respetivamente (o canal de pagamento contém 10 bitcoins no total). Se Bob iniciar um encerramento forçado e afirmar que tem 8 BTC no canal de pagamento (publicando uma transação de compromisso mais antiga), Alice pode simplesmente publicar a última transação de compromisso e reclamar os 8 BTC de Bob do contrato de arbitragem. Isto servirá para dissuadir o Bob, garantindo que as partes não precisam de confiar umas nas outras quando abrem um canal Lightning.
nem o vosso nó, nem as vossas moedas.
O problema com a Lightning Network é que não é possível fazer a autocustódia, a menos que você tenha seu próprio nó Lightning. Caso contrário, você deve depositar seu BTC em um nó Lightning confiável para usar a rede, onde seus bitcoins fazem parte de seu livro-razão interno e eles fazem transações em seu nome. Se o nó Lightning que detém o seu depósito falhar, então o seu BTC foge com ele e não tem qualquer recurso. Isto é basicamente pior do que depositar os seus bitcoins numa CEX de confiança - quer dizer, pelo menos está a lidar com a Binance ou a Coinbase!
Se decidir gerir o seu próprio nó Lightning, terá de estar constantemente online para monitorizar as violações de canal dos seus pares. Embora você possa designar nós da Torre de Vigilância para ajudá-lo a monitorar violações (eles armazenarão seus compromissos que são gerados em cada transação que você faz no canal de pagamento para contestar fechamentos de força fraudulentos em seu nome), você essencialmente volta a confiar em entidades centralizadas. Mais uma vez, mais vale confiar na Binance ou na Coinbase do que numa qualquer empresa de vigilância aleatória para salvaguardar os seus bitcoins!
[Sam Aiken] ilustrado: a torre de vigia LN em ação
Como se o acima exposto não fosse suficiente para o dissuadir, se gerir o seu próprio nó Lightning, terá de gerir manualmente a liquidez do seu próprio nó em relação aos seus pares. Por exemplo, se um canal de pagamento tiver apenas 10 BTC no total, então o saldo máximo que cada parte pode manter entre si é de 10 BTC. No entanto, isto não obstante o facto de poder ter ligações a vários pares (uma vez que é provável que esteja a fazer pagamentos a muitas partes diferentes) - se quiser fazer uma transação com alguém com quem não tem uma ligação direta, terá de contar com outros nós Lightning que tenham ligações a si e à sua contraparte, também com liquidez suficiente para encaminhar o pagamento. Agora pode ver porque é que a gestão de liquidez é muito complicada para o executor de nós médio.
Portanto, a maioria dos nós Lightning simplesmente elimina isso e se conecta a nós de roteamento, que são nós Lightning bem capitalizados (provavelmente administrados por grandes instituições) dedicados ao roteamento de pagamentos. Eles ficam entre os Lightning nodes como um canal intermediário, agindo como um quase-corretor de pagamentos em toda a rede. Como resultado, a rede tende a centralizar-se neste aspeto - no momento em que escrevo, os 10 principais nós Lightning representam mais de 75% de toda a capacidade da rede!
[LnRouter.app] nós de relâmpago activos, filtrados por capacidade
A Phoenix Wallet, desenvolvida pela ACINQ, é uma tentativa de simplificar a autocustódia na Lightning Network para o utilizador comum. Quando descarrega a aplicação da carteira, o seu telefone torna-se automaticamente no seu próprio nó Lightning. Para simplificar o gerenciamento de liquidez e o roteamento de pagamentos, seu nó Lightning se conectará ao nó ACINQ, contando com o ACINQ como um roteador para seus pagamentos de entrada e saída.
No entanto, continua a ser-lhe exigido que esteja periodicamente online e atento a violações - caso contrário, continua à mercê da ACINQ. Por muito improvável que seja, se a ACINQ tentar forçar o encerramento do seu canal com um compromisso desatualizado, terá de estar online para o contestar e apresentar o compromisso mais recente correto. Caso contrário, poderá perder os seus fundos para a ACINQ.
conclusão
A Lightning Network foi concebida para os utilizadores de nós. No entanto, no mundo real, nem toda a gente precisa de gerir o seu próprio nó - isto não é realista nem prático.
Infelizmente, a Lightning Network nunca foi concebida para o detentor médio de BTC que não é um geek. O facto de ser necessário gerir um nó apenas para se manter auto-custodial, juntamente com o seu caso de utilização restritivo de ser estritamente uma rede de pagamentos (não programável para desbloquear nativamente casos de utilização mais ricos como o DeFi), relega o protocolo para as franjas do verdadeiro Bitcoiner que gere o seu próprio nó.
Nem o seu nó, nem as suas moedas. E não é ideal para o utilizador comum.
Cadeias de estados
O conceito de Statechains inspira-se fortemente nos canais de pagamento da Lightning, em que ambos permitem transacções offchain ilimitadas que serão eventualmente "liquidadas" na Bitcoin no seu encerramento.
tldr
Ao contrário dos canais Lightning (que são multisigs 2-de-2), o endereço de depósito UTXO de uma statechain é criado completamente fora da cadeia pelo operador, que é uma entidade de confiança que gera partilhas de chaves tanto para si como para o proprietário atual do UTXO. O proprietário do UTXO que pretende iniciar uma cadeia de estado colabora com o operador (entidade de confiança) para criar um endereço onde a chave pública correspondente é formada a partir do primeiro proprietário e das partilhas de chaves do operador. A partir daqui, o proprietário financia a statechain com o UTXO (ou bitcoins) e, em seguida, cria uma transação de backup (com a cooperação do operador), que é um bloqueio de tempo que permitirá ao proprietário reclamar unilateralmente o seu UTXO de volta após a sua expiração.
[Nik/Coinmonks] Statechains em ação: transferir a propriedade do UTXO de Alice para Bob
Se o proprietário atual pretender transferir a propriedade do UTXO para um novo proprietário, o operador irá simplesmente gerar de novo as acções-chave correspondentes ao mesmo endereço de depósito e eliminar a sua ação-chave com o antigo proprietário. Em seguida, o novo proprietário cria uma transação de backup (com a cooperação do operador), mas com um timelock mais curto. De cada vez que uma cadeia de estados muda de mãos, o operador elimina a quota de chave anterior e assina a transação de reserva do novo proprietário, que terá um período de bloqueio mais curto do que o do proprietário anterior, ou seja, até que o período de bloqueio não possa ser mais reduzido (o que exige a criação de uma nova cadeia de estados para o novo proprietário).
Desta forma, o antigo proprietário não pode retirar unilateralmente fundos da statechain em vez do novo proprietário. Porque, para sair cooperativamente da statechain (retirada instantânea), o antigo proprietário precisa que o operador co-assine a sua transação de saída (o que o operador já não pode fazer, uma vez que eliminou a sua quota de chave anterior que poderia co-assinar a transação), caso contrário o antigo proprietário tem de esperar que o seu timelock expire antes de poder submeter a sua transação de backup. No entanto, mesmo que o operador fique offline quando o novo proprietário quiser sair da cadeia de estados, pode sempre submeter a sua transação de backup e reclamar os fundos antes do antigo proprietário, uma vez que a sua transação de backup tem um timelock mais curto.
no operador em quem confiamos
Como se não fosse suficientemente óbvio, o operador é o único ponto de falha das cadeias de estado. Os novos proprietários precisam de confiar que o operador apagou efetivamente a sua anterior quota de chave e que não irá conspirar para reclamar fundos para o anterior proprietário. Uma vez que o servidor do operador é basicamente uma caixa fechada da web2, o novo proprietário não tem forma de verificar a eliminação da quota de chave anterior do operador (isto é, a menos que seja o próprio operador).
O Mercury Layer, um projeto de statechain, visa eliminar esse fator de confiança. Utilizando uma variante cega de Schnorr, o operador Mercury não tem conhecimento da própria cadeia Bitcoin. Assim, o operador não tem ideia de qual endereço de depósito é co-assinante, os detalhes das transações de backup, nem sabe de quaisquer assinaturas que eles geram. Assumindo que o mesmo operador lida com várias statechains, a Mercury irá essencialmente assinar às cegas todos os pedidos de co-assinatura que chegarem, sem conhecimento do que a assinatura irá permitir. Isso impede o conluio seletivo pelo operador, garantindo que a geração de chaves e a assinatura sejam feitas corretamente em seu servidor, pois eles simplesmente não têm incentivo para serem maliciosos (eles não sabem o que está em jogo devido à assinatura cega).
[Ruben Somsen] o operador está a assinar mensagens cegas - não sabe se se trata de transacções Bitcoin ou de outra coisa qualquer.
Apesar dos esforços da Mercury, no entanto, as statechains permanecem fundamentalmente severamente limitadas. Você só pode "enviar" a quantidade exata de BTC que você depositou na statechain, já que as statechains em sua essência são simplesmente um protocolo de transferência de propriedade de endereço em vez de realmente facilitar as transferências UTXO como a Lightning Network. Além disso, no caso de o operador ficar offline, todos os "envios" serão interrompidos e você terá que esperar que seu longo timelock expire antes de poder reivindicar seus fundos de volta ao Bitcoin por meio de uma transação de backup.
conclusão
Embora as statechains ofereçam um "hack" inteligente para a transferência de UTXOs em relação ao custo e às limitações do Bitcoin, elas permanecem inadequadas para transferências de UTXOs de alta frequência em larga escala e de valores diferentes. Neste contexto, as statechains são ainda mais restritivas do que a Lightning Network - para além de só se poder transferir o UTXO exato com que se financiou a statechain, também se tem de lidar com a mesma falta de programabilidade que impede que se desbloqueiem casos de utilização mais ricos para além dos pagamentos (ou seja, DeFi).
No final das contas, as statechains são exatamente isso - um protocolo de transferência de propriedade de endereço "hacky" com confiança minimizada. Quero dizer, pelo menos o Lightning funciona de facto para os corredores de nós!
Cadeias de estados - divertidas para os programadores, não tão divertidas para todos os outros.
BTC de custódia
As soluções de custódia de BTC (chamadas de "bitbanks" pelos OGs), apesar de serem uma bofetada ideológica na cara dos "verdadeiros" Bitcoiners, continuam a ser, sem dúvida, uma das vias mais seguras (e também mais convenientes) para o utilizador médio transacionar os seus bitcoins de uma forma barata, rápida e razoavelmente segura.
Os depositários de BTC de confiança estão, na sua maioria, entre as instituições de criptografia mais antigas e são altamente considerados no sector, e mesmo na TradFi.
tldr
Bastante auto-explicativas, as soluções BTC de custódia envolvem normalmente entidades de renome em que os depositantes confiam o suficiente para actuarem como guardiãs de todas as bitcoins depositadas junto delas. Posteriormente, estas entidades cunhariam tokens representativos em diferentes cadeias (e ambientes), em que cada unidade seria apoiada 1:1 com a quantidade de bitcoins mantida em reserva pelo depositário (em teoria).
Como vivem numa cadeia mais barata e mais rápida do que a Bitcoin, estes tokens representativos da BTC (por exemplo, wBTC, cbBTC, etc.) permitem aos seus detentores utilizá-los na DeFi, obter rendimentos denominados em BTC e efetuar transacções entre si num ambiente de execução muito mais rápido e mais barato.
no guardião em quem confiamos
[BitGo] BitGo: o depositário de confiança do wBTC
Escusado será dizer que os utilizadores de soluções BTC de custódia devem confiar plenamente na entidade de custódia do token representativo das BTC que detêm. Diferentes entidades de custódia implicariam diferentes níveis de risco, de acordo com a interpretação do ponto de vista do titular.
Por exemplo, um utilizador estaria mais inclinado a utilizar o wBTC da BitGo se fosse alguém que valorizasse o historial, a liquidez da bolsa e o seu carácter OG. Da mesma forma, as pessoas do outro lado do espetro podem preferir manter o cbBTC da Coinbase se forem alguém que coloca maior ênfase em regulamentos claros, transparência e respeito pelo devido processo legal e estado de direito americano. Isto é análogo às considerações de alguém ao decidir entre o USDT da Tether ou o USDC da Circle para a sua stablecoin de eleição - ou então, pode simplesmente ter ambas!
conclusão
Embora as soluções de custódia de BTC sirvam atualmente como uma ponte útil para os utilizadores de BTC que, de outra forma, não seriam autoconservadores, continuam a ser, na melhor das hipóteses, uma solução provisória.
Quando detém wBTC, está a confiar na BitGo tal como confiaria numa CEX quando tem fundos depositados com eles. O mesmo vale para o cbBTC da Coinbase, o BBTC da Binance e vários outros custodiantes de BTC por aí.
Uma segurança opsec frouxa e um encontro com o poderoso Lazarus (espero que não), e lá se vão os teus bitcoins para financiar as bombas nucleares do Kim!
Federado BTC
Imagine o wBTC, mas em vez de ter apenas a BitGo como guardiã, tem também a Wintermute, a ChorusOne e outras instituições a juntarem-se à festa e a receberem as chaves do reino.
O que é que é melhor do que um guardião? Um monte deles!
tldr
As pontes BTC federadas são essencialmente uma ponte BTC de custódia colectiva. Envolvem várias entidades respeitáveis que formam um conjunto de signatários, pelo que é necessária uma maioria para autorizar transacções em bitcoins depositados entre elas.
A ideia é eliminar o risco de um único ponto de falha que está presente nas soluções BTC de custódia. Da mesma forma que usaria uma carteira multisig em vez de uma EOA para custodiar a maior parte das suas poupanças, a ideia é que, ao distribuir os privilégios de assinatura por várias entidades de confiança, pode confiar menos em cada signatário individual.
Como tal, para comprometer uma configuração BTC federada (e roubar os bitcoins nela armazenados), o atacante teria de comprometer a maioria das entidades que fazem parte do conjunto de signatários. Comprometer a Coinbase é difícil. Mas comprometer a Coinbase, a OKX, a Wintermute e a Fireblocks sem ser detectado é uma tarefa bastante ambiciosa para qualquer potencial atacante.
multisigs e MPCs
Simplificando demais, existem basicamente duas maneiras de distribuir privilégios de assinatura em uma configuração BTC federada - por meio de construções multisig (multi-signature) e/ou MPC (multi-party computation). Não vou entrar nos detalhes de implementação de cada um (é muito), mas a ideia principal é que, em um multisig, o endereço "compartilhado" é gerado na cadeia e cada signatário possui uma chave privada totalmente independente. Isto significa que quando uma transação a partir do endereço partilhado é assinada coletivamente pelos signatários, a assinatura é registada na cadeia.
Com o MPC, o endereço "partilhado" é gerado fora da cadeia e cada signatário possui uma parte parcial da chave. Ao assinar uma transação onchain, os signatários calculam conjuntamente uma assinatura combinando as suas quotas de chave. Do ponto de vista da cadeia de blocos, parece que a assinatura é apenas uma assinatura padrão proveniente de um signatário, quando, na verdade, é gerada coletivamente fora da cadeia pelo conjunto de signatários da construção MPC.
É claro que existem nuances e compensações entre cada abordagem. Embora elaborá-las esteja fora do escopo deste artigo, eu recomendaria a leitura desta cartilha MPC vs. Multi-sig da Fireblocks, caso você seja um nerd que queira mergulhar em detalhes e outras coisas.
na federação confiamos
Em teoria, tudo isto parece muito seguro. Temos as melhores instituições de criptomoedas, cada uma com a sua reputação em jogo, a proteger coletivamente a ponte federada de BTC. O que é que pode correr mal?
Como vê, menos confiança não significa não ter confiança. Com uma ponte BTC federada, a seleção do signatário é de extrema importância. A federação precisa de incluir um número suficiente de signatários, um limiar de maioria seguro (pelo menos dois terços) e uma distribuição geográfica suficiente. Para não mencionar que cada signatário já precisa de ter uma reputação suficientemente boa que esteja disposto a proteger, bem como ter interesse no sucesso da ponte federada.
Para mim, das instituições que são signatárias de pelo menos uma ponte BTC federada atualmente em funcionamento, há honestamente apenas uma mão-cheia delas a quem confiaria as minhas poupanças. Com os dedos cruzados, você tem o confiável Coinbase - então provavelmente Galaxy, Wintermute e Fireblocks. Não estou a dizer que as restantes instituições são todas falsas, mas confiar-lhes 100% das minhas poupanças é outra questão.
Em suma, não vale a pena ter 15 signatários na sua federação, quando 10 deles não implementam boas práticas de segurança ou são apenas esboços. O problema é que é mais fácil encontrar 15 signatários de excelente reputação e com grande opsec, quanto mais 50 signatários.
Quando toda a gente afirma ser respeitável e segura? Voilà, apenas alguns o são de facto!
Dito isto, é minha opinião que as pontes BTC federadas continuam a ser a melhor forma de "exportar" BTC para outras cadeias (ou camadas) que são externas à cadeia principal da Bitcoin. Espera-se que os cypherpunks rolem nas suas sepulturas, mas uma federação cuidadosamente selecionada de signatários de qualidade seria, na maioria dos casos, mais segura do que qualquer alternativa sem permissão que seja possível nas circunstâncias actuais.
Afinal de contas, há uma razão para que a maioria das representações de BTC que se vêem atualmente dependam sobretudo de uma federação de signatários. Temos a solvBTC, a pumpBTC, a LBTC da Lombard, a sBTC da Stacks, a BTC.b da Avalanche, a WBTC da Bitlayer, a L-BTC da Liquid, a MBTC da Merlin - todas elas exigiriam que confiássemos na federação de signatários que cada uma delas selecionou. Mas como é difícil encontrar signatários realmente respeitáveis, não se surpreenda ao encontrar várias instâncias de sobreposições de signatários entre federações, nas quais o mesmo signatário faria parte de duas ou mais configurações de ponte. Por exemplo, Cobo é um signatário do solvBTC, pumpBTC e do MBTC de Merlin. Ou Chorus.one, signatário tanto da LBTC da Lombard como da sBTC da Stacks.
Existem até casos em que dois signatários dentro de uma federação são, na verdade, parte do mesmo ecossistema ou entidade mais ampla. Por exemplo, o BTC.b da Avalanche inclui a Avascan e a Ava Labs como parte de sua federação de 8 signatários. Assumindo um limiar de maioria de 5 de 8 (o mínimo necessário), isso deixa o atacante com "apenas" 3 signatários restantes para subornar ou comprometer (e ameaçar seriamente a segurança da ponte BTC.b).
Lombard LBTC
Para seu crédito, alguns projectos reconhecem a importância da opsec do signatário e tomaram medidas para minimizar este vetor de ataque. Por exemplo, a Lombard emprega uma abordagem de segurança em vários níveis, exigindo que seu Consórcio (conjunto de signatários) execute o CubeSigner, uma plataforma de gerenciamento de chaves sem custódia criada pela Cubist utilizando enclaves Nitro selados por HSM. Na prática, o CubeSigner permite que as chaves permaneçam em hardware seguro desde a geração do endereço até à assinatura da transação - ninguém, nem mesmo a Cubist ou os próprios signatários, pode ver as chaves e muito menos os atacantes externos podem extraí-las.
No entanto, tal como se confia no Ledger quanto à integridade e incorruptibilidade das carteiras de hardware do Ledger que se tem em casa, os detentores de LBTC da Lombard também precisariam de confiar no Cubist quanto à integridade e incorruptibilidade das instâncias do CubeSigner geridas pelos signatários do Consórcio - caso contrário, voltaríamos a confiar em cada signatário do Consórcio para não estragar o seu próprio opsec.
[Lombard] ilustrado: Arquitetura LBTC da Lombard
Para além disso, isto não obstante o risco de um possível conluio entre signatários, por mais improvável que pareça. O simples facto é que, se a maioria dos signatários do Consórcio Lombard entrarem em conluio, poderão comprometer as BTC detidas nos endereços do Consórcio e roubar os fundos dos utilizadores.
conclusão
Como indústria, estaríamos a prestar um mau serviço a nós próprios se ficássemos satisfeitos com a seleção de representações BTC que temos atualmente. É duro, mas tem de ser dito: não há sentido para a Bitcoin (e, de facto, para toda esta indústria) se apenas algumas baleias selecionadas com os bolsos para pagar as taxas de transação da cadeia principal forem as únicas que podem transacionar BTC de uma forma livre de confiança. Toda esta noção de BTC como a moeda sólida sem confiança para as massas deixaria de existir quando a única forma realista para a maioria das pessoas poupar, gastar e transacionar BTC exigisse que depositassem confiança em entidades geridas por humanos falíveis sob jurisdição estatal.
As pontes federadas de BTC abriram, de facto, o caminho para as pessoas deterem e transaccionarem BTC de uma forma rápida e barata, sendo ainda relativamente seguras em comparação com outras alternativas disponíveis. Mas elas nunca foram concebidas como o fim do jogo para o escalonamento do Bitcoin, mas sim como um meio para um fim.
Até agora, é suficientemente bom, mas não é certamente a solução do Santo Graal de que a indústria (e o mercado) necessita desesperadamente.
Porta-enxerto rBTC
[Rootstock] Rootstock: uma das soluções de escalonamento OG do Bitcoin
Lançado em janeiro de 2018, o Rootstock é a primeira e mais duradoura sidechain do Bitcoin. Ele aproveita a mineração de mesclagem para consenso e emprega uma ponte BTC federada bidirecional onde o rBTC também é usado para pagar taxas de gás em Rootstock.
O problema? A ponte BTC federada da Rootstock não requer uma suposição de maioria honesta para ser segura!
Agora que já tenho a vossa atenção, vamos lá começar.
mineração por fusão
A cadeia Rootstock utiliza a mineração por fusão para chegar a um consenso. Ao contrário das cadeias PoS (em que a proporção dos seus activos apostados relativamente ao conjunto de apostas representa o seu poder de voto), as cadeias de mineração por fusão procuram aproveitar a capacidade de hashrate que já está a ser utilizada para minerar Bitcoin, alargando-a para validar a cadeia Rootstock. Isto permite aos mineiros de Bitcoin proteger simultaneamente a Bitcoin e a Rootstock com a mesma infraestrutura e consumo de energia, permitindo-lhes ganhar prémios de mineração de ambas as redes com o mesmo gasto. Se estiver mais familiarizado com PoS, a mineração de fusão seria análoga ao restaking - o mesmo recurso (por exemplo, ETH) é utilizado para proteger simultaneamente a cadeia PoS nativa (através de plataformas de staking líquidas) e redes PoS externas (restaurando o seu LST para proteger as suas redes de eleição).
[Alexei Zamyatin] ilustrado: merge-mining
No momento em que escrevo, ~80% dos mineiros de Bitcoin optaram por participar no processo de mineração de fusão de Rootstock - cada PoW de um bloco de Rootstock herdará agora ~80% do poder de hashing da Bitcoin!
Para facilitar um maior rendimento na cadeia, os blocos da Rootstock foram concebidos para serem extraídos mais rapidamente do que os blocos da Bitcoin (por conseguinte, têm uma dificuldade inferior à da Bitcoin). Atualmente, o tempo médio de bloqueio da Rootstock é de cerca de 25 segundos, em comparação com o tempo médio de bloqueio de 10 minutos da Bitcoin.
tldr
Para fazer a ponte entre o BTC e a cadeia, a Rootstock implementou um tipo especial de configuração BTC federada que vem com um toque de hardware. Os Pegnatories (signatários) são obrigados a executar o módulo de segurança de hardware da Rootstock, chamado PowHSM. O PowHSM é um dispositivo à prova de adulteração responsável por armazenar a chave do signatário que faz parte do esquema multisig da federação. Semelhante à implementação do CubeSigner da Lombard, o PowHSM foi concebido para garantir que as chaves permanecem no hardware seguro desde a geração até à assinatura - ninguém, nem mesmo a Rootstock ou os próprios signatários, pode ver as chaves e muito menos os atacantes externos podem extraí-las.
O contrato Bridge no Rootstock executa o Bitcoin SPV, dando-lhe uma visão do Bitcoin a partir do Rootstock de uma forma fiável. Para as transacções de peg-in, os pegnatories aguardam que o depósito BTC do utilizador na Bitcoin acumule 100 confirmações antes de informar a Bridge, que irá então cunhar rBTC para o utilizador após verificação do depósito BTC do utilizador (via Bitcoin SPV).
Para transacções de peg-out, a Bridge aceitará primeiro o pedido de peg-out. Após 4000 confirmações de bloco (no Rootstock), a Bridge constrói a transação de peg-out do Bitcoin correspondente a esse pedido para que os pegnatories assinem. Cada PowHSM receberá então este comando (via Powpeg, também conhecido como nós completos do Rootstock) e accionará o pegnatory para assinar a transação. Uma vez que a maioria dos pegnatórios assine a transação, o multisig Bitcoin da Rootstock irá então libertar o montante correspondente de BTC para o endereço Bitcoin do utilizador que efectua o levantamento.
que se danem os conluios
O que diferencia a implementação da ponte BTC federada da Rootstock das outras é o facto de não exigir uma maioria honesta de confiança do seu conjunto de signatários para que a sua ponte permaneça segura. Por outras palavras, mesmo que a maioria dos pegnatários da Rootstock se conluie, não será capaz de comprometer a ponte e roubar os fundos dos utilizadores.
Como é que isto é possível? A razão é que o Rootstock consegue dissociar a geração de transacções da assinatura de transacções e associá-la à assinatura segura por HSM ligada ao Powpeg.
Para ilustrar, numa construção típica multisig ou MPC, os seus signatários geram e assinam transacções. Tomando a Lombard como exemplo, um utilizador deve primeiro submeter um pedido de peg-out interagindo na cadeia com um contrato-ponte da Lombard. Um dos signatários da Lombard irá recolher este pedido e, em seguida, gerar o pedido do utilizador como uma transação Bitcoin antes de o propor ao Consórcio para aprovação. Após a aprovação da maioria, o multisig Bitcoin da Lombard libertará então o montante BTC correspondente para o utilizador que efectua o levantamento. Espera-se que isso seja representativo em todas as pontes BTC federadas, com menos variações menores (inconsequentes).
Em seguida, observe que o signatário Lombard é quem gera a transação Bitcoin facilitando a saída do usuário. Na eventualidade de um conluio entre a maioria dos signatários, o signatário (com a bênção da maioria) poderá propor uma transação desonesta ao Consórcio para aprovação da maioria. É por isso que as pontes federadas de BTC quase sempre implicaram um pressuposto de segurança de maioria honesta - isto é, até Rootstock!
[IOV Labs] ilustrado: arquitetura do Powpeg da Rootstock
A Rootstock é única no sentido em que os pegnatórios não geram transacções Bitcoin correspondentes ao pedido de peg-out de um utilizador. Isto porque o contrato Bridge na Rootstock é o que cria a transação Bitcoin para o utilizador, que por sua vez é validada pelos mineiros de Bitcoin que optaram por participar no processo de mineração de fusão da cadeia. Os Pegnatories não desempenham qualquer papel na geração de transacções - o seu papel é apenas o de executar o PowHSM, que se liga ao Powpeg e assinará "automaticamente" a transação já construída, uma vez recebida.
Para visualizar, imagine que está a visitar a interface Uniswap para fazer uma troca. Primeiro, sua carteira (ou seja, Metamask) irá gerar dados de transação com base no que você pretende fazer (por exemplo, "trocar X ETH por USDC"), que então aparece em sua carteira de hardware (ou seja, Ledger) para você assinar. Nesse cenário, aquele que clica na interface Uniswap é análogo ao usuário que está retirando, a carteira que gera os dados da transação é análoga ao contrato Bridge em Rootstock, e aquele que pressiona os botões físicos na carteira de hardware é análogo ao PowHSM executado pelo pegnatory assinando a transação recebida.
no hardware em que confiamos.
Recorde-se que a blockchain da Rootstock está agora a ser minada por fusão com 80% do poder de hashing da Bitcoin. Portanto, a menos que queira seguir o caminho mais difícil e tentar comprometer a ponte rBTC, possuindo >40% do poder de hashing da Bitcoin e mantendo-o durante pelo menos 4000 blocos da Rootstock (~28 horas), como potencial atacante seria melhor visar a integridade da implementação PowHSM da Rootstock. Da mesma forma que se confia no Cubist quando se trata de negar o risco opsec do signatário do Lombard, o utilizador também precisa de confiar na Rootstock Labs para que o PowHSM gerido pelos pegnatórios não tenha quaisquer bugs ou backdoors ocultos que possam ser explorados pela Rootstock, por um potencial atacante ou mesmo pelos próprios pegnatórios.
Em defesa da Rootstock, eles realmente tomaram medidas para reduzir a quantidade de confiança que os usuários precisam colocar com eles, abrindo o firmware PowHSM. No entanto, como o firmware em si é implementado sobre o Ledger Nano S ou o Intel SGX, os utilizadores continuam a ter de confiar na Ledger ou na Intel (como fabricantes) na sua palavra de que o chip Secure Element é de facto seguro e que não introduzirão canais secretos, geradores de números aleatórios tendenciosos ou qualquer forma de backdoor nos seus dispositivos.
conclusão
Aproveitando a defesa em profundidade (também conhecida como segurança em camadas), a Rootstock conseguiu o que nenhum outro conseguiu - implementar uma ponte BTC federada que não requer uma suposição de maioria honesta para a segurança dos fundos depositados pelos seus utilizadores.
Mas, novamente, menos confiança não significa nenhuma confiança. Continua a ser necessário confiar na composição do conjunto de 12 pegnatory da Rootstock, tal como se confia nos conjuntos de signatários de outras configurações de pontes federadas. No entanto, no caso da Rootstock, uma vez que os pegnatórios não têm o poder de adulterar os dados da transação (eles "meramente" correm o PowHSM), elimina-se o risco de conluio de uma maioria honesta e "apenas" se confia nos pegnatórios para a vivacidade. No entanto, no caso de a maioria dos pegnatórios ficar offline, corre o risco de ter os seus fundos presos no multisig Bitcoin da Rootstock.
Além disso, também é necessário confiar na segurança da implementação do PowHSM da Rootstock. Isto inclui confiar que as instalações de firmware nos PowHSMs são efectuadas corretamente e também confiar na Ledger e/ou na Intel quanto à integridade dos seus dispositivos.
[Rootstock] o panorama geral: A paridade bidirecional federada da Rootstock e a cadeia principal da Bitcoin
A ponte rBTC da Rootstock é, de facto, uma grande melhoria em relação às pontes BTC federadas existentes, mas o facto permanece: ainda necessita que o utilizador deposite algum nível de confiança em certas partes da pilha. Embora eu não negue que a segurança oferecida pela configuração da ponte federada da Rootstock já é mais do que suficiente para 99% dos tokens e representações por aí, vou discordar quando se trata de BTC - uma ponte de confiança minimizada não é apenas preferida, mas sim um pré-requisito.
A Rootstock merece muitas flores por ter (na minha opinião) não só a melhor implementação de ponte BTC federada, mas também a melhor ponte BTC global que está atualmente em funcionamento - equilibrando elegantemente a necessidade de segurança e eficiência de capital com o seu design.
No entanto, o trabalho ainda não está terminado.
BTC com garantia
Para além da Lightning, as pontes BTC colateralizadas representam uma das poucas formas conhecidas de "exportar" BTC para uma cadeia ou camada escalável de uma forma verdadeiramente sem permissões.
Não há reputações envolvidas, não são necessárias entidades de confiança. Concebida para ser aberta a qualquer pessoa, mas com um nível de confiança reduzido, os utilizadores não precisam de confiar em ninguém.
Aqui, o dinheiro é literalmente rei.
tldr
A ideia é simples: por cada dólar de BTC depositado na ponte BTC colateralizada, haveria pelo menos mais de um dólar de outros activos a apoiá-lo.
E a implementação? Nem por isso!
Embora existam pequenas variações, podemos categorizar as pontes BTC colateralizadas em dois tipos de implementação: pontes do tipo CDP e pontes ponderadas por participação.
Interlay iBTC
CDP significa posição de dívida colateralizada, popularizada pela MakerDAO e é encontrada principalmente em projetos de stablecoin descentralizados, como o LUSD da Liquity e o próprio DAI da MakerDAO. Para cunhar um token de dívida (também conhecido como LUSD ou DAI), os usuários devem depositar garantias (ou seja, wBTC, ETH) que excedam o valor da dívida máxima permitida da posição. O rácio de garantia dependerá da volatilidade percebida e do risco do ativo de garantia - os activos seguros "blue-chip" tenderiam a obter um rácio mais baixo, enquanto os activos de cauda longa exigiriam um rácio de garantia mais elevado para compensar o seu risco percebido. Se o rácio de garantia cair abaixo de um determinado limiar (ou seja, 110%), os cofres entrarão em liquidação, correndo os detentores de posições o risco de perder a totalidade da sua garantia.
O iBTC da Interlay é um exemplo de implementação de uma ponte BTC ao estilo CDP, em que cada $1 de BTC em ponte deve ser apoiado por >$1 de garantia na cadeia de destino. Para cunhar iBTC, os vaulters devem primeiro depositar garantias na Interlay antes de depositar BTC na cadeia principal. A quantidade de iBTC que pode ser cunhada corresponde ao valor da garantia do vaulter na Interlay: se a garantia bloqueada valer $160, os vaulters só podem cunhar $100 de iBTC na Interlay(160% CR). Se o valor da garantia do vaulter cair abaixo do rácio de liquidação, qualquer pessoa poderá queimar iBTC para resgatar a sua garantia a um prémio (110%), o que garante que o sistema se mantém saudável, uma vez que os liquidatários irão monitorizar constantemente os cofres para uma oportunidade de extrair prémios de liquidação.
[Interlay] ilustrado: Interlay iBTC
Para resgatar iBTC por BTC em Bitcoin, os utilizadores começam por enviar um pedido a um vaulter, que processará o levantamento enviando o montante correspondente em BTC para o utilizador a partir do seu cofre Bitcoin. Se o vaulter ficar offline ou simplesmente se recusar a resgatar BTC, o utilizador pode reclamar a garantia do vaulter proporcional ao valor do seu resgate de iBTC, mais alguma recompensa de "resgate falhado". Desta forma, os vaulters são incentivados a resgatar BTC para o utilizador, para não correrem o risco de pagar um prémio ao utilizador com a sua garantia bloqueada no Interlay.
Limiar tBTC
Por outro lado, as pontes ponderadas por participação são basicamente pontes BTC federadas, mas, em vez de restringir o conjunto de signatários a apenas algumas entidades de confiança escolhidas a dedo, qualquer pessoa pode participar como signatário, apostando os seus activos na ponte (e executando o software necessário para operar como signatário da ponte). Os privilégios de assinatura são distribuídos via multisig e/ou MPC, dependendo dos detalhes de implementação de cada ponte.
Agora vamos dar uma olhada no tBTC da Threshold, sem dúvida a implementação de ponte BTC ponderada por participação mais proeminente. A Threshold aproveita o MPC para gerar o endereço de depósito de Bitcoin de sua ponte, cada um consistindo de 100 signatários. Os signatários são escolhidos através de um processo aleatório (via Sortition Pool), onde a probabilidade de um staker ser escolhido para ser um signatário é igual à sua percentagem de $T apostado em relação ao conjunto de signatários - se apostou 10 $T e o conjunto de signatários tem 800 $T apostados no total, a sua hipótese de ser selecionado como signatário para esse endereço de depósito Bitcoin será de 1,25%. Assumindo 100 signatários para um endereço de depósito de Bitcoin, você pode esperar que seu nó irá compor pelo menos 1 signatário do conjunto. Para além disso, uma vez que utiliza o algoritmo Threshold ECDSA para a geração e assinatura de carteiras, 51 dos 100 signatários têm de cooperar para mover fundos para fora dos endereços de depósito Bitcoin da Threshold.
[Chaos Labs] ilustrado: Limiar tBTC
A cada 14 dias, a ponte irá gerar um novo endereço de depósito Bitcoin para depósitos BTC do utilizador com base na composição atual de staking do Threshold. Para além de permitir que os novos stakers se tornem signatários dos futuros endereços de depósito Bitcoin da Threshold, isto também garante a segurança futura: mesmo que uma maioria corrupta faça parte da composição de staking da Threshold, só comprometerá os novos endereços de depósito Bitcoin gerados a partir desse momento. Em outras palavras, se você usou o Threshold para fazer a ponte com seu BTC (e cunhar tBTC) antes que a maioria corrupta assumisse a composição da aposta, seu BTC permanecerá armazenado com segurança no endereço de depósito Bitcoin controlado pelo conjunto de signatários de maioria honesta então seguro.
iBTC - na garantia em que confiamos
Ambos os modelos de pontes (tipo CDP e ponderado por participação) não impõem um conjunto fechado de entidades privilegiadas na sua conceção. A identidade e a reputação do signatário não importam aqui - a única coisa que importa em termos de segurança da ponte é a garantia que está bloqueada no sistema.
No caso da ponte do tipo CDP da Interlay, os utilizadores têm de confiar na garantia que está a apoiar cada iBTC. Lixo que entra, lixo que sai - se a ponte aceitar activos não válidos como garantia, correrá o risco de subcolateralização: os liquidatários podem não estar motivados para liquidar cofres se a garantia que recebem em troca não tiver um mercado líquido ou uma descoberta de preços eficiente. Para esclarecer este ponto, imagine que é um liquidatário e pergunte a si próprio: está disposto a liquidar um cofre pagando um prémio de 10% por uma memecoin com pouca liquidez na cadeia e suscetível a oscilações de preço de 20% de hora a hora?
Isto não obstante o risco de oráculo em que terá de incorrer - como utilizador, é inevitável que tenha de confiar na rede de oráculos que transmite os preços dos activos de garantia no Interlay. Os oráculos não são construídos da mesma forma - enquanto alguns têm uma amostra considerável para as suas fontes de preços e implementam práticas de segurança robustas, outros podem ser um pouco mais suspeitos. De facto, o elo mais fraco acaba muitas vezes por ser o oráculo e não as garantias do CDP ou a implementação dos seus contratos inteligentes!
tBTC - nos stakers confiamos
Naturalmente, por ser uma ponte ponderada por estaca, os detentores de tBTC precisariam confiar que a composição de estaca de $T da Threshold permanece descentralizada e que nenhuma entidade ou coalizão única será capaz de compreender mais de 51% de $T em estaca - presente ou futuro.
Embora a segurança futura da Threshold limite os danos a apenas futuros depósitos de BTC após o ponto de comprometimento (composição de staking), não se pode ter certeza de quando isso realmente acontece. O atacante pode simplesmente dividir os seus saldos de $T em vários endereços, o que faz com que pareça que os seus saldos são detidos por várias partes quando, na realidade, são controlados pela mesma entidade. Isso é agravado pela incapacidade do algoritmo de assinatura subjacente do Threshold de identificar signatários mal-comportados (pelo menos no tBTC v1), o que permite que possíveis atacantes permaneçam sem serem detectados à medida que se infiltram lentamente no conjunto de signatários e (eventualmente) formam uma maioria de staking. O acima exposto é aparentemente uma preocupação suficiente para a Threshold, de tal forma que eles decidiram lançar a ponte com um conjunto de signatários com permissão, no qual apenas entidades respeitáveis e verificadas podem ser signatárias - efetivamente tornando a Threshold, pelo menos em sua forma atual, uma ponte BTC quase federada!
Mas, para fins de argumentação, vamos supor que a ponte não tem permissão - o token $T atingiu bilhões em valor de mercado, e que seria altamente improvável para qualquer atacante ser capaz de acumular $T até 51% da composição de apostas da ponte. Mesmo neste estado de "fim de jogo", a ponte continua a ser limitada pela capacidade: os depósitos de BTC dos utilizadores só são considerados economicamente seguros se o conjunto de signatários puder perder mais em garantias de staking do que o que poderiam ganhar com o roubo de fundos dos utilizadores em todos os endereços de Bitcoin depositados que controlam coletivamente.
Para quantificar o acima exposto, vamos imaginar um cenário em que um total de $10M de $T é apostado no Threshold. Também por uma questão de simplicidade, vamos assumir que o conjunto de signatários permanece inalterado durante todo o processo. Uma vez que precisa de 51 de 100 para assinar, pode dizer que a segurança económica da ponte vale $5.1M - este é o valor máximo de garantia que está disponível para o Threshold cortar os stakers desonestos. Agora pode ver onde isto vai dar - teoricamente, quando a soma dos depósitos BTC dos utilizadores em endereços de depósito Bitcoin controlados atingir um total de mais de 5,1 milhões de dólares, tornar-se-ia lucrativo para os signatários conspirarem e desviarem os fundos dos utilizadores. Embora, na prática, o conjunto de signatários não seja fixo em vários endereços de depósito de Bitcoin (para acomodar stakers novos e antigos), a teoria do jogo por trás disso ainda se mantém: uma maioria desonesta do conjunto de signatários é capaz de comprometer a ponte, desde que o valor dos depósitos de BTC dos utilizadores em endereços de depósito de Bitcoin controlados seja superior à garantia em jogo que eles podem perder.
conclusão
Para além da Lightning, apenas as pontes BTC com garantia podem afirmar que são verdadeiramente sem permissões. Infelizmente, eles também carregam um conjunto de enigmas e suposições implícitas de confiança que existem fora da própria ponte.
A segurança das pontes do tipo CDP está basicamente entrelaçada com a composição das garantias que aceitam para apoiar a ponte. Se a ponte se restringir apenas a ativos de alta qualidade (ou seja, ETH), então eles precisariam competir com outros protocolos DeFi em rendimento para atrair esses ativos: por que um detentor de ETH deveria depositar com você, quando eles podem obter rendimentos mais altos em outros protocolos?
CDP-style bridges are also highly capital-inefficient — in the case of Interlay, at least $1.6 worth of collateral is needed in order to mint $1 worth of iBTC. You can only lower the collateralization ratio down to a certain threshold: set it too low (<110%), and you’re staring at a barrel of failed liquidations and the risk of the bridge failing due to being straddled by bad debt.
Há também a questão da segurança do oráculo. Para que as liquidações ordenadas sejam possíveis em primeiro lugar, as pontes do tipo CDP dependem de feeds de preços robustos e precisos provenientes do oráculo. O que significa que, por defeito, os utilizadores teriam de confiar também na rede ou no fornecedor do oráculo da ponte.
No caso das pontes ponderadas por participação, a distribuição de participações é o fator decisivo - afinal de contas, elas determinam quem fará parte do conjunto de signatários ao gerar os novos endereços de depósito Bitcoin da ponte. Os utilizadores têm de confiar que a distribuição da propriedade do token de staking é suficientemente descentralizada para que nenhuma entidade ou coligação consiga atingir a maioria - agora e no futuro.
Além disso, as pontes ponderadas por participação são fundamentalmente limitadas em termos de capacidade (embora muito melhor do que as pontes do tipo CDP) - só podem garantir economicamente os depósitos de BTC do utilizador até ao valor total da garantia em participação de uma potencial maioria desonesta do conjunto de signatários. Isto limita efetivamente a quantidade de BTC que pode ser armazenada de forma segura nos múltiplos endereços de depósito da ponte - em nenhuma circunstância o valor total dos depósitos de BTC dos utilizadores nesses endereços deve exceder o valor total da garantia em jogo da maioria de signatários que os controla.
As representações não são iguais
Sair da cadeia principal tem as suas próprias nuances. É verdade que as representações de BTC externas ao Bitcoin nunca serão tão seguras quanto manter o BTC na cadeia principal, mas às vezes você simplesmente não precisa de tanta segurança para o seu estoque. Nem toda a gente aqui é milionária!
Embora eu acredite que a maioria das camadas e pontes de escalonamento BTC discutidas acima permanecerão razoavelmente seguras no futuro previsível, acho importante que, como um hodler BTC autocustodial, você deva pelo menos estar ciente das opções que você tem no mercado hoje. Espero que, através deste artigo, o hodler médio de BTC esteja agora melhor informado sobre os compromissos de confiança que existem ao navegar em diferentes ambientes de auto-custódia.
Para o nosso próximo artigo da série, vamos explorar a descoberta revolucionária que é o BitVM, um paradigma de computação no Bitcoin que permite que os programas sejam executados no Bitcoin de uma forma otimista. Isso significa que ele lida com a maior parte da computação fora da cadeia e, portanto, não é prejudicado pelas limitações do Bitcoin. No entanto, se alguém discordar do resultado, pode levantar uma disputa on-chain no Bitcoin. Se houver alguma batota, a pessoa fraudulenta é exposta e punida. Como primeiro passo, isso permitirá a construção de pontes BTC de confiança minimizada do Bitcoin para camadas de escalonamento externas pela primeira vez. No futuro, o BitVM poderia até mesmo permitir verdadeiros rollups de Bitcoin, onde os dados de transação são armazenados no blockchain do Bitcoin.
A cadeia híbrida da BOB funde os pontos fortes da segurança da Bitcoin e as ferramentas de ponta da EVM, herdando o melhor dos dois mundos. Pioneira na primeira implementação prática do BitVM no mundo, a BOB será o lar de transacções de bitcoin seguras e baratas e DeFi - eis a Bitcoin nativa, fora da Bitcoin!
Parece demasiado bom para ser verdade? Fique atento à Parte 2 - um mergulho profundo na Cadeia Híbrida do BOB, a porta de entrada para o Bitcoin DeFi.
Se achar que me escapou alguma coisa que valha a pena mencionar, contacte-me no X/Twitter - estou sempre aberto a sugestões e feedback. Além disso, se este artigo foi útil para si, agradecemos que o reposte e o goste!
