Introdução
O BOB é um L2 híbrido único, concebido para combinar a segurança do Bitcoin com a programabilidade do Ethereum. Os L2s híbridos herdam a segurança do Bitcoin, como a rede mais segura e descentralizada. A segurança do Bitcoin é então usada para criar pontes de confiança minimizada para Bitcoin, Ethereum e outros L1s. Como resultado, o Hybrid L2 não dependerá de pontes de terceiros para interoperabilidade e resolve o problema da liquidez fragmentada da multi-cadeia BTC.
Ao fundir a segurança e o capital do Bitcoin com a inovação e versatilidade DeFi da Ethereum, o BOB colocará o Bitcoin no centro do DeFi - desbloqueando novos casos de uso e trilhões em liquidez. Isso fará do BOB o lar ideal para o Bitcoin DeFi: o melhor e mais seguro lugar para ganhar rendimento em seu Bitcoin.
Em 2024, publicámos o whitepaper Hybrid L2, apresentando a visão Hybrid e o design de alto nível para o L2 híbrido BOB, bem como o roteiro de 3 fases de atualização BOB de ETH L2 para Hybrid L2.
Neste artigo, descrevemos como o BOB alcançará a Fase 2: Um rollup ETH com finalidade Bitcoin e uma ponte BTC alimentada por BitVM. Como parte dessa atualização, o BOB alcançará as cinco novas propriedades a seguir:
- Validade do estado através de provas ZK: Os blocos BOB são verificados criptograficamente e comprovadamente corretos para evitar falhas de segurança. Isto torna a sequência de transacções sem confiança, permitindo a descentralização do sequenciador, e melhora os tempos de finalização.
- Finalidade através de staking de Bitcoin: A BOB tem uma única cadeia canónica em qualquer ponte nativa, imposta pela finalidade Bitcoin através de staking BTC. Se os Finality Providers (FPs) assinarem cadeias concorrentes, a sua participação em BTC será reduzida.
- Ponte nativa de Bitcoin via BitVM: A BOB terá uma ponte Bitcoin nativa baseada no projeto BitVM2 de coautoria.
- Levantamentos rápidos: Utilizando provas de validade e FPs, os levantamentos de BOB para Bitcoin e Ethereum demorarão, no máximo, algumas horas.
- Disponibilidade de dados híbridos: Os utilizadores da BOB podem incluir transacções na BOB enviando uma transação na rede principal da Bitcoin. Isto permite levantamentos de volta para a Bitcoin sem que o sequenciador possa censurar as transacções.
Blocos de construção da Fase 2
Na Fase 1, a BOB lançou a sua rede principal como um rollup OP Stack no Ethereum, apoiando os activos BTC do Ethereum (wBTC, SolvBTC, LBTC, tBTC, ...). A BOB continuará a utilizar os blobs EIP-4844 da Ethereum como DA e apoiará a ligação ao Ethereum através dos contratos-ponte padrão da OP.
Na Fase 2, o BOB introduz três blocos de construção para adicionar validade de estado ("ZK rollup"), finalidade Bitcoin e uma ponte BTC nativa.
- Provas de validade: Utilizando SNARKs sobre propostas de estado BOB, qualquer terceiro, cliente leve ou cadeia externa pode verificar criptograficamente que as propostas de estado BOB são criadas corretamente. As provas de validade são postadas e verificadas no Ethereum. Isto garante que o sequenciador BOB não pode produzir blocos inválidos e faz do BOB um rollup de validade (por vezes referido como "ZK rollup"). As provas de validade também formam a base para as pontes nativas para Bitcoin (via BitVM) e Ethereum.
- Provedores de Finalidade (FPs) com estaca BTC: BOB introduz FPs com estaca BTC, alimentados por Babylon. Os FPs apostam BTC no Bitcoin e assinam as propostas de estado do BOB. Se os FPs assinarem mais do que uma versão da cadeia BOB, o seu BTC é cortado em Bitcoin (as chaves privadas são divulgadas, leia mais aqui). O corte por equívoco introduz um custo económico elevado para a tentativa de bifurcação da cadeia BOB, oferecendo garantias de finalidade mais fortes. Essa propriedade desempenha um papel crítico no design do L2 híbrido, pois garante uma operação consistente das pontes nativas BTC e ETH. Embora um sequenciador corrompido não possa criar blocos BOB inválidos (devido a provas de validade), ele poderia criar duas versões válidas, mas conflitantes, da cadeia BOB (por exemplo, contendo um gasto duplo) e tentar criar inconsistência nas pontes BTC e ETH. A finalização BTC-staked evita esta situação, impondo uma única versão canónica do BOB, verificada tanto na Bitcoin como na Ethereum.
- BitVM: O BitVM é um mecanismo para executar programas arbitrários no Bitcoin de uma forma otimista: a execução acontece fora da cadeia, mas em caso de falhas, as disputas são resolvidas e aplicadas na cadeia. Usamos o BitVM para criar uma ponte de confiança minimizada entre o Bitcoin e o BOB. Especificamente, criamos uma ponte bidirecional de cliente leve: A BOB já pode verificar os depósitos na Bitcoin, a BitVM permite-nos verificar os levantamentos na BOB e garantir o processamento correto na cadeia principal da Bitcoin. Deste modo, verificamos a prova SNARK sobre o estado do BOB, bem como a finalidade do BTC, utilizando o mecanismo à prova de fraude do BitVM.
O design da BOB Hybrid L2
Utilizamos agora os três blocos de construção para criar o primeiro Hybrid L2 de sempre:
- Validade Rollup e Finalidade Bitcoin: Combinando Provas de Validade e FPs com participação em BTC, o BOB Hybrid L2 permite a segurança das transacções e a finalidade rápida garantida pelo BTC. Os FP comprometem-se a que o estado BOB seja válido, apresentando uma prova de validade e fornecendo assinaturas sobre as propostas de estado BOB, ponderadas pela sua participação em BTC.
- Ponte nativa de Bitcoin: Alavancando as Provas de Validade, FPs BTC-Staked e BitVM, o BOB adiciona uma ponte Bitcoin nativa. No BitVM, os operadores reivindicam BTC das instâncias do BitVM através de uma combinação complexa de várias provas da operação da ponte e da finalização do estado do BOB.
- Ponte e liquidação nativas do Ethereum: Integrando as Provas de Validade e os FPs com apostas em BTC, os proponentes do Ethereum nativo afirmam que o BOB é válido e finalizado pelos FPs para completar os levantamentos dos utilizadores para o Ethereum.

