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

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

Ми всі будуємо одне й те саме? Продовжуйте читати, щоб дізнатися.

ДякуюАвішай (SodaLabs) Лукас (Taceo), Майкл (Рівновага), іНіко (Arcium) за обговорення, які допомогли сформувати цей пост.

Що може бути, вільне від того, що було

Існуюча приватна інфраструктура в блокчейнах розроблена для обробки дуже конкретних використань, таких як приватні платежі або голосування. Це досить вузький погляд і в основному відображає те, для чого наразі використовуються блокчейни (торгівля, перекази та спекуляції). Як Том Валпо це сказав - Криптовалюта страждає від парадоксу Фермі:

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

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

Емпіричний аналіз (як з web2, так і з web3) показує, що більшість користувачів не готові доплачувати або перестрибувати через додаткові цикли для додаткової конфіденційності, і ми погоджуємося, що конфіденційність сама по собі не є перевагою для продажу. Тим не менш, це дозволяє новим і (сподіваюся) більш значущим варіантам використання існувати поверх блокчейнів, дозволяючи нам вирватися з парадоксу Фермі.

Технології покращення конфіденційності (PETs) та сучасні рішення криптографії («програмована криптографія“) є основними будівельними блоками для реалізації цієї візії (див додатокдля отримання додаткової інформації про різні доступні рішення та їх компроміси)

Три гіпотези, які формують наші погляди

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

1. Криптографія буде абстрагована від розробників програм: Більшість розробників програм не хочуть (або не знають, як) працювати з криптографією, необхідною для конфіденційності. Неприйнятно очікувати, що вони реалізують криптографію самостійно та будуватимуть приватні ланцюжки, специфічні для додатків (наприклад,ZcashабоNamada) або приватні застосунки на основі публічного ланцюжка (наприклад, Tornado Cash). Це просто занадто складно і вимагає занадто багато зусиль, що обмежує простір для дизайну для більшості розробників (не можуть створювати додатки, які потребують деяких гарантій конфіденційності). Тому ми вважаємо, що складність управління криптографією повинна бути абстрагована від розробників додатків. Два підходи тут - програмовна приватна інфраструктура (спільна приватна L1 / L2) або «конфіденційність як сервіс», який дозволяє використовувати конфіденційні обчислення в зовнішніх сервісах.
2. Багато випадків використання (ймовірно, більше, ніж ми думаємо) вимагають спільного приватного стану: Як згадувалося раніше, багато додатків вимагають деякого прихованого стану та/або логіки для належної роботи. Спільна приватна держава є підмножиною цього, де кілька сторін обчислюють один і той же шматок приватної держави. Хоча ми можемо довірити централізованій стороні, що вона зробить це за нас і призначить цей день, в ідеалі ми хочемо зробити це з мінімізацією довіри, щоб уникнути одиничних точок відмови. Докази з нульовим розголошенням (ZKP) самі по собі не можуть цього досягти - нам потрібно використовувати додаткові інструменти, такі як довірені середовища виконання (TEE), повністю гомоморфне шифрування (FHE) та/або багатосторонні обчислення (MPC).
3. Більші захищені набори максимізують конфіденційність: Більшість інформації розкривається, коли вхід або вихіднабір захищених даних, тому ми повинні намагатися його мінімізувати. Наявність кількох приватних додатків, побудованих на одному і тому ж блокчейні, може допомогти зміцнити гарантії конфіденційності, збільшуючи кількість користувачів та транзакцій в межах одного захищеного набору.

Кінцева гра інфраструктури конфіденційності

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

Не зовсім так. Усі вони мають різні компроміси, і ми вже бачимо, як вони поєднуються різними способами. Всього ми визначили 11 різних підходів (див. додаток).

Сьогодні два найпопулярніших підходи до побудови приватної інфраструктури в блокчейнах використовують або ZKPs, або FHE. Однак обидва мають фундаментальні недоліки:

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

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

Зверніть увагу, що, незважаючи на те, що ці два підходи в кінцевому рахунку збігаються, МРК використовується для різних цілей:

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

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

1. Які гарантії конфіденційності можуть надати MPC протоколи в блокчейні?
2. Чи достатньо зріла технологія? Якщо ні, які є технічні перешкоди?
3. З огляду на силу гарантій і накладні витрати, які вони вводять, чи має це сенс у порівнянні з альтернативними підходами?

Давайте докладніше розглянемо ці питання.

Аналіз ризиків та слабкостей за допомогою MPC

Коли рішення використовує FHE, завжди потрібно запитати: «Хто володіє ключем для дешифрування?». Якщо відповідь - «мережа», наступне питання: «Які реальні сутності становлять цю мережу?». Останнє питання має значення для всіх випадків використання, які ґрунтуються на MPC будь-якої форми або формату.

