Вступ

Що, якби ти щогодини втрачав пам'ять? І вам потрібно постійно когось просити розповісти, що ви зробили? Це поточний стан розумних контрактів. У таких блокчейнах, як Ethereum, смарт-контракти не можуть отримати прямий доступ до станів, що перевищують 256 блоків. Ця проблема ще більше загострюється в екосистемі з кількома ланцюжками, де пошук і перевірка даних на різних рівнях виконання ще складніше.

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

Доступ до даних у мережі

Є кілька способів, за допомогою яких прикладні програми можуть отримати доступ до даних і стану. Усі підходи вимагають, щоб програма довіряла людям/організаціям або криптоекономічній безпеці чи коду, і мали певні компроміси:

Довіра до людей/організацій:

• Архівні вузли: Оператори можуть запускати архівний вузол самостійно або покладатися на постачальників послуг архівних вузлів, таких як Alchemy або Infura, щоб отримати доступ до всіх даних, починаючи з блоку Genesis. Вони надають ті самі дані, що й повний вузол, але також усі історичні дані про стан усього блокчейну. Сервіси поза ланцюгом, такі як Etherscan і Dune Analytics, використовують вузли архіву для доступу до даних у ланцюзі. Учасники поза ланцюгом можуть підтвердити достовірність цих даних, а смарт-контракти в ланцюзі можуть підтвердити, що дані підписані довіреним учасником/комітетом. Цілісність базових даних не перевіряється. Цей підхід вимагає від dapp впевненості в тому, що постачальник послуг архівного вузла запускає інфраструктуру правильно та без будь-яких зловмисних намірів.

Економічна безпека Trust Crypto:

• Індексатори: протокол індексації організовує всі дані в Blockchain, дозволяючи розробникам створювати та публікувати відкриті API, які програми можуть запитувати. Індивідуальні індексатори — це оператори вузлів, які розміщують токени для надання послуг індексування та обробки запитів. Однак суперечки можуть виникнути, якщо надані дані є неправильними, а арбітражний процес може зайняти час. Крім того, дані з індексаторів, таких як The Graph, не можуть безпосередньо використовуватися бізнес-логікою смарт-контрактів і використовуються в аналітичному контексті даних на основі web2.
• Oracle: постачальники послуг Oracle використовують дані, зібрані від багатьох незалежних операторів вузлів. Проблема тут полягає в тому, що дані, доступні з Oracles, можуть не часто оновлюватися та мають обмежений обсяг. Такі оракули, як Chainlink, зазвичай підтримують лише певні стани, такі як канали цін, і для конкретних програмних станів та історії вони неможливі. Крім того, цей підхід також вводить певний рівень відхилень у даних і вимагає довіри до операторів вузлів.

Код довіри:

• Спеціальні змінні та функції: Блокчейни, такі як Ethereum, мають спеціальні змінні та функції, які в основному використовуються для надання інформації про блокчейн або є допоміжними функціями загального використання. Для смарт-контракту можливий лише доступ до хешу блоку 256 останніх блоків. Хеші блоків доступні не для всіх блоків з причин масштабованості. Було б корисно мати доступ до історичних хешів блоків, оскільки це могло б дозволити перевірити докази проти них. У виконанні EVM немає коду операції, який надає доступ до вмісту старого блоку або попереднього вмісту транзакцій або виходів квитанцій, тому вузол може безпечно забути ці речі та мати можливість обробляти нові блоки. Цей метод також обмежений одним блокчейном.

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

Зберігання даних в блокчейні

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

Візьмемо для прикладу блок Ethereum. Ethereum використовує певний тип дерева Merkle, відомий як «дерево Merkle Patricia» (MPT). Заголовки блоків Ethereum містять корені чотирьох різних спроб Merkle-Patricia, тобто Trie стану, Trie зберігання, Trie квитанцій і Trie транзакцій. Ці 4 спроби кодують відображення, які містять усі дані Ethereum. Дерева Merkle використовуються завдяки їх ефективності зберігання даних. Використовуючи рекурсивні хеші, зрештою потрібно зберігати лише кореневий хеш, що економить багато місця. Вони дозволяють будь-кому довести існування елемента в дереві, довівши, що рекурсивне хешування вузлів призводить до того самого кореневого хешу. Докази Merkle дозволяють легким клієнтам Ethereum отримати відповіді на такі запитання:

• Чи існує ця транзакція в певному блоці?
• Який поточний баланс мого рахунку?
• Цей обліковий запис існує?

Замість завантаження кожної транзакції та кожного блоку «легкий клієнт» може лише завантажити ланцюжок заголовків блоків і перевірити інформацію за допомогою Merkle Proofs. Це робить загальний процес високоефективним. Щоб краще зрозуміти реалізацію, переваги та проблеми, пов’язані з Merkle Trees, перегляньте цю статтю дослідження Віталіка та Maven11.

Докази зберігання

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

Що можуть забезпечити докази зберігання?

Докази зберігання дозволяють дві основні функції:

1. Отримайте доступ до історичних даних у ланцюжку за останні 256 блоків, аж до блоку генезису
2. Доступ до даних у ланцюжку (історичних і поточних) одного блокчейну в іншому блокчейні за допомогою перевірки консенсусу або мосту L1-L2 у випадку L2

Як функціонують докази зберігання?

Докази зберігання на дуже високому рівні перевіряють, чи є конкретний блок частиною канонічної історії блокчейну, а потім перевіряють, чи є певні запитувані дані частиною блоку. Цього можна досягти за допомогою:

• Обробка в ланцюжку: dapps можуть взяти початковий довірений блок, передати блок як дані виклику для доступу до попереднього блоку та пройти весь шлях назад до блоку генезису. Це вимагає великої кількості обчислень у ланцюжку та величезної кількості даних викликів. Цей підхід взагалі неможливий на практиці через величезну кількість обчислень, необхідних у ланцюжку. У 2018 році Aragon спробував застосувати підхід у ланцюзі, але це було неможливо через високу вартість у ланцюзі.
• Використання доказів ZK: підхід подібний до обробки в ланцюжку, за винятком того факту, що перевірка ZK використовується для переміщення складних обчислень поза ланцюгом.

1. Доступ до даних у тому самому ланцюжку: ZK-доказ можна використовувати, щоб підтвердити, що довільний історичний заголовок блоку є предком одного з 256 останніх заголовків блоку, доступних у середовищі виконання. Інший підхід полягає в індексації всієї історії вихідного ланцюжка та генеруванні ZK-підтвердження того самого, щоб довести, що індексування відбулося правильно. Це підтвердження регулярно оновлюється, оскільки нові блоки додаються до вихідного ланцюжка. Доступ до даних між ланцюжками: постачальник збирає заголовки блоків вихідного ланцюжка в ланцюжку призначення та підтверджує дійсність цих заголовків блоків за допомогою доказу консенсусу ZK. Також можна використовувати існуюче рішення AMP, як-от Axelar, Celer або LayerZero, щоб запитувати заголовки блоків.
2. Кеш хешів заголовків блоків вихідного ланцюжка або кореневий хеш накопичувача хешів блоків поза ланцюгом зберігається в ланцюжку призначення. Цей кеш оновлюється на регулярній основі та використовується для ефективного підтвердження в ланцюжку того, що певний блок існує та має криптографічний зв’язок із нещодавнім хешем блоку, доступним із стану. Цей процес відомий як підтвердження безперервності ланцюга. Також можна використовувати спеціальний блокчейн для зберігання заголовків блоків усіх вихідних ланцюжків.
3. Доступ до історичних даних/блоку здійснюється з індексованих даних поза ланцюжком або кешу в ланцюжку (залежно від складності запиту) за запитом dapp у ланцюжку призначення. Хоча кеш хешу заголовків блоків підтримується в ланцюжку, фактичні дані можуть зберігатися поза ланцюгом.
4. Існування даних у вказаному блоці перевіряється за допомогою доказів включення Merkle, і для них генерується доказ zk. Це підтвердження поєднується з підтвердженням zk правильного індексування або підтвердженням консенсусу ZK, і підтвердження стає доступним у ланцюжку для надійної перевірки.
5. Потім dapps можуть перевірити це підтвердження в ланцюжку та використовувати дані для виконання бажаної дії. Разом із перевіркою доказу ZK публічні параметри, такі як номер блоку та хеш блоку, перевіряються на кеш-пам’ять заголовків блоків, які зберігаються в ланцюжку.

