Os usuários de Bitcoin devem apenas precisar de BTC no Bitcoin para forçar uma retirada de seus BTC da BOB de volta para o Bitcoin. Estamos trabalhando em uma solução híbrida: padrão para Ethereum como DA, permitindo que os usuários incluam transações na BOB por meio de uma transação especial no Bitcoin. Estamos animados para compartilhar nosso trabalho em andamento neste post do blog.

tl;dr

• L2s devem ter a mesma resistência à censura que as L1s nas quais são baseadas
• Na Gate, os usuários já podem forçar a retirada de seus ativos da Gate para Ethereum por meio de uma transação Ethereum
• Para sua ponte BitVM, a BOB está trabalhando na integração do Bitcoin como uma forma para os usuários fazerem transações na BOB.
• Os usuários de Bitcoin poderão sacar seus BTC da BOB sem precisar enviar uma transação para a BOB

Uma das propriedades principais dos L2s é que seu estado precisa progredir mesmo quando o o sequenciador está offline. L2s conseguem isso lendo e escrevendo seu estado de uma camada de Disponibilidade de Dados (DA) que pode ser atualizada independentemente do L2 estar online. Dessa forma, os usuários podem forçar a inclusão de suas transações mesmo quando o sequenciador está offline ou o sequenciador não aceita suas transações diretamente.

Para a ponte BitVM da BOB, isso apresenta um problema interessante. Atualmente, a BOB usa blobs Ethereum EIP-4844 como sua camada DA. Usuários no Ethereum podem facilmente acionar saques de volta para Bitcoin via a ponte BitVM. No entanto, requer que os usuários tenham ETH no Ethereum.

Isso não é bom o suficiente para nós: os usuários de Bitcoin só precisam de BTC em Bitcoin para forçar um saque de seu BTC de BOB de volta para Bitcoin. Estamos trabalhando em uma solução híbrida: usando Ethereum como DA por padrão, permitindo que os usuários forcem a inclusão de transações em BOB por meio de uma transação especial em Bitcoin. Estamos animados para compartilhar nosso trabalho em andamento neste post do blog.

Um histórico sobre DA e Derivação

O processo de derivaçãoé bastante importante para L2s: todo o estado L2 do BOB precisa ser construído a partir do L1 e da camada DA. Isso permite que os L2s desfrutem da mesma resistência à censura que a camada DA, no nosso caso, Ethereum.

Simplificado, nos rollups (especificamente cadeias OP Stack), temos dois tipos de dados no L1:

• Transações de depósitofeito para o contrato "OptimismPortal". Essas são as transações feitas pelos usuários no Ethereum, geralmente para depositar seus ativos no BOB. Essas transações de depósito também podem ser usadas para executar outras transações no BOB.
• Lotes enviados pelo sequenciador (ou op-batcher para ser mais preciso) a partir de transações L2. Isso inclui todas as transações feitas diretamente pelos usuários no BOB e eventualmente são incluídas de volta aos blocos Ethereum.

Bitcoin como Camada DA

Se quisermos o Bitcoin como uma camada DA, por que não mudar completamente para usar o Bitcoin como uma camada DA? A resposta é principalmentecusto. O Bitcoin tem muito pouca capacidade de armazenamento disponível (cerca de 4MB aproximadamente a cada 10 minutos) e, portanto, o custo de armazenamento é alto.

No entanto, no nosso caso, a BOB ainda pode usar o Ethereum como sua camada DA 'principal' onde ela envia todos os seus dados de transações, mas adicionar o Bitcoin como uma camada de contingência altamente resistente à censura se o Ethereum DA estiver indisponível. Essencialmente, o Ethereum se torna a camada DA otimista, enquanto o Bitcoin se torna a última opção cara, mas tolerante a falhas.

Pipeline de Derivação Híbrida

A solução básica é adicionar Bitcoin ao BOB como parte do pipeline de derivação, de modo que o BOB (e especificamente o "op-node") processe entradas nesta ordem:

1. Transações forçadas de retirada do Bitcoin (recém-adicionadas especificamente para BOB)
2. Depósitos de Ethereum para o contrato OptimismPortal (padrão OP Stack) de BOB
3. Lotes de Ethereum do op-batcher (padrão de pilha OP)

Vamos entrar em uma possível solução para codificar as transações de retirada forçada do Bitcoin no pipeline de derivação BOB. Observe que isso ainda está sendo pesquisado, portanto, alterações são possíveis.

Transações Forçadas de Retirada do Bitcoin

Precisaremos de três partes para criar uma transação de retirada forçada:

1. Construa a transação de retirada forçada no Bitcoin.
2. Armazene a transação de saque forçado no Bitcoin dentro dos limites de tamanho do Bitcoin.
3. Lidar com custos de gás para a transação de saque forçado no Bitcoin.

1. Construir a Transação de Retirada Forçada

Uma pilha OPtransação de depósito tem a seguinte estrutura:

• bytes32 sourceHash: o hash de origem, identifica de forma única a origem do depósito.
• endereço de: O endereço da conta remetente.
• endereço para: O endereço da conta do destinatário, ou o endereço nulo (de comprimento zero) se a transação depositada for uma criação de contrato.
• uint256 mint: O valor ETH a ser criado na L2.
• uint256 valor: O valor ETH a ser enviado para a conta do destinatário.
• uint64 gas: O limite de gás para a transação L2.
• bool isSystemTx: Se verdadeiro, a transação não interage com o pool de gás do bloco L2.
• dados de bytes: O calldata.

Uma transação de saque forçado requer a inclusão da transação de saque codificada no campo de dados da transação de depósito. Isso é feito criando a transação no BOB que aciona a retirada do BOB para o Bitcoin e funcionaria exatamente da mesma forma que se a transação fosse enviada do Ethereum.

