На межах зашифрованих пулів пам'яті

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

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

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

На жаль, з практичних та теоретичних причин ми не вважаємо, що зашифровані пул пам'яті можуть забезпечити універсальне рішення для MEV. Ми окреслюємо труднощі та досліджуємо, як можуть бути спроектовані зашифровані пул пам'яті.

Як працюють зашифровані пул пам'яті

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

1. Користувачі транслюють свої зашифровані транзакції.
2. Шифровані транзакції фіксуються в ланцюзі (в деяких пропозиціях після того, якдоказово перемішані випадковим чином)
3. Після того, як підтверджений блок буде фіналізовано, транзакції розшифровуються.
4. Нарешті, транзакції виконуються.

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

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

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

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

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

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

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

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

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

Шифрування з затримкою та блокуванням часу: Альтернативою шифруванню з порогом є шифрування з затримкою. Користувачі шифрують свої транзакції за допомогою публічного ключа, секретний ключ якого захований у загадці з блокуванням часу. Загадка з блокуванням часу – це криптографічна загадка, яка інкапсульовує секрет, який можна розкрити лише після того, як мине певний заздалегідь визначений проміжок часу – більш конкретно, загадку можна розшифрувати, повторно виконуючи деякі непаралелізовані обчислення. У цьому випадку цю загадку може відкрити будь-хто, щоб відновити ключ та розшифрувати транзакції, але лише після повільного (власне послідовного) обчислення, яке спроектовано так, щоб тривати достатньо довго, щоб транзакції не можна було розшифрувати до їх фіналізації. Найсильніша версія цього примітиву використовує затримка шифруваннящоб публічно створити таку головоломку. Її також можна наблизити, використовуючи довірену комісію для обчислення головоломки за допомогою шифрування з часовими блокуваннями, хоча в той момент переваги над пороговим шифруванням ставляться під сумнів.

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

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

SNARKs також можливі для будь-яких NP-відношень. Можна уявити собі шифрування свідків як шифрування даних для будь-кого, хто може обчислити SNARK, що доводить бажану умову. Для зашифрованих пулів пам'яті одним із прикладів такої умови було б те, що транзакції можуть бути розшифровані тільки тоді, коли блок був завершено.

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

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

Технічні виклики для зашифрованих пулів пам'яті

Декілька важливих практичних викликів обмежують здатність зашифрованих пулів пам'яті запобігати MEV. Загалом, збереження інформації в таємниці є складним завданням. Цікаво, що шифрування - це інструмент, який рідко використовується у веб3-просторі. Але у нас є десятиліття практичного досвіду, які демонструють виклики впровадження шифрування в Інтернеті (TLS/HTTPS) та для приватного спілкування (від PGP до сучасних зашифрованих месенджерів, таких як Signal або Whatsapp). Хоча шифрування є інструментом для збереження конфіденційності, воно не гарантує її.

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

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

Ми можемо розглянути кілька типів метаданих, деякі з яких є класичними викликами з шифруванням, а деякі є унікальними для зашифрованих пулів пам'яті.

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

• Час трансляції: Шифрування також не приховує інформацію про час (іншекласичний вектор атаки). У контексті web3 певні відправники — наприклад, у структурованому продажу — можуть виконувати транзакції через певні інтервали. Час виконання транзакцій також може бути корельований з іншою інформацією, такою як активність на зовнішніх біржах або новинні події. Більш тонкий спосіб використання інформації про час — це арбітраж CEX/DEX. Секвенсор може отримати вигоду, вставляючи транзакцію, створену якомога пізніше, використовуючи більш актуальну інформацію про ціни CEX. Той же секвенсор може виключити будь-які інші транзакції (навіть якщо вони зашифровані), що транслюються після певного моменту часу, забезпечуючи, що його транзакція є єдиною, яка має перевагу найсвіжішої інформації про ціни.

• IP-адреса-вихід: Шукаючі можуть вивести ідентичність відправника транзакції, спостерігаючи за мережою рівноправних учасників та спостерігаючи за IP-адресою-вихід. Ця проблема насправді булавизначено понад десять років тому на ранніх етапах Bitcoin. Це може бути корисно для шукачів, якщо у конкретних відправників є специфічні патерни — наприклад, знання відправника може дозволити зв'язати зашифровану транзакцію з попередніми транзакціями, які вже були розшифровані.

• Інформація про відправника транзакції та комісії/газ: Нарешті, комісії за транзакції є типом метаданих, специфічним для зашифрованих пулів пам'яті. У Ethereum транзакції класично включають (ончен) адресу відправника, яка використовується для сплати комісій, а також максимальний бюджет газу та комісію за одиницю газу, яку відправник готовий сплатити. Адреса відправника, як і адреса мережі-джерела, може бути використана для зв'язування транзакцій разом і з реальними суб'єктами. Бюджет газу може бути використаний для оцінки того, що транзакція має намір зробити. Наприклад, взаємодія з конкретним DEX може вимагати певну кількість газу, яка підлягає ідентифікації.

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

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

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

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

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

Багато з проблем зашифрованих пулів пам'яті спільні для блокчейнів, які самі прагнуть забезпечити конфіденційність транзакцій (наприклад, Zcash, Monero). Якщо є хоч якась позитивна сторона, то це те, що вирішення всіх викликів шифрування для зменшення MEV в свою чергу відкриє шлях для конфіденційності транзакцій.

Економічні виклики для зашифрованих пулів пам'яті

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

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

