Переслати оригінальний заголовок 'Системний розшифровувач волокна: великий експеримент з встановлення мережі Lightning на CKB'

23 серпня CKB офіційно випустила Fiber Network, рішення Lightning Network на базі CKB. Ця новина швидко викликала бурхливе обговорення в спільноті, що призвело до зростання ціни CKB майже на 30% протягом одного дня. Сильну реакцію можна пояснити переконливим наративом Lightning Network і тим фактом, що Fiber пропонує оновлене рішення в порівнянні з традиційною Lightning Network з численними поліпшеннями. Наприклад, Fiber підтримує кілька типів активів, включаючи CKB, BTC і стейблкоїни, і отримує вигоду від нижчих комісій за транзакції CKB і швидшого часу відгуку, що дозволяє значно покращити UX. Крім того, Fiber зробив кілька оптимізацій з точки зору конфіденційності та безпеки. Крім того, оптоволокно та мережа BTC Lightning Network можуть з'єднуватися між собою, утворюючи більшу мережу P2P. Представники CKB навіть згадали, що вони планують встановити 100 000 фізичних вузлів у Fiber та Lightning Network під час офлайн-заходів, щоб покращити та просунути платіжну мережу P2P. Це, безсумнівно, грандіозна і безпрецедентна історія

Якщо офіційна візія CKB буде реалізована у майбутньому, це буде значним допомогом для мережі Lightning, CKB та ширшої екосистеми Bitcoin. За даними мемпула, у мережі Lightning BTC наразі знаходиться понад 300 мільйонів доларів США, з приблизно 12 000 вузлами та майже 50 000 платіжними каналами, що були створені між ними.

На spendmybtc.com ми можемо спостерігати, що все більше продавців підтримують платежі Lightning Network. У міру зростання впізнаваності BTC зростання офчейн-платіжних рішень, таких як Lightning Network і Fiber, ймовірно, набиратиме обертів. Щоб систематично проаналізувати технічне рішення Fiber, "Geek Web3" підготував цей дослідницький звіт про загальне рішення Fiber. Як реалізація Lightning Network, заснованої на CKB, принципи Fiber багато в чому узгоджуються з Bitcoin Lightning Network, але включають оптимізацію в багатьох деталях. Загальна архітектура Fiber складається з чотирьох основних компонентів: платіжних каналів, WatchTower, маршрутизації з декількома переходами та міждоменних платежів. Почнемо з пояснення найважливішої складової: платіжних каналів.

Засади мережі Lightning та Fiber: платіжні канали

Платіжні канали, по суті, переводять транзакції за межі ланцюга, а остаточний стан розраховується ончейн через деякий час. Оскільки транзакції здійснюються поза мережею, вони часто обходять обмеження продуктивності основного ланцюга, такого як BTC. Наприклад, якщо Аліса та Боб відкривають канал разом, вони спочатку створюють ончейн-акаунт із мультипідписом і вносять деякі кошти, скажімо, по 100 одиниць кожен, як баланс у офчейн-каналі. Потім вони можуть проводити кілька транзакцій у межах каналу, а коли вони закривають канал, вони синхронізують остаточні баланси в мережі, при цьому обліковий запис із мультипідписом здійснює платежі обом сторонам — це і є «розрахунок».

Наприклад, якщо обидві сторони починають з по 100 одиниць, і Еліс передає 50 одиниць Бобу, за якою слідує ще один переказ у 10 одиниць, а потім Боб передає 30 одиниць назад Еліс, їх кінцеві баланси будуть: Еліс - 70 одиниць, Боб - 130 одиниць. Загальний баланс залишається незмінним, як це показано на прикладі куля-сорочки. Якщо одна сторона виходить з каналу, кінцеві баланси (Еліс: 70, Боб: 130) синхронізуються на ланцюжку, і 200 одиниць багато-підписного рахунку розподіляються відповідно до цих кінцевих балансів для завершення розрахунку.

Хоча цей процес здається простим, на практиці він вимагає складних міркувань. Ви не можете передбачити, коли інша сторона вирішить вийти з каналу. Наприклад, Боб може вийти після другої транзакції або навіть після першої, оскільки канал дозволяє учасникам вільно виходити. Щоб вирішити цю проблему, система припускає, що будь-хто може вийти в будь-який час, і будь-яка сторона може передати остаточний баланс ланцюжку для розрахунку. Це управляється за допомогою «транзакцій зобов'язань», які фіксують останні залишки в каналі. Кожна транзакція породжує відповідну транзакцію зобов'язання. Щоб вийти з каналу, ви надсилаєте в ланцюжок останню транзакцію зобов'язання, щоб вивести свою частку з облікового запису з мультипідписом.