Деякі з проектів, які використовують цей підхід, включають Herodotus, Lagrange, Axiom, Hyper Oracle, Brevis Network і nil Foundation. Незважаючи на те, що докладаються значні зусилля, щоб зробити додатки свідомими стану в кількох блокчейнах, IBC (Inter Blockchain Communication) виділяється як стандарт сумісності, який дає змогу таким програмам, як ICQ (міжланцюгові запити) та ICA (міжланцюгові облікові записи). ICQ дозволяє програмам у ланцюзі A запитувати стан ланцюга B, включаючи запит у простий пакет IBC, а ICA дозволяє одному блокчейну безпечно контролювати обліковий запис в іншому блокчейні. Їх поєднання може створити цікаві варіанти використання між ланцюгами. Постачальники RaaS, такі як Saga, за умовчанням пропонують ці функції для всіх своїх мереж додатків за допомогою IBC.

Існує багато способів оптимізації доказів зберігання, щоб знайти правильний баланс споживання пам’яті, часу перевірки, часу перевірки, ефективності обчислень і досвіду розробника. Загальний процес можна розділити на 3 основні підпроцеси.

• Доступ до даних
• Обробка даних
• Генерація ZK Proof для доступу та обробки даних

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

• Існуючий блокчейн Ethereum. Існуючу структуру блокчейну Ethereum можна використати для підтвердження цінності будь-якого історичного слота зберігання щодо поточного заголовка блоку за допомогою ZKP. Це можна розглядати як один великий доказ включення. Це доказ того, що, враховуючи останній заголовок блоку X на висоті b, існує заголовок блоку Y, який є предком X на висоті bk. Він заснований на безпеці консенсусу Ethereum і вимагає швидкої перевірки системи для ефективності. Саме такий підхід використовував Лагранж.
• Кеш гірських хребтів Меркле (MMR) у ланцюжку: Гірський хребет Меркла можна розглядати як список дерев Меркла, де окремі дерева Меркле об’єднуються, коли два дерева досягають однакового розміру. Окремі дерева Merkle у MMR поєднуються шляхом додавання батьківських вузлів до попередніх коренів дерев. MMR — це структура даних, подібна до дерев Merkle, з деякими додатковими перевагами, такими як ефективне додавання елементів і ефективні запити даних, особливо під час читання послідовних даних із великих наборів даних. Додавання нових заголовків через дерево Merkle вимагатиме передачі всіх сестринських вузлів на кожному рівні. Для ефективного додавання даних Axiom використовує MMR для підтримки кешу хешу заголовків блоків у ланцюжку. Геродот зберігає кореневий хеш накопичувача хешу блоків MMR у ланцюжку. Це дозволяє їм перевіряти отримані дані на ці хеші заголовків блоків за допомогою доказів включення. Такий підхід вимагає регулярного оновлення кешу та створює проблеми з живучістю, якщо не децентралізовано.
• Геродот підтримує два різних MMR. Залежно від конкретного блокчейну або рівня накопичувачі можуть бути адаптовані для використання різних функцій хешування, оптимізуючи ефективність і витрати на обчислення. Для підтвердження на Starknet можна використовувати хеш poseidon, але хеш Keccack можна використовувати для ланцюжків EVM.
• Кеш-пам’ять MMR поза ланцюгом: Геродот підтримує кеш-пам’ять попередньо отриманих запитів і результатів, щоб пришвидшити отримання даних у разі повторного запиту даних. Для цього потрібна додаткова інфраструктура, ніж просто запуск архівного вузла. Оптимізація позамережевої інфраструктури може потенційно знизити витрати для кінцевого користувача.
• Виділений блокчейн для зберігання: Brevis покладається на спеціальний зведений ZK (рівень агрегації) для зберігання всіх заголовків блоків усіх ланцюжків, які вони засвідчують. Без цього рівня агрегації кожному ланцюжку потрібно було б зберігати заголовки блоків для кожного іншого ланцюжка, що призведе до O(N2) «з’єднань» для N блокчейнів. Завдяки введенню рівня агрегації кожному блокчейну потрібно лише зберігати корінь стану для зведення, зменшуючи загальні з’єднання до O(N). Цей рівень також використовується для агрегування кількох доказів для заголовків блоків/результатів запиту, і можна надіслати єдине доказ для перевірки в кожному підключеному блокчейні.
• Передача повідомлень L1-L2: можна уникнути перевірки консенсусу вихідного ланцюга у випадку L2, оскільки L2 підтримують власний обмін повідомленнями для оновлення контрактів L2 на L1. Кеш можна оновлювати в Ethereum, а передачу повідомлень L1-L2 можна використовувати для надсилання хешу блоку або кореня дерева, скомпільованого поза ланцюгом, іншим L2. Геродот приймає цей підхід, але це неможливо для alt L1.

Обробка даних:

Разом із доступом до даних смарт-контракти також повинні мати можливість виконувати довільні обчислення поверх даних. Хоча деякі випадки використання можуть не вимагати обчислень, це важлива додаткова послуга для багатьох інших випадків використання. Багато постачальників послуг дозволяють обчислювати дані, оскільки zk-доказ обчислень може бути згенерований і наданий у ланцюжку для перевірки. Оскільки існуючі AMP-рішення, як-от Axelar, LayerZero, Polyhedra Network, потенційно можуть використовуватися для доступу до даних, обробка даних може стати відмінною рисою для постачальників послуг із збереженням даних.

Наприклад, Hyper Oracle дозволяє розробникам визначати спеціальні обчислення поза мережею за допомогою JavaScript. Brevis розробив відкритий ринок ZK Query Engines, який приймає запити даних від dApps і обробляє їх за допомогою атестованих заголовків блоків. Смарт-контракт надсилає запит на дані, які збирає перевірка з торгової площадки. Програма перевірки генерує доказ на основі вхідних даних запиту, відповідних заголовків блоків (із рівня агрегації Brevis) і результатів. Lagrange представив ZK Big Data Stack, щоб підтвердити моделі розподіленого програмування, такі як SQL, MapReduce і Spark/RDD. Докази є модульними і можуть бути згенеровані з будь-якого заголовка блоку, що походить від існуючих перехресних мостів і протоколів AMP. ZK MapReduce, перший продукт у стеку Lagrange ZK BigData, є механізмом розподілених обчислень (на основі добре відомої моделі програмування MapReduce) для підтвердження результатів обчислень із залученням значних наборів багатоланцюжкових даних. Наприклад, одне підтвердження ZKMR може бути використане для підтвердження змін у ліквідності DEX, розгорнутого на 4–5 ланцюжках протягом певного часового вікна. Для відносно простих запитів обчислення також можна виконувати безпосередньо в ланцюжку, як це робив Геродот на даний момент.

Генерація доказів:

• Оновлювані докази: оновлювані докази можна використовувати, коли доказ потрібно обчислити та ефективно підтримувати в рухомому потоці блоків. Коли прикладна програма бажає підтримувати доказ ковзного середнього для змінної контракту (наприклад, ціни токена), у міру створення нових блоків без повторного обчислення нового доказу з нуля існуючі докази можна ефективно оновити. Щоб підтвердити динамічне паралельне обчислення даних у стані on-chain, Лагранж створює зобов’язання пакетного вектора, яке називається Recproof, на основі частини MPT, оновлює його на льоту та динамічно обчислює над ним. Рекурсивно створюючи дерево Verkle поверх MPT, Lagrange здатний ефективно обчислювати великі обсяги динамічних даних стану в ланцюжку.
• Дерева Verkle: на відміну від дерев Merkle, де нам потрібно надати всі вузли, які мають спільний батьківський елемент, дерева Verkle потребують лише шляху до кореня. Цей шлях набагато менший порівняно з усіма сестринськими вузлами у випадку дерева Меркла. Ethereum також вивчає можливість використання дерев Verkle у майбутніх випусках, щоб мінімізувати кількість стану, який повинні зберігати повні вузли Ethereum. Brevis використовує Verkle Tree для зберігання підтверджених заголовків блоків і результатів запитів на рівні агрегації. Це значно зменшує розмір підтвердження включення даних, особливо коли дерево містить велику кількість елементів, а також підтримує ефективне підтвердження включення для пакета даних.
• Моніторинг Mempool для швидшої генерації доказів: Геродот нещодавно анонсував турбо, яке дозволяє розробникам додавати кілька рядків коду до свого коду смарт-контракту, щоб указати запит даних. Геродот стежить за транзакціями смарт-контрактів у mempool, які взаємодіють із турбоконтрактами. Процес створення доказів починається, коли транзакція знаходиться в самому мемпулі. Після того, як підтвердження буде згенеровано та перевірено в ланцюжку, результати записані в контракт на турбо-своп у ланцюзі. Результати можна записати до контракту турбо-свопу лише після того, як вони підтверджені доказами зберігання. Щойно це станеться, частина комісії за транзакцію розподіляється з секвенсором або розробником блоків, що спонукає їх чекати ще трохи, щоб отримати комісію. Для простих запитів даних можливо, що запитувані дані стають доступними в ланцюжку до того, як транзакція від користувача буде включена в блок.

Застосування доказів стану/зберігання

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

Рівень програми:

Управління:

• Голосування між ланцюжками: протокол голосування в ланцюжку може дозволити користувачам у ланцюзі B довести право власності на активи в ланцюзі A. Користувачам не доведеться перемикати свої активи, щоб отримати право голосу в новому ланцюжку. Приклад: SnapshotX про Геродота
• Розповсюдження маркерів керування: програми можуть розповсюджувати більше маркерів керування активним користувачам або першим користувачам. Приклад: RetroPGF на Лагранжі

Ідентичність і репутація:

• Підтвердження права власності: користувач може надати підтвердження права власності на певні NFT, SBT або активи в ланцюжку A, що дозволяє йому виконувати певні дії в ланцюжку B. Наприклад, ланцюжок ігрових програм може вирішити запустити свою колекцію NFT на інший ланцюжок із наявною ліквідністю, наприклад Ethereum або будь-який L2. Це дозволить грі отримати доступ до ліквідності, яка існує в інших місцях, і поєднати утиліту NFT, фактично не вимагаючи з’єднання NFT.
• Підтвердження використання: користувачі можуть отримувати знижки або преміум-функції на основі їх використання платформи в минулому (доведіть, що обсяг торгівлі X на Uniswap)
• Підтвердження OG: користувач може підтвердити, що він/вона володіє активним обліковим записом, якому більше X днів
• Кредитний рейтинг у ланцюжку: багатоланцюгова платформа кредитних рейтингів може збирати дані з кількох облікових записів одного користувача для створення кредитного рейтингу

Усі наведені вище докази можна використовувати для надання користувачам персоналізованого досвіду. Dapps може пропонувати знижки або привілеї, щоб утримати досвідчених трейдерів або користувачів, і запропонувати спрощену роботу для користувачів-початківців.

Defi:

• Кредитування між ланцюжками: користувачі можуть заблокувати активи в ланцюжку A та взяти позику в ланцюжку B замість перемикання токенів
• Страхування в ланцюжку: збої можна визначити за допомогою доступу до історичних даних у ланцюжку, а страхування можна повністю врегулювати в ланцюжку.
• TWAP ціни активу в пулі: програма може обчислити та отримати середню ціну активу в пулі AMM за певний період часу. Приклад: Uniswap TWAP Oracle з Axiom
• Ціна опціону: протокол опціонів у ланцюжку може визначати ціну опціону, використовуючи волатильність активу за останні n блоків на децентралізованій біржі.

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

Проміжне ПЗ:

• Наміри: докази зберігання дозволять користувачам чіткіше та чіткіше висловлювати свої наміри. Хоча робота розв’язувачів полягає у виконанні необхідних кроків для виконання наміру користувача, користувач може більш чітко визначити умови на основі даних і параметрів у ланцюжку. Розв’язувачі також можуть довести достовірність даних у мережі, використаних для пошуку оптимального рішення.
• Абстракція облікового запису: користувачі можуть покладатися на дані, що надходять з інших мереж, використовуючи докази зберігання, щоб установлювати правила через абстракцію облікового запису. Приклад: кожен гаманець має одноразовий номер. Ми можемо довести, що рік тому одноразовий номер був певним числом, а зараз той самий. Це можна використати, щоб довести, що цей гаманець взагалі не використовувався, а доступ до гаманця можна делегувати іншому гаманцю.
• Автоматизація в ланцюжку: смарт-контракти можуть автоматизувати певні дії на основі попередньо визначених умов, які залежать від даних у ланцюжку. Автоматизовані програми повинні викликати розумні контракти через певні проміжки часу, щоб підтримувати оптимальний потік цін AMM або підтримувати протоколи кредитування в належному стані, уникаючи безнадійних боргів. Hyper Oracle забезпечує автоматизацію та доступ до даних у мережі.

Інфраструктура

• Ненадійний мережевий Oracle: децентралізовані мережі Oracle збирають відповіді від численних окремих вузлів Oracle у мережі Oracle. Oracle Networks може усунути цю надлишковість і використовувати криптографічний захист для даних у ланцюжку. Мережа Oracle може завантажувати дані з кількох ланцюжків (L1, L2 та alt L1) в один ланцюг і просто доводити існування, використовуючи докази зберігання в іншому місці. Рішення DeFi зі значною тягою також можуть працювати на спеціальному рішенні. Наприклад, Lido Finance, найбільший постачальник ставки ліквідності, об’єднався з Nil Foundation, щоб фінансувати розробку zkOracle. Рішення забезпечать безнадійний доступ до історичних даних у EVM і забезпечать 15 мільярдів доларів ліквідності Lido Finance Ethereum.
• Протоколи AMP. Існуючі рішення AMP можуть підвищити виразність своїх повідомлень завдяки партнерству з постачальниками послуг зберігання. Це підхід, запропонований Лагранжем у їхній статті Modular Thesis .

Висновок

Поінформованість дає змогу технологічним компаніям краще обслуговувати своїх клієнтів. Від ідентифікації користувача до купівельної поведінки та соціальних графіків, технологічні компанії використовують обізнаність, щоб розблокувати такі можливості, як точне націлювання, сегментація клієнтів і вірусний маркетинг. Традиційним технологічним компаніям потрібен чіткий дозвіл від користувачів, і вони повинні бути обережними під час керування даними користувачів. Однак усі дані користувача в блокчейнах без дозволу є загальнодоступними, без розкриття особи користувача. Розумні контракти повинні мати можливість використовувати загальнодоступні дані для кращого обслуговування користувачів. Розробка та впровадження більш спеціалізованих екосистем зробить обізнаність держави з часом, а блокчейни стануть все більш важливою проблемою, яку потрібно вирішити. Докази зберігання можуть дозволити Ethereum стати рівнем ідентифікації та власності на активи, а також бути рівнем розрахунків. Користувачі могли підтримувати свою особу та ключові активи в Ethereum, які можна було використовувати в кількох блокчейнах без постійного з’єднання активів. Ми продовжуємо радіти новим можливостям і сценаріям використання, які відкриються в майбутньому.

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

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