On Lightning Network – демонстрация в солидност

Пост за гости на HodlX  Изпратете вашата публикация

Lightning Network се появи за първи път в белия документ, предложен от Джоузеф Пуон и Тадеус Драйя през 2015 г. Той генерира огромни отговори и дискусии сред общността на биткойните и е широко разглеждан като втората по важност бяла книга за биткойните след новаторската работа на Сатоши Накамото.

Тъй като Мълниеносна мрежа разчита на протокола в Segregated Witness (SegWit), тя до голяма степен остава концепция и се развива само вътрешно. Още от разклона на Bitcoin SegWit през 2017 г., развитието на Lightning Network непрекъснато върви напред по правилния път.

През март 2018 г. Lightning Labs разработи и пусна първоначалната тестова версия. По-късно ACINQ и Blockstream последваха примера и стартираха редица внедрения в мрежата. Според данните от 1ml, в момента в Lightning Network има общо 8 204 възли и 37 901 платежни канала, с 1021,37 BTC (приблизително 5,34 милиона щатски долара) в платежните канали, което доказва, че Lightning Network е постигнал значителен ръст през последната година.

Lightning Network има за цел да се справи с мащабируемостта на Bitcoin. Както всички знаем, първоначално биткойнът е създаден като електронна система за пари в брой, за да осигури децентрализирана и денонощна мрежа за електронни плащания, но проблемът с мащабирането на биткойн далеч не е задоволителен.

Ако изчислим въз основа на средно 300 възела на сделка, Bitcoin е способен да обработва само 5,6 транзакции в секунда, докато Visa може да обработва 47 000 tps при своя пиков капацитет. За да достигне този капацитет, биткойн ще трябва да разшири размера на блока си до около 8 GB, като всяка година се добавят 400 TB нови данни за блока, което очевидно е нереалистично.

Lightning Network е само едно от многото решения, които блокчейн общността предложи за решаване на проблема с мащабирането на Биткойн, като големи блокове, DPoS, DAG, шардинг, двупосочна фиксирана странична верига, комуникация между вериги и т.н..

Те предложиха да се оптимизират основите на технологията на разпределената книга, напр. коригиране на конфигурационните параметри, оптимизиране на структурите на данни, модифициране на консенсусни алгоритми, обработка на разделение на книга, оптимизиране на мрежови ресурси и т.н., но резултатът не беше идеален и беше постигнато само много ограничено подобрение на производителността след цялата упорита работа (увеличаване на капацитета за съхранение, увеличаване мрежов трафик, увеличаване на логическата сложност, намаляване на децентрализацията). В сравнение с Visa, Bitcoin все още изостава значително.

Изглежда, че Lightning Network е най-доброто решение.

Поради сложността на биткойн интелигентните договори е трудно да се разберат техническите принципи на Lightning Network. Следователно екипът на OK Research повторно внедри Lightning Network с Solidity език, за да разбере технологията, свързана с внедряването на Lightning Network. По-долу сме обобщили основните процедури и принципи на Lightning Network за вас.

Основен технически принцип на Lightning Network

Основната идея на Lightning Network е да създаде временни канали за плащане извън веригата, които позволяват на двете страни да извършват неограничени транзакции извън веригата с множество канали за плащане, но само крайната транзакция ще бъде записана в блокчейна. По този начин транзакциите са много по-ефективни и мигновени, тъй като не е необходимо да чакат актуализирането на блока. Lightning Network работи върху това как да не се редактират транзакциите извън веригата.

1. Lightning Network е изградена върху три важни концепции – виртуална банка, транзакции за ангажименти и платежни канали.

а) Виртуална банка

Интелигентният договор работи като банка. Вземете за пример Алис и Боб, виртуалната банка е –

  • Мащабируемо – Има само два акаунта – Alice’s и Bob’s
  • Без доверие – отворен, прозрачен, не може да бъде фалшифициран, подправен или отменен
  • Автономност на потребителя – Алис и Боб управляват активите заедно
  • Мулти-подпис – Всяко преразпределение на фонда трябва да бъде подписано от Алис и Боб

б) Транзакции за поети задължения

Сделката за ангажимент е когато двете страни постигнат споразумение за разпределение на средствата и се подпишат. Актуализацията не се излъчва веднага в блокчейна, но се съхранява в локалната мрежа.

Сделката за ангажимент изразява истинската воля на двете страни. Това е споразумение за разпределение на средствата между тях. Транзакцията –

  • Не може да се фалшифицира
  • Не може да бъде фалшифициран
  • Може да се презапише

в) Канали за плащане