Validade do Rollup e Finalidade da Bitcoin
O sequenciador BOB produz blocos a cada 2 segundos. Após um certo número de blocos BOB terem sido criados, o estado de BOB é finalizado - semelhante a um ponto de controlo. Para isso, o sequenciador BOB gera uma prova de validade SNARK de BOB, incluindo todos os blocos produzidos desde o último ponto de controlo/prova. Esta prova verifica criptograficamente que todas as transacções processadas são válidas.
O sequenciador submete o hash da proposta de estado, a assinatura e a prova de validade aos FPs apostados em BTC. Os FPs devem ter apostado BTC no Bitcoin para se qualificar como FPs BOB e receber parte das taxas do sequenciador em troca de recompensas de aposta. Consideramos uma proposta de estado BOB final uma vez que tenha sido assinada por pelo menos ⅔ da aposta BTC. Além disso, o compromisso assinado com o estado BOB é regularmente verificado para Bitcoin. Após 100 blocos de Bitcoin, o ponto de verificação é considerado finalizado.
Esta combinação de prova de validade e finalidade Bitcoin é então utilizada para verificar e executar corretamente depósitos e levantamentos para as pontes nativas Bitcoin e Ethereum.
Ponte Bitcoin nativa
No BitVM, os chamados operadores facilitam aos utilizadores a entrada e saída de BTC do BOB. Os operadores e os utilizadores criam uma instância BitVM para cada depósito em que o utilizador bloqueia um montante de BTC e recebe bobBTC no BOB. Quando um utilizador inicia um levantamento, o operador envia-lhe primeiro BTC da sua própria carteira (adiantando as BTC) e depois reclama as BTC do depósito BitVM. O operador só pode reclamar as BTC do BitVM se puder provar que (1) forneceu BTC a um utilizador que efectuou o levantamento e (2) o pedido de levantamento correspondente (que queima bobBTC) foi finalizado. Este processo é otimista: o operador inicia o processo de reivindicação de BTC (sob a forma de um SNARK), afirmando que processou corretamente o pedido de levantamento, e pode ser contestado por qualquer utilizador observador durante um período de tempo pré-definido ("período de contestação").
Se desafiado, o operador e o desafiador verificam uma pequena parte do programa verificador SNARK no Bitcoin em script Bitcoin. Se o desafiador provar com sucesso que o operador está a fazer batota, o BTC permanece na instância BitVM, e o operador é cortado e removido da ponte. Se o operador for honesto, ele recebe o BTC da instância do BitVM e o desafiante é eliminado.