Джерело: Доповідь Зами на ETH CC

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

• Якій порог зловмисних сторін може витримати протокол?
• Які сторони складають мережу і наскільки вони надійні?
• Кількість різних сторін, які беруть участь в мережі та їх розподіл - Чи є які-небудь загальні вектори атаки?
• Чи мережа бездозвільна, чи з дозволу (економічна зацікавленість проти репутації/правової бази)?
• Яка кара за зловживання? Чи є злагодження грою теоретично оптимальним результатом?

1. Наскільки міцні гарантії конфіденційності можуть забезпечити MPC-протоколи в блокчейнах?

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

Поріг, необхідний для розшифрування, залежить від вибраної схеми MPC - це, в основному, компроміс між живучістю («гарантованою доставкою виводу») та безпекою. Ви можете мати схему N/N, яка є дуже безпечною, але зламується, якщо просто один вузол виходить з лінії. З іншого боку, схеми N/2 або N/3 більш стійкі, але мають вищий ризик змови.

Дві умови, які потрібно збалансувати:

1. Секретна інформація ніколи не витікає (наприклад, ключ розшифрування)
2. Секретна інформація ніколи не зникає (навіть якщо, скажімо, 1/3 сторін раптово відходять).

Обраний схема варіюється в різних реалізаціях. Наприклад, Zama націлюється на N/3, тоді як Arcium в даний час впроваджує Схема Н/Пале згодом планується також підтримка схем з вищими гарантіями активності (та більшими припущеннями довіри).

Одним із компромісів на цьому рубежі компромісу було б неоднозначне рішення:

• Високодовірний комітет, який вирішує ключові питання з N/3 порогом, наприклад.
• Обчислювальні комітети, які є ротаційними та мають, наприклад, поріг N-1 (або кілька різних обчислювальних комітетів з різними характеристиками, з яких користувачі можуть вибирати).

Хоча це привабливо в теорії, воно також вводить додаткову складність, таку як те, як комітет обчислень взаємодіятиме з високодовірчим комітетом.

Ще один спосіб посилити гарантії безпеки – запустити MPC на довіреному обладнанні, щоб ключові ресурси зберігалися в захищеному анклаві. Це ускладнює вилучення або використання спільних ресурсів ключів для чогось іншого, крім того, що визначено протоколом. Принаймні ZamaіArciumдосліджують аспекти TEE.

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

2. Технологія достатньо зріла? Якщо ні, то які є проблеми?

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

1. Набір малих операторів: Щоб забезпечити керованість накладними витратами на зв'язок, більшість існуючих протоколів наразі обмежені малими наборами операторів. Наприклад, мережа дешифрування Зама в даний час дозволяє використовувати максимум 4 вузли (хоча вони планують розширити до 16). Виходячи з початкових тестів, опублікованих Zama для своєї мережі дешифрування (TKMS), для розшифровки потрібно 0,5-1 секунди навіть з 4-вузловим кластером (повний потік e2e займає набагато більше часу). Іншим прикладом є Taceo Реалізація MPC для бази даних Worldcoin, яка має 3 сторони (з умовою 2/3 чесної сторони).

1. Джерело: Zama talk at ETH CC
2. Дозвільний набір операторів: у більшості випадків операторський набір має дозвіл. Це означає, що ми покладаємося на репутацію та юридичні контракти, а не на економічну чи криптографічну безпеку. Основна проблема з інклюзивним набором операторів полягає в тому, що немає способу дізнатися, чи вступають люди в змову поза мережею. Крім того, це вимагатиме регулярного початкового завантаження або перерозподілу спільної частки ключа, щоб вузли могли динамічно входити/виходити з мережі. Незважаючи на те, що кінцевою метою є інклюзивні набори операторів, і тривають дослідження щодо того, як розширити механізм PoS для порогового MPC (наприклад, Zama), дозволений маршрут здається найкращим шляхом на даний момент.

Альтернативні підходи

Повноцінний коктейль конфіденційності складається з:

• FHE для делегованого приватного обчислення
• ZKP для перевірки того, що обчислення FHE було виконано правильно
• MPC для порогового розшифрування
• Кожен вузол MPC працює в межах TEE для додаткової безпеки

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

Це варто? Можливо, але також варто розглянути альтернативні підходи, які можуть принести значно кращу обчислювальну ефективність за рахунок лише трохи слабших гарантій конфіденційності. Як Lyron з Seismicзазначено - ми повинні зосередитися на найпростішому рішенні, яке задовольняє наші критерії рівня конфіденційності та прийнятних компромісів, а не надто інженерити тільки ради цього.