Ми можемо зробити висновок, що транзакції зобов'язань використовуються для розрахунків за балансами обох сторін у ланцюжку каналу, при цьому будь-яка зі сторін може подати останню транзакцію зобов'язань для виходу з каналу. Однак є важливий шкідливий сценарій: Боб може подати в мережу застарілий баланс і транзакцію зобов'язань. Наприклад, після генерації Commit Tx3 баланс Боба становить 130 одиниць. Але на свою користь, Боб може представити застарілий коміт Tx2, який показує баланс у 160 одиниць. Цей застарілий баланс являє собою класичну атаку «подвійних витрат».

Щоб запобігти таким ситуаціям подвійного витрачання, необхідно вжити відповідних штрафних заходів. Проектування цих штрафних заходів є основою системи одного-до-одного платіжного каналу, і розуміння цього є важливим для розуміння того, як працюють платіжні канали. При проектуванні каналу, якщо будь-яка сторона подає застарілий стан та транзакцію зобов'язання в ланцюжок, замість отримання вигоди, вони знайдуть, що інша сторона може зняти всі кошти. Це використовує концепції "асиметричних транзакцій зобов'язання" та "ключів анулювання", які є критичними. Давайте спочатку пояснимо "асиметричні транзакції зобов'язання" на прикладі Commit Tx3.

У цьому сценарії Боб створює транзакцію зобов'язання та надсилає її Еліс для обробки. Як показано, ця транзакція передбачає переказ Bitcoin, заявляючи, що 70 одиниць з рахунку з багато підписами призначені для Еліс та 130 одиниць для Боба. Однак умови розблокування є "асиметричними", накладаючи суворі обмеження на Еліс та користуючись Бобом.

Коли Аліса отримує транзакцію зобов'язання від Боба, вона може додати свій підпис, щоб відповідати вимозі мультипідпису 2/2. Після цього Аліса може вибрати, чи подати цю транзакцію зобов'язання на ланцюжок для виходу з каналу. У іншому випадку вона може продовжувати здійснювати транзакції в межах каналу, якщо не подає її.

Важливо зауважити, що цю транзакцію зобов'язань складає Боб і має умови, які несприятливі для Еліс. У Еліс є вибір прийняти або відхилити її, але ми повинні забезпечити, щоб вона зберегла деяку автономію. У дизайні платіжних каналів лише Еліс може подати “несприятливу” транзакцію зобов'язань до ланцюжка, оскільки для таких транзакцій зобов'язань потрібен 2/2 багато-підпис. Після того, як Боб складає транзакцію локально, вона має лише його підпис і не має підпису Еліс.

Аліса може «прийняти підпис Боба, але не дати свого». Це схоже на договір, який вимагає подвійного підпису. Якщо Боб підпише контракт першим і надішле контракт Алісі, вона може не надавати свій підпис. Щоб контракт набув чинності, Алісі потрібно було його підписати, а потім подати; В іншому випадку вона може утриматися від його підписання або подачі. Таким чином, в даному випадку у Аліси є засоби, щоб обмежити дії Боба.

Ось ключова точка: Кожен раз, коли в каналі відбувається транзакція, генерується пара транзакцій зобов'язань з двома дзеркальними версіями, як показано нижче. Аліса та Боб можуть кожен створити транзакції зобов'язань, які є вигідними для них самих, вказавши їхні відповідні баланси або суми, які будуть отримані при виході, а потім надіслати ці транзакції одне одному для обробки.

Цікаво, що, хоча обидві транзакції зобов'язання декларують ту саму «суму, що отримується при виході», умови виведення відрізняються. Це показує поняття «асиметричних транзакцій зобов'язання», згадане раніше.

Як вже пояснено, для кожної транзакції зобов'язань потрібен 2/2 багатоадресний підпис для її підтвердження. Транзакція зобов'язань, створена Бобом на його користь, не відповідає вимозі 2/2 багатоадресного підпису, тоді як транзакція зобов'язань, яка задовольняє цю вимогу, знаходиться в розпорядженні Еліс та може бути відправлена тільки нею, створюючи механізм перевірки та балансу. Та ж логіка застосовується у зворотному напрямку.