Канал за плащане е, когато и двете платежни страни използват виртуалната банка, за да депонират активите си и преразпределят баланса на депозитите си по взаимно споразумение, така че стойността да може да бъде прехвърлена.

Сделката за ангажимент се разделя на пряка и непряка връзка.

RSMC (Договор за падеж на възстановима последователност) и HTLC (Хеширани договори за заключване)

1. RSMC (Договор за падеж с отменяема последователност)

Той включва активната страна, която активно изпраща транзакции за ангажимент на виртуалната банка за разпределение на средства, и приемащата страна, която пасивно получава разпределението, предоставено от активната страна.

RSMC предотвратява злонамерени мотиви чрез механизъм за депозиране на доверие.

Когато активната страна инициира искане за ликвидация, фондът на получаващата страна, да речем 100 щ.д., ще бъде осребрен и незабавно върнат в сметката на получаващата страна. Активът на активната страна ($ 100) ще бъде заключен като депозит. Времето за заключване се определя от параметъра freeze_time, зададен от интелигентния договор (freeze_time се отнася до актива на активната страна, който е заключен, което може да бъде договорено и от двете страни). Ако получаващата страна разбере, че транзакцията за ангажимент, поискана от активната страна, е била отменена, получаващата страна може да отключи отменената ключалка в рамките на периода на блокиране и да приеме доверителния депозит на активната страна като глоба. Напротив, след периода на блокиране, активната страна може да изтегли доверителния си депозит.

RSMC е двоен ангажимент и за двамата контрагенти. Всяка страна пази копие от ангажимента и двете копия са обвързващи и ефективни за виртуалната банка. Двойният ангажимент позволява поддръжката на двупосочните канали за плащане, като се избягва блокиране в платежния канал поради грешка от двете страни.

Общите свойства между двата ангажимента – номер на ангажимент, баланс, време на замразяване.

Разликите между двата ангажимента – активна и приемаща страна, подписала страна, депозит и заключване за отмяна.

Процесът на сетълмент на RSMC може да бъде разделен на три части.

Отваряне на канал

  • Алис и Боб създават №1 RSMC и всеки от тях внася 100 BTC във фонд.

Създаване на транзакция за ангажимент (плащане)

  • Между Алис и Боб се създава нова задължителна връзка. Те ще създадат RSMC №2 и ще обменят подписи, за да актуализират собствеността върху фонда. Имайте предвид, че Алис и Боб държат подписа на контрагента. След като въведат свой собствен подпис в транзакцията, той ще влезе в сила незабавно.
  • И двете страни излъчват частния ключ за заключване на отмяна на RSMC №1, който ще стане невалиден едновременно. RSMC може непрекъснато да се заменя. Броят на ангажиментите се увеличава с по един за замяна.

Затваряне на канал

  • Алис се подписва на #N RSMC, който вече включва подписа на Боб, и изпраща искане за сетълмент до виртуалната банка.
  • Като активна страна, 50 BTC на Алиса са замразени като депозит, докато 150 BTC на Bob се освобождават незабавно. Когато средствата на Алис са замразени, ако Боб установи, че ангажиментът за преразпределение на средства не е успешен, напр. # 1 RSMC се провали, той може да предизвика отмяна по всяко време и да поиска и депозита, на който има законно право.
  • Ако ангажиментът остане валиден през целия период на замразяване на средствата, Алис ще може да си върне депозита.

Въпреки че RSMC може да задоволи основните нужди на процеса на сетълмент, той има очевидни ограничения. Каналът трябва да е отворен между двете страни в RSMC за плащане. За да се реши това ограничение, се предлага договор за заключване на хеш (HTLC). HTLC прави плащане маршрутизирано през два или повече платежни канала.

2. Договор за Hash Timelock (HTLC): решаване на проблемите с атомността в платежните канали

В HTLC са включени две условия: Timelock и Hashlock.

  • Timelock – изисква получателят да потвърди получаването в рамките на определен период от време (T).
  • Hashlock – едната страна генерира произволно число (H) и генерира своя хеш (R), ако другата част е в състояние да докаже Hash (R) = H, тогава плащането е валидно.

В повечето случаи HTLC включва свойствата на RSMC. Той действа като мост между две винаги ефективни RSMC. Нов RSMC ще бъде създаден, ако са изпълнени условията за заключване и хеш-блокиране. В противен случай предишният RSMC ще бъде приет вместо това.

Процес на HTLC плащания