1. Використання MPC безпосередньо для загальних обчислень

Якщо як ZK, так і FHE в кінцевому підсумку повертаються до довіри до припущень MPC, чому б не використовувати MPC для обчислення безпосередньо? Це дійсно важливе питання і щось, над чим працюють команди, такі як Arcium, SodaLabs(використовуєтьсяCoti v2), Taceo, і НілліонСлід зазначити, що MPC приймає багато форм, але з трьох основних підходів ми тут маємо на увазі протоколи на основі секретного розподілу та замаскованих схем (GC), а не протоколи на основі повного гомоморфного шифрування, які використовують MPC для розшифрування.

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

Існують деякі способи зменшення накладних витрат, наприклад, шляхом проведення попередньої обробки (тобто найбільш витратних частин протоколу) вперед та офлайн - щось обоєArciumіSodaLabsрозглядають. Обчислення потім виконується у режимі онлайн, в якому використовується частина даних, що були отримані на етапі офлайн. Це значно зменшує загальну комунікаційну навантаженість.

Таблиця нижче від SodaLabs показує початкові результати, щодо того, як довго займає виконання різних опкодів 1 000 разів у їх gcEVM (вказано у мікросекундах). Хоча це крок у правильному напрямку, але ще багато роботи залишається щодо покращення ефективності та розширення множини операторів поза декількома вузлами.

Джерело: SodaLabs

Перевага підходу на основі ZK полягає в тому, що ви використовуєте MPC лише для випадків, які вимагають обчислень над спільним приватним станом. FHE більше конкурує з MPC і сильно покладається на апаратне прискорення.

2. Довірені середовища виконання

Останнім часом знову зросло зацікавлення у TEE, які можуть використовуватися як в ізоляції (приватні блокчейни на основі TEE або співпроцесори), так і в поєднанні з іншими PET, такими як рішення на основі ZK (використовувати TEE лише для обчислення над спільним приватним станом).

Хоча TEE в деяких аспектах є більш витриманим і не вносить багато додаткових навантажень на продуктивність, він не без недоліків. По-перше, TEE має різні припущення щодо довіри (1/N) і пропонує апаратне рішення, а не програмне. Часто чути критику щодо минулого.вразливості SGX, але варто зауважити, що TEE ≠ Intel SGX. TEE також потребує довіри до постачальника апаратного забезпечення, а апаратне забезпечення є дорогим (недоступним для більшості). Одним рішенням для зменшення ризику фізичних атак може бути ...запускайте TEE в космосідля надзвичайно важливих справ.

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

3. Приватний DAC та інші підходи, що ґрунтуються на довірених третіх сторонах для конфіденційності

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

Комітети з доступності приватних даних (DAC) є одним із прикладів цього; Члени ЦАП зберігають дані поза мережею, і користувачі довіряють їм правильне зберігання даних і примусове оновлення переходу стану. Ще одним різновидом цього є Франшизний секвенсорзапропоновано Томом Валпо.

Хоча цей підхід робить великі компроміси в гарантіях конфіденційності, це може бути єдиною прийнятною альтернативою для додатків з низькою вартістю та високою продуктивністю з точки зору вартості та продуктивності (принаймні наразі). Наприклад,Протокол Lens, який планує використовувати приватний DAC для досягнення приватних каналів. Для використання випадків використання, таких як соціальна мережа на ланцюжку, компроміс між конфіденційністю та вартістю/продуктивністю, ймовірно, є розумним наразі (враховуючи вартість та накладні витрати альтернатив).

4. Приховані адреси

Stealth-адреси можуть забезпечувати подібні гарантії конфіденційності, як створення нової адреси для кожної транзакції, але процес автоматизований на бекенді та абстрагований від користувачів. Докладнішу інформацію дивіться огляд Віталіка або це глибоке занурення в різні підходи. Основні гравці в цьому полі включаютьУмбраіFluidkey.

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

Крім того, гарантії конфіденційності, які забезпечують адреси Stealth, не такі міцні, як альтернативи. Анонімність може бути порушена зпростий аналіз кластерів, особливо якщо вхідні та вихідні перекази не знаходяться в подібному діапазоні (наприклад, отримано $10,000, але в середньому витрачається $10-100 на щоденні операції). Ще одним викликом у використанні прихованих адрес є оновлення ключів, яке сьогодні потрібно робити окремо для кожного гаманця (згортання ключів може допомогти вирішити цю проблему). З точки зору UX протоколи прихованих адрес також потребують абстракції облікового запису або посередника для оплати комісій, якщо на рахунку немає токена оплати (наприклад, ETH).