Especificamente para BOB, o operador faz a seguinte reivindicação para uma instância BitVM: Eles combinam a transação de retirada de Bitcoin (= a transação PegOut) com a prova de que o BTC em ponte no BOB foi queimado em um bloco finalizado, ou seja, um bloco BOB que faz parte de uma proposta de estado finalizado. Também provam que a transação PegOut e a referência do ponto de controlo BOB (como parte do ponto de controlo do estado BOB assinado pelos stakers BTC para a Bitcoin) na Bitcoin estão na mesma cadeia.
Para uma introdução mais aprofundada sobre o BitVM, diferenças entre possíveis abordagens de design e atualizações de progresso mais recentes, consulte nosso Relatório de status do BitVM.
Ponte e liquidação nativas do Ethereum
Existem dois tipos populares de rollup no Ethereum: Rollups optimistas e de validade. Nos rollups optimistas, as propostas de estado regulares podem ser contestadas durante uma janela de tempo predefinida. Se uma proposta de estado não for contestada com sucesso, ela é considerada finalizada. Nos rollups de validade, uma proposta de estado é acompanhada por uma prova ZK que garante a validade do estado. A prova é verificada no Ethereum e, se for válida, o estado é imediatamente finalizado.
Como parte da Fase 2, o BOB se tornará um rollup de validade. Isso garante que o mesmo estado finalizado usado para BitVM também seja usado para Ethereum. A prova de validade para BOB é diferente de outros rollups de validade. Combina duas provas: (1) a validade do bloco BOB evitando falhas de segurança e (2) uma prova de que os FPs atestam a cadeia canónica do BOB. A prova sobre os FPs inclui a presença de ⅔ ou mais de FPs com estaca BTC, um ponto de verificação das assinaturas de FP no Bitcoin e que o ponto de verificação tem pelo menos 100 confirmações no Bitcoin.
Podemos frequentemente finalizar o estado da BOB no Ethereum submetendo esta prova de validade combinada. Isto, por sua vez, reduz o tempo de retirada para o Ethereum do atual padrão de 7 dias de um rollup otimista para apenas algumas horas - de acordo com o padrão para rollups de validade.
Disponibilidade de dados híbridos
Por conceção, os utilizadores podem incluir uma transação na BOB submetendo uma transação no Ethereum, protegendo-os contra a censura do sequenciador. Em combinação com as provas de validade e as liquidações no Ethereum abertas a qualquer pessoa, os utilizadores podem forçar a retirada dos seus activos para o Ethereum em situações de emergência.
Recentemente, o BOB introduziu o novo conceito de disponibilidade de dados híbridos, em que o Bitcoin é adicionado ao pipeline de derivação de um rollup ETH. À semelhança da forma como os utilizadores podem enviar transacções arbitrárias juntamente com um depósito no contrato OptimismPortal no Ethereum, permitimos que os utilizadores enviem transacções arbitrárias para o BOB no Bitcoin. O principal caso de uso para isso é incluir transações de retirada no BOB para Bitcoin se o sequenciador estiver offline ou censurando usuários no L2.
No post completo, descrevemos como a adição do Bitcoin ao pipeline de derivação alcança a resistência à censura do Bitcoin para transações L2.
Perspectivas para a Fase 3: Segurança total da Bitcoin
Se o Bitcoin adicionar a funcionalidade para verificar provas de validade nativamente no script Bitcoin, o BOB pode se estabelecer diretamente no Bitcoin com total segurança Bitcoin. Isso representa o estado ideal da Fase 3: segurança total do Bitcoin que pode ser comprovada através de um cliente Bitcoin light para qualquer outra cadeia. Isso significa que o BOB se estabelece no Bitcoin e a finalização (de pontes) em outras cadeias é feita pela verificação do Bitcoin. É uma suposição de confiança razoável: se o Bitcoin falhar, provavelmente todas as outras cadeias também falharão.
Na ausência de um fork do Bitcoin que permita verificadores ZK na cadeia, o BOB terá de aproveitar a verificação otimista através do BitVM. Conseguir rollups otimistas no Bitcoin sem suposições de confiança adicionais requer o uso da cadeia principal do Bitcoin como uma camada de disponibilidade de dados. Atualmente, os custos de DA da Bitcoin são onerosos(ver relatório Galaxy) e representam um desafio em termos económicos.
Consequentemente, para completar a transição para a Fase 3, a BOB tem de atingir uma escala suficiente em termos de utilizadores activos, de modo a que as taxas adicionais de disponibilidade de dados não aumentem as taxas de transação para além das taxas dos concorrentes Ethereum L2. As camadas alternativas de disponibilidade de dados podem ser consideradas como um compromisso entre custo e segurança, uma vez que introduzem pressupostos de confiança adicionais para além dos da Bitcoin.
É importante sublinhar que a utilização de uma camada DA alternativa com verificação BitVM para a finalidade do rollup não acrescenta vantagens em relação à conceção da Fase 2: a segurança (normalmente PoS) da camada DA tem de ser fiável. Além disso, tal construção requer a verificação de uma prova de cliente leve para o consenso (PoS alternativo) do DA no BitVM, que é uma questão de investigação em aberto.
Consequentemente, a fase 2 da BOB é a solução mais segura e viável na prática para a DeFi das BTC atualmente, especialmente devido ao facto de a participação das BTC ser reduzida em caso de equívoco.
Conclusão
Apresentamos o plano técnico para atualizar o BOB para o primeiro Hybrid L2 de todos os tempos: um rollup Ethereum com finalidade Bitcoin e pontes nativas e minimizadas de confiança para ativos BTC e ETH.
Começaremos a implementar o Hybrid L2 na testnet nas próximas semanas e completaremos a atualização para a mainnet após auditorias bem sucedidas. Paralelamente, estamos a concluir uma especificação técnica completa, incluindo provas de segurança, que será divulgada em breve. A ponte BitVM da BOB já foi lançada na testnet, com a integração do operador a começar em breve.