Um protocolo de pagamento dual offline de tokens BRC20 baseado em contratos de hash time lock (HTLC) melhorados e transações de Bitcoin com assinaturas parciais (PSBT)

Resumo

Este white paper propõe um protocolo técnico chamado Bitcoin-itip, destinado a realizar transferências de valor ponto a ponto de tokens BRC20 em um ambiente totalmente offline. Este protocolo combina contratos de hash time lock (HTLC) melhorados nativos do Bitcoin, uma estrutura de transação de Bitcoin com assinaturas parciais (PSBT) e um mecanismo de compromisso de estado baseado em indexadores BRC20, construindo uma camada de pagamento dual offline que é segura, verificável e finalmente liquidadas na mainnet do Bitcoin. A solução não depende de nenhum servidor centralizado ou sidechain, seguindo rigorosamente as suposições de segurança da rede Bitcoin e as especificações do protocolo BRC20, proporcionando uma solução inovadora para a circulação de ativos digitais em cenários sem rede, com rede fraca ou alta latência.

1. Introdução: Problemas e Objetivos

O padrão de token BRC20 utiliza o protocolo Ordinals do Bitcoin para gravar dados do token em satoshis, mas sua transferência depende completamente da transmissão da transação na blockchain do Bitcoin para atualizar o estado do indexador. Isso resulta na falha da funcionalidade de pagamento em cenários sem conexão à internet (como áreas remotas, pagamentos de emergência, ambientes com requisitos de segurança elevados). As soluções tradicionais de pagamento offline enfrentam dois desafios centrais: "ataque de double spend" e "atraso de sincronização de estado".

O objetivo do protocolo Bitcoin-itip é:

1. Realizar pagamentos totalmente offline: Permitir a transferência segura do compromisso de propriedade dos tokens BRC20 entre dois dispositivos offline.

2. Prevenir ataques de double spend: Garantir, através de criptografia e contratos on-chain, que qualquer transação offline tenha unicidade e determinismo quando finalmente registrada na blockchain.

3. Manter a compatibilidade com BRC20: Todas as operações offline eventualmente se transformam em transações on-chain que estão em conformidade com o padrão BRC20.

4. Minimizar suposições de confiança: Dependendo apenas da segurança da rede Bitcoin e do estado temporário dos dispositivos de ambas as partes.

2. Princípio central

O núcleo do protocolo é decompor um pagamento offline em três fases indissociáveis, cuja relação lógica e fluxo de dados são mostrados na figura abaixo:

