Вступ

Майбутнє за мультиланцюжками. Прагнення до масштабованості привело Ethereum до згортання. Перехід до модульних блокчейнів знову привернув увагу до мереж додатків. А за горизонтом ми чуємо шепіт про згортання для конкретних програм, L3 та суверенні ланцюги.

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

Як виглядатиме кінцева гра взаємопов’язаного web3? Ми віримо, що всі мости перетворяться на міжланцюговий обмін повідомленнями або протоколи «передачі довільних повідомлень» (AMP), щоб розблокувати нові варіанти використання, дозволяючи програмам передавати довільні повідомлення від джерела до ланцюга призначення. Ми також побачимо, як з’явиться «ландшафт механізму довіри», де розробники йдуть на різні компроміси щодо зручності використання, складності та безпеки.

Кожне рішення AMP потребує двох критичних можливостей:

• Перевірка: можливість перевірити дійсність повідомлення з ланцюжка джерела в ланцюжку призначення
• Жвавість: здатність передавати інформацію від джерела до місця призначення

100% перевірка без довіри неможлива, і від користувачів вимагається довіряти коду, теорії ігор, людям (або об’єктам) або їх поєднанню, залежно від того, чи виконується перевірка в ланцюзі чи поза ланцюгом.

Ми поділяємо загальний ландшафт взаємодії на основі механізму довіри та архітектури інтеграції.

Механізм довіри:

1. Код довіри/математика: для цих рішень існує онлайн-доказ, який може перевірити будь-хто. Ці рішення, як правило, покладаються на легкий клієнт для підтвердження консенсусу ланцюга джерела в ланцюжку призначення або перевірки дійсності переходу стану для ланцюга джерела в ланцюг призначення. Перевірку через легкі клієнти можна зробити набагато ефективнішою завдяки доказам Zero Knowledge для стиснення довільно довгих обчислень в автономному режимі та забезпечення простої перевірки в ланцюжку для підтвердження обчислень.
2. Теорія гри довіри: існує додаткове припущення про довіру, коли користувач/додаток має довіряти третій стороні або мережі третіх сторін щодо автентичності транзакцій. Ці механізми можна зробити більш безпечними за допомогою мереж без дозволів у поєднанні з теорією ігор, як-от економічні стимули та оптимістична безпека.
3. Довіряйте людям: ці рішення покладаються на чесність більшості валідаторів або незалежність організацій, які передають різну інформацію. Вони вимагають довіри до третіх сторін на додаток до довіри до консенсусу двох взаємодіючих ланцюгів. Тут на карту поставлено лише репутацію учасників. Якщо достатньо суб’єктів-учасників погоджуються, що транзакція є дійсною, вона вважається дійсною.

Важливо зазначити, що всі рішення певною мірою потребують довіри як до коду, так і до людей. Будь-яке рішення з помилковим кодом може бути використано хакерами, і кожне рішення має певний людський елемент у налаштуванні, оновленні або обслуговуванні кодової бази.

Архітектура інтеграції:

1. Модель «точка-точка»: між кожним джерелом і кожним пунктом призначення необхідно встановити спеціальний канал зв’язку.
2. Модель Hub and Spoke: необхідно встановити канал зв’язку з центральним концентратором, який забезпечує підключення до всіх інших блокчейнів, підключених до цього концентратора.

Модель «точка-точка» відносно важко масштабувати, оскільки для кожного підключеного блокчейну потрібен попарний канал зв’язку. Розробка цих каналів може бути складною для блокчейнів із різними консенсусами та фреймворками. Однак попарні мости забезпечують більшу гнучкість для налаштування конфігурацій, якщо це необхідно. Гібридний підхід також можливий, наприклад, за допомогою протоколу зв’язку між блоками (IBC) із маршрутизацією з кількома стрибками через концентратор, що усуває потребу в прямому попарному зв’язку, але повторно вводить більшу складність у безпеці, затримці та вартості міркування.