Не важко уявити, як це виглядатиме, оскільки версія цього, під назвою MEV Share, існує сьогодні. MEV Share — це аукціон потоку ордерів, який дозволяє користувачам вибірково подавати інформацію про свої транзакції до пулу, де шукачі змагаються за можливість використати можливість MEV, представлену транзакцією. Шукач з виграшною ставкою витягує MEV і повертає частину свого прибутку (тобто ставку або частину ставки) користувачу.

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

Інші можливі сценарії включають великі будівельники, які змушують користувачів розкривати свої транзакції (або деяку інформацію про них) з причин цензури. Стійкість до цензури є важливою та суперечливою темою в межах web3, але якщо великі пропоненти та/або будівельники мають юридичні зобов'язання забезпечувати список цензури (наприклад, шляхом OFAC), вони можуть відмовитися послідовно обробляти будь-які зашифровані транзакції. Технічно це питання може бути вирішене, якщо користувачі зможуть створити доказ нульового знання про те, що їх зашифрована транзакція відповідає списку цензури, але це також додасть витрат і складності. Навіть якщо ланцюг має сильний опір цензурі, де зашифровані транзакції гарантовано включаються, будівельники блоків все ще можуть надавати пріоритет транзакціям, які вони знають у відкритому вигляді, ставлячи їх на верхню частину блоку, а зашифровані транзакції - на нижню частину блоку. Отже, транзакції, які бажають певних гарантій виконання, можуть бути змушені розкривати свій вміст для будівельників в будь-якому випадку.

Інші виклики ефективності

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

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

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

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

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

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

Pranav Garimidi є науковим співробітником у a16z Crypto. Він проводить дослідження проблем у проектуванні механізмів та алгоритмічній теорії ігор у контексті блокчейн-систем. Він особливо зосереджений на тому, як стимули взаємодіють у всій блокчейн-структурі. До a16z Пранава навчався в Колумбійському університеті, де отримав ступінь у галузі комп'ютерних наук.

Йозеф Бонно є доцентом на кафедрі комп'ютерних наук Інституту Корана Нью-Йоркського університету та технічним радником a16z crypto. Його дослідження зосереджені на прикладній криптографії та безпеці блокчейну. Він викладав курси з криптовалюти в Університеті Мельбурна, NYU, Стенфорді та Принстоні, а також отримав ступінь кандидата наук з комп'ютерних наук в Університеті Кембриджу та ступені бакалавра/магістра в Стенфорді.

Ліоба Хаймбах є студентом четвертого року в аспірантурі під керівництвом проф. д-ра Рожера Ваттенхофера у Розподілені обчислення (Disco)група в ETH Zurich. Її дослідження зосереджені на блокчейн-протоколах з акцентом на децентралізовані фінанси (DeFi). Зокрема, вона зосереджується на забезпеченні доступної, децентралізованої, справедливої та ефективної блокчейн-екосистеми та DeFi. Вона була дослідницькою стажисткою у a16z crypto влітку 2024 року.

Висловлені тут думки є особистими думками цитованого персоналу AH Capital Management, L.L.C. (“a16z”) і не є думками a16z або його афілійованих осіб. Деяка інформація, що міститься тут, була отримана з третіх джерел, зокрема з портфельних компаній фондів, які управляються a16z. Хоча інформація взята з джерел, які вважаються надійними, a16z не перевіряв цю інформацію самостійно і не робить жодних заяв щодо поточної або тривалої точності інформації чи її доречності для конкретної ситуації. Крім того, цей контент може містити рекламу третьої сторони; a16z не переглядав таку рекламу і не підтримує жоден рекламний контент, що міститься в ній.

Цей контент надається виключно для інформаційних цілей і не повинен використовуватися як юридична, бізнесова, інвестиційна чи податкова порада. Вам слід проконсультуватися зі своїми радниками щодо цих питань. Посилання на будь-які цінні папери або цифрові активи є лише ілюстративними і не є інвестиційною рекомендацією чи пропозицією надати інвестиційні консультаційні послуги. Крім того, цей контент не адресовано і не призначений для використання інвесторами або потенційними інвесторами і не може використовуватися в жодних обставинах при ухваленні рішення про інвестування в будь-який фонд, що управляється a16z. (Пропозиція інвестувати в фонд a16z буде зроблена лише шляхом приватного розміщення меморандуму, угоди про підписку та інших відповідних документів будь-якого такого фонду і має бути прочитана в повному обсязі.) Будь-які інвестиції або компанії портфеля, що згадуються, на які посилаються або які описуються, не є представниками всіх інвестицій у засобах, що управляються a16z, і не може бути жодних гарантій, що інвестиції будуть прибутковими або що інші інвестиції, зроблені в майбутньому, матимуть подібні характеристики чи результати. Список інвестицій, зроблених фондами, що управляються Андреесеном Хоровіцом (за винятком інвестицій, для яких емітент не надав дозволу a16z на їх публічне розкриття, а також незаявлених інвестицій у публічно торговані цифрові активи), доступний за адресою https://a16z.com/investments/.

Вміст говорить лише на дату, вказану. Будь-які прогнози, оцінки, прогнози, цілі, перспективи та/або думки, висловлені в цих матеріалах, можуть змінюватися без попередження і можуть відрізнятися або бути протилежними думкам, висловленим іншими. Будь ласка, ознайомтеся з https://a16z.com/disclosures для додаткової важливої інформації.

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

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