tl;dr
- Os L2s devem ter a mesma resistência à censura que os L1s em que se baseiam
- No BOB, os utilizadores já podem forçar o levantamento dos seus activos do BOB para o Ethereum através de uma transação Ethereum
- Para a sua ponte BitVM, a BOB está a trabalhar na integração da Bitcoin como forma de os utilizadores executarem transacções na BOB
- Os utilizadores de Bitcoin poderão levantar as suas BTC do BOB sem terem de enviar uma transação para o BOB
Uma das principais propriedades dos L2s é que o seu estado precisa de progredir mesmo quando o sequenciador está offline. Os L2s conseguem-no lendo e escrevendo o seu estado a partir de uma camada de Disponibilidade de Dados (DA) que pode ser actualizada independentemente de o L2 estar online. Desta forma, os utilizadores podem forçar a inclusão das suas transacções mesmo quando o sequenciador está offline, ou o sequenciador não aceita as suas transacções diretamente.
Para a ponte BitVM da BOB, isto coloca um problema interessante. Atualmente, a BOB utiliza blobs EIP-4844 da Ethereum como camada DA. Os utilizadores do Ethereum podem facilmente desencadear levantamentos de volta para o Bitcoin através da ponte BitVM. No entanto, é necessário que os utilizadores tenham ETH no Ethereum.
Isto não é suficiente para nós: Os utilizadores de Bitcoin só devem precisar de BTC em Bitcoin para forçar um levantamento das suas BTC de BOB para Bitcoin. Estamos a trabalhar numa solução híbrida: utilizar o Ethereum como DA por defeito e permitir que os utilizadores forcem a inclusão de transacções no BOB através de uma transação especial no Bitcoin. Estamos entusiasmados por partilhar o nosso trabalho em curso nesta publicação do blogue.
Antecedentes sobre DA e Derivação
O processo de derivação é bastante importante para os L2s: todo o estado L2 do BOB precisa de 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.
Simplificando, nos rollups (especificamente nas cadeias OP Stack), temos dois tipos de dados no L1:
- Transacções de depósito efectuadas para o contrato "OptimismPortal". Estas são as transacções efectuadas pelos utilizadores no Ethereum, normalmente para depositar os seus activos em BOB. Estas transacções de depósito podem também ser utilizadas para executar outras transacções em BOB.
- Lotes submetidos pelo sequenciador (ou op-batcher para ser mais preciso) a partir de transacções L2. Estas incluem todas as transacções efectuadas diretamente pelos utilizadores na BOB e são eventualmente incluídas nos blobs Ethereum.
Bitcoin como camada DA
Se queremos a Bitcoin como uma camada DA, por que não passar a usar a Bitcoin completamente como uma camada DA? A resposta é principalmente o custo. O Bitcoin tem muito pouco armazenamento disponível (cerca de 4MB aproximadamente a cada 10 minutos) e, portanto, o custo de armazenamento é alto.
No entanto, no nosso caso, o BOB pode continuar a utilizar o Ethereum como a sua camada DA "principal", onde coloca todos os seus dados de transação, mas adiciona o Bitcoin como uma camada de recurso altamente resistente à censura se o Ethereum DA não estiver disponível. Essencialmente, o Ethereum torna-se a camada DA otimista, enquanto o Bitcoin se torna o último recurso dispendioso mas tolerante a falhas.
Pipeline de derivação híbrida
A solução básica consiste em adicionar o Bitcoin à BOB como parte do pipeline de derivação, de modo a que a BOB (e especificamente o "op-node") processe as entradas por esta ordem:
- Transacções de levantamento forçado de Bitcoin (recentemente adicionadas especificamente para BOB)
- Depósitos Ethereum no contrato OptimismPortal da BOB (norma OP Stack)
- Lotes Ethereum do op-batcher (padrão OP Stack)
Vamos saltar para uma possível solução para codificar as transacções de levantamento forçado de Bitcoin no pipeline de derivação BOB. Note-se que isto ainda está a ser investigado, pelo que são possíveis alterações.
Transacções de levantamento forçado de Bitcoin
São necessárias três partes para criar uma transação de levantamento forçado:
- Construir a transação de levantamento forçado em Bitcoin.
- Armazenar a transação de levantamento forçado na Bitcoin dentro dos limites de tamanho da Bitcoin.
- Tratamento dos custos do gás para a transação de levantamento forçado na Bitcoin.
1. Construir a transação de levantamento forçado
Uma transação de depósito de pilha OP tem a seguinte estrutura:
- bytes32 sourceHash: o source-hash, que identifica de forma exclusiva a origem do depósito.
- endereço de: O endereço da conta do remetente.
- endereço para: O endereço da conta do destinatário, ou o endereço nulo (comprimento zero) se a transação depositada for uma criação de contrato.
- uint256 mint: O valor de ETH para cunhar em L2.
- valor uint256: 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.
- bytes data: Os dados da chamada.
Uma transação de levantamento forçado requer a inclusão da transação de levantamento codificada no campo de dados da transação de depósito. Isto é feito através da criação da transação na BOB que desencadeia a retirada da BOB para a Bitcoin e funcionaria exatamente da mesma forma que se a transação fosse enviada a partir da Ethereum.
Podemos então armazenar uma versão (comprimida) da transação de levantamento forçado na Bitcoin que inclui todos os dados acima referidos.
2. Armazenar a Transação de Retirada Forçada no Bitcoin
Como os dados da transação de levantamento forçado são maiores do que o que normalmente deve ser armazenado numa saída OP_RETURN, é provável que utilizemos uma saída Taproot para armazenar os dados.
Embora seja fácil identificar uma transação de depósito (que pode incluir um levantamento) no Ethereum devido ao facto de ser enviada para o contrato OptimismPortal do BOB, não é tão fácil identificar uma transação de levantamento forçado no Bitcoin.
Serialização de dados: A transação de levantamento forçado é serializada utilizando scripts Taproot dentro de uma estrutura "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 "transação"
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Esquema de autorização/receção em duas fases:
Tal como acontece com os Ordinals, os utilizadores terão de submeter duas transacções à Bitcoin:
- Transação de Compromisso: Cria uma saída Taproot com o script que contém o conteúdo da inscrição. Esta transação ainda não revela os dados e será necessária a segunda transação para que os nós completos e sequenciadores BOB incluam a transação de retirada.
- Reveal Transaction (Revelar transação): Gasta a saída da transação de confirmação, revelando a inscrição na cadeia, ou seja, revelando a transação de levantamento do utilizador para inclusão no BOB.
3. Tratar os custos do gás para a transação de retirada forçada
Este é o problema mais em aberto até à data, estando atualmente a ser consideradas duas opções:
- Defina o gás como 0 para a transação de retirada forçada no Bitcoin e deduza os custos de gás do saldo ETH do usuário no BOB. Desta forma, apenas os utilizadores que têm ETH no BOB podem forçar levantamentos. No entanto, esta não é uma boa opção, pois exigiria que os utilizadores tivessem ETH no BOB para forçar levantamentos, ou seja, os utilizadores que têm BTC no Bitcoin não podem forçar levantamentos.
- O gás é pago pelos utilizadores em BTC na Bitcoin. A rede BOB teria de ter um endereço na Bitcoin que pudesse receber BTC e trocaria efetivamente as BTC recebidas pelo utilizador por ETH na BOB para pagar a parte L1 dos custos do gás mais os custos de execução. Esta opção pode ser efectuada utilizando o BOB Gateway e definindo o endereço EVM do BOB DAO como destinatário das BTC.
Estamos também a experimentar mais ideias, por isso, fique atento a mais actualizações!
Juntar tudo
Qualquer pessoa pode determinar o estado da BOB, bastando para tal verificar os dados relativos à Bitcoin e à Ethereum:
- Ler todas as transacções de levantamento da Bitcoin. Estas são codificadas como duas transacções para cada levantamento, ou seja, uma transação de confirmação e uma transação de revelação. Esta é a adição que estamos a fazer ao OP Stack e onde melhoramos o pipeline de derivação.
- Ler todas as transacções efectuadas no contrato OptimismPortal da BOB no Ethereum. Isso já faz parte do pipeline padrão de derivação do OP Stack.
- Ler todas as transacções efectuadas diretamente na BOB e integradas como parte de lotes no Ethereum. É importante notar que os nós completos não lêem diretamente do sequenciador para receber transacções confirmadas, mas lêem dos blobs Ethereum. Isto já faz parte do pipeline padrão de derivação da pilha OP.
Desafios técnicos
Consistência de dados: Embora seja importante garantir a consistência dos 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 transacçõ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 da camada de consenso) que primeiro verifica se uma transação resulta numa mudança de estado válida antes de a aceitar.
Provas de fraude e validade: O sistema de prova de fraude para BitVM e Ethereum precisa de ser melhorado para lidar com dados de ambas as cadeias, o que pode tornar a resolução de litígios mais complexa. Para resolver este problema, temos de contabilizar com precisão as possíveis transacções da Bitcoin e da Ethereum como parte da ponte BitVM e da liquidação da BOB na Ethereum.
Aumento do armazenamento: Além disso, os nós BOB na rede enfrentam requisitos acrescidos de armazenamento e largura de banda, uma vez que têm de processar e armazenar dados da Bitcoin e da Ethereum. No entanto, poderíamos atenuar esta situação exigindo que as transacções BOB efectuadas em Bitcoin fossem incluídas em blobs Ethereum com uma referência aos blocos Bitcoin mais recentes. Desta forma, os nós só precisam de sincronizar blocos Bitcoin recentes.
Próximos passos
Estamos entusiasmados por alargar a fronteira dos rollups híbridos que combinam a segurança da Bitcoin com a inovação da Ethereum. Neste problema concreto, estamos interessados em ter a resistência da Bitcoin à censura das transacções combinada com a pilha de rollups da BOB. Actualizaremos esta publicação do blogue com mais informações à medida que fizermos progressos.