Отже, Еліс та Боб можуть лише подавати транзакції з фіксацією, які є невигідними для себе. Якщо будь-яка зі сторін подає транзакцію з фіксацією до ланцюжка і вона стає дієвою, канал закривається.

Стосовно раніше обговореного сценарію «подвійного витрачання», якщо хтось подає застарілу транзакцію зобов'язання на ланцюжок, вступає в гру концепція «ключів відклику». Наприклад, якщо Боб подає застарілий Tx2 на ланцюжок, Еліс може використовувати ключ відклику, пов'язаний з Tx2, щоб зняти гроші, які Боб повинен був отримати.

У прикладі діаграми, припускаючи, що остання транзакція зобов'язання - Commit Tx3 і Tx2 застаріла, якщо Боб подає застарілу Tx2, Аліса може діяти протягом періоду блокування часу, використовуючи рецизійний ключ Tx2 для виведення коштів Боба.

Щодо останнього Tx3, Аліса не має його ключа анулювання і отримає його лише після створення Tx4 у майбутньому. Це пов'язано з природою криптографії на відкритому/закритому ключі та властивостями UTXO. З міркувань кратності, тут не обговорюються деталі реалізації ключів анулювання.

Ключовий висновок полягає в тому, що якщо Боб наважиться подати в мережу застарілу транзакцію зобов'язань, Аліса може використовувати ключ відкликання, щоб зняти кошти Боба як штраф. Так само, якщо Аліса діє зловмисно, Боб може застосувати таке ж покарання до неї. Цей механізм гарантує, що індивідуальні платіжні канали ефективно запобігають подвійним витратам, оскільки раціональні учасники уникатимуть зловмисних дій.

У цьому контексті Fiber, на основі CKB, пропонує значні покращення порівняно з мережею Bitcoin Lightning. Вона природно підтримує операції та перекази різних типів активів, включаючи CKB, BTC та стабільні монети RGB++, тоді як мережа Lightning природно підтримує лише Bitcoin. Навіть з оновленням Taproot Asset, мережа Bitcoin Lightning все ще не може природно підтримувати не-BTC активи та може лише опосередковано підтримувати стабільні монети.

(Зображення джерела: Dapangdun). Крім того, оскільки Fiber ґрунтується на CKB як своєму основному ланцюжку Layer 1, комісії за відкриття та закриття каналів значно нижчі порівняно з мережею BTC Lightning. Це зменшує витрати користувача на транзакції, що представляє собою чітку перевагу з точки зору користувацького досвіду (UX).

24/7 безпека: WatchTower

Проблема з відкликанням ключів полягає в тому, що учасники каналу повинні постійно моніторити одне одного, щоб запобігти поданню застарілих транзакцій зобов'язань. Однак ніхто не може бути онлайн цілодобово, тому що відбувається, якщо одна сторона діє зловмисно, тоді як інша перебуває в автономному режимі? Як Fiber, так і біткоїнова мережа Lightning вирішують цю проблему за допомогою дизайну WatchTowers.

WatchTowers призначені для моніторингу онлайн-активності цілодобово. Якщо хтось подає застарілу транзакцію зобов'язання, WatchTower вчасно вживе заходів для захисту каналу та коштів. Ось як це працює:

Після того як транзакція зобов'язання відправлена, Еліс або Боб можуть підготувати відповідну транзакцію покарання наперед (використовуючи ключ скасування для обробки застарілої транзакції зобов'язання, заявивши отримувача як себе). Після цього вони надають текст цієї транзакції покарання WatchTower.

Коли WatchTower виявляє застарілу транзакцію зобов'язання, яка подається до ланцюжка, він також подасть підготовлену транзакцію штрафу, здійснюючи штраф і забезпечуючи цілісність каналу.

Fiber захищає конфіденційність учасників, вимагаючи від користувачів надсилати лише "хеш застарілої транзакції зобов'язання + звичайний текст транзакції покарання" до WatchTower. Таким чином, WatchTower спочатку знає лише хеш транзакції зобов'язання, а не її звичайний текст. WatchTower бачить звичайний текст лише в разі подання когось застарілої транзакції зобов'язання на ланцюжок, після чого він також подасть транзакцію покарання. Це забезпечує, що WatchTower буде бачити лише запис транзакцій учасника в разі фактичних порушень, і навіть тоді він побачить лише одну транзакцію.

