Zdá se, že BOLT 12 a LNURL umožňují uživatelům sítě Bitcoin Lightning Network totéž. Jaké jsou však technické rozdíly?
Co je BOLT 12? Inu, je to spousta různých funkcí a pohyblivých prvků poskládaných dohromady, aby se dosáhlo několika různých věcí – statické QR kódy, modulární faktury, soukromí pro osobu přijímající platbu.
Ale co je to vlastně celý balíček? Je to způsob, jak pomocí jediného QR kódu, „nabídky“, získat faktury z uzlu způsobem, který zachovává soukromí, a zároveň umožňuje takové věci, jako je požadavek, aby vzdálený uzel zaplatil vaši fakturu.
Každý, kdo zná LNURL, by si teď měl říct: „Tohle zní hodně podobně jako LNURL.“ Tohle je velmi podobný příklad Ale pro ty z vás, kteří nevědí, co to LNURL je a jak funguje, je zde stručné vysvětlení.
Co je LNURL?
LNURL je zásobník jednoduchých protokolů pro koordinaci informací potřebných k provádění plateb prostřednictvím sítě Lightning Network s využitím protokolu HTTP. Úplný seznam částí protokolu LNURL najdete zde, ale já se budu věnovat jen několika základním způsobům použití, které se překrývají s protokolem BOLT 12.
Třemi základními prvky protokolu LNURL jsou schéma ověřování, kdy lze k přihlášení ke službě použít veřejný klíč, schéma žádosti o fakturu, kdy peněženka může pingnout server prostřednictvím statického QR kódu a získat fakturu, a schéma žádosti o výběr, kdy peněženka může pingnout server a požádat, aby server zaplatil fakturu poskytnutou peněženkou. Faktury Lightning jsou mnohem delší než adresy v řetězci Bitcoin, samotná platba je již interaktivní proces vyžadující, aby obě strany byly online, takže interaktivní koordinace platebních údajů prostřednictvím síťového připojení dává smysl.
Autentizační protokol je vlastně jen to, že server poskytne náhodně vygenerované číslo, které peněženka uživatele podepíše nově vygenerovaným klíčem. Poté, co server obdrží podepsanou náhodnou hodnotu, uloží související klíč, který bude použit při budoucích přihlášeních.
Funkce žádosti o fakturu je způsob, jak poskytnout uživateli informace o platbě, kterou chce provést, ve formátu, který není fakturou. Poskytuje popis platby, minimální a maximální částku, kterou služba očekává, že bude zaplacena, a adresu URL peněženky, ze které lze vyžádat skutečnou fakturu. Odtud peněženka tyto informace zobrazí uživateli a umožní mu nastavit konečnou částku a vyžádat si fakturu. Po odeslání požadavku na fakturu a přijetí požadavku zpět ze serveru peněženka ověří, zda částky odpovídají tomu, co uživatel nastavil, a fakturu zaplatí.
Žádost o výběr funguje tak, že se na službu odešle ping a v odpovědi se obdrží popis, adresa URL, na kterou se má faktura odeslat, náhodný řetězec (nebo deterministický, aby se dal spojit s účtem nebo uživatelem) a minimální a maximální částka, kterou lze vybrat. Po vyplnění příslušné hodnoty peněženka vrátí serveru fakturu, a pokud je platná a v rámci parametrů částky, služba fakturu proplatí. Kromě toho lze použít protokol LNURL authenticate, který zajistí, že pomocí odkazu LNURL může úspěšně vybírat pouze zamýšlený uživatel.
LNURL vyhladil a vylepšil velkou část uživatelského rozhraní v souvislosti s používáním sítě Lightning Network, ale k jeho využití je nutné použít webový server. Všechny požadavky a odpovědi jsou zpracovávány prostřednictvím protokolu HTTP a k obsluze těchto zjednodušených způsobů koordinace a provádění plateb je zapotřebí další infrastruktura mimo samotný uzel Lightning. To je naprosto rozumný požadavek pro každého poskytovatele online služeb nebo obchodníka, který bude reálně stejně potřebovat webový server, aby mohl poskytovat své služby nebo produkty online. Pro netechnického koncového uživatele v domácnosti, který prostě chce takovou zjednodušenou zkušenost, pouličního prodejce, fyzický obchod nebo jiné uživatele, kteří již nevyžadují použití webového serveru, to však může být zatěžující a potenciálně rizikový požadavek.
Co je BOLT 12?
BOLT 12 nabízí pokus o dosažení některých základních funkcí, které poskytuje LNURL, aniž by vyžadoval použití webového serveru. Nabídka zakóduje údaje potřebné k dosažení uzlu pro vyžádání faktury za účelem provedení platby, a to buď node_id, nebo zaslepenou cestu (několik posledních skoků v cibulové trase, předem vypočtených a zašifrovaných) k tomuto uzlu pomocí cibulových zpráv. Může také zakódovat minimální částku pro platbu, měnu, ve které se platí, dobu platnosti a čísla minimálního/maximálního množství (pro nákup více položek).
Jedná se o všechny informace potřebné k získání skutečné faktury od uzlu, který nabídku vystavil. Někdo, kdo chce zaplatit fakturu, tak učiní prostřednictvím cibulových zpráv, což je jedna ze základních funkcí systému BOLT 12. Umožňuje uzlům navázat mezi sebou přímé, end-to-end šifrované spojení, které nezahrnuje kanál Lightning. Stejně jako platby Lightning je lze použít k směrování zpráv onion. Po získání nabídky použije plátce informace v ní zakódované k odeslání zprávy invoice_request. Tvůrce nabídky pak odpoví zpět skutečnou fakturou.
K dispozici je také podpora pro generování unikátních nabídek na uživatele, které umožňují příjemci požádat tvůrce nabídky o platbu, podobně jako funkce LNURL pro žádost o výběr. Faktury BOLT 12 se vážou k jedinečnému klíči plátce – ten lze použít v případě vystavování vratek k prokázání, že jste osobou, která fakturu skutečně zaplatila. Lze jej také použít v kombinaci s nabídkou na odstoupení od smlouvy, aby bylo zaručeno, že pouze správná osoba může uspět v získání faktury zaplacené tvůrcem, na rozdíl od toho, kdo je schopen získat kopii nabídky.
Tato dvě použití nabídek efektivně plní stejnou funkci jako požadavky na fakturu a odstoupení od smlouvy LNURL, aniž by bylo nutné provozovat webový server.
LNURL nebo BOLT 12? Vše je o kompromisech
LNURL i BOLT 12 plní stejnou obecnou funkci, jaký je tedy mezi nimi vlastně rozdíl? K čemu je potřeba BOLT 12, když už existuje LNURL? Klíčovým rozdílem je webový server. Webový server vyžaduje provozování další infrastruktury, doménové jméno, certifikát TLS a odborné znalosti pro správu těchto věcí.
Zatímco pro většinu podniků a služeb to nestojí ani za zmínku, protože tyto věci jsou pro provozování jakéhokoli internetového obchodu vůbec potřeba, pro typického netechnického koncového uživatele je to velký problém. Není rozumné očekávat, že uživatel bude udržovat další infrastrukturu přišroubovanou na svém uzlu Lightning, aby měl přístup k zjednodušenému a jednoduchému uživatelskému prostředí. Je zde také otázka centralizace DNS; doména není něco, co by mohl její vlastník někdy skutečně ovládat.
Odhlédneme-li od těchto otázek, mohou obě existovat současně. LNURL funguje dobře a v ekosystému Lightning je již velmi rozšířen, jen není reálným řešením pro jiné uživatele než podniky nebo služby. BOLT 12, jak je přijímán, může tuto mezeru zaplnit a poskytnout stejné zjednodušené uživatelské prostředí pro koncové uživatele v domácnostech, kteří nejsou podniky.
Obě řešení dosahují zhruba stejné věci pro dvě různé třídy uživatelů, a to je v pořádku
Toto je hostující příspěvek od Shinobiho. Vyjádřené názory jsou výhradně jeho vlastní a nemusí nutně odrážet názory společnosti BTC Inc nebo Bitcoin Magazine.