Podemos então armazenar uma versão (compactada) da transação de saque forçado no Bitcoin que inclui todos os dados acima.

2. Armazene a Transação de Saque Forçado no Bitcoin

Como os dados para a transação de retirada forçada são maiores do que o normalmente armazenado em uma saída OP_RETURN, provavelmente usaremos um Taprootsaída para armazenar os dados.

Embora seja fácil identificar uma transação de depósito (que pode incluir uma retirada) no Ethereum devido a ser enviada para o contrato OptimismPortal de BOB, não é tão fácil identificar uma transação de retirada forçada no Bitcoin.

Serialização de Dados: A transação de saque forçado é serializada usando scripts Taproot dentro de uma estrutura de “envelope”. Estes são noops na rede Bitcoin e são usados, por exemplo, para Ordinais também. Ajustamos a estrutura para atender às nossas necessidades.

Não definido
OP_FALSE OP_IF
OP_PUSH “bob”
OP_1
OP_PUSH "transação"
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Esquema de Compromisso/Revelação de Duas Fases:
Como acontece com os Ordinais, os usuários terão que enviar duas transações para o Bitcoin:

• Commit Transaction: Cria uma saída de Taproot comprometendo-se com o script que contém o conteúdo da inscrição. Esta transação ainda não revela os dados e precisaremos da segunda transação para os nós completos e sequenciadores do BOB incluírem a transação de retirada.
• Revelar Transação: Gasta a saída da transação de compromisso, revelando a inscrição on-chain, ou seja, revelando a transação de saque do usuário para inclusão em BOB.

3. Tratar dos Custos de Gás para a Transação de Retirada Forçada

Este é o problema mais aberto até agora, com duas opções atualmente em consideração:

• Defina o gás como 0 para a transação de saque forçado no Bitcoin e deduza os custos do gás do saldo ETH do usuário em BOB. Dessa forma, apenas os usuários que possuem ETH em BOB podem forçar saques. No entanto, essa não é uma boa opção, pois exigiria que os usuários tenham ETH em BOB para forçar saques, ou seja, os usuários que possuem BTC no Bitcoin não podem forçar saques.
• A gasolina é paga pelos usuários em BTC no Bitcoin. A rede BOB precisaria ter um endereço no Bitcoin que possa receber BTC e efetivamente trocar o BTC recebido pelo usuário por ETH no BOB para pagar os custos de gás da parte L1, além dos custos de execução. Essa opção é provável usandogateway BOBe definindo o endereço EVM da BOB DAO como o destinatário do BTC.

Também estamos experimentando mais ideias, então fique ligado para mais atualizações!

Colocando tudo junto

Qualquer pessoa pode determinar o estado do BOB apenas verificando os dados no Bitcoin e Ethereum:

1. Leia todas as transações de saque do Bitcoin. Elas são codificadas como duas transações para cada saque, ou seja, uma transação de compromisso e uma transação de revelação. Esta é a adição que estamos fazendo à Pilha OP e onde aprimoramos o pipeline de derivação.
2. Leia todas as transações feitas para o contrato do OptimismPortal de BOB na Ethereum. Isso já faz parte do pipeline de derivação da pilha padrão OP.
3. Leia todas as transações feitas diretamente na BOB e integradas como parte dos lotes no Ethereum. Importante, os nós completos não leem diretamente do sequenciador para receber transações confirmadas, mas eles leem dos blocos do Ethereum. Isso já faz parte do pipeline de derivação da pilha OP padrão.

Desafios Técnicos

Consistência de dados: Embora seja importante garantir a consistência de dados entre as cadeias Ethereum e Bitcoin, a mera presença de dados de transação em ambas as cadeias não garante a validade. As transações devem representar transições de estado válidas de acordo com a função de transição de estado do rollup para serem consideradas legítimas. A solução requer a implementação de lógica de validação dentro do op-node (ou outras implementações de camada de consenso) que verifica primeiro se uma transação resulta em uma alteração de estado válida antes de aceitá-la.

Provas de fraude e validade: O sistema de prova de fraude tanto para BitVM quanto para Ethereum precisa ser aprimorado para lidar com dados de ambas as cadeias, o que poderia tornar a resolução de disputas mais complexa. Para resolver isso, precisamos contabilizar com precisão as transações possíveis de Bitcoin e Ethereum como parte da ponte BitVM e da liquidação de BOB no Ethereum.

Aumento de armazenamento: Além disso, os nós BOB na rede enfrentam requisitos de armazenamento e largura de banda aumentados, uma vez que precisam processar e armazenar dados do Bitcoin e do Ethereum. No entanto, poderíamos mitigar isso exigindo que as transações BOB feitas no Bitcoin precisassem ser incluídas em blocos Ethereum com uma referência aos últimos blocos do Bitcoin. Dessa forma, os nós precisariam apenas sincronizar os blocos recentes do Bitcoin.

Próximos Passos

Estamos animados em empurrar a fronteira dos rollups híbridos combinando a segurança do Bitcoin com a inovação do Ethereum. Neste problema concreto, estamos interessados em ter a resistência à censura do Bitcoin de transações combinadas com a pilha de rollup do BOB. Atualizaremos esta postagem no blog com mais informações à medida que avançarmos.

Aviso Legal:

1. Este artigo é reproduzido de [BOB]. Todos os direitos autorais pertencem ao autor original [Dominik Harz]. Se houver objeções a essa reimpressão, entre em contato com o Gate Learnequipe, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: as opiniões expressas neste artigo são exclusivamente do autor e não constituem conselhos de investimento.
3. A equipe do Gate Learn traduziu o artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.