У плані оптимізації Fiber поліпшує підхід мережі Bitcoin Lightning до механізмів штрафів. Помітним недоліком “LN-Penalty” мережі Lightning є те, що WatchTowers повинні зберігати всі застарілі хеші транзакцій зобов’язання та відповідні ключі анулювання, що призводить до значного тиску на зберігання. У 2018 році спільнота Bitcoin запропонувала рішення під назвою “eltoo”, щоб вирішити цю проблему. Eltoo дозволить останній транзакції зобов’язання штрафувати застарілі, зменшуючи потребу у зберіганні всіх попередніх транзакцій. Однак це рішення вимагає активації опкоду SIGHASH_ANYPREVOUT, який наразі не був реалізований.

З іншого боку, Fiber використовує протокол Daric, який модифікує конструкцію ключа анулювання, щоб зробити один ключ анулювання застосовним до декількох застарілих транзакцій зобов'язання. Цей підхід значно зменшує вимоги до зберігання WatchTowers та користувацьких клієнтів.

Щодо систем мережевого трафіку: Платіжні канали підходять для одноразових транзакцій, але Lightning Network підтримує мультихопові платежі, що дозволяє проводити транзакції між сторонами, які не мають прямого каналу, шляхом маршрутизації через посередницькі вузли. Наприклад, якщо у Еліси і Кена немає прямого каналу, але у Кена і Боба є, і у Боба і Еліси є, Боб може виступати посередником для здійснення транзакцій між Елісою і Кеном.

«Мультихопова маршрутизація» покращує гнучкість та охопленість мережі. Однак відправники повинні бути уважні щодо стану всіх публічних вузлів та каналів. У Fiber вся структура мережі, включаючи всі публічні канали, є повністю прозорою, що дозволяє будь-якому вузлу отримувати інформацію про мережу від інших вузлів. Оскільки стан мережі у мережі Lightning постійно змінюється, Fiber використовує алгоритм Дейкстри для знаходження найкоротшого маршруту, мінімізуючи кількість посередників та встановлюючи транзакційний шлях між двома сторонами.

Для вирішення проблеми довіри до посередників: Як ви можете забезпечити, що вони є чесними? Наприклад, якщо Алісі потрібно здійснити платіж у 100 одиниць Кенові, але Боб, який є посередником між ними, може утримувати кошти. HTLC та PTLC використовуються для запобігання такої зловмисної поведінки. Припустимо, що Аліса хоче заплатити Даніелю 100 одиниць, але у них немає прямого каналу. Аліса виявляє, що може маршрутизувати платіж через посередників Боба та Карол. HTLC вводиться як платіжний канал: спочатку Аліса ініціює запит до Даніеля, який потім надає Алісі хеш r, але Аліса не знає преімедж R, відповідного r.

Потім Еліса укладає угоду про оплату з Бобом через HTLC: Еліса готова заплатити Бобу 102 одиниці, але Боб повинен розкрити ключ R протягом 30 хвилин; в іншому випадку Еліса забере гроші. Так само Боб створює HTLC з Керол: Боб заплатить Керол 101 одиницю, але Керол повинна розкрити ключ R протягом 25 хвилин; в іншому випадку Боб забере гроші. Керол робить те саме з Даніелем: Керол готова заплатити Даніелю 100 одиниць, але Даніел повинен розкрити ключ R протягом 20 хвилин; в іншому випадку Керол забере гроші.

Даніель розуміє, що ключ R, який запитала Керол, насправді те, що хоче Аліса, оскільки тільки Аліса зацікавлена в значенні R. Таким чином, Даніель співпрацює з Керол, надає ключ R і отримує 100 одиниць від Керол. Таким чином, Аліса досягає своєї мети - сплати Даніелю 100 одиниць.

Згодом Керол надає ключ R Бобу і отримує 101 одиницю. Потім Боб дає ключ R Алісі і отримує 102 одиниці. Спостерігаючи за прибутками та програшами кожного, Аліса втрачає 102 одиниці, Боб і Керол заробляють по 1 одиниці, а Деніел отримує 100 одиниць. 1 одиниця, зароблена Бобом і Керол, - це їхній гонорар, отриманий з Аліси.