Отляво надясно, установяване на ангажимент напред; отдясно наляво, изпращане на хеширан номер назад, за да завършите плащането.

  • Карол генерира произволно число (R), след това генерира своя хеш (H) и изпраща и двете на Алис;
  • Алис създава HTLC с Боб. Часовникът е зададен като 2T. Алис изпраща Н на Боб.
  • Боб създава HTLC с Карол. Часовникът е зададен на T (трябва да е по-кратък от 2T). Боб изпраща H на Карол.
  • Карол изпраща H, хешираното R, на Боб за проверка. Ако номерът съвпада преди изтичането, винаги ще бъде създаден винаги ефективен RSMC въз основа на HTLC и HTLC ще бъде отменен едновременно, като изпълни своята отговорност. Но ако числото R не съвпада или плащането изтича, HTLC ще се провали и плащането ще се върне към последния RSMC.
  • Боб ще изпрати номер R от Карол на Алис за проверка. И горният процес на валидиране се повтаря.

Сред трите страни Алис и Карол са крайните точки на транзакцията, Боб е само търговец, който свързва другите две страни. Всъщност Боб може да установи платежни отношения с всяка от страните. Например ангажиментите, установени между Боб и Алис, и Боб и Карол, могат да бъдат различни. Боб може да плати на Карол 9,9 долара и да таксува Алис 10 долара. $ 0,1 ще бъде таксата за трансфер за Боб.

3. Рисковете, които двата вида договори се опитват да разрешат – измама и атомност

  • Измама – ами ако другата страна е коварна и безпринципна?
  • В RSMC, от # N-1 до #N ангажименти, активната страна може да се възползва, като не отменя ангажимента # N-1. Следователно трябва да се добави допълнително условие за активната страна за излъчване на заключителната анулиране.
  • В HTLC, от # N-1 до #N ангажименти, само приемащата страна може да излъчва само хеширания номер, за да получи плащането (същото като анулирането на ангажимент # N-1). Ако активната страна не отмени ангажимент # N-1, получаващата страна все още може да го поиска директно чрез виртуалната банка. В заключение, HTLC установява балансирано правило „всичко или нищо“, за да избегне измамата на участниците.
  • Рисковете от множество канали за плащане: атомност на съседните канали

    В пътя на плащане активната страна създава HTLC за приемащата страна. След това приемащата страна изпраща хешираната стойност назад. Плащанията от лявата страна трябва да бъдат извършени преди тези от дясната страна.

  • За всички посредници извършването на плащания за възли от дясната страна означава получаване на хеширания номер в рамките на времето. А часовият механизъм от лявата страна трябва да е по-дълъг от часовия механизъм от дясната страна. Така че посредниците трябва да могат да искат еднакво обезщетение от възлите в дясната страна, което означава, че предимствата на посредниците обикновено идват от страната с по-кратък интервал от време. Ако се опитаме да отидем в обратна посока, възлите от дясната страна никога не извършват никакво плащане и никога не могат да получат хеширания номер. Така че плащането от лявата страна също никога няма да завърши. Това е атомността на съседните канали.
  • Като цяло механизмът на доверие е изграден върху автономията на двете страни. На етапа на вземане на решение приемащата страна се подписва преди активната страна да го направи. Следователно активната страна има право на първоначално преразглеждане, а активната страна има право на второ преразглеждане. На етапа на изпълнение активната страна има право на подаване, виртуалната банка право на изпълнение, а получаващата страна право на преглед в рамките на определен период от време.

Blockchain Trilemma and Lightning Network Solution

Биткойн е равностойна електронна парична система. Той е новаторски, защото създаде цифрова система за разплащане с уникалната характеристика на системата за плащане в брой – уреждане на плащането незабавно. Обмяната на стойност се извършва незабавно с размяната на „символи на стойността“, заедно с информацията за активите и прехвърлянето на вземанията и пасивите на кредитора. Цифровите плащания се борят да постигнат това, тъй като цифровият файл може да бъде дублиран или фалшифициран, което са двата най-обсъждани въпроса при цифровите плащания – валидиране и двойно харчене.

Проверка – този проблем е решен от Биткойн с помощта на цифров подпис. Който притежава частния ключ, притежава биткойн.

Двойно харчене – както е показано на диаграмата по-долу, когато Боб приема транзакцията на Алис, той ще трябва да потвърди, че транзакцията не се дублира, като провери цялата книга. Предотвратяването на двойни разходи създава проблем с мащабируемостта.

Както е написано от Сатоши Макамото в Bitcoin – Peer-to-Peer Electronic Cash System:

„Трябва ни начин получателят да разбере, че предишните собственици не са подписвали никакви по-ранни транзакции. За нашите цели най-ранната транзакция е тази, която се брои, така че не се интересуваме от по-късните опити за двойно харчене. Единственият начин да потвърдите отсъствието на транзакция е да знаете всички транзакции. “

Единственият начин за решаване на двойните разходи е придобиването на всички записи за транзакции, на които се основава разпределената книга на Satoshi. Но цената е непосилна.

  • Съхранение – всеки възел трябва да съхранява копие на пълната книга
  • Проверка – всеки възел трябва да валидира всички транзакции
  • Комуникация – всеки възел трябва да комуникира помежду си
  • Консенсус – всеки възел трябва да осигури хеш мощност за консенсус

За всяка транзакция необходимото съхранение, изчисление и комуникация ще бъдат положително пропорционални на броя на валидиращите възли. За постигане на консенсус между разпръснатите възли е необходимо повече време. Това е трилемата за блокчейн, за която винаги чуваме, трудността при постигане на децентрализация, сигурност и мащабируемост едновременно.

Появяват се решения за решаване на проблема с мащабируемостта през последните години, като по-голям размер на блока, DAG мрежа, нови механизми (DPOS, PBFT), шардинг и странична верига. Механизмите за консенсус като DPOS и PBFT жертват степен на децентрализация за мащабируемост, намалявайки броя на възлите за валидиране.

Тенденционните предложения за шардинг и странични вериги са по-напреднали. Въпреки че те също така намаляват обхвата на валидиращите възли, за да увеличат ефективността на консенсуса, те интегрираха идеята за „групиране“, което избягва валидирането често да се прави на конкретни възли, намалявайки рисковете от манипулация.

Независимо от това, технологията за рязко оцветяване е все още в зародиш. Тепърва ще се извършват повече проучвания и експерименти по проблеми като случайност, баланс и зависимост. Просто казано, все още няма абсолютна резолюция за Blockchain Trilemma. Но Lightning Network се откроява сред решенията за мащабиране извън веригата.

Логиката зад Lightning Network е проста. То не се ограничава от „равностойната парична система“. Вместо това той въведе механизъм за прехвърляне на дългове, който много прилича на банков превод. Прехвърлянето между Алис и Боб вече не е собственост на актива, а дълг към виртуална банка. Решението за двойно харчене е опростено – Боб вече трябва само да потвърди виртуалната банка за салдото по сметката, вместо да потвърди с цялата мрежа за записа на прехвърляне на Алиса. Виртуалната банка на Lightning Network обаче не включва идеята за централизиран посредник, вместо това се използва интелигентен договор, за да се гарантира уреждането на дълга от виртуалната банка.

Както и да е, Lightning Network постигна намаляване на значителен брой транзакции, които изискват пълен консенсус. Чрез изграждането на канал за разплащане извън веригата, той изпълнява валидиране и предотвратяване на двойни разходи с безкрайни групи. Тъй като няма зависимост между групите извън веригата, това минимизира риска, който част от мрежата налага на цялата мрежа.

Предимства на Lightning Network

Пет основни предимства на мълниеносната мрежа:

Ниски такси за транзакции

  • Миньорите не се изискват. Начисляват се малки такси за използване на каналите за плащане между възлите.

Потвърждение в реално време

  • По-малък брой възли в участие. Транзакциите обикновено се завършват между стотици милисекунди до няколко секунди.

Голям паралелен капацитет за обработка

  • Капацитет на канала = Bitcoin TPS x 3600 x 24 x Средна възраст на канала / 4 = 3 952 800
  • Капацитет за паралелна обработка = Капацитет на канала / Канали, заети за транзакция = 658 880

    * средната възраст на канала е източник; каналите, заети за транзакция, по подразбиране са 6 въз основа на шестте степени на разделяне.

Малък размер

  • Повечето данни се съхраняват извън веригата, освобождавайки място за съхранение в блокчейна.

Анонимност

  • Транзакциите са извън веригата и са почти невъзможни за проследяване.

В следващите глави ще се потопим по-дълбоко и ще проучим защо моделът за уреждане на дълга би бил по-ефективен, както и минусите на Lightning Network и нововъзникващите решения.

Тази публикация първоначално се появи в Medium. Прочетете още.

Относно OKEx

OKEx е водеща в света борса за дигитални активи със седалище в Малта, предлагаща изчерпателни услуги за търговия с цифрови активи, включително търговия със символи, фючърсна търговия, вечна суап търговия и индекс тракер на глобални търговци с технология блокчейн. В момента борсата предлага над 400 двойки токени и фючърси, позволяващи на потребителите да оптимизират своите стратегии.

About the author