Os usuários do Bitcoin só precisam de BTC no Bitcoin para forçar uma retirada de seus BTC da BOB de volta ao Bitcoin. Estamos trabalhando em uma solução híbrida: com Ethereum como DA por padrão, 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.

Resumo demasiado longo; não li

• L2s deve ter a mesma resistência à censura que os L1s nos quais eles são baseados
• Na BOB, os usuários já podem retirar seus ativos da BOB para o Ethereum por meio de uma transação Ethereum.
• Para sua ponte BitVM, BOB está trabalhando na integração do Bitcoin como uma forma para os usuários executarem transações na BOB.
• Os usuários de Bitcoin poderão retirar seu BTC da BOB sem precisar enviar uma transação para a BOB.

Uma das propriedades principais dos L2s é que o seu estado precisa de progredir mesmo quando o O sequenciador está offline. L2s alcançam isso lendo e escrevendo seu estado a partir de uma camada de Disponibilidade de Dados (DA) que pode ser atualizada independentemente do L2 estar online. Desta 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, isto coloca um problema interessante. Atualmente, a BOB utiliza os blocos Ethereum EIP-4844 como sua camada DA. Os utilizadores na Ethereum podem facilmente desencadear levantamentos de volta para o Bitcoin através da ponte BitVM. No entanto, requer que os utilizadores tenham ETH na Ethereum.

Isso não é suficientemente bom para nós: os usuários de Bitcoin só precisam de BTC no Bitcoin para forçar uma retirada de seus BTC de BOB de volta para o Bitcoin. Estamos trabalhando em uma solução híbrida: usando Ethereum como DA por padrão, permitindo aos usuários incluir transações em BOB por meio de uma transação especial no Bitcoin. Estamos animados para compartilhar nosso trabalho em andamento neste post do blog.

Um Fundo Sobre DA e Derivação

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

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

• Transações de depósitofeitas para o contrato "OptimismPortal". Estas são as transações que os usuários fazem normalmente no Ethereum 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 submetidos pelo sequenciador (ou op-batcher para ser mais preciso) a partir de transações L2. Estes incluem todas as transações feitas diretamente pelos utilizadores no BOB e são eventualmente incluídas de volta nos blobs Ethereum.

Bitcoin como camada de 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 pouco armazenamento disponível (cerca de 4MB aproximadamente a cada 10 minutos), e, portanto, o custo de armazenamento é elevado.

No entanto, no nosso caso, BOB ainda pode usar o Ethereum como a sua camada DA “principal” onde ele publica todos os seus dados de transação, mas adicionar o Bitcoin como uma camada de fallback altamente resistente à censura se o Ethereum DA estiver indisponível. Essencialmente, o Ethereum torna-se a camada DA otimista, enquanto o Bitcoin torna-se o último recurso caro, 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 (especificamente o “op-node”) processe as entradas nessa ordem:

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

Vamos mergulhar em uma possível solução para codificar as transações de saque forçado de Bitcoin no pipeline de derivação BOB. Observe que isso ainda está em pesquisa, portanto, alterações são possíveis.

Transações forçadas de retirada de 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. Armazenar a transação de saque forçado no Bitcoin dentro dos limites de tamanho do Bitcoin.
3. Gerenciar os custos de gás para a transação de retirada forçada 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, que identifica exclusivamente 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 criar em L2.
• uint256 valor: O valor ETH a enviar para a conta do destinatário.
• uint64 gas: O limite de gás para a transação L2.
• bool isSystemTx: Se for verdadeiro, a transação não interage com o pool de gás de 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 o saque do BOB para Bitcoin e funcionaria exatamente da mesma forma como se a transação fosse enviada do Ethereum.

Podemos então armazenar uma versão (comprimida) da transação de retirada forçada no Bitcoin que inclui todos os dados acima.

2. Armazene a Transação de Retirada Forçada no Bitcoin

Como os dados para a transação de saque forçado 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 por ser enviada para o contrato OptimismPortal da 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 Ordinals também. Ajustamos a estrutura para atender às nossas necessidades.

Não definido
OP_FALSE OP_IF
OP_PUSH “bob”
OP_1
OP_PUSH “transaction”
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Esquema de Compromisso/Revelação em Duas Fases:
Assim como nos Ordinais, os utilizadores terão de submeter duas transações ao Bitcoin:

• Transação de Compromisso: Cria uma saída Taproot comprometida com o script contendo o conteúdo da inscrição. Esta transação ainda não revela os dados e precisaremos da segunda transação para que os nós completos e sequenciadores do BOB incluam a transação de retirada.
• Transação Revelada: 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 no BOB.

3. Lidar com os custos de gás para a transação de saque forçado

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 retirada forçada no Bitcoin e deduza os custos com gás do saldo ETH do usuário em BOB. Desta forma, apenas os usuários que possuem ETH em BOB podem forçar as retiradas. No entanto, esta não é uma boa opção, pois exigiria que os usuários tenham ETH em BOB para forçar as retiradas, ou seja, usuários que possuem BTC no Bitcoin não podem forçar as retiradas.
• O gás é pago pelos utilizadores em BTC no Bitcoin. A rede BOB precisaria de ter um endereço no Bitcoin que possa receber BTC e efetivamente trocar o BTC recebido pelo utilizador em ETH na BOB para pagar os custos de gás da parte L1 mais os custos de execução. Esta opção é provável através da utilização degateway BOBe definindo o endereço EVM do BOB DAO como o destinatário BTC.

Também estamos a experimentar mais ideias, por isso fique atento a mais atualizações!

Juntando tudo

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

1. Ler todas as transações de saque de Bitcoin. Estas são codificadas como duas transações para cada saque, ou seja, uma transação de commit e uma transação de revelação. Esta é a adição que estamos fazendo à Pilha OP e onde melhoramos o pipeline de derivação.
2. Leia todas as transações feitas para o contrato OptimismPortal de BOB no Ethereum. Isso já faz parte do pipeline de derivação da pilha OP padrão.
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 Ethereum. Isso já faz parte do pipeline de derivação padrão do OP Stack.

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ções 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 nó de operação (ou outras implementações de camada de consenso) que primeiro verifica se uma transação resulta em uma mudança 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 do Bitcoin e Ethereum como parte da ponte BitVM e do acerto do BOB no Ethereum.

Aumento de armazenamento: Além disso, os nós BOB na rede enfrentam requisitos crescentes de armazenamento e largura de banda, pois precisam processar e armazenar dados do Bitcoin e Ethereum. No entanto, isso pode ser mitigado exigindo que transações BOB feitas no Bitcoin sejam incluídas nos blobs do Ethereum com uma referência aos últimos blocos do Bitcoin. Dessa forma, os nós só precisam sincronizar os blocos recentes do Bitcoin.

Próximos Passos

Estamos entusiasmados por impulsionar 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 em transações combinada com a pilha de rollup do BOB. Atualizaremos esta publicação do blog com mais informações à medida que fizermos progressos.

Isenção de responsabilidade:

1. Este artigo é reproduzido a partir de [BOB]. Todos os direitos de autor pertencem ao autor original [Dominik Harz]. Se houver objeções a esta reimpressão, contacte o Gate Learnequipa, e eles vão tratar disso prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem um conselho de investimento.
3. A equipa do Learn Gate traduziu o artigo para outras línguas. É proibido copiar, distribuir ou plagiar os artigos traduzidos, a menos que seja mencionado.