Навіть якщо хтось у шляху оплати, наприклад, Керол, не надає ключ R нижчестоящому Бобу, це не призводить до втрат для Боба: після закінчення тайм-ауту Боб може зняти сконструйований HTLC. Те саме стосується і Еліс. Проте, мережа Lightning має свої проблеми: шляхи не повинні бути занадто довгими. Якщо шлях надто довгий із занадто багатьма посередниками, це може знизити надійність платежу. Деякі посередники можуть бути в автономному режимі або не мати достатнього балансу для сконструйованого HTLC (наприклад, кожен посередник у попередньому прикладі повинен мати більше 100 одиниць). Тому додавання більше посередників збільшує ймовірність помилок.

Крім того, HTLC можуть витікати приватність. Хоча цибулева маршрутизація може забезпечити деяку захист приватності, шифруючи інформацію про маршрутизацію на кожному кроці, щоб кожен учасник знаходився тільки у своїх найближчих сусідах, а не у повному шляху, HTLC все ще піддаються виведенню відносин. З вищої точки зору можна все ще вивести повний маршрут маршрутизації.

Припустимо, що Боб та Даніель контролюються тією самою сутністю та щодня отримують багато HTLC. Вони зауважують, що ключ R, який запитала Еліс та Кароліна, завжди однаковий, і що внизовий вузол Єва, пов'язаний з Даніелем, завжди знає вміст ключа R. Таким чином, Даніель та Боб можуть вивести, що існує шлях оплати між Еліс та Євою, оскільки вони завжди мають справу з однаковим ключем та можуть контролювати їхні відносини. Для вирішення цього Fiber використовує PTLC, які підвищують конфіденційність над HTLC, використовуючи різні ключі для розблокування кожного PTLC в шляху оплати. Спостерігання лише PTLC не може визначити відносин між вузлами. Поєднуючи PTLC з цибулевою маршрутизацією, Fiber стає ідеальним рішенням для збереження конфіденційності платежів.

Крім того, традиційна мережа Lightning Network вразлива до «велосипедної атаки на заміну», яка може призвести до крадіжки активів у посередників на шляху оплати. Ця проблема призвела до того, що розробник Антуан Ріар відмовився від розробки Lightning Network. На даний момент Bitcoin Lightning Network не має фундаментального вирішення цієї проблеми, що робить її больовою точкою. В даний час CKB вирішує цей сценарій атаки за допомогою поліпшень на рівні пулу транзакцій, що дозволяє Fiber пом'якшити проблему. Оскільки заміна велосипедної атаки та її вирішення досить складні, у цій статті ми не будемо заглиблюватися в неї далі. Зацікавлені читачі можуть звернутися до відповідних статей з BTCStudy та офіційних ресурсів CKB для отримання додаткової інформації.

У цілому, Fiber представляє собою значне поліпшення порівняно з традиційною мережею Lightning як з точки зору конфіденційності, так і з точки зору безпеки. Fiber покращує міждоменові атомарні платежі між собою та мережею Bitcoin Lightning.

З використанням HTLC та PTLC Fiber може забезпечити перекриття доменів платежів з Bitcoin Lightning Network, забезпечуючи «атомарність крос-доменних дій», що означає, що всі етапи крос-доменної транзакції або повністю успішні, або повністю невдалими, без часткового успіху або невдачі. Забезпечуючи крос-доменну атомарність, ризик втрати активів зменшується. Це дозволяє Fiber з'єднуватися з Bitcoin Lightning Network, надаючи можливість прямих платежів з Fiber на користувачів у мережі BTC Lightning (при цьому отримувач обмежений BTC) і дозволяючи конвертацію CKB.

B та RGB++ активи в еквівалент Bitcoin в мережі BTC Lightning.

Ось спрощене пояснення процесу: Припустимо, що Аліса працює з вузлом в мережі Fiber, а Боб - з вузлом в мережі Bitcoin Lightning Network. Якщо Аліса хоче переказати гроші Бобу, вона може зробити це через помічника між доменами - Інґрід. Інґрід буде працювати з вузлами в мережах Fiber та BTC Lightning Networks, виступаючи посередником на шляху платежу.

