By Bitcoin Jurnal - 6 oy oldin - O'qish vaqti: 5 daqiqa
To'lovni ajratish va almashtirish: maxfiylik va to'lov muvaffaqiyatini bir vaqtning o'zida yaxshilash
Lightning protokolining asosiy cheklovlaridan biri bu to'lov marshrutini qanday boshqarish va amalga oshirishdir. U to'liq manbaga yo'naltiriladi, ya'ni to'lovni jo'natuvchi to'lovni osonlashtirish uchun o'zidan qabul qiluvchigacha bo'lgan barcha yo'nalishni quruvchidir. Bu vaqt o'tishi bilan kanallar balansining o'zgarishi haqida gap ketganda muammo tug'diradi, chunki ular tarmoq bo'ylab ko'plab turli foydalanuvchilar o'rtasida to'lovlarni yo'naltirishda, jo'natuvchi "qulflangan" va ma'lum bir marshrutni tanlashga qaror qilgandan so'ng, bu yo'nalishni muvaffaqiyatsizlikka qadar o'zgartirib bo'lmaydi. xabar jo'natuvchiga qaytib, ularga dastlabki urinish muvaffaqiyatsizlikka uchragan nuqta bo'ylab butunlay yangi marshrutni qurishga imkon beradi.
Buning uchun og'ir va zerikarli UX bilan shug'ullanish yoki to'lov tekshiruvidan foydalanish kerak bo'ladi, siz foydalanmoqchi bo'lgan marshrut haqiqiy to'lov bilan qayta urinishdan oldin ishlay oladimi yoki yo'qligini bilish uchun ataylab muvaffaqiyatsiz bo'ladigan to'lovlarni qasddan ishlab chiqarish. Birinchisi shunchaki yomon foydalanuvchi tajribasi va keng miqyosdagi odamlar uchun to'lov echimi bo'lishi uchun biror narsani ishlab chiqishda siz xohlagan narsa emas, ikkinchisi esa butun tarmoqqa ortiqcha yuk yuklaydi, chunki marshrutlash tugunlari tarmoq bilan shug'ullanishi kerak. faqat marshrutning hayotiyligini tekshirish uchun yakunlash niyatisiz amalga oshirilgan doimiy to'lovlarning tirbandligi va likvidligi bilan bog'liq qiyinchiliklar.
Ushbu muammolarning yakuniy sababi - jo'natuvchining ishtirokisiz o'rta to'lovni o'zgartirish yo'lining imkoni yo'qligi. Butun to'lov yo'nalishi piyoz shifrlanganligi sababli, buni amalga oshirish mumkin emas. Har bir hop faqat o'zidan oldingi hop haqida va undan keyingi hop haqida ma'lumotga ega bo'lib, ular o'zlaridan qabul qiluvchiga muqobil marshrutni yaratishga imkon beradigan yakuniy manzil haqida hech qanday ma'lumotga ega emaslar.
Garchi bu manbaga asoslangan marshrutlashdan voz kechish uchun katta to'siq bo'lsa-da, bu unga to'liq to'sqinlik qilmaydi. Vositachi tugun sifatida siz o'zingizdan belgilangan manzilgacha bo'lgan yangi marshrutni to'liq qayta tiklay olmasangiz ham, to'lovni o'zingizdan jo'natuvchi tanlagan yo'lda belgilangan keyingi hopga o'zgartirishingiz mumkin. Shunday qilib, agar Bob Kerolga yo'naltirishi kerak bo'lgan to'lovni olsa va uni yo'naltirishi kerak bo'lgan kanal uni yo'naltirish imkoniyatiga ega bo'lmasa, u o'sha kanal orqali qo'lidan kelganini yuborishi va qolgan qismini yo'naltirishi mumkin. boshqa yo'llar orqali to'lov miqdori u o'zidan Kerolga topishi mumkin.
O'tgan oy Gijs van Dam yozgan CLN uchun kontseptsiya plaginining isboti (mavjud Bu yerga) aynan shunday qiladi, ustiga qurish ko'p yo'nalishli to'lovlar to'lovni taqsimlash va qabul qiluvchiga bir nechta yo'nalishlarni olish imkonini beradi. Agar Bob va Kerol ikkalasi ham plaginni ishlatayotgan bo‘lsa, tegishli holatlarda, Kerol nima qilayotganini ko‘rib, uni darhol tashlab qo‘ymasligi uchun bir kanal bo‘ylab yuborilayotgan to‘lov aslida qisman o‘zgartirilayotgani haqida bir-birlariga xabar berishlari mumkin. yuborilgani u kutganidan kamroq. Shunday qilib, agar jo'natuvchi tomonidan qaror qabul qilingan marshrut yaroqsiz bo'lsa, Bob va Kerol o'rtasida muqobil marshrutlar mavjud bo'lsa, ular shunchaki kerakli miqdorni yo'naltirishlari mumkin va to'lov to'liq muvaffaqiyatsizlikka uchramasdan, jo'natuvchiga qayta yo'naltirilishi va boshqa yo'nalishni o'zgartirmasdan muvaffaqiyatli bo'lishi mumkin. ular.
Agar tarmoqda standartlashtirilgan xatti-harakatlar sifatida keng qo'llanilsa, bu to'lovlarning muvaffaqiyat darajasiga katta ijobiy ta'sir ko'rsatishi mumkin, bu shunchaki ishlaydigan oddiy to'lov mexanizmini qidirayotgan Lightning foydalanuvchilarining UX-ni keskin yaxshilaydi. Bu juda oddiy va mantiqiy xatti-harakat bo'lib, taniqli kamchilikni sezilarli darajada yaxshilashi mumkin. Bu hammasi qila olmaydi.
Gijs van Dam ushbu muammoni hal qilishga qiziqib qolganining asosiy sabablaridan biri, aslida, foydalanuvchilar uchun to'lov muvaffaqiyati darajasi va UXni yaxshilash bilan hech qanday aloqasi yo'q, bu aslida maxfiylik kamchiligi edi. Lightning himoyasiz bo'lgan taniqli maxfiylik muammolaridan biri kanalni tekshirish, bu Gijsni tashvishga solgan muammo.
Yuqorida aytib o'tganimdek, u ba'zi hamyonlar tomonidan haqiqiy to'lovni amalga oshirishdan oldin to'lov muvaffaqiyatli bo'lishini ta'minlash uchun ishlatiladi, ammo bu usuldan pul mablag'larining kanalning har ikki tomonida taqsimlanishini aniqlash uchun ham foydalanish mumkin. Qayta-qayta va sinchkovlik bilan tanlangan summalar bilan amalga oshirilgan har bir tekshirish urinishining muvaffaqiyati va muvaffaqiyatsizligi mablag'lar kanalning har bir tomonida qanday taqsimlanganligini aniqlashi mumkin. Bundan ham ko'proq va muntazam ravishda ko'plab kanallar bo'ylab tizimli ravishda amalga oshirilgan bu usul, hatto kanallar bo'ylab balanslar o'zgarishini real vaqt rejimida ko'rish orqali to'lovlarni anonimlashtirishi mumkin.
Lightning doimiy ravishda tranzaktsion foydalanish uchun maxfiylik vositasi sifatida tuziladi, ammo haqiqatga ko'ra, maxfiylikni tekshirish kanali kabi usullar ko'p hollarda foydalanuvchi tarmoq bilan o'zaro aloqada bo'lmagan holda eng yaxshi holatda zaif bo'lishi mumkin. To'lovlarni bo'lish va almashtirishning qiziqarli yon ta'siridan biri shundaki, u tekshiruv hujumlarini buzadi. Tekshiruv hujumining ishlashining sababi shundaki, siz to'lov muvaffaqiyatsiz tugamaguncha turli miqdorlarda tekshirishni davom ettirishingiz mumkin. Agar to'g'ri bajarilgan bo'lsa, bu sizga oxirgi muvaffaqiyatli to'lov urinishi bilan kanal balansining taqsimlanishi bo'lgan muvaffaqiyatsiz urinish o'rtasida juda kichik diapazonni beradi.
Chaqmoq tugunlari boshqa bo'lishi mumkin bo'lmagan qismlar to'lovlarini tezda qayta yo'naltirishi mumkin bo'lgan dunyodawise muvaffaqiyatsiz bo'lsa, shuning uchun ular muvaffaqiyatga erishadilar, bu kanal balansini tekshirishga tayanadigan o'ziga xos taxminni butunlay buzadi. Toʻlovga urinish muvaffaqiyatsiz boʻladi, agar siz yoʻnaltirmoqchi boʻlgan aniq kanalda uni yoʻnaltirish uchun likvidlik boʻlmasa. To'lovni taqsimlash va almashtirish bilan bu taxmin endi to'g'ri emas va tarmoqdagi ko'proq tugunlar kommutatsiyani qo'llab-quvvatlasa, bu xato shunchalik ko'p bo'ladi (Gijs tomonidan haqiqiy dunyo Lightning tarmog'i ma'lumotlaridan foydalangan holda simulyatsiyaga ko'ra 62% gacha).
Shunday qilib, bu taklif nafaqat nisbatan sodda, balki to'lovga urinishlarning muvaffaqiyat darajasini oshirish yo'lini ta'minlabgina qolmay, balki Lightning tarmog'ining maxfiylikdagi eng katta kamchiliklaridan birini hal qilishga yordam beradi. Men, ayniqsa, so'nggi paytlarda o'ylayman Chaqmoqning zaifligi, bu taklif shuni ko'rsatadiki, Lightning muammolardan xoli bo'lmasa-da, ularni hal qilish yoki yumshatish mumkin emas. Hatto bitta muammoni hal qilish boshqa muammoga yordam berish uchun juda keng tarqalgan bo'ladi.
Rim bir kunda qurilgan emas, va haqiqatda saqlab qolgan echimlar Bitcoinning asosiy xususiyatlari kengaytiriladigan va barqaror tarzda ham bo'lmaydi.
Asl manba: Bitcoin jurnal