Код довіри/мат

Як легкі клієнти перевіряють консенсус вихідного ланцюга щодо ланцюга призначення?

Легкий клієнт/вузол — це частина програмного забезпечення, яка підключається до повних вузлів для взаємодії з блокчейном. Легкі клієнти в ланцюжку призначення зазвичай зберігають історію заголовків блоків (послідовно) вихідного ланцюжка, чого достатньо для перевірки транзакцій. Агенти поза ланцюгом, такі як ретранслятори, відстежують події в вихідному ланцюжку, генерують криптографічні докази включення та пересилають їх разом із заголовками блоків легкому клієнту в ланцюжку призначення. Легкі клієнти можуть перевірити транзакцію, оскільки вони зберігають заголовки блоків послідовно, і кожен заголовок блоку містить кореневий хеш Merkle, який можна використовувати для підтвердження стану. Ключові особливості цього механізму:

1. Безпека:

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

1. Реалізація: залежить від наявності підтримки криптографічних примітивів, необхідних для перевірки

• Якщо підключається однаковий тип ланцюжка (однаковий фреймворк програми та алгоритм консенсусу), тоді реалізація легкого клієнта з обох сторін буде однаковою. Приклад: IBC для всіх мереж на основі Cosmos SDK.
• Якщо з’єднати два різних типи ланцюжків (різні фреймворки додатків або типи консенсусу), реалізація легкого клієнта буде відрізнятися. Приклад: Composable Finance працює над підключенням ланцюжків Cosmos SDK через IBC до Substrate (фреймворк програми екосистеми Polkadot). Для цього потрібен легкий клієнт Tendermint у ланцюжку субстратів і так званий м’який легкий клієнт, доданий до ланцюжка Cosmos SDK

1. виклики:

• Ресурсомісткість: Дорого запускати попарні легкі клієнти на всіх ланцюгах, оскільки записи в блокчейни є дорогими, і їх неможливо запустити в ланцюгах із наборами динамічних валідаторів, як-от Ethereum.
• Розширюваність: для кожної комбінації ланцюжків потрібна легка клієнтська реалізація. З огляду на те, що реалізація залежить від архітектури ланцюга, важко масштабувати та з’єднувати різні екосистеми.
• Експлуатація коду: помилки в коді можуть призвести до вразливостей. Експлойт ланцюга BNB у жовтні 2022 року виявив критичну вразливість у безпеці, яка вплинула на всі ланцюги з підтримкою IBC.

Як ZK-докази перевіряють дійсність переходу стану для ланцюга джерела в ланцюг призначення?

Запуск попарних легких клієнтів у всіх ланцюгах є надзвичайно дорогим і не практичним для всіх блокчейнів. Легкі клієнти в таких реалізаціях, як IBC, також повинні відстежувати набір валідаторів вихідного ланцюга, що непрактично для ланцюжків із динамічними наборами валідаторів, як-от Ethereum. ZK proofs забезпечує рішення для скорочення газу та часу верифікації. Замість виконання всього обчислення в ланцюжку, лише перевірка підтвердження обчислень виконується в ланцюзі, а фактичне обчислення виконується поза ланцюгом. Перевірку підтвердження обчислень можна виконати за менший час і з меншими витратами газу, ніж повторний запуск початкового обчислення. Ключові особливості цього механізму:

1. Безпека: безпека zk-SNARK залежить від еліптичних кривих, а zk-STARK — від хеш-функцій. zk-SNARK можуть вимагати або не вимагати надійного налаштування. Довірене налаштування потрібне лише спочатку, що стосується початкової події створення ключів, які використовуються для створення доказів, необхідних для перевірки цих доказів. Якщо секрети в події налаштування не знищено, вони можуть бути використані для підробки транзакцій шляхом фальшивих перевірок. Після завершення довіреного налаштування припущення про довіру не вводяться.
2. Реалізація: Сьогодні існують різні схеми підтвердження ZK, такі як SNARK, STARK, VPD, SNARG, і наразі SNARK є найбільш поширеною. Рекурсивні ZK-докази — це ще одна остання розробка, яка дозволяє розподілити всю роботу з доведення між декількома комп’ютерами, а не одним. Щоб згенерувати докази дійсності, необхідно реалізувати такі основні примітиви:

• перевірка схеми підпису, що використовується валідаторами
• включення підтвердження відкритих ключів валідатора в зобов’язання набору валідатора (яке зберігається в ланцюжку)
• відстеження набору валідаторів, який може постійно змінюватися

1. виклики:

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

1. Приклади: Polymer ZK-IBC від Polymer Labs, Succinct Labs. Polymer працює над IBC із підтримкою кількох переходів , щоб збільшити зв’язок, одночасно зменшуючи кількість необхідних парних з’єднань.

Теорія ігор довіри

Протоколи сумісності, які спираються на теорію ігор, можна загалом розділити на 2 категорії залежно від того, як вони стимулюють чесну поведінку учасників:

1. Економічна безпека: кілька зовнішніх учасників (наприклад, валідатори) досягають консенсусу щодо оновленого стану вихідного ланцюжка. Це схоже на налаштування кількох підписів, але для того, щоб стати валідатором, учасники повинні поставити певну кількість токенів, яку можна скоротити, якщо буде виявлено будь-яку зловмисну активність. У налаштуваннях без дозволу будь-хто може накопичувати ставки та стати валідатором. Існують також блокові винагороди, які діють як економічні стимули, коли валідатори-учасники дотримуються протоколу. Таким чином учасники економічно стимулюються бути чесними. Однак, якщо сума, яку можна вкрасти, значно перевищує суму, поставлену на ставку, тоді учасники можуть спробувати змови з метою викрадення коштів. Приклади: Axelar, Celer IM
2. Оптимістична безпека: оптимістичні рішення безпеки спираються на припущення про довіру меншості, яке передбачає, що лише меншість учасників блокчейну живі, чесні та дотримуються правил протоколу. Рішення може вимагати лише одного чесного учасника мати гарантію. Найпоширенішим прикладом є оптимальне рішення, коли кожен може надати докази шахрайства. Тут також є економічний стимул, але навіть для чесного спостерігача практично можливо пропустити шахрайську транзакцію. Оптимістичні зведені програми також використовують цей підхід. Приклади: Nomad, ChainLink CCIP

• У випадку з Nomad спостерігачі можуть довести шахрайство. Однак спостерігачі Nomad були в білому списку на момент написання статті.
• ChainLink CCIP використовуватиме мережу боротьби з шахрайством, яка складатиметься з децентралізованих мереж оракул з єдиною метою моніторингу зловмисної діяльності. Реалізація мережі боротьби з шахрайством CCIP ще невідома.

Основні особливості цих механізмів:

1. Безпека: для ефективних механізмів теорії ігор для обох механізмів важливо мати бездозвільну участь валідаторів і спостерігачів. Відповідно до механізму економічної безпеки кошти можуть піддаватися більшому ризику, якщо сума ставки нижча за суму, яку можна вкрасти. Згідно з оптимістичним механізмом безпеки, припущення щодо довіри меншості для оптимістичних рішень можуть бути використані, якщо ніхто не надає докази шахрайства або якщо авторизовані спостерігачі скомпрометовані/видалені, тоді як механізми економічної безпеки не мають такої ж залежності від живучості для безпеки.
2. Реалізація:

• Проміжний ланцюг із власними валідаторами: група зовнішніх валідаторів відстежує вихідний ланцюг, досягає консенсусу щодо дійсності транзакції кожного разу, коли виявляється виклик, і надає атестацію в ланцюжку призначення, якщо консенсус досягається. Від валідаторів зазвичай вимагається ставка певної кількості токенів, яку можна скоротити, якщо буде виявлено зловмисну активність. Приклади: Axelar Network, Celer IM
• Через агентів поза ланцюгом: агентів поза ланцюгом можна використовувати для реалізації оптимістичного рішення, схожого на згортання, де протягом попередньо визначеного часового вікна агентам поза ланцюгом буде дозволено надати докази шахрайства та скасувати транзакцію. Приклад: Nomad покладається на незалежних агентів поза мережею для передачі заголовка та криптографічного підтвердження. ChainLink CCIP використовуватиме свою існуючу мережу Oracle для моніторингу та підтвердження міжланцюжкових транзакцій.

1. виклики:

• Припущення про довіру можуть бути використані для крадіжки коштів, якщо більшість валідаторів вступають у змову, що вимагає контрзаходів, таких як квадратичне голосування та докази шахрайства.
• Закінченість: оптимістичні рішення AMP на основі безпеки вносять складність у остаточність і живість, оскільки користувачам і програмам потрібно чекати вікна шахрайства.

1. Переваги:

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

Довіряйте людям

1. Припущення чесності більшості: ці рішення покладаються на реалізацію кількох підписів, де кілька організацій перевіряють і підписують транзакції. Після досягнення мінімального порогу транзакція вважається дійсною. Тут припускається, що більшість суб’єктів є чесними, і якщо більшість із цих суб’єктів підписує певну транзакцію, вона є дійсною. Тут на карту поставлено лише репутацію учасників. Приклади: Multichain (Anycall V6), Wormhole. Експлойти через помилки смарт-контрактів все ще можливі, про що свідчить злом Wormhole на початку 2022 року.
2. Незалежність: ці рішення розділяють весь процес передачі повідомлень на дві частини та покладаються на різні незалежні об’єкти для керування цими двома процесами. Тут припускається, що дві організації незалежні одна від одної і не вступають у змову. Приклад: LayerZero. Заголовки блоків передаються на вимогу децентралізованими оракулами, а докази транзакцій надсилаються через ретранслятори. Якщо підтвердження збігається із заголовками, транзакція вважається дійсною. Хоча зіставлення доказів залежить від коду/математики, учасники повинні довіряти об’єктам, щоб вони залишалися незалежними. Програми, створені на базі LayerZero, мають можливість вибирати свій Oracle і Relayer (або розміщувати власний Oracle/Relayer), таким чином обмежуючи ризик змови окремих оракул/ретрансляторів. Кінцеві користувачі повинні бути впевнені, що LayerZero, третя сторона або сама програма запускають оракул і ретранслятор незалежно та без злих намірів.

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

Поза припущеннями довіри та майбутнім сумісності

Розглядаючи безпеку та зручність використання рішення AMP, ми також повинні враховувати деталі, окрім основних механізмів. Оскільки це рухомі частини, які можуть змінюватися з часом, ми не включили їх у загальне порівняння.