```mermaid

flowchart TD

subgraph A [Fase Um: Preparação Online]

direction LR

A1["Criar e financiar<br\u003e carteira de múltiplas assinaturas"] --\u003e A2["Gerar e sincronizar<br\u003e recibo de saldo inicial (S0)"]

end

subgraph B [Fase Dois: Pagamento Offline]

direction LR

B1["Verificar recibo do recebedor (Rx)<br\u003e com estado atual (Sx)"] --\u003e B2["Construir e trocar colaborativamente<br\u003eP

SBT e a Preimage cifrada (Cx)"]

B2 --\u003e B3["Atualizar estado local para Sx+1"]

end

subgraph C [Fase Três: Liquidação Online]

C1["Transmitir o recibo de estado final (Sfinal) <br\u003e para a rede Bitcoin"] --\u003e C2["O indexador BRC20 <br\u003e analisa e atualiza o saldo"]

end

A -- "Inicialização do estado da carteira offline" --\u003e B

B -- "Liquidação do estado final na blockchain" --\u003e C

Fase Um (Preparação Online) é a base de todas as operações offline. Ambas as partes devem previamente estabelecer um endereço de Bitcoin controlado por múltiplas assinaturas 2-of-2 (P2WSH) e transferir os tokens BRC20 que serão utilizados offline para esse endereço. Este endereço está associado a um script HTLC aprimorado meticulosamente projetado, que não apenas gerencia o Bitcoin, mas também grava o estado de saldo offline dos tokens BRC20 (S0) através de gravações de dados específicas (Inscrição de Compromisso). A sincronização online nesta fase garante que ambas as partes alcancem um consenso sobre o estado inicial.

Fase Dois (Pagamento Offline) é o núcleo do protocolo. Quando ambos os dispositivos estão offline, o fluxo de pagamento é concluído através de quatro passos de interação criptográfica:

1. Verificação e início: O pagador verifica o recibo fornecido pelo recebedor (Rx), e o compara com o recibo de estado atual salvo localmente (Sx), confirmando a capacidade de pagamento.

2. Construção da transação: Ambas as partes, com base em Sx, colaboram para construir uma transação de Bitcoin "incompleta" utilizando a estrutura PSBT. Essa transação contém duas saídas: uma apontando para o endereço original de múltiplas assinaturas (mas com o valor reduzido, representando a transferência do token), e outra para troco. O ponto chave é que o UTXO correspondente ao gasto de Sx deve atender às condições do script HTLC.

3. Troca condicional: O pagador gera uma chave secreta aleatória (Preimage) e calcula seu hash (H). Ele insere H na transação e entrega a parte PSBT com o novo compromisso de estado (Sx+1) assinada parcialmente ao recebedor. Ao mesmo tempo, ele transmite offline o texto cifrado (Cx) (ou seja, a Preimage criptografada com a chave pública do recebedor) (por meio de NFC ou código QR).

4. Atualização de estado: O recebedor decripta Cx para obter a Preimage, completando assim a assinatura final da PSBT, resultando em uma transação totalmente assinada e válida. Ambas as partes atualizam localmente o estado para Sx+1. Até aqui, a propriedade offline do token BRC20 foi transferida, mas o estado na blockchain do Bitcoin não mudou.

Fase Três (Liquidação Online) Realiza a determinação final do valor. Quando qualquer um dos dispositivos se reconectar à rede, o recibo de estado final (Sfinal), correspondente à transação totalmente assinada gerada pela última transação offline, pode ser transmitido para a rede Bitcoin. Os mineradores verificarão se a transação atende às condições do script HTLC (ou seja, se forneceu a Preimage correta). Após a confirmação da transação, o indexador BRC20 analisará a transação e o compromisso do novo estado gravado, atualizando assim o saldo público de ambas as partes na blockchain, completando o ciclo de pagamento offline.

3. Componentes técnicos chave

3.1 Script de contrato de bloqueio de tempo de hash aprimorado (HTLC)

Este script é o núcleo da segurança dos fundos e da execução lógica. Um script de pagamento padrão é o seguinte:

OP_IF

OP_SHA256 <H> OP_EQUALVERIFY

<Chave Pública do Recebedor>

OP_ELSE

<Locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP

<Chave Pública do Pagador>

OP_ENDIF

OP_CHECKSIG

A inovação do Bitcoin-itip está em:

· Vínculo de estado: <H> não é apenas o hash da Preimage aleatória, mas também derivado do "hash do estado anterior (Sx) + detalhes da nova transação", garantindo que cada Preimage seja válida apenas para uma única transferência de estado específica.

· Saída dupla: O ramo OP_ELSE permite que o pagador recupere os fundos após o período de bloqueio (como 24 horas), prevenindo que o recebedor nunca transmita a transação online.

· Suporte de dados: A saída da transação contém uma saída especial OP_RETURN, gravando o compromisso hash do novo estado Sx+1, para reconhecimento pelo indexador BRC20.

3.2 Estrutura de transação de Bitcoin com assinaturas parciais (PSBT)

PSBT permite que a transação seja construída e assinada progressivamente entre várias partes, adaptando-se perfeitamente a múltiplas interações em cenários offline. No Bitcoin-itip, um pagamento offline PSBT contém:

· Entradas não assinadas (apontando para UTXOs contendo tokens BRC20).

· Saídas pendentes (nova alocação de tokens e troco).

· Informações necessárias sobre o script e o hash lock.

· Assinaturas adicionadas sequencialmente por ambas as partes.

3.3 Canal de transmissão offline

O protocolo não limita a camada física, podendo utilizar:

· Código QR: Exibição unidirecional ou bidirecional, codificando dados PSBT, Preimage criptografado ou assinatura.

· NFC: Para interações de proximidade, proporcionando uma experiência mais fluida.

· Bluetooth: Adequado para pagamentos contínuos múltiplos.

4. Passos operacionais detalhados

Passo 1: Inicialização da carteira e injeção de fundos (online)

1. As aplicações de carteira do pagador e do recebedor geram pares de chaves de pagamento offline BRC20 exclusivos.

2. Colaborar na criação de um endereço de múltiplas assinaturas P2WSH 2-of-2, e gerar o compromisso de estado inicial S0.

3. O pagador inicia uma transação padrão de transferência de BRC20, enviando uma certa quantidade de tokens para o endereço P2WSH. Após a confirmação on-chain desta transação, o pool de fundos offline é estabelecido.

Passo 2: Fluxo de pagamento offline (offline)

1. Negociação: Os dispositivos de ambas as partes estabelecem uma sessão por qualquer meio offline. O recebedor apresenta um recibo contendo sua chave pública e o número da transação atual.

2. Construção: A carteira do pagador verifica Rx, com base no estado atual Sx e no valor do pagamento, cria um novo rascunho de PSBT, calculando o novo hash de estado Sx+1.

3. Bloqueio: O pagador gera um número aleatório R, calcula H = SHA256(Sx || R || Amount), e insere H nas condições do script da PSBT. A Preimage é criptografada com a chave pública do recebedor, resultando no texto cifrado Cx.

4. Troca: O pagador realiza a primeira assinatura parcial da PSBT e envia a PSBT e Cx ao recebedor.

5. Desbloqueio: O recebedor decifra Cx para obter R, verificando H ?= SHA256(Sx || R || Amount). Após a validação, utiliza R para completar a segunda assinatura da PSBT. Neste ponto, a transação está completamente assinada, mas não foi transmitida.

6. Confirmação: O recebedor retorna uma cópia da transação assinada ao pagador. Ambas as partes armazenam essa transação com segurança localmente e atualizam seus registros de estado para Sx+1.

Passo 3: Liquidação final (online)

1. Quando um dispositivo (pagador ou recebedor) se conecta à rede, a carteira automaticamente ou manualmente transmite a transação totalmente assinada armazenada localmente, com o número de série mais alto (ou seja, a mais recente), para a rede Bitcoin.

2. Mineradores da rede processam essa transação. Como foi fornecido o R correto, a verificação do script é bem-sucedida, e a transação é empacotada em um bloco.

3. O indexador BRC20 escaneia o bloco, reconhecendo os dados OP_RETURN na transação (contendo Sfinal), e analisa as mudanças correspondentes na alocação de tokens, atualizando os saldos de ambas as partes no banco de dados de índice fora da cadeia.

5. Análise de segurança e risco

· Defesa contra ataques de double spend: Cada pagamento offline é vinculado exclusivamente a um UTXO on-chain e a uma sequência contínua de estados (S0, S1, S2…). Qualquer tentativa de transmitir duas transações com estados finais diferentes (Sfinal) será rejeitada pela rede Bitcoin devido ao gasto do mesmo UTXO após a primeira confirmação. O PSBT trocado offline é inválido até que a Preimage correta seja fornecida.

· Risco de negação de serviço: O recebedor, após obter a transação assinada, pode se recusar a transmiti-la online, o que pode resultar no bloqueio dos fundos do pagador. Através do ramo OP_ELSE do HTLC, o pagador pode unilateralmente recuperar os fundos após o período de bloqueio, garantindo a segurança básica.

· Considerações de privacidade: Os detalhes do pagamento offline são transmitidos apenas entre as partes, e só se tornam públicos na blockchain na transmissão da transação final, proporcionando uma camada adicional de privacidade.

· Segurança do dispositivo: O armazenamento seguro das chaves privadas é uma condição fundamental, recomendando-se o uso de elementos de segurança (SE) ou ambiente de execução confiável (TEE).

6. Limitações e trabalhos futuros

· Complexidade: O protocolo envolve múltiplas assinaturas, scripts complexos e interações offline, exigindo altos padrões dos desenvolvedores de carteiras e da experiência do usuário.

· Limite de capacidade: O espaço de bloco do Bitcoin é limitado, e o custo de liquidações frequentes de pequenos pagamentos offline é alto. No futuro, pode-se explorar a possibilidade de agrupar várias transações offline em uma única transação de liquidação on-chain (rede de canais).

· Dependência do indexador: A atualização final do saldo BRC20 depende do suporte do indexador para a análise do formato específico do Bitcoin-itip, necessitando de consenso comunitário.

· Custo inicial de configuração: Cada par de contrapartes deve estabelecer e financiar um endereço de múltiplas assinaturas específico, o que tem um custo inicial considerável.

7. Conclusão

O protocolo Bitcoin-itip demonstra sistematicamente pela primeira vez a viabilidade de pagamentos offline seguros duplos de tokens BRC20. Ao integrar de maneira inteligente a programabilidade dos scripts do Bitcoin, a flexibilidade interativa do PSBT e a continuidade do compromisso de estado, o protocolo constrói uma sólida camada de transmissão de valor offline sem introduzir suposições de confiança adicionais. Ele expande as fronteiras de aplicabilidade do Bitcoin e dos tokens BRC20, fornecendo um caminho técnico crucial para a construção de uma infraestrutura financeira mais resiliente e inclusiva. A implementação deste protocolo depende do impulso conjunto de provedores de carteira, provedores de serviço de indexação e da comunidade, e seu sucesso será um marco importante na inovação da camada de aplicação do Bitcoin.

Isenção de responsabilidade: O protocolo descrito neste white paper é uma proposta técnica que ainda não foi submetida a uma auditoria de segurança em larga escala ou testes práticos. Desenvolvedores e usuários devem estar plenamente cientes dos riscos ao implantar experimentalmente. O Bitcoin e o ecossistema BRC20 ainda estão em rápida evolução, e os detalhes da implementação podem precisar ser ajustados com as atualizações do protocolo.

#比特赏银itip #比特币生态 #Bitcoin谷歌搜索量暴升

Contato da comunidade central do protocolo BRC20 itip: itip2024@outlook.com

@币安广场 @Binance BiBi @CZ @Sun Research 孙宇晨研究 @Jiayi Li @迪大户 @唐华斑竹 @周周1688 @金先生聊MEME @欧吉巴克 @Yi He @Luna春婷 @Walrus 🦭/acc