Protokol pembayaran dual offline BRC20 berbasis kontrak kunci waktu hash (HTLC) yang ditingkatkan dan transaksi Bitcoin yang ditandatangani sebagian (PSBT)
Ringkasan
Dokumen ini mengajukan sebuah protokol teknis yang disebut Bitcoin-itip, yang bertujuan untuk merealisasikan transfer nilai peer-to-peer dari token BRC20 dalam lingkungan sepenuhnya offline. Protokol ini membangun lapisan pembayaran dual offline yang aman, dapat diverifikasi, dan akhirnya diselesaikan oleh jaringan utama Bitcoin, dengan menggabungkan kontrak kunci waktu hash yang ditingkatkan (HTLC) dari skrip asli Bitcoin, arsitektur transaksi Bitcoin yang ditandatangani sebagian (PSBT), dan mekanisme komitmen status berbasis pengindeks BRC20. Solusi ini tidak bergantung pada server terpusat atau sidechain mana pun, dan secara ketat mengikuti asumsi keamanan jaringan Bitcoin dan spesifikasi protokol BRC20, menyediakan solusi inovatif untuk peredaran aset digital dalam skenario tanpa jaringan, jaringan lemah, atau latensi tinggi.
1. Pendahuluan: Masalah dan Tujuan
Standar token BRC20 memanfaatkan protokol Ordinals Bitcoin untuk mengukir data token di satoshi, tetapi transfernya sepenuhnya bergantung pada siaran transaksi di blockchain Bitcoin untuk memperbarui status pengindeks. Ini mengakibatkan fungsionalitas pembayaran di skenario tanpa koneksi internet (seperti daerah terpencil, pembayaran darurat, lingkungan dengan persyaratan keamanan tinggi tertentu) menjadi tidak berfungsi. Solusi pembayaran offline tradisional menghadapi dua tantangan inti: "serangan pengeluaran ganda" dan "penundaan sinkronisasi status".
Tujuan protokol Bitcoin-itip adalah:
1. Mewujudkan pembayaran offline sepenuhnya: Memungkinkan dua perangkat offline untuk secara aman mentransfer komitmen kepemilikan token BRC20.
2. Mencegah serangan pengeluaran ganda: Memastikan keunikan dan kepastian dari setiap transaksi offline saat akhirnya diunggah ke blockchain melalui kriptografi dan kontrak di blockchain.
3. Memastikan kompatibilitas dengan BRC20: Semua operasi offline pada akhirnya dikonversi menjadi transaksi di blockchain yang memenuhi standar BRC20.
4. Meminimalkan asumsi kepercayaan: Hanya bergantung pada keamanan jaringan Bitcoin dan status sementara perangkat kedua belah pihak.
2. Prinsip inti
Inti dari protokol adalah membagi satu pembayaran offline menjadi tiga tahap yang tidak terpisahkan, dengan hubungan logis dan aliran data seperti yang ditunjukkan dalam gambar di bawah:
```mermaid
flowchart TD
subgraph A [Tahap Pertama: Persiapan Daring]
direction LR
A1[“Membuat dan mendanai<br> dompet multisig”] --> A2[“Menghasilkan dan menyinkronkan<br> bukti saldo awal (S0)”]
end
subgraph B [Tahap Kedua: Pembayaran Offline]
direction LR
B1[“Memverifikasi bukti penerima (Rx)<br> dengan status saat ini (Sx)”] --> B2[“Bersama-sama membangun dan bertukar<br>P
SBT dan ciphertext yang tidak terkunci (Cx)"
B2 --> B3[“Memperbarui status lokal menjadi Sx+1”]
end
subgraph C [Tahap Ketiga: Penyelesaian Daring]
C1[“Menyebarkan bukti status akhir (Sfinal)<br> ke jaringan Bitcoin”] --> C2[“Pengindeks BRC20<br> mengurai dan memperbarui saldo”]
end
A -- "Inisialisasi status dompet offline" --> B
B -- "Penyelesaian status akhir di blockchain" --> C
Tahap Pertama (Persiapan Daring) adalah dasar untuk semua operasi offline. Kedua belah pihak perlu membangun alamat Bitcoin yang dikendalikan oleh multisig 2-of-2 (P2WSH) sebelumnya, dan mengalihkan token BRC20 yang akan digunakan untuk sirkulasi offline ke alamat tersebut. Alamat ini terkait dengan skrip HTLC yang ditingkatkan yang dirancang dengan cermat, yang tidak hanya mengelola Bitcoin tetapi juga mencatat status saldo offline token BRC20 (S0) melalui pengukiran data tertentu (Komitmen Inskripsi). Sinkronisasi daring di tahap ini memastikan bahwa kedua belah pihak mencapai konsensus tentang status awal.
Tahap Kedua (Pembayaran Offline) adalah inti dari protokol. Ketika kedua perangkat pihak offline, proses pembayaran diselesaikan melalui empat langkah interaksi kriptografi:
1. Verifikasi dan inisiasi: Pihak pembayar memverifikasi bukti penerimaan yang diberikan oleh pihak penerima (Rx), dan mencocokkannya dengan bukti status saat ini yang disimpan secara lokal (Sx), untuk mengonfirmasi kemampuan pembayaran.
2. Pembangunan transaksi: Kedua belah pihak berdasarkan Sx, menggunakan kerangka PSBT untuk bersama-sama membangun transaksi Bitcoin yang "belum selesai". Transaksi ini mencakup dua output: satu menuju alamat multisig asli (tetapi jumlahnya berkurang, mewakili transfer token), yang lainnya untuk kembalian. Kuncinya adalah, UTXO yang dibelanjakan yang sesuai dengan Sx harus memenuhi kondisi skrip HTLC.
3. Pertukaran kondisi: Pihak pembayar menghasilkan kunci rahasia acak (Preimage) dan menghitung nilai hashnya (H). Dia menyematkan H ke dalam transaksi, dan menyerahkan bagian PSBT yang berisi komitmen status baru (Sx+1) setelah ditandatangani parsial kepada pihak penerima. Pada saat yang sama, dia mentransfer ciphertext (Cx) (yaitu, Preimage yang dienkripsi dengan kunci publik pihak penerima) secara offline (misalnya melalui NFC atau kode QR).
4. Pembaruan status: Pihak penerima mendekripsi Cx untuk mendapatkan Preimage, menyelesaikan tanda tangan akhir untuk PSBT, sehingga memperoleh transaksi yang ditandatangani penuh yang valid. Kedua belah pihak masing-masing memperbarui status mereka secara lokal menjadi Sx+1. Dengan ini, kepemilikan offline token BRC20 telah beralih, tetapi status di blockchain Bitcoin tetap tidak berubah.
Tahap Ketiga (Penyelesaian Daring) Untuk menentukan nilai secara akhir. Ketika salah satu pihak perangkat terhubung kembali ke jaringan, dapat menyebarkan transaksi yang ditandatangani penuh yang dihasilkan dari pembayaran offline terakhir yang terkait dengan bukti status akhir (Sfinal) ke jaringan Bitcoin. Penambang akan memverifikasi apakah transaksi memenuhi skrip HTLC (yaitu, apakah menyediakan Preimage yang benar). Setelah transaksi dikonfirmasi, pengindeks BRC20 akan mengurai transaksi dan komitmen status baru yang diukir di dalamnya, berdasarkan itu memperbarui saldo publik kedua belah pihak di blockchain, menyelesaikan seluruh siklus pembayaran offline.
3. Komponen teknologi kunci
3.1 Skrip kontrak kunci waktu hash yang ditingkatkan (HTLC)
Skrip ini adalah inti dari keamanan dana dan eksekusi logis. Skrip pembayaran standar adalah sebagai berikut:
OP_IF
OP_SHA256 <H> OP_EQUALVERIFY
<Kunci Publik Penerima>
OP_ELSE
<Waktu Kunci> OP_CHECKLOCKTIMEVERIFY OP_DROP
<Kunci Publik Pembayar>
OP_ENDIF
OP_CHECKSIG
Peningkatan Bitcoin-itip adalah:
· Ikatan status: <H> tidak hanya hash dari Preimage acak, tetapi juga diturunkan dari "hash status sebelumnya (Sx) + detail transaksi baru", sehingga setiap Preimage hanya berlaku untuk satu perpindahan status tertentu sekali.
· Ekspor ganda: Cabang OP_ELSE memungkinkan pihak pembayar untuk menarik kembali dana setelah periode penguncian (seperti 24 jam), mencegah pihak penerima untuk tidak pernah menyebarkan transaksi.
· Pembawa data: Output transaksi berisi output OP_RETURN khusus, yang mengukir komitmen hash untuk status baru Sx+1, yang dikenali oleh pengindeks BRC20.
3.2 Kerangka transaksi Bitcoin dengan tanda tangan parsial (PSBT)
PSBT memungkinkan transaksi dibangun dan ditandatangani secara bertahap di antara beberapa pihak, sangat cocok untuk interaksi multi-langkah dalam skenario offline. Dalam Bitcoin-itip, satu pembayaran offline PSBT mencakup:
· Input yang tidak ditandatangani (mengarah ke UTXO yang berisi token BRC20).
· Output yang belum ditentukan (distribusi token baru dan kembalian).
· Informasi skrip dan kunci hash yang diperlukan.
· Tanda tangan yang ditambahkan secara bergantian oleh kedua belah pihak.
3.3 Saluran pengiriman offline
Protokol tidak membatasi lapisan fisik, dapat memanfaatkan:
· Kode QR: Ditampilkan secara satu arah atau dua arah, mengkodekan data PSBT, Preimage terenkripsi, atau tanda tangan.
· NFC: Untuk interaksi dekat, memberikan pengalaman yang lebih lancar.
· Bluetooth: Cocok untuk pembayaran berturut-turut.
4. Rincian langkah-langkah operasi
Langkah 1: Inisialisasi dompet dan injeksi dana (daring)
1. Aplikasi dompet pihak pembayar dan pihak penerima menghasilkan pasangan kunci pembayaran offline BRC20 yang eksklusif.
2. Bersama-sama membuat alamat P2WSH multisig 2-of-2, dan menghasilkan komitmen status awal S0.
3. Pihak pembayar memulai transaksi transfer standar BRC20, mengirimkan sejumlah token ke alamat P2WSH tersebut. Setelah transaksi ini dikonfirmasi di blockchain, kolam dana offline terbentuk.
Langkah 2: Proses pembayaran offline tunggal (offline)
1. Negosiasi: Perangkat kedua belah pihak membangun sesi melalui cara offline apa pun. Pihak penerima menunjukkan bukti penerimaan yang mencakup kunci publik dan nomor urut transaksi saat ini Rx.
2. Pembangunan: Dompet pihak pembayar memverifikasi Rx, berdasarkan status saat ini Sx dan jumlah pembayaran, menciptakan draf PSBT baru, menghitung hash status baru Sx+1.
3. Penguncian: Pihak pembayar menghasilkan nomor acak R, menghitung H = SHA256(Sx || R || Amount), dan menetapkan H ke dalam kondisi skrip PSBT. Menggunakan kunci publik pihak penerima untuk mengenkripsi R menghasilkan ciphertext Cx.
4. Pertukaran: Pihak pembayar melakukan tanda tangan parsial pertama pada PSBT, mengirimkan PSBT dan Cx ke pihak penerima.
5. Penguncian: Pihak penerima mendekripsi Cx untuk mendapatkan R, memverifikasi H ?= SHA256(Sx || R || Amount). Setelah verifikasi berhasil, menggunakan R untuk menyelesaikan tanda tangan kedua pada PSBT. Pada saat ini, transaksi telah ditandatangani sepenuhnya, tetapi belum disiarkan.
6. Konfirmasi: Pihak penerima mengembalikan salinan transaksi yang telah ditandatangani kepada pihak pembayar. Kedua belah pihak menyimpan transaksi ini secara aman di lokal, dan memperbarui buku status mereka menjadi Sx+1.
Langkah 3: Penyelesaian akhir (daring)
1. Ketika perangkat (pihak pembayar atau pihak penerima) terhubung ke jaringan, dompet secara otomatis atau manual akan menyebarkan transaksi yang ditandatangani penuh dan disimpan secara lokal dengan nomor urut tertinggi (yaitu, yang terbaru) ke jaringan Bitcoin.
2. Penambang jaringan memproses transaksi ini. Karena R yang benar disediakan, verifikasi skrip berhasil, transaksi dikemas dalam blok.
3. Pengindeks BRC20 memindai blok tersebut, mengidentifikasi data OP_RETURN dalam transaksi (termasuk Sfinal), dan menganalisis perubahan distribusi token yang sesuai untuk memperbarui saldo kedua belah pihak dalam basis data pengindeks off-chain.
5. Analisis Keamanan dan Risiko
· Pertahanan terhadap serangan pengeluaran ganda: Setiap pembayaran offline secara unik terikat pada satu UTXO di blockchain dan urutan status yang berkelanjutan (S0, S1, S2…). Setiap upaya untuk menyiarkan transaksi dengan dua status akhir yang berbeda (Sfinal) akan ditolak oleh jaringan Bitcoin setelah konfirmasi pertama karena membelanjakan UTXO yang sama. PSBT yang dipertukarkan secara offline itu sendiri tidak valid, hingga Preimage yang benar disediakan.
· Risiko penolakan layanan: Pihak penerima menolak untuk menyebarkan transaksi yang sudah ditandatangani setelah mendapatkan, yang dapat menyebabkan dana pihak pembayar terkunci. Melalui cabang OP_ELSE dari HTLC, pihak pembayar dapat secara sepihak menarik kembali dana setelah periode penguncian, menjamin keamanan dasar.
· Pertimbangan privasi: Detail pembayaran offline hanya disampaikan di antara kedua belah pihak, dan hanya diungkapkan di blockchain saat transaksi akhir disiarkan, memberikan lapisan privasi tambahan.
· Keamanan perangkat: Penyimpanan aman kunci pribadi adalah prasyarat fundamental, disarankan untuk menggunakan elemen keamanan (SE) atau lingkungan eksekusi tepercaya (TEE).
6. Batasan dan Pekerjaan Masa Depan
· Kompleksitas: Protokol melibatkan multisig, skrip kompleks, dan interaksi offline, menempatkan tuntutan tinggi pada pengembang dompet dan pengalaman pengguna.
· Batas kapasitas: Ruang blok Bitcoin terbatas, biaya penyelesaian pembayaran kecil secara offline seringkali tinggi. Di masa depan, dapat dieksplorasi untuk menggabungkan beberapa transaksi offline menjadi satu transaksi penyelesaian di blockchain (jaringan saluran).
· Ketergantungan pengindeks: Pembaruan akhir saldo BRC20 bergantung pada dukungan pengindeks untuk analisis format khusus Bitcoin-itip, memerlukan konsensus komunitas.
· Biaya pengaturan awal: Setiap pasangan pihak perlu membangun dan mendanai alamat multisig khusus sebelumnya, dengan biaya awal tertentu.
7. Kesimpulan
Protokol Bitcoin-itip untuk pertama kalinya secara sistematis membuktikan kelayakan pembayaran offline aman untuk token BRC20. Dengan menggabungkan kecerdasan pemrograman skrip Bitcoin, fleksibilitas interaksi PSBT, dan kontinuitas komitmen status, protokol ini membangun lapisan transfer nilai offline yang kokoh tanpa memperkenalkan asumsi kepercayaan tambahan. Ini memperluas batasan penggunaan Bitcoin dan token BRC20, menyediakan jalur teknologi kunci untuk membangun infrastruktur keuangan yang lebih gesit dan inklusif. Implementasi protokol ini bergantung pada kolaborasi penyedia dompet, penyedia layanan pengindeks, dan komunitas, dan keberhasilan penerapannya akan menjadi tonggak penting dalam inovasi lapisan aplikasi Bitcoin.
Penafian: Protokol yang dijelaskan dalam makalah ini adalah usulan teknis, yang belum melalui audit keamanan berskala besar dan pengujian lapangan. Pengembang dan pengguna harus memiliki pemahaman penuh tentang risiko saat menerapkan secara eksperimental. Bitcoin dan ekosistem BRC20 masih dalam perkembangan cepat, detail implementasi spesifik mungkin perlu disesuaikan seiring dengan pembaruan protokol.
#比特赏银itip #比特币生态 #Bitcoin谷歌搜索量暴升
Kontak komunitas inti protokol BRC20 itip: itip2024@outlook.com
@币安广场 @Binance BiBi @CZ @Sun Research 孙宇晨研究 @Jiayi Li @迪大户 @唐华斑竹 @周周1688 @金先生聊MEME @欧吉巴克 @Yi He @Luna春婷 @Walrus 🦭/acc