Apakah itu BOLT 12? Nah, ini adalah banyak ciri yang berbeza dan bahagian bergerak yang digabungkan untuk mencapai pelbagai perkara yang berbeza — kod QR statik, invois modular, privasi untuk orang yang menerima pembayaran.
Tetapi apakah keseluruhan pakej itu? Ini adalah satu cara untuk mempunyai satu kod QR,”tawaran”, membolehkan anda mengambil invois daripada nod dengan cara memelihara privasi, sambil turut membenarkan perkara seperti meminta nod jauh membayar invois anda.
Sekarang, sesiapa yang biasa dengan LNURL harus sudah berfikir,”Ini kedengaran seperti LNURL.”Tetapi bagi anda yang tidak tahu apa itu LNURL atau cara ia berfungsi, berikut adalah pecahan pantas.
Apakah itu LNURL?
LNURL ialah timbunan protokol mudah untuk menyelaraskan maklumat yang diperlukan untuk membuat pembayaran melalui Rangkaian Lightning menggunakan HTTP. Senarai penuh bahagian protokol LNURL boleh didapati di sini, tetapi saya hanya akan pergi ke beberapa kegunaan teras yang bertindih dengan BOLT 12.
Tiga bahagian teras protokol LNURL ialah skim pengesahan, di mana kunci awam boleh digunakan untuk log masuk ke perkhidmatan, skim permintaan invois di mana dompet boleh ping pelayan melalui kod QR statik dan mendapatkan semula invois, dan skim permintaan pengeluaran di mana dompet boleh ping pelayan dan meminta pelayan membayar invois yang disediakan oleh dompet. Invois kilat adalah lebih panjang daripada alamat Bitcoin dalam rantaian, pembayaran itu sendiri sudah menjadi proses interaktif yang memerlukan kedua-dua pihak berada dalam talian, jadi menyelaraskan butiran pembayaran secara interaktif melalui sambungan rangkaian adalah masuk akal.
Protokol pengesahan secara efektif hanyalah pelayan yang menyediakan nombor yang dijana secara rawak yang ditandatangani oleh dompet pengguna dengan kunci yang baru dijana. Selepas nilai rawak yang ditandatangani diterima oleh pelayan, ia menyimpan kunci yang berkaitan untuk digunakan dalam log masuk masa hadapan.
Fungsi permintaan invois ialah cara untuk memberikan maklumat kepada pengguna tentang pembayaran yang mereka ingin buat dalam format yang bukan invois. Ini memberikan penerangan tentang pembayaran, jumlah minimum dan maksimum yang dijangka dibayar oleh perkhidmatan, dan URL untuk dompet untuk meminta invois sebenar. Dari sini, dompet memaparkan maklumat ini kepada pengguna, membolehkan mereka menetapkan jumlah akhir dan meminta invois. Selepas menghantar permintaan invois dan menerima satu semula daripada pelayan, dompet mengesahkan bahawa jumlah itu sepadan dengan apa yang ditetapkan pengguna dan membayar invois.
Permintaan pengeluaran berfungsi dengan ping perkhidmatan, dan menerima sebagai balasan perihalan, URL untuk menghantar invois, rentetan rawak (atau deterministik untuk terikat pada akaun atau pengguna) dan jumlah minimum dan jumlah maksimum yang boleh dikeluarkan. Selepas mengisi nilai yang sesuai, dompet mengembalikan invois kepada pelayan, dan jika ia sah dan dalam parameter amaun, perkhidmatan membayar invois. Protokol pengesahan LNURL boleh digunakan sebagai tambahan kepada ini untuk memastikan bahawa hanya pengguna yang dimaksudkan boleh berjaya menarik diri menggunakan pautan LNURL.
LNURL telah melancarkan dan menambah baik kebanyakan pengalaman UX semasa menggunakan Rangkaian Lightning, tetapi ia memerlukan penggunaan pelayan web untuk digunakan. Semua permintaan dan respons dikendalikan melalui HTTP, dan infrastruktur tambahan di luar nod Lightning itu sendiri diperlukan untuk mengendalikan cara menyelaras dan membuat pembayaran yang diperkemas ini. Ini adalah keperluan yang sangat munasabah untuk mana-mana pembekal perkhidmatan dalam talian atau pedagang, yang secara realistik akan memerlukan pelayan web juga untuk menyediakan perkhidmatan atau produk mereka dalam talian. Walau bagaimanapun, bagi pengguna akhir bukan teknikal di rumah yang hanya mahukan pengalaman yang diperkemas seperti itu, penjual jalanan, kedai fizikal atau pengguna lain yang belum memerlukan penggunaan pelayan web, ini boleh menjadi keperluan yang membebankan dan berpotensi berisiko.
Apakah BOLT 12?
BOLT 12 menawarkan percubaan untuk mencapai beberapa fungsi teras yang LNURL sediakan tanpa memerlukan penggunaan pelayan web. Tawaran mengekod data yang diperlukan untuk mencapai nod untuk meminta invois untuk membuat pembayaran, sama ada node_id atau laluan buta (beberapa lompatan terakhir dalam laluan bawang, diprakira dan disulitkan) ke nod itu menggunakan mesej bawang. Ia juga boleh mengekodkan jumlah minimum untuk pembayaran, mata wang yang dibayar, masa tamat tempoh dan nombor kuantiti minimum/maksimum (untuk membeli berbilang item).
Ini adalah semua maklumat yang diperlukan untuk mengambil invois sebenar daripada nod yang mengeluarkan tawaran. Seseorang yang ingin membayar invois berbuat demikian melalui mesej onion, salah satu ciri teras BOLT 12. Ia membenarkan nod membuat sambungan terus disulitkan hujung ke hujung antara satu sama lain yang tidak melibatkan saluran Lightning. Sama seperti pembayaran Lightning, ini boleh digunakan untuk mesej laluan bawang. Selepas mendapat tawaran, pembayar akan menggunakan maklumat yang dikodkan di dalamnya untuk menghantar mesej invoice_request. Pencipta tawaran kemudiannya akan membalas semula dengan invois sebenar.
Terdapat juga sokongan untuk menjana tawaran unik bagi setiap pengguna yang membolehkan penerima meminta bayaran daripada pencipta tawaran, serupa dengan ciri permintaan pengeluaran LNURL. Invois BOLT 12 terikat kepada kunci pembayar yang unik — ini boleh digunakan dalam kes mengeluarkan bayaran balik untuk membuktikan anda adalah orang yang benar-benar membayar invois tersebut. Ini juga boleh digunakan dalam kombinasi dengan tawaran pengeluaran untuk menjamin bahawa hanya orang yang betul boleh berjaya mendapatkan invois yang dibayar oleh pencipta, berbanding sesiapa yang boleh mendapatkan salinan tawaran.
Kedua-dua penggunaan tawaran ini dengan berkesan memenuhi fungsi yang sama seperti permintaan invois dan pengeluaran LNURL, tanpa perlu menjalankan pelayan web.
LNURL Atau BOLT 12? Ini Semua Mengenai Tukar Ganti
LNURL dan BOLT 12 kedua-duanya mencapai kefungsian umum yang sama, jadi apakah sebenarnya perbezaan antara keduanya? Apakah keperluan untuk BOLT 12 jika LNURL sudah wujud? Perbezaan utama ialah pelayan web. Pelayan web memerlukan lebih banyak infrastruktur, nama domain, sijil TLS dan kepakaran untuk mengurus perkara ini.
Walaupun ini bukan isu yang patut disebut untuk kebanyakan perniagaan dan perkhidmatan, kerana perkara ini diperlukan untuk mengendalikan sebarang perniagaan dalam talian pada mulanya, ini merupakan isu besar untuk pengguna akhir bukan teknikal biasa anda. Ia bukanlah jangkaan yang munasabah bagi pengguna untuk mengekalkan infrastruktur tambahan yang dipasang di atas nod Lightning mereka untuk mendapat akses kepada pengalaman pengguna yang diperkemas dan mudah. Terdapat juga persoalan mengenai pemusatan DNS; domain bukanlah sesuatu yang benar-benar boleh dikawal oleh pemiliknya.
Isu-isu ini diketepikan, kedua-duanya boleh wujud bersama. LNURL berfungsi dengan baik, dan sudah diterima pakai secara meluas dalam ekosistem Lightning, ia bukanlah penyelesaian yang realistik untuk pengguna selain daripada perniagaan atau perkhidmatan. BOLT 12 kerana ia diterima pakai boleh mengisi jurang itu, dan memberikan pengalaman pengguna diperkemas yang sama untuk pengguna akhir di rumah yang bukan perniagaan.
Kedua-dua penyelesaian mencapai perkara yang hampir sama untuk dua kelas pengguna yang berbeza, dan itu OK.
Ini adalah siaran tetamu oleh Shinobi. Pendapat yang dinyatakan adalah milik mereka sepenuhnya dan tidak semestinya mencerminkan pendapat BTC Inc atau Majalah Bitcoin.