Мабуть, Lightning Network - найбільш очікувана технологічна новинка для біткойнов. Передбачається, що ця платіжна система, ідея якої була прідложена рік тому, дозволить майже безкоштовно виконувати величезну кількість транзакцій поза блокчейна біткойнов, і для цього не доведеться жертвувати безпекою.
Щоб як слід зрозуміти концепцію, потрібно послідовно вивчити всі будівельні блоки, котори вона включає. Для початку давайте розберемося, які елементи задіяні в створенні двонаправленого платіжного каналу - першою важливою складовою Lightning Network.
Елемент 1: непідтверджені транзакції
У першому наближенні можна сказати, що Lightning Network заснована на звичайних біткойн-транзакціях, тільки ці транзакції не передаються в біткойн-мережу (по крайней мере, відразу). Замість цього вони зберігаються на локальних вузлах користувачів, але можуть бути відправлені в мережу в будь-який момент.
Чорним кольором позначено підтверджена транзакція. Синя транзакція може бути відправлена в мережу Алісою, але тільки в тому випадку, якщо підтверджена попередня транзакція. Червона транзакція може бути відправлена в мережу Бобом - з тим же умовою: якщо підтверджена попередня транзакція. В даному прикладі Аліса може в будь-який момент підписати і транслювати в мережу свою непідтверджену транзакцію, відправивши 2 біткойнов Бобу, і лише після цього Боб зможе підписати свою транзакцію, що відправляє 1 біткойн Керол.
Елемент 2: механізм захисту від подвійного витрати
В даному прикладі Аліса повинна вибрати транзакцію, яку вона хоче підписати і відправити в мережу. Отримати подтвежденія для обох транзакцій вона не може.
Елемент 3: мультіподпісь
Елемент 4: тимчасові блокування
Четвертий елемент Lightning Network - це тимчасові блокування. Вони дозволяють блокувати біткойни в виході, щоб їх можна було витратити (включити в наступний вхід) лише через якийсь час.
Тимчасові блокування бувають двох видів: абсолютні, або CheckLockTimeVerify (CLTV), і відносні, або CheckSequenceVerify (CSV). Блокування CLTV блокує біткойни до якогось (більш-менш) конкретного моменту в майбутньому: до фактичного часу або певного блоку. В CSV замість цього використовується відносний час. Як тільки вихід з CSV записаний в блокчейн, має бути створене певну кількість блоків, перш ніж ці біткойни можна буде витратити.
У Lightning Network блокування CSV (позначена на малюнку годинами) часто використовується як затримка.
Елемент 5: хеши і секрети
Криптографічні примітиви відносяться до фундаментальних блокам самого біткойнов, але в Lightning Network вони використовуються інакше.
Якщо коротко, то «значення» або «секрет» - це довга унікальна рядок чисел, яку практично неможливо вгадати навіть на дуже потужних комп'ютерах. Цей секрет можна «хешировать» - перетворити в інший рядок чисел, або «хеш». Хитрість в тому, що будь-який, хто знає значення, може з легкістю отримати його хеш, але зворотне неможливо: хешування - односпрямована операція.
Цей трюк можна використовувати в самому біткойнов - знову ж таки, для блокування біткойнов. Наприклад, можна включити хеш в вихід транзакції з вимогою, що будь-який, хто хоче витратити його, повинен вказати у вході відповідне хешу значення.
У цій статті секрет зображується як кольоровий ключ, а відповідний хеш - як замок такого ж кольору.
Перше завдання: двонаправлені платіжні канали
Ідея платіжних каналів обговорювалася ще до Lightning Network. Безумовно, звичайні платіжні канали корисні, але обмежені: вони Односпрямована. Ключова особливість Lightning Network - це двонаправлені платіжні канали «без довіри».
Щоб створити двонаправлений платіжний канал, сторони повинні спочатку узгодити відкриває транзакцію. Ця транзакція визначає обсяг депозитів, які повинна внести кожна сторона.
Припустимо, Аліса хоче відправити Бобу один біткойн. Аліса і Боб збираються платити один одному часто, тому вони вирішують відкрити двонаправлений платіжний канал (мабуть, цілий біткойн - це забагато для платіжного каналу, тому що він більше підходить для мікроплатежів, але в цьому немає нічого неможливого).
Крім того, Аліса і Боб створюють секрет (рядок чисел) і отримують її хеш.
Аліса підписує транзакцію-зобов'язання, але не транслює її в мережу! Замість цього вона відправляє її Бобу.
Боб підписує свою транзакцію-зобов'язання і відправляє її Алісі.
Після обміну зобов'язаннями і хешамі секретів Аліса і Боб підписують і відправляють в біткойн-мережу відкриває транзакцію, яка записується в блокчейн. Після цього канал можна вважати відкритим.
Проте насправді жодна зі сторін не підписує і не транслює в мережу свою транзакцію, і це найважливіше в платіжному каналі.
Трохи пізніше Боб хоче повернути Алісі 1 біткойн. Їм потрібно оновити стан каналу, і для цього вони роблять дві речі.
Далі Аліса і Боб передають один одному свої секрети з першого сценарію.
Після цього Аліса і Боб можуть підписати і відправити в мережу отримані транзакції-зобов'язання. Той, хто зробить це, зможе отримати свої 5 біткойнов через 1000 блоків, а друга сторона - негайно.
Але що заважає Бобу натомість відправити в мережу стару транзакцію-зобов'язання? Здавалося б, в цьому випадку він повинен отримати 6 біткойнов ...
Звичайно ж, зробити це заважає йому його перший секрет, який він тільки що передав Алісі. Боб не може використовувати стару транзакцію-зобов'язання, тому що Алісі відомий його перший секрет. Якби Боб підписав і відправив в мережу старе зобов'язання, він негайно відправив би 4 біткойнов Алісі, а сам зміг би отримати свої 6 біткойнов лише через 1000 блоків. Тим часом Аліса сама змогла б отримати ці 6 біткойнов, тому що їй відомий секрет Боба! Ну а оскільки Бобу відомий секрет Аліси, це працює і у зворотному напрямку: якщо Аліса спробує відправити у мережу своє старе зобов'язання, Боб зможе забрати все біткойни з даного каналу.
Це означає, що Аліса і Боб економічно зацікавлені в тому, щоб дотримуватися правил і транслювати в мережу тільки транзакції з актуальним станом каналу.
Тепер цю схему двонаправленого платіжного каналу потрібно розширити, щоб можна було здійснювати платежі через мережу.
Припустимо, що тепер Аліса хоче відправить 1 біткойн Керол. Для цього Аліса і Керол могли б створити платіжний канал між собою, але виявляється, що канал є між Бобом і Керол, так що Аліса може заплатити Керол через Боба: вона може відправити 1 біткойн Бобу, а Боб заплатить Керол.
Однак Аліса не довіряє Бобу і Керол - вона боїться, що, якщо вона відправить 1 біткойн Бобу, той ніколи не заплатить Керол або ж заплатить, але Керол заявить, що не отримувала ніяких грошей, і Аліса не знатиме, хто з них говорить правду .
Таким чином, Аліса готова заплатити Бобу 1 біткойн, тільки якщо буде впевнена, що він, в свою чергу, заплатить Керол 1 біткойн. Це можливо завдяки нехитрому криптографічного протоколу.
Коли Аліса хоче відправити 1 біткойн Керол, вона просить Керол створити значення (випадкову рядок чисел) і повідомити їй його хеш. Вона також просить Керол повідомити Боба, що він може отримати це значення за 1 біткойн. Далі Аліса каже Бобу, що відправить йому 1 біткойн, якщо він надасть їй значення, відповідне хешу, який вона отримала від Керол. Боб приймає пропозицію Керол і відправляє їй 1 біткойн, а за це отримує значення. Після цього Боб повідомляє значення Алісі. Аліса знає, що Боб купив це значення у Керол за 1 біткойн, і компенсує йому його витрати.
У цьому спрощеному сценарії посередник в особі Боба все ж повинен довіряти Алісі і Керол. Він повинен бути впевнений, що Керол дійсно повідомить йому потрібне значення в обмін на 1 біткойн, і він також повинен бути впевнений, що Аліса насправді відправить йому 1 біткойн, як тільки він повідомить їй потрібне значення.
Чесність такого обміну біткойнов на значення повинна бути гарантована у всій мережі. Точніше кажучи, якщо Боб відправляє 1 біткойн Керол, він повинен мати гарантію того, що отримає 1 біткойн від Аліси. Для цього використовуються контракти з хешированием і тимчасової блокуванням (HTLC).
Контракти з хешированием і тимчасової блокуванням
Це означає, що у Боба буде два тижні на те, щоб створити транзакцію з підписом і значенням, що відправляє заблокований біткойн йому. Це гарантує чесність угоди: Боб може зажадати біткойн Аліси, тільки вказавши в транзакції необхідне значення, яке стає відомо Алісі (і всієї біткойн-мережі). А якщо Боб не надасть потрібне значення вчасно, Аліса отримає свій біткойн назад. Все просто.
Але насправді контракти HTLC необхідні на рівні мережі.
Як вже було сказано, HTLC створюють не тільки Аліса з Бобом, а й Боб з Керол. Якщо Керол зажадає 1 біткойн у Боба, він отримає в обмін потрібне йому значення - воно буде записано в блокчейн. Ну а якщо ця операція буде здійснена, Боб гарантовано отримає 1 біткойн від Аліси: для цього йому досить додати оприлюднене Керол значення в HTLC, укладений з Алісою. Два каналу пов'язані.
Важливо відзначити, що Боб повинен отримати значення від Керол раніше, ніж Аліса отримає шанс зажадати свій біткойн назад, в іншому випадку він залишиться зі значенням, але без грошей. Таким чином, HTLC між Бобом і Керол повинен закінчуватися раніше. ніж HTLC між Алісою і Бобом (наприклад, через 10 днів і 2 тижні відповідно; з цієї ж причини в HTLC необхідно використовувати блокування CheckLockTimeVerify (CLTV), а не CheckSequenceVerify (CSV)).
Щоб Lightning Network була корисною, залишилося вирішити лише одне завдання: все це повинно виконуватися поза блокчейна.
Тепер Алісі, Бобу і Керол потрібно додати HTLC в канал, щоб Боб, що купив у Керол значення за 1 біткойн, напевно міг компенсувати свої витрати, отримавши біткойн від Аліси.
Все це нам вже відомо, а тепер зміна. Цього разу транзакції-зобов'язання Аліси і Боба включають новий вихід з одним біткойнов (інакше кажучи, баланси розподіляються відносно 4-5-1: 4 біткойнов для Аліси, 5 для Боба і 1 для нового виходу).
Цей новий вихід відповідає HTLC-контрактом, і розблокувати його можна трьома способами.
Перш за все, цей вихід (в зобов'язанні і Аліси, і Боба) розблокує біткойн, якщо подальша транзакція включає підпис і значення Боба. Таким чином, неавісімо від того, хто підпише і надішле в мережу транзакцію-зобов'язання, - Аліса або Боб - розблокувати цей вихід може тільки Боб, вказавши потрібне значення. Однак між двома зобов'язаннями є одне невелике розходження: якщо Боб вирішить закрити канал, буде задіяна CSV-блокування і йому доведеться почекати 1000 блоків. Якщо ж канал закриє Аліса, він отримає 1 біткойн негайно).
Причина, по якій Бобу доведеться почекати 1000 блоків, така ж, як і раніше: це дозволяє Алісі забрати 1 біткойн в тому випадку, якщо Боб спробує підписати і відправити в мережу старе стан каналу. Це призводить нас до другого способу розблокування нового виходу: Аліса може «вкрасти» гроші, якщо вкаже (найновіший) секрет Боба. Але якщо вона спробує смошенничать і відправить в мережу застаріле стан каналу, Боб зможе отримати 1 біткойн, скориставшись секретом Аліси (йому навіть не доведеться вказувати значення).
Нарешті, в будь-якому HTLC обидві транзакції-зобов'язання включають звичайну CLTV-блокування (яка в нашому випадку повертає гроші Алісі). Якщо Боб не надасть потрібне значення протягом обумовленого періоду (наприклад, через те, що він не отримав його від Керол), біткойн буде повернутий Алісі.
Що ж ми маємо на поточний момент?
У Аліси і Боба є по транзакції-зобов'язанням. Якщо Аліса відправить своє зобов'язання в блокчейн, вона негайно відправить 5 біткойнов Бобу. Вона також може почекати 1000 блоків і забрати 4 біткойнов. Крім того, у Боба є 2 тижні на те, щоб надати значення і забрати 1 біткойн з HTLC-виходу (якщо він не надасть значення за 2 тижні, Аліса зможе повернути цей біткойн собі).
Боб може в будь-який момент відправити своє зобов'язання в блокчейн і негайно відправити 4 біткойнов Алісі, а також він може почекати 1000 блоків і забрати 5 біткойнов (крім того, як було сказано трохи вище, він може забрати 1 біткойн з HTLC-виходу, надавши потрібну значення).
І, звичайно, якщо Аліса або Боб спробують схитрувати і відправити в мережу застаріле стан каналу, чесна сторона зможе отримати всі біткойни в каналі.
Отже, тепер Боб гарантовано зможе отримати біткойн в обмін на значення (якщо, звичайно, воно у нього є). Для цього йому потрібно лише підписати і відправити в мережу транзакцію-зобов'язання, яку він отримав від Аліси, включити значення в наступну транзакцію і теж відправити її в мережу.
Алісі це відомо, і вона ніяк не може вкрасти у Боба його біткойн - навіть якщо вона якимось чином дізнається значення.
Таким чином, Аліса і Боб можуть узгодити платіжний баланс поза каналу. Боб може просто передати значення Алісі, а Аліса оновить стан каналу без HTLC-контракту і тайм-ауту. Так вони і будуть робити, якщо вони зацікавлені в підтримці каналу, тому що це простіше, ніж фіксувати стан каналу в блокчейне.
Тепер вам повинна бути зрозуміла реальна міць мережі Lightning Network:
Майже все, що ми обговорили в цій статті, ніколи не потрапить в блокчейн.
Якщо Аліса і Боб захочуть мирно закрити канал за обопільною згодою, вони можуть просто створити транзакцію, переобумовленої все. що сталося після відкриває транзакції. Інакше кажучи, якщо в нашому прикладі Аліса хоче закрити канал, вона може створити транзакцію, яка виплачує 4 біткойнов їй і 6 Бобу, і попросити Боба підписати цю транзакцію. У Боба немає причин відмовляти Алісі, тому він майже напевно піде їй назустріч. Після підписання і відправки транзакції канал буде закритий.
Таким чином, в біткойн-мережу будуть трансльовані лише відкриває і закриває транзакції, навіть якщо між ними Аліса і Боб зробили мільйони платежів один одному! Наскільки це розвантажує блокчейн, уявіть самі.
Аарон ван Вірдум (Aaron van Wirdum)