• Цілісність коду: у нещодавньому минулому багато хакерів спричинили помилки в коді, що потребує надійних аудитів, добре спланованих винагород за помилки та кількох клієнтських реалізацій. Якщо всі валідатори (в економічній/оптимістичній/репутаційній безпеці) запускають той самий клієнт (програмне забезпечення для перевірки), це збільшує залежність від однієї кодової бази та зменшує різноманітність клієнтів. Ethereum, наприклад, покладається на кілька клієнтів виконання, таких як geth, nethermind, erigon, besu, akula. Кілька реалізацій на різних мовах, ймовірно, збільшить різноманітність без домінування будь-якого клієнта в мережі, тим самим усуваючи потенційну єдину точку відмови. Наявність кількох клієнтів також може підвищити продуктивність, якщо меншість валідаторів/підписувачів/легких клієнтів вийде з ладу через експлойти/помилки в одній конкретній реалізації.
• Налаштування та можливість оновлення: користувачі та розробники повинні знати, чи можуть валідатори/спостерігачі приєднуватися до мережі без дозволу, інакше довіра прихована вибором дозволених об’єктів. Оновлення смарт-контрактів також може викликати помилки, які можуть призвести до експлойтів або навіть потенційно змінити припущення про довіру. Щоб зменшити ці ризики, можна застосувати різні рішення. Наприклад, у поточному екземплярі шлюзи Axelar можна оновлювати за умови схвалення офлайн-комісії (порогове значення 4/8), однак у найближчому майбутньому Axelar планує вимагати від усіх валідаторів колективного схвалення будь-яких оновлень шлюзів. Основні контракти Wormhole можна оновлювати та керувати ними через мережеву систему управління Wormhole. LayerZero покладається на незмінні смарт-контракти та незмінні бібліотеки, щоб уникнути будь-яких оновлень, однак він може надіслати нову бібліотеку, і прикладні програми з налаштуваннями за замовчуванням отримають оновлену версію, а прикладні програми з установленою вручну версією повинні будуть встановити нову. .
• MEV: Різні блокчейни не синхронізуються через загальний годинник і мають різний час до остаточного завершення. У результаті порядок і час виконання в цільовому ланцюжку можуть відрізнятися в різних ланцюгах. MEV у міжланцюжковому світі складно чітко визначити. Це вводить компроміс між живістю та порядком виконання. Упорядкований канал забезпечить упорядковану доставку повідомлень, але канал закриється, якщо одне повідомлення закінчиться. Інша програма може віддати перевагу сценарію, коли замовлення не потрібне, але це не впливає на доставку інших повідомлень.

Тенденції та перспективи на майбутнє:

• Настроювана та додаткова безпека: щоб краще обслуговувати різноманітні сценарії використання, рішення AMP заохочуються до більшої гнучкості для розробників. Axelar представив підхід до модернізації передачі та перевірки повідомлень без будь-яких змін у логіці прикладного рівня. HyperLane V2 представив модулі, які дозволяють розробникам вибирати з кількох варіантів, таких як економічна безпека, оптимістична безпека, динамічна безпека та гібридна безпека. CelerIM пропонує додаткову оптимістичну безпеку разом з економічною безпекою. Багато рішень чекають попередньо визначеної мінімальної кількості підтверджень блоків у вихідному ланцюжку перед передачею повідомлення. LayerZero дозволяє розробникам оновлювати ці параметри. Ми очікуємо, що деякі рішення AMP і надалі пропонуватимуть більшу гнучкість, але ці варіанти дизайну заслуговують на деяке обговорення. Чи повинні додатки мати можливість налаштовувати свою безпеку, якою мірою та що станеться, якщо додатки приймуть нестандартну архітектуру дизайну? Обізнаність користувачів щодо основних концепцій безпеки може ставати дедалі важливішою. Зрештою, ми передбачаємо агрегацію та абстракцію рішень AMP, можливо, у певній формі комбінації або «додаткової» безпеки.
• Зростання та зрілість механізмів «код довіри/математика»: в ідеальній кінцевій грі довіра до всіх міжланцюжкових повідомлень буде зведена до мінімуму завдяки використанню доказів нульового знання (ZK) для перевірки повідомлень і станів. Ми вже спостерігаємо цю зміну з появою таких проектів, як Polymer Labs і Succinct Labs. Multichain також нещодавно опублікував технічний документ про zkRouter для забезпечення сумісності через ZK-докази. Завдяки нещодавно анонсованій віртуальній машині Axelar розробники можуть використовувати Interchain Amplifier для встановлення нових підключень до мережі Axelar без дозволу. Наприклад, після розробки надійних легких клієнтів і ZK-доказів стану Ethereum розробник може легко інтегрувати їх у мережу Axelar, щоб замінити або покращити існуюче з’єднання. LayerZero у своїй документації говорить про можливість додавання нових оптимізованих бібліотек обміну повідомленнями в майбутньому. Новіші проекти, такі як Lagrange, досліджують агрегацію кількох доказів із кількох вихідних ланцюжків, а Геродот робить докази зберігання можливими за допомогою доказів ZK. Однак цей перехід займе час, оскільки цей підхід важко масштабувати серед блокчейнів, які покладаються на різні консенсусні механізми та фреймворки. ZK є відносно новою та складною технологією, яку важко перевірити, і наразі верифікація та створення доказів не є оптимальними з точки зору витрат. Ми вважаємо, що в довгостроковій перспективі для підтримки високомасштабованих міжланцюжкових додатків у блокчейні багато рішень AMP, ймовірно, доповнять довірених людей та організації програмним забезпеченням, яке можна перевірити, оскільки:
• Можливість використання коду може бути зведена до мінімуму за допомогою перевірок і винагород за помилки. З часом стане легше довіряти цим системам, оскільки їхня історія слугуватиме доказом їх безпеки.
• Зменшиться вартість генерації доказів ЗК. Завдяки більшій кількості досліджень і розробок у ZKP, рекурсивному ZK, агрегації доказів і спеціалізованому апаратному забезпеченні ми очікуємо, що час і вартість створення доказів і перевірки значно зменшаться, що зробить цей підхід більш економічно ефективним.
• Блокчейни стануть більш зручними для zk. У майбутньому zkEVM зможуть надати стислий доказ дійсності виконання, а легкі клієнтські рішення зможуть легко перевірити як виконання, так і консенсус вихідного ланцюжка в ланцюжку призначення. У кінцевій грі Ethereum також є плани «zk-SNARK все», включаючи консенсус.
• Доказ гуманності/репутації/ідентичності: безпека складних систем, як-от рішень AMP, не може бути інкапсульована в єдину структуру й вимагає кількох рівнів рішень. Наприклад, разом із економічними стимулами, Axelar запровадив квадратичне голосування , щоб запобігти концентрації прав голосу серед підмножини вузлів і сприяти децентралізації. Інші докази людяності, репутації та ідентичності також можуть доповнювати механізми налаштування та дозволу.