Ризики для нашої тези

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

1. Спільна приватна держава не така важлива, як ми її уявляємо: у цьому випадку інфраструктура, заснована на ZK, має більше шансів на перемогу, оскільки вона має сильніші гарантії конфіденційності та нижчі накладні витрати, ніж FHE. Вже є випадки використання, коли системи на основі ZK добре працюють для ізольованих випадків використання, таких як протокол приватних платежів Payy.
2. Компроміс у продуктивності не вартий вигоди в гарантіях конфіденційності: можна стверджувати, що припущення про довіру мережі MPC з 2-3 дозволеними сторонами суттєво не відрізняються від одного централізованого гравця, і що значне збільшення витрат/накладних витрат не варте того. Це може бути справедливо для багатьох додатків, особливо малоцінних, чутливих до витрат (наприклад, соціальних або ігрових). Однак є також багато цінних випадків використання, коли співпраця наразі дуже дорога (або неможлива) через юридичні проблеми або великі тертя координації. Саме в останньому випадку можуть проявити себе рішення на основі MPC та FHE.
3. Спеціалізація виграє в порівнянні з універсальним дизайном: побудова нового ланцюжка та створення спільноти користувачів та розробників є складним завданням. Через це універсальна інфраструктура конфіденційності (L1/L2) може мати проблеми з отриманням популярності. Іншим питанням є спеціалізація; дуже важко створити протокол, який би охоплював усі можливі компроміси. У цьому світі переможуть рішення, які надають конфіденційність для існуючих екосистем (конфіденційність як сервіс) або спеціалізовані випадки використання (наприклад, для платежів). Проте ми сумніваємось в останньому через складність, яку воно вводить для розробників додатків, які повинні самостійно впроваджувати криптографію (замість того, щоб її абстрагувати).
4. Регулювання продовжує ускладнювати експерименти з рішеннями приватності: це ризик для будь-якого, хто будує як інфраструктуру приватності, так і застосунки з деякими гарантіями приватності. Нефінансові використання не стикаються з регуляторним ризиком, але важко (неможливо) контролювати, що будується на основі бездозвільної інфраструктури приватності. Ми можемо вирішити технічні проблеми, перш ніж регуляторні.
5. Накладні витрати на MPC і схеми на основі FHE залишаються занадто високими для більшості випадків використання: у той час як MPC страждає в основному від накладних витрат на зв'язок, команди FHE значною мірою покладаються на апаратне прискорення для підвищення своєї продуктивності. Однак, якщо ми зможемо екстраполювати еволюцію спеціалізованого обладнання на стороні ZK, це займе набагато більше часу, ніж більшість хотіла б, перш ніж ми отримаємо готове до виробництва обладнання FHE. Приклади команд, які працюють над апаратним прискоренням PHE, включають Optalysys, Фелаі Niobium.

Зведення

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

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

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

Навіть якщо у вас є найкращий молоток у світі, не все є цвяхом.

Додаток 1: Різні підходи до приватності в блокчейнах

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

Існує багато різних PET, з яких можна вибрати, але найбільш актуальними для галузі блокчейну є трилітерні супи - ZKP, MPC, FHE та TEE - разом з додатковими методами, такими як приховані адреси:

Ці PET можна поєднувати різними способами, щоб досягти різних компромісів та припущень про довіру. У нас також є рішення, які ґрунтуються на довіреній третій стороні (посередникова приватність), такі як комітети приватної доступності даних (DAC). Це може забезпечити конфіденційність від інших користувачів, але гарантії конфіденційності повністю ґрунтуються на довірі до третьої сторони. У цьому сенсі вона нагадує «web2 privacy» (конфіденційність від інших користувачів), але її можна посилити додатковими гарантіями (криптографічними або економічними).

Всього ми виявили 11 різних підходів до забезпечення певних гарантій конфіденційності в мережах блокчейн. Деякі з спостережених компромісів включають:

• Довір'я проти мінімізованого довіри до конфіденційності (чи є одна точка відмови?)
• Апаратний vs програмний підхід
• Окремі випадки проти комбінації кількох ПЗЕ
• L1 проти L2
• Конфіденційність нового ланцюга vs Add-on для існуючих ланцюгів ("конфіденційність як послуга")
• Розмір екранованого набору (Багатоланцюговий > Одноланцюговий > Застосування > Один актив)

Додаток 2: Огляд галузі

У межах цих 11 категорій багато різних компаній працюють над одним або кількома рішеннями. Нижче наведено (невичерпний) огляд поточного стану галузі:

Застереження:

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