Якщо Боб хоче отримати 1 BTC, Аліса може провести переговори з обмінним курсом з Інгрід, встановивши 1 CKB рівним 1 BTC. Потім Аліса надішле 1,1 CKB Інгрід в мережі Fiber, а Інгрід надішле 1 BTC Бобу в мережі Bitcoin Lightning, залишаючи 0,1 CKB як комісію.

Процес полягає в встановленні шляху оплати між Алісою, Інгрід та Бобом, використовуючи HTLC. Боб повинен надати Інгрід ключ R для отримання коштів. Як тільки у Інгрід з’явиться ключ R, вона зможе розблокувати кошти, які Аліса заблокувала в HTLC.

Міждоменні дії між BTC Lightning Network і Fiber є атомарними, тобто або обидва HTLC розблоковані, а міждоменний платіж успішно виконано, або жоден з них не розблоковано, і платіж не вдається. Це гарантує, що Аліса не втратить гроші, якщо Боб їх не отримає.

Інгрід потенційно не зможе розблокувати HTLC Аліси, знаючи ключ R, але це зашкодить Інгрід, а не Алісі. Таким чином, конструкція оптоволокна забезпечує безпеку для користувачів і не вимагає довіри до третіх осіб, дозволяючи передавати дані між різними P2P-мережами з мінімальними змінами.

Інші переваги Fiber порівняно з мережею біткойн-блискавки BTC

Раніше ми згадували, що Fiber підтримує місцеві активи CKB та активи RGB++ (особливо стейблкоїни), що надає йому значний потенціал для оплати в реальному часі і робить його ідеально підходящим для щоденних невеликих транзакцій.

На противагу цьому, основною проблемою Bitcoin Lightning Network є управління ліквідністю. Як ми обговорювали на початку, загальний баланс у платіжному каналі є фіксованим. Якщо баланс однієї сторони вичерпано, вона не може переказати кошти іншій стороні, якщо інша сторона не надішле гроші першою. Для цього потрібно перезавантажити кошти або відкрити новий канал.

Додатково, в складній мережі з багатьма проміжними вузлами, якщо деякі проміжні вузли мають недостатній баланс та не можуть пересилати платежі, це може призвести до невдачі всього шляху оплати. Це одна з болючих точок Мережі Блискавок. Типове рішення передбачає надання ефективних механізмів впровадження ліквідності, щоб забезпечити можливість внесення коштів більшістю вузлів за потребою.

Однак, в мережі Bitcoin Lightning, ін'єкція ліквідності, а також відкриття або закриття каналу, відбуваються на біткоїновому блокчейні. Якщо комісії мережі Bitcoin дуже високі, це негативно впливає на користувацький досвід платіжних каналів. Наприклад, якщо ви хочете відкрити канал з потужністю у $100, але вартість налаштування становить $10, це означає, що 10% ваших коштів споживаються лише для налаштування каналу, що є неприйнятним для більшості користувачів. Та ж сама проблема виникає з ін'єкцією ліквідності.

На відміну, Волокно пропонує значні переваги. По-перше, TPS (транзакції на секунду) CKB набагато вищий, ніж у Bitcoin, з вартістю, що досягає витрат на рівні центів. По-друге, для вирішення проблеми нестачі ліквідності та забезпечення плавних транзакцій, Fiber планує співпрацювати з Mercury Layer для впровадження нових рішень, які усувають потребу в операціях на ланцюжку для ін'єкції ліквідності, тим самим вирішуючи проблеми UX та вартості.

Тепер ми систематично намалювали загальну технічну архітектуру Fiber зі зведенням у порівнянні з мережею Bitcoin Lightning, як показано на зображенні вище. З урахуванням складності та широти тем, охоплених як Fiber, так і мережею Lightning, одна стаття може не встигнути охопити кожний аспект. В майбутньому ми плануємо випустити серію статей, фокусуючись на різних аспектах як мережі Lightning, так і Fiber. Слідкуйте за оновленнями.

Відмова від відповідальності:

1. Ця стаття передрукована з [Geek web3]. Переслати оригінальний заголовок 'Системне розуміння Fiber: великий експеримент з прив'язкою мережі Lightning до CKB'. Усі авторські права належать оригінальному автору [Faust & Nickqiao, гік веб3]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Sanv Nurlaeкоманда і вони оперативно цим займуться.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно власні автора і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Sanv Nurlae. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.