У дусі відкритості Web3 ми, ймовірно, побачимо множинне майбутнє, де співіснують численні підходи. Насправді, додатки можуть вибрати використання кількох рішень взаємодії, або у вигляді резервування, або дозволити користувачам змішувати та поєднувати з розкриттям компромісів. Рішення «точка-точка» можуть мати пріоритет між маршрутами з «високим трафіком», тоді як моделі концентраторів і спиць можуть домінувати в довгому хвості ланцюгів. Зрештою, це залежить від нас, колективу дем і користувачів, розробників і учасників, щоб сформувати топографію взаємопов’язаної мережі3.

Ми хотіли б подякувати Бо Ду та Пітеру Кіму з Polymer Labs, Галену Муру з Axelar Network, Умі Рой з Succinct Labs, Максу Глассману та Райану Заріку з LayerZero за перегляд і надання цінних відгуків.

Список літератури:

• Axelar: https://docs.axelar.dev/
• CelerIM: https://im-docs.celer.network/developer/celer-im-overview
• ChainLink CCIP: https://blog.chain.link/introducing-the-cross-chain-interoperability-protocol-ccip/
• дебридж: https://docs.debridge.finance/
• IBC: https://tutorials.cosmos.network/academy/3-ibc/
• LayerZero: https://layerzero.gitbook.io/docs/
• Multichain: https://docs.multichain.org/getting-started/introduction
• Nomad: https://docs.nomad.xyz/nomad-101/introduction
• Polymer Labs: https://polymerlabs.medium.com/
• Лабораторії Succinct: https://blog.succinct.xyz/
• Червоточина: https://docs.wormhole.com/wormhole/

Додатковий список для читання:

• Навігація довільними мостами обміну повідомленнями: система порівняння: https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• L2Bridge Risk Framework: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• Горацій на мосту: https://maven11.substack.com/p/horatius-at-the-bridge

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

1. Цю статтю передруковано з [середовище]. Усі авторські права належать оригінальному автору [LongHash Ventures]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.