Ключ до трансформації Ethereum: майбутнє рекурсивних доказів STARK на наступні десять років

Протягом наступних десяти років Ethereum повинен задовольнити три основні вимоги: безпеку після квантових обчислень, захист приватності та масштабованість.

Автор: _deanstef

Ethereum наближається до поворотного моменту.

Його перше десятиліття підтвердило гіпотезу: публічні блокчейни можуть масштабно підтримувати значущі застосунки. Смарт-контракти, DeFi, стейблкоїни, appchains та токенізація перетворили Ethereum з експериментальної децентралізованої обчислювальної платформи на розрахунковий шар зростаючої цифрової економіки.

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

Оскільки Ethereum стає ключовою інфраструктурою, він повинен бути зміцнений для майбутніх років, ставши надійною, безпечною та ефективною обчислювальною системою, що працює на (децентралізованому) масштабі. Зокрема, Ethereum повинен:

• Витримати загрози, які ще не існують, особливо криптографічно пов'язані квантові комп'ютери (CRQC).
• Мати достатній рівень приватності, щоб задовольнити вимоги реальної економічної діяльності до конфіденційності.
• Досягти масштабованості без відмови від нейтральності, відкритості та стійкості до цензури, які стали основою його успіху.

Місія Фонду Ethereum нещодавно уточнила це бачення через CROPS.

Ethereum повинен «перш за все зберігати стійкість до цензури, бути з відкритим кодом, забезпечувати приватність та безпеку».

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

Ethereum strawmap малює поступовий, багаторічний шлях еволюції до Lean Ethereum — концепції, що покладається на прості криптографічні докази, розширює мережу до 10K TPS та оновлює до постквантових примітивів, не відмовляючись від децентралізованого перероблення протоколу. Ця технологічна стек в значній мірі побудована навколо STARKs (Scalable Transparent Argument of Knowledge). STARK — це криптографічний доказ, заснований на хешах, який не потребує довіреної налаштування; варто зазначити, що його можна агрегувати, що дозволяє об'єднувати багато різних обчислень в один доказ.

На цьому шляху я бачу три основні стовпи досліджень:

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

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

Безпека після квантових обчислень

Перехід до постквантового (PQ) Ethereum повинен охопити кожен компонент існуючого протоколу, який підлягає квантовим атакам. Як підсумували дорожня карта Віталіка та нещодавня стаття про квантові ризики Nethermind, ці компоненти охоплюють ECDSA підписи, BLS консенсусні докази, KZG зобов'язання для blob, а також SNARK на основі пар для розрахунків на L1. Їх спільна риса полягає в складності задачі дискретного логарифму на еліптичних кривих, яку алгоритм Шора може вирішити за поліноміальний час на CRQC.

Альтернативні кандидати розподілені по спектру:

• Схеми підпису на основі решіток (наприклад, ML-DSA, Falcon) зберігають підпис відносно малим, але вартість верифікації на ланцюзі є високою, перевищуючи мільйон Gas, а їх теорія агрегації ще не зріла.
• Схеми підпису на основі хешу покладаються лише на безпеку основної хеш-функції, але за рахунок обсягу: розмір підпису досягає кількох кілобайт, а вартість верифікації сьогодні може сягати десятків тисяч Gas. Вони поділяються на станційні варіанти, такі як XMSS, які мають менший обсяг, але вимагають, щоб підписувач відстежував стан ключа; та безстанційні варіанти, такі як SPHINCS+, які мають більший обсяг, дорожчі для верифікації, але не потребують управління станом.
• Система доказів STARK базується на хеш-функціях у моделі випадкових оракулів. Вони є прозорими, природно постквантовими та не потребують довіреної налаштування. Їхня ціна — обсяг та вартість верифікації. Один STARK несе тисячі хешів Меркла, тому розмір кожного доказу досягає десятків до сотень кілобайт; а з використанням сучасних доказувачів, вартість верифікації на ланцюзі може досягати мільйонів Gas, що на порядок вище, ніж вартість Gas на основі парних SNARK.

В цілому, впровадження PQ примітивів на різних рівнях протоколу Ethereum стикається з основними викликами, пов'язаними з більшими підписами та доказами, дорожчою верифікацією та складнішими протоколами:

Консенсус

Розмір набору валідаторів Ethereum є динамічним, приблизно 1/32 валідаторів роблять підтвердження в кожному слоті. BLS агрегація стискає їх голоси на ланцюзі до всього 8 підписів по 96 байт, і саме ця агрегація робить можливим такий великий набір валідаторів. Однак перед CRQC приватний ключ валідатора може бути виведений з його публічного ключа, тому супротивник, який володіє публічним ключем валідатора, може підробити їхні докази та остаточно закріпити недійсний ланцюг. Природною постквантовою альтернативою є станційні хеш-схеми, такі як XMSS, оскільки валідатори можуть безпечно управляти своїм станом ключа під час підписання консенсусу. Однак XMSS не може агрегувати так, як BLS; при приблизно 1 мільйоні валідаторів кожен слот потребує окремого перенесення близько 31,000 PQ підписів. При розрахунку приблизно 3 кБ на підпис, обсяг даних на кожен слот становитиме близько 90 МБ, що на кілька порядків вище, ніж те, що може досягти сучасна агрегація. У сценарії остаточності в одному слоті ситуація буде ще гіршою. Щоб завершити кожен блок у своїх слотах, весь набір валідаторів повинен підтвердити в кожному слоті, що призведе до обсягу підписних даних до рівня ГБ.

Облікові записи

Облікові записи користувачів використовують ECDSA для автентифікації. Як тільки обліковий запис ініціює транзакцію, його публічний ключ стає видимим, тому CRQC може відновити приватний ключ, підписуючи транзакцію від імені власника, що дозволяє вільно витрачати кошти. Його заміна є неминучою, але зовнішні облікові записи (EOA) не можуть управляти станом підпису так, як валідатори, тому їм потрібні безстанційні схеми, що підвищить вартість верифікації підписів на виконавчому рівні. Наразі немає чітких переможців. Робота EF зосереджена на безстанційній хеш-схемі SPHINCS+, хоча схеми на основі решіток все ще розглядаються, що в значній мірі залежить від вартості верифікації. Вартість верифікації SPHINCS+ на EVM є високою, саме тому деякі роботи спрямовані на те, щоб зробити безстанційні схеми дешевшими: SPHINCS-minus є перевірювачем, що базується на keccak; а інші роботи обходять це, використовуючи абстракцію облікових записів для ротації одноразових ключів, що дозволяє кожному підпису використовувати набагато дешевшу одноразову схему.

Rollups

Rollup завершує транзакції, публікуючи докази дійсності на L1. Найдешевший спосіб верифікації сьогодні базується на парних SNARK: доказ займає лише кілька сотень байт, а вартість верифікації становить близько 200–500k Gas. CRQC зруйнує парні припущення, на яких вони базуються, тому зловмисник може підробити докази дійсності для стану переходу, який ніколи не відбувався, і L1 прийме це, остаточно закріпивши шахрайський стан rollup та його пов'язані зняття. Це також знищує багато трюків, на яких rollup покладається для підтримки низьких витрат, наприклад, упаковка великого STARK в маленький фінальний SNARK для завершення, оскільки ця зовнішня упаковка також базується на парних. Без цього rollup повинен безпосередньо верифікувати STARK на L1, що коштує мільйонів Gas, що на порядок вище, ніж SNARK. Збереження доступності верифікації STARK наразі є відкритим дослідницьким питанням.

Доступність даних

Ethereum blob використовує KZG зобов'язання, що є схемою поліноміальних зобов'язань, яка генерує 48-байтове зобов'язання для кожного 128 kB blob. KZG полегшує вибірку доступності даних, оскільки він забезпечує (i) постійний розмір відкриття, тому вартість верифікації кожного зразка низька, (ii) лінійність, що підтримує 2D вибірку, а також (iii) можливість виправлення, пошкоджене кодування може бути виправлено на основі того ж зобов'язання. На жаль, KZG також базується на парах, тому CRQC може підробити відкриття, видаючи недоступні дані за доступні. Альтернативи, безпечні для квантових обчислень, повинні походити з хешованих зобов'язань, питання полягає в тому, скільки гарантій KZG ще можна зберегти. Існуючі постквантові кандидати стикаються з різними компромісами в обчислювальній та мережевій ефективності, маючи більший розмір зобов'язання та зростаючі витрати на докази та верифікацію. FRIDA є прозорою DAS схемою на основі FRI, побудованою на 1D кодах Ріда–Соломона, вибірка яких тестує близькість до кодового слова. Її ціна — пропускна здатність: зразки KZG потребують лише постійного розміру відкриття, тоді як кожен зразок FRIDA супроводжується повним доказом близькості, тому кожен зразок є значно більшим. ZODA є ще однією альтернативою для 2D кодування, яка дозволяє кожному зразку рядка та стовпця самосертифікуватися та забезпечує точне зв'язування з даними, що зобов'язуються, але ця гарантія є зразковою та локальною (вона охоплює лише запитувані позиції), і вибірка вимагає завантаження цілого рядка та стовпця кодування. Третій підхід упаковує кодування в STARK. Його ідея полягає в тому, щоб у zkVM довести, що зобов'язані дані є дійсним кодом Ріда–Соломона. Таким чином, один доказ може точно сертифікувати все кодування — не близькість, а не зразок за зразком — і без довіреної налаштування. Ціна — пропускна здатність доказів. Дослідження EF щодо leanDA дизайну та бенчмаркінгу вимірювало цей підхід: на сучасному високопродуктивному ЦП, пропускна здатність становить близько 0.9 MiB/s, іноді досягаючи близько 1 MiB/s. Поточні дослідження спрямовані на те, щоб зробити його достатньо швидким.

Напрями досліджень

Подолання розриву в прийнятті PQ примітивів стане основним напрямком дослідницької роботи в найближчі роки. Ми можемо узагальнити відповідні дослідження в три міждисциплінарні напрямки:

Ефективність протоколу, у двох аспектах:

• Агегрована підписка PQ. Мета полягає в тому, щоб об'єднати багато великих підписів PQ в одне свідчення, щоб зберегти низькі витрати на ключових етапах протоколу (особливо в консенсусі). LeanVM від EF вже здатна агегрувати XMSS зі швидкістю приблизно 1480 підписів на секунду в свідчення менше 200 KiB, і ці свідчення можуть рекурсивно комбінуватися, тому підписи можуть агегруватися паралельно, а потім об'єднуватися. Відкритим питанням є: чи можна розробити протокол, який залишиться життєздатним на шляху до однозначної остаточності в один слот (тобто вся колекція валідаторів надає свідчення в кожному слоті) і за можливості в короткий час слоту; крім того, хто генерує ці свідчення та відповідні стимули.
• Верифікація транзакцій. Frames (EIP-8141) дозволяють рахункам нести свій власний код для авторизації транзакцій, виводячи верифікацію підписів з рівня протоколу в логіку, визначену користувачем. Верифікація більше не прив'язана до фіксованих підписів ECDSA, кожен рахунок може вибрати свою схему. Напрямок, який потрібно дослідити, - це те, як працює ця верифікація: чи відбувається це через попередньо скомпільовані функції, встановлені для кожної схеми, чи через постквантові, агреговані свідчення. Останнє досліджується в EIP-8288, який об'єднує підписові свідчення багатьох транзакцій в одне, навіть якщо кількість PQ транзакцій зростає, це дозволяє зберігати розмір свідчення в кожному блоці та пропускну здатність mempool стабільними.

Криптографічна ефективність. Зменшення розміру та витрат на верифікацію PQ підписів; наприклад, вартість верифікації SPHINCS-minus на EVM становить близько 94k Gas. В ідеалі дослідницька спільнота повинна розробити підписи, дружні до zk, щоб їх можна було ефективно доводити в zkVM (EF працює над leanSPHINCS у цьому напрямку).

Інфраструктура свідчень. Вартість свідчень PQ-операцій в основному визначається базовими хеш-операціями. Стандартні хеш-функції (наприклад, Keccak, SHA) є не рідними операціями, їх потрібно арифметизувати, що призводить до обчислювальних витрат. Досліджуються два шляхи: хеші, дружні до SNARK, такі як Poseidon (швидкі, але з меншим практичним тестуванням), а також системи свідчень, які безпосередньо обробляють нерідні операції, так що стандартна криптографія може бути доведена без дорогого моделювання полів. Для останнього прогрес у дослідженнях швидкий, нещодавні роботи, такі як Zinc+ та модульні зобов'язання на цілих числах.

Постквантові примітиви вже існують, але їх обсяги даних більші, а витрати на верифікацію вищі. Дослідницька мета полягає в тому, щоб зробити їх практичними на поточному рівні протоколу. Наприклад, публікація дуже великих підписів у mempool призведе до вибухового зростання обсягу даних, які кожен клієнт повинен зберігати та перевіряти, а верифікація цих підписів вимагатиме більше Gas, що створює навантаження на користувачів і валідаторів. Ключова технологія зосереджена на свідченнях STARK, які можуть бути ефективно агреговані, зменшуючи витрати на дані та складність верифікації з O(n) до O(1). Клієнти більше не обробляють і не перевіряють n різних PQ підписів, а лише обробляють одне агреговане свідчення. І саме ці ж властивості відкривають можливості для масштабування, про що ми поговоримо далі.

Програмована конфіденційність

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

Споживчі пулі конфіденційності, такі як RAILGUN та Privacy Pools, забезпечують конфіденційність для звичайних гаманців; в той час як корпоративні платформи, такі як Paladin, забезпечують програмовану, готову до відповідності конфіденційність для організацій. Але наразі немає жодного рішення, яке б одночасно відповідало вимогам корпоративного рівня та було б так само зручним, як звичайний гаманець; і використання будь-якого з них все ще означає обробку оффлайн-стану (такого як Merkle-дерево, недійсні елементи та криптографічні ключі) і генерацію нульових знань для кожної операції. Найбільша простота Vitalik L1 конфіденційності та дорожня карта конфіденційності pcaversaccio добре підсумовують існуючі напрямки досліджень конфіденційності в Ethereum. Ці напрямки можна узагальнити в чотирьох вищих вимірах:

Доступність

Тут є дві проблеми. По-перше, створення конфіденційної транзакції повинно відчуватися так само, як відправка звичайної транзакції, але сьогодні це вимагає спеціально побудованої транзакції, відстеження оффлайн-стану та генерації нульових знань. По-друге, це повинно бути економічно вигідно, але конфіденційний переказ об'єднує SNARK, тому він несе більше даних і вищі витрати на верифікацію, ніж публічний переказ, і як тільки постквантові підписи та свідчення будуть додані, ця різниця лише зросте. Стандартизовані рамки, такі як Kohaku та Paladin, які можуть приховати цю складність, починають вирішувати першу проблему, хоча обидва все ще на ранніх стадіях і активно розробляються. Ключ до другої проблеми полягає в агрегуванні свідчень (пропозиція EIP-8288), що є економічно вигідним способом об'єднання свідчень багатьох транзакцій в одне та розподілу витрат на верифікацію.

Без довіри та антицензурність

Сьогодні багато протоколів конфіденційності покладаються на релейерів (relayers), які представляють користувачів при подачі транзакцій, що є довіреним посередником, який може цензурувати, затримувати або анонімізувати. Усунення цієї залежності є метою. Транзакції Frame (EIP-8141) є першим кроком: вони розділяють «хто авторизує транзакцію» та «хто платить Gas, як виконується», тому платник може бути іншим, ніж підписувач, а витрати на конфіденційність більше не потребують рахунку, пов'язаного з особистістю, щоб потрапити в блокчейн. Два взаємодоповнюючі елементи заповнюють цю прогалину. Рандомні числа з ключами EIP-8250 забезпечують незалежну область випадкових чисел, тому конфіденційні операції одного й того ж відправника не конфліктують; нещодавні корені (EIP-8272) дозволяють транзакціям заявляти про Меркле корінь, на якому базується їхнє свідчення, тому свідчення залишаються дійсними в міру просування дерева. Вони разом забезпечують стабільну, внутрішню верифікацію для конфіденційних транзакцій, тому їхня дійсність не залежить від швидко змінюваного стану, і будь-хто може перевірити асинхронно. Щодо обов'язкового списку включення FOCIL (EIP-7805), включаючі (includers) можуть незалежно перевіряти дійсність транзакції та запитувати її включення, надаючи гарантії антицензурності, які не можуть бути надані методами, що покладаються на релейерів.

Витяг даних

Читання так само важко, як і запис. Приватний стан (технічно кажучи, це зашифровані нотатки, які використовуються протоколами конфіденційності) не позначає отримувача у відкритому вигляді, тому клієнт повинен сканувати та зберігати величезні обсяги даних, лише для того, щоб знайти отримані платежі; а кожен раз, коли запит до RPC, це розкриває, які дані його цікавлять, і, отже, розкриває, кому ці дані належать. Той же принцип без посередників також застосовується. Приватний пошук інформації (PIR) дозволить клієнтам читати з RPC без розкриття запиту, тоді як рішення для виявлення повідомлень без відомостей дозволять їм знаходити свої нотатки без сканування всього. Однак компроміси в ефективності та обмежена зрілість роблять впровадження цих рішень активною областю досліджень.

Конфіденційність на рівні протоколу

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

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

Консенсус сам по собі містить кілька проблем, і STARK допомагає з кожною з них.

Продуктивність

Генерація більших блоків без підвищення витрат на верифікацію. Як тільки верифікатори перевіряють доказ дійсності, а не повторно виконують блок, будівельники можуть публікувати дійсні докази, утримуючи при цьому основні дані, тому необхідно явно гарантувати доступність даних. Напрямок blocks-in-blobs упаковує транзакції в blob, верифікатори проводять вибірку доступності, а не завантажують повний обсяг; STARK пропозиції призначені для підтвердження того, що блоки виконуються правильно і кодуються вірно. Таким чином, витрати на верифікацію зростають разом з розширенням доказу, а не з розміром блоку.

Час слота

Скорочення інтервалів між блоками шляхом розділення доступного ланцюга та механізму остаточності. Невелика комісія, обрана випадковим чином, постійно генерує блоки на критичному шляху, як це показано в швидкому LMD-GHOST шарі з кількома сотнями верифікаторів та дизайні розділеного консенсусу; в той час як повний набір верифікаторів паралельно завершує остаточність поза критичним шляхом. Менша кількість верифікаторів на кожному етапі означає менше агрегацій STARK на гарячому шляху та коротший час слота.

Остаточність

Скорочення часу остаточності, який сьогодні становить близько шістнадцяти хвилин, наприклад, через одноразову остаточність, усуваючи один раунд голосування з критичного шляху.

Ці три пункти суперечать вимогам PQ. Як тільки докази (attestations) переходять на хешовані підписи, які не можуть агрегації, жодне з вищезазначених покращень стане надзвичайно важким для реалізації в межах розумного бюджету пропускної здатності.

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

Саме тут рекурсивний STARK стає основою протоколу. Об'єднання цих частин - агрегація виконання, докази blocks-in-blobs та агрегація постквантових доказів - є напрямком, в якому дослідження повинні рухатися далі.

* Третя вісь - це розширення шару даних, але це строго пов'язано з дослідженнями PQ DA.

Перспективи

Дорожня карта невизначена, дослідження ніколи не є лінійними. Але деякі залежності виглядають надійними.

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

Чи зможе агрегація STARK підтримувати Ethereum, залежить від кількох конкретних і все ще відкритих питань:

• Агрегація гетерогенних підписів. Доказувати та комбінувати різні PQ підписи в одній агрегації, наприклад, агрегація хешованих підписів та підписів на основі решітки в одному STARK. Рівень облікових записів не вибере єдине рішення, тому агрегація повинна бути незалежною від конкретного рішення.
• Ефективне доведення хешу. Витрати на доведення визначаються основним хешем, а вимоги до пропускної здатності все ще далекі від необхідного. Ця компроміс полягає в тому, що доведення перевірених хешів (таких як Keccak і SHA) на неоригінальних полях призводить до арифметичних витрат; в той час як zk-дружні хеші (такі як Poseidon2) мають низькі витрати на доведення, але піддаються меншій криптоаналізі.
• Міждоменна агрегація. Складання різних типів STARK в один рекурсивний доказ - від перевірки PQ підписів, приватних переказів до переходів стану rollup - дозволяє всьому стеку ділити одне й те саме доведення.
• Адаптація агрегації до консенсусу. Пряме зіткнення з часовими вимогами консенсусу: агрегація повного набору верифікаторів в межах одного слота, при цьому час слота постійно скорочується, і пошук оптимального балансу між розміром комісії, довжиною слота та остаточністю.
• Готовність протоколу. Забезпечення одночасної наявності інфраструктури, що підтримує ці агрегації, на рівні mempool (наприклад, використовуючи Frame та EIP-8288) та на рівні консенсусу: на масштабі мільйона верифікаторів, кожен STARK доказ PQ підпису також повинен бути агрегований, як сьогоднішні BLS підписи.
• Виправлення стимулів. Агрегація лише переносить витрати, а не усуває їх: витрати на доведення концентруються на будівельниках блоків, що викликає реальні питання про стимули та централізацію.

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

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