MSTR Cat

Blockchain/Tahap V · Lapisan/5.1 Lightning/Pelajaran 3

Invois: BOLT11 dan BOLT12

Daripada rentetan sekali guna kepada tawaran boleh guna semula, serta pelayan web yang merapatkan jurang itu

BahanDompet Lightning yang mampu mendekod invoisAlat penyahkod BOLT11 awam yang boleh diakses melalui pelayar webContoh invois BOLT11 dan rentetan tawaran BOLT12

Ingin tahu

  1. Mengapakah permintaan pembayaran yang tamat tempoh dalam satu jam memaksa peniaga menjana semula invois secara berterusan?
  2. Bagaimanakah kod QR statik boleh kekal sah selama bertahun-tahun sambil masih menghasilkan invois yang unik dan selamat untuk setiap transaksi?
  3. Apakah medan data khusus yang membolehkan dompet mengesahkan bahawa invois tersebut tidak diubah suai sebelum dana dihantar?

Teroka

  1. Invois BOLT11 ialah rentetan bech32 yang bermula dengan 'lnbc' dan mengandungi semua parameter pembayaran yang diperlukan. Ia mengekodkan jumlah pilihan (dalam bitcoin, dengan huruf pengganda, sehingga pecahan satoshi), hash pembayaran khusus yang diterbitkan daripada preimej rahsia, dan cap masa tamat tempoh yang lalainya satu jam. Kunci awam nod penerima mengenal pasti destinasi, manakala petunjuk laluan pilihan membimbing pembayar sekiranya saluran langsung tidak tersedia. Seluruh rentetan tersebut ditandatangani oleh penerima, sekali gus memastikan integritinya.
  2. Arkitektur ini menjadikan invois BOLT11 hanya boleh digunakan sekali sahaja. Setelah penghantar membayar hash pembayaran yang berkaitan, invois tersebut dianggap selesai dan tidak boleh ditebus semula. Membayarnya dua kali adalah tidak selamat: selepas pembayaran pertama, preimej diketahui oleh setiap nod dalam laluan tersebut, jadi mana-mana nod itu yang turut berada dalam laluan pembayaran kedua boleh mengambilnya. Kekangan ini memerlukan kod QR dinamik dalam perniagaan runcit, di mana peniaga perlu menjana rentetan baharu untuk setiap pelanggan, sekali gus merumitkan perkakasan titik jualan.
  3. Pembangun komuniti menangani geseran ini melalui LNURL dan Lightning Address, yang bergantung pada pelayan web luaran. Pengguna mengimbas URI statik yang merujuk kepada titik hujung pelayan; dompet kemudian mendapatkan invois BOLT11 baharu daripada pelayan tersebut sebelum memulakan pembayaran. Cara ini memisahkan alamat awam daripada data transaksi tertentu, membolehkan satu pautan menerima pembayaran tanpa had sambil mengekalkan keselamatan invois unik sekali guna di belakang tabir.
  4. Tawaran ('offers') BOLT12, yang direka oleh Rusty Russell dan ditambahkan ke dalam spesifikasi pada tahun 2024, menjadikan aliran ini sebahagian daripada protokol. Kod pembayaran boleh guna semula ini bermula dengan 'lno' dan berfungsi sebagai pengecam statik untuk nod penerima. Apabila dikimbas, dompet pembayar menghantar mesej onion secara terus melalui Lightning Network untuk mendapatkan invois baharu daripada pencipta tawaran. Ini menghapuskan kebergantungan pada pelayan web luaran dan mengintegrasikan penjanaan permintaan ke dalam protokol teras.
  5. Tawaran BOLT12 menyokong ciri yang tiada dalam BOLT11, termasuk aliran di mana peniaga membayar pengguna, seperti bayaran balik atau pengeluaran (bayaran berulang pernah didrafkan tetapi dikeluarkan daripada spesifikasi yang digabungkan). Tawaran juga boleh menggunakan laluan terlindung (blinded paths) untuk menyembunyikan nod penerima dalam graf saluran, dan bukannya menerbitkan kunci awamnya. Reka bentuk ini mengurangkan kebocoran privasi berbanding invois standard yang mendedahkan petunjuk laluan atau alamat sandaran secara langsung.
  6. Pembayaran spontan memintas invois sepenuhnya dengan menggunakan protokol keysend atau AMP (Atomic Multi-Path), di mana penghantar menolak dana ke kunci nod yang diketahui tanpa permintaan terlebih dahulu. Untuk pengesahan secara praktikal, tampalkan sebarang invois Lightning ke dalam penyahkod BOLT11 awam. Kenal pasti prefiks yang boleh dibaca manusia, jumlah, hash pembayaran, masa tamat tempoh, dan tandatangan penerima. Bandingkan dengan rentetan 'lno', yang tidak mengandungi hash pembayaran, hanya apa yang diperlukan oleh pembayar untuk meminta invois: ID nod atau laluan terlindung kepadanya.

Fakta utama

  • Invois BOLT11 ialah rentetan bech32 yang digunakan sekali sahaja dan bermula dengan ‘lnbc’, yang mengandungi jumlah, hash, dan tandatangan.
  • LNURL dan Lightning Address menggunakan pelayan web untuk mendapatkan invois BOLT11 baharu daripada pautan statik.
  • Tawaran BOLT12 bermula dengan 'lno' dan menjana invois unik melalui mesej onion di Lightning Network.
  • Tawaran BOLT12 boleh digunakan semula dan menyokong pembayaran daripada peniaga ke pengguna seperti pemulangan wang, yang tidak disokong oleh BOLT11.
  • Masa tamat tempoh lalai untuk invois BOLT11 ialah satu jam (3600 saat).
  • Keysend membenarkan pembayaran spontan ke kunci awam nod tanpa invois.

Latihan sembilan, enam, tiga, satu

9KumpulSenaraikan 9 format atau pengecam permintaan pembayaran yang berbeza yang digunakan dalam kewangan digital, daripada kod pemindahan bank lama hingga standard kripto moden. Nyatakan sama ada setiap satu digunakan sekali sahaja atau boleh digunakan semula.
6KelompokkanKumpulkan 9 item tersebut ke dalam 6 kategori berdasarkan cara ia mengendalikan keunikan: statik-boleh guna semula, dinamik-sekali guna, perantaraan pelayan-ambil baharu, natif protokol-ambil baharu, berasaskan kunci-spontan, atau lain-lain.
3SaringKurangkan 6 kumpulan tersebut kepada 3 tukar ganti asas antara kemudahan pengguna (kod statik) dan keselamatan kriptografi (hash unik).
1KristalkanTulis 1 ayat yang menerangkan sebab tawaran BOLT12 menghapuskan keperluan pelayan web luaran dalam aliran pembayaran boleh guna semula.

Semakan fakta

Tarikh, angka dan dakwaan telah disemak berbanding dengan sumber yang diterbitkan yang disenaraikan di bawah.

Buka dalam akademi interaktif →

EN PT ES ZH JA KO RU DE FR