SNARK Безопасность и производительность

SNARK (Краткий неинтерактивный аргумент знаний) — это криптографический инструмент, который открывает новые захватывающие возможности в проектировании систем, особенно в децентрализованных условиях. SNARK позволяют обрабатывать данные ненадежным организациям, которые затем могут доказать, что данные действительны и были обработаны правильно. Наивным способом доказать это была бы публикация данных, позволяющая любому желающему проверить их достоверность и напрямую обработать их. 

СНАРК достигает того же эффекта, но с меньшими затратами.s валидаторам. Например, при проверяемом объединении второго уровня (L2) служба объединения обрабатывает транзакции блокчейна. Сервис периодически публикует балансы счетов своих пользователей в блокчейне первого уровня. Каждый раз, когда он публикует обновление балансов, он добавляет подтверждение SNARK о том, что ему известна последовательность действительных транзакций, которые изменили старые балансы счетов на обновленные. Таким образом, валидаторам блокчейна не придется выполнять тяжелую работу по проверке достоверности транзакций (например, проверять цифровую подпись для каждой транзакции) или явно обрабатывать транзакции для расчета обновленных балансов.  

My предыдущей публикации сосредоточено на работе испытателей SNARK – основном определяющем факторе применимости SNARK. Хотя запуск средства доказательства SNARK может потребовать больших вычислительных ресурсов, поскольку создание доказательства для крупномасштабных вычислений может быть невозможным, проверка SNARK обычно намного дешевле, чем прямая проверка и обработка данных. Однако затраты на проверку SNARK значительно различаются. В этом посте раскрываются эти затраты и сравниваются свойства безопасности различных SNARK. 

В частности, я объясняю, что в практических SNARK с возможной постквантовой безопасностью (PQ-SNARK) существует значительное противоречие между затратами на безопасность и проверку. Более того, в некоторых случаях это противоречие в настоящее время разрешается в пользу затрат на проверку, а не безопасности.

Чтобы SNARK реализовали свой потенциал, развернутые системы должны быть безопасными, а пользователи должны быть уверены в их безопасности. Я завершаю пост, предлагая простые действия, которые сообщество Web3 может предпринять, чтобы обеспечить сохранение этих свойств в долгосрочной перспективе. 

Количественные меры безопасности 

SNARK безопасен, если с вычислительной точки зрения невозможно получить убедительное доказательство ложного утверждения. Например, в контексте накопительных пакетов L2 злоумышленник, желающий украсть мои средства, захочет доказать ложное утверждение вида: «Я знаю транзакцию с цифровой подписью, которая переводит все активы Джастина на мой собственный счет». 

Уровень безопасности SNARK измеряется объемом работы, которую необходимо проделать, чтобы найти убедительное доказательство ложного утверждения. Подобно другим криптографическим примитивам, таким как цифровые подписи, логарифм этого объема работы называется «битами безопасности». Например, 30 бит безопасности подразумевают, что 2³⁰ ≈ 1 миллиард «шагов работы» необходим для атаки на СНАРК. По своей сути это приблизительная мера реальной безопасности, поскольку понятие одного шага работы может варьироваться, а практические соображения, такие как требования к памяти или возможности параллелизма, не учитываются.

И качественные

Биты безопасности — это количественный мера безопасности СНАРК. СНАРК также различаются по своим качественный охранные свойства. 

Например, некоторые SNARK требуют церемонии доверенной установки для создания структурированного проверочного ключа. SNARK, которые вообще не требуют доверенной настройки, называются прозрачный. 

Чтобы непрозрачный SNARK был безопасным, обычно хотя бы один участник церемонии должен вести себя честно, то есть он создал, а затем выбросил «люк», который в сочетании с люками всех остальных участников облегчил бы процесс. найти убедительные «доказательства» СНАРК любого ложного утверждения. Доверенные установки не являетесь пробег с сотнями или тысячами участников, чтобы сделать это предположение как можно более мягким. 

СНАРК также различаются по своей восприимчивости к квантовым атакам. В частности, многие SNARK (например, Грот16, ПлонК, Marlin, Bulletproofs, Новая звезда) полагаются на предположение, что дискретные логарифмы трудно вычислить (а в некоторых случаях и на дополнительные предположения). Вычисление дискретных логарифмов — это то, что квантовые компьютеры смогут делать эффективно. Следовательно, эти SNARK не являются постквантовобезопасными (не-PQ). 

Хотя предпринимаются срочные усилия по переходу на постквантовый схемы шифрованияЭто в первую очередь обусловлено необходимостью сохранять в тайне зашифрованные сообщения на многие десятилетия вперед. Противник, который хранит перехваченное сообщение сегодня и ждет прибытия квантового компьютера, скажем, через пятьдесят лет, может использовать компьютер для расшифровки сообщения пятидесятилетней давности. Со СНАРКами ситуация совершенно иная. Использование SNARK без PQ сегодня не должно поставить под угрозу безопасность блокчейнов через пятьдесят лет, даже если к тому времени действительно появятся квантовые компьютеры. 

Полиномиальные обязательства

Все SNARK используют криптографический примитив, известный как полиномиальная схема обязательств, и этот компонент часто является узким местом производительности. (Подробнее см. мой предыдущей публикации.) Кроме того, прозрачность и правдоподобная постквантовая безопасность SNARK определяются исключительно используемой им полиномиальной схемой обязательств. 

Ярким примером является так называемый Полиномиальные обязательства KZG, которые используются ПлонК, Marlin, и многие другие. Обязательства КЗГ не являются ни прозрачными, ни постквантовыми. Другие схемы обязательств являются прозрачными, но не постквантовыми, в том числе Bulletproofs, Дайракси солнечник. 

Есть и другие схемы, одновременно прозрачные и правдоподобные постквантовые. К ним относятся ПТ, свет, Лигеро++, Торможениеи Orion. Все эти схемы основаны на кодах, исправляющих ошибки. Хеширование — единственный криптографический примитив, который они используют. Их также объединяет следующее свойство: затраты на проверку (измеряемые количеством оценок хэша и полевых операций) растут линейно с количеством бит безопасности.

Грубо говоря, одна «итерация» этих постквантовых полиномиальных обязательств обеспечивает лишь небольшое количество (скажем, 2–4) бит безопасности. Таким образом, протокол необходимо повторять много раз, чтобы «усилить» уровень безопасности, при этом затраты на проверку растут с каждым повторением. Таким образом, чтобы контролировать затраты на проверку в PQ-SNARK (и, следовательно, затраты на газ в приложениях блокчейна), разработчики протоколов заинтересованы в поддержании низкого уровня безопасности. 

С редким Исключения, это противоречие между конкретными затратами на безопасность и проверку не возникает в SNARK, не относящихся к PQ (как прозрачных, так и непрозрачных). Не-PQ-SNARK используют группы эллиптических кривых, в которых предполагается, что дискретные логарифмы трудно вычислить, а их уровни безопасности определяются используемой группой. Размер соответствующей группы эллиптических кривых и, следовательно, стоимость каждой групповой операции растут с желаемым уровнем безопасности. Однако номер элементов группы в доказательстве не зависят от выбора группы. 

В PQ-SNARK не только размер хеш-оценок растет линейно с желаемым уровнем безопасности, но и количество оценок, включенных в доказательство и выполняемых верификатором. 

Конкретные затраты на верификатор и безопасность развернутых SNARK

Конкретные затраты на верификаторы и уровни безопасности развернутых SNARK значительно различаются. Вот несколько наглядных примеров:

Стоимость верификатора 

My предыдущей публикации упомянул два примера конкретных затрат на проверку: ПлонК стоимость доказательств под 300,000 газ для проверки на Ethereum, а доказательства StarkWare стоят около 5 миллионов газа. Доказательства StarkWare прозрачны и правдоподобны постквантовые, а доказательства PlonK — нет. Однако, как подробно описано далее, доказательства StarkWare выполняются на гораздо более низком уровне безопасности, чем доказательства PlonK на Ethereum.

Бетонная безопасность

Единственная эллиптическая кривая с прекомпиляциями Ethereum называется altbn128, поэтому это кривая для всех SNARK, не относящихся к PQ, развернутых при использовании Ethereum, включая АцтекскийИ зксинкх. Первоначально считалось, что эта кривая — а, следовательно, и развернутые SNARK, которые ее используют — обеспечивают примерно 128 бит безопасности. Но из-за улучшенные атаки (точное время выполнения которого трудно определить), сейчас считается, что кривая обеспечивает уровень безопасности от 100 до 110 бит. 

Есть EIP под рассмотрение ввести прекомпиляции для различных кривых, которые, как все еще полагают, обеспечивают около 128 бит безопасности. Такие кривые уже использован в SNARK проектов, не связанных с Ethereum, включая ZCash, Algorand, Dfinity, Filecoin и Aleo. 

Напротив, согласно данным в цепочке, PQ-SNARK от StarkWare (в ее так называемой системе SHARP, сокращенно от SHARed Prover) настроены на 80-битную защиту. Этот уровень безопасности сохраняется при определенных предположениях о статистической достоверности FRI (о которых я расскажу позже в этом посте). 

Термин «80 бит безопасности» в этом контексте расплывчат, поэтому позвольте мне его растолковать. Грубо говоря, это означает, что злоумышленник может предоставить убедительное доказательство ложного утверждения, вычислив хеш-функцию 2.⁸⁰ раз (а именно KECCAK-256, хеш-функция, используемая Ethereum). Точнее, злоумышленник, готовый выполнить 2^k хэш-оценки могут дать убедительное доказательство с вероятностью примерно 2^к-80. Например, с 2⁷⁰ хэш-оценок можно найти «доказательство» ложного утверждения SNARK с вероятностью около 2^-10 = 1/1024 

Это понятие слабее, чем то, что означает термин «80 бит безопасности» в других контекстах. Например, устойчивая к коллизиям хэш-функция (CRHF), настроенная на 80-битную безопасность, будет выдавать 160-битные выходные данные. Если хеш-функция хорошо спроектирована, самой быстрой процедурой поиска коллизий будет Атака на день рождения, процедура грубой силы, которая может найти столкновение примерно с 2^160/2 = 2⁸⁰ хеш-оценки. Однако с 2^k хеш-оценок, атака Birthday обнаружит коллизию с вероятностью всего 2^2-160. 

Например, 2⁷⁰ хэш-оценки приведут к коллизии с вероятностью 2^-20  ≈ 1/1,000,000 1 1,000. Это намного меньше, чем вероятность 80/XNUMX того, что злоумышленник подделает доказательство PQ-SNARK, настроенное на XNUMX бит безопасности. 

Эта разница может радикально изменить привлекательность проведения атаки. Для иллюстрации представьте, что злоумышленник имеет бюджет в 100 тысяч долларов, на который можно купить 2⁷⁰ хеш-оценки. Предположим, что в случае успеха злоумышленник выплата составит 200 миллионов долларов. Ожидаемая стоимость атаки на PQ-SNARK, настроенную на 80-битную безопасность, составляет (1/1,000) * 200 миллионов долларов США, или 200 тысяч долларов США — удвоенная стоимость. Если бы вероятность успеха составляла всего 1/1,000,000 200 XNUMX, как в случае с CRHF, ожидаемая стоимость атаки составила бы всего XNUMX долларов. 

Два понятия «80 бит безопасности» также существенно различаются по своей устойчивости к независимым атакам. Например, предположим, что каждая из 1,000 независимых сторон атакует PQ-SNARK, выполняя 2⁷⁰ хеш-оценки. Поскольку каждый из них добивается успеха с вероятностью около 1/1,000, по крайней мере один из них вполне вероятен. Это было бы не так, если бы каждый из них добился успеха с вероятностью всего лишь 1/1,000,000 XNUMX XNUMX.

Ожидается, что хорошо спроектированные группы эллиптических кривых будут вести себя аналогично CRHF с атаками, похожими на дни рождения, такими как Ро-алгоритм Полларда будучи самым известным. Это означает, что в группе, предлагающей 128 бит безопасности, 2^k групповые операции должны давать решение задачи дискретного логарифма с вероятностью всего 2.^2-256, Например, 2⁷⁰ групповые операции найдут дискретный логарифм лишь с астрономически малой вероятностью 2^-116. Более того, каждая групповая операция выполняется медленнее, чем оценка CRHF. 

Сколько хэш-оценок возможно сегодня?

В январе 2020 года стоимость вычислений чуть меньше 2⁶⁴ Оценки SHA-1 с использованием графических процессоров были $45,000. Это ставит стоимость 2⁷⁰ Оценки SHA-1 для графических процессоров составляют несколько миллионов долларов (возможно, ниже после слияния Ethereum, поскольку переход от майнинга доказательства работы с доминированием графических процессоров, вероятно, снизит спрос на вычисления на графических процессорах, снизив их стоимость). 

Поскольку накопительные пакеты данных уже хранят сотни миллионов долларов в средствах пользователей, поиск убедительных доказательств ложного заявления может принести много миллионов долларов прибыли. Настройка PQ-SNARK с уровнем безопасности 80 бит при агрессивных предположениях оставляет менее 10 бит пространства для маневра между прибыльными атаками и предполагаемой безопасностью PQ-SNARK.

Еще один показатель: скорость хеширования сети Биткойн в настоящее время составляет около 2⁶⁴  хеш-оценок в секунду, то есть биткойн-майнеры в целом выполняют 2⁸⁰ Оценки SHA-256 каждые 18 часов. Конечно, эта ошеломляющая цифра обусловлена ​​огромными инвестициями в ASIC для добычи биткойнов. 

Предполагая шесть биткойн-блоков создается в час, и учитывая текущую награду за блок в размере 6.25 биткойнов за блок, эти 2⁸⁰ Оценки SHA-256 предположительно стоят менее 22,000 18 долларов США * 6 * 6.25 * 15 ≈ XNUMX миллионов долларов США. В противном случае майнинг биткойнов не был бы прибыльным при нынешних ценах. 

Предлагаемые действия для здоровой экосистемы

Весь смысл использования SNARK в объединениях заключается в достижении масштабируемости блокчейна без необходимости слепо доверять пользователям сервису объединения. Поскольку служба объединения написала смарт-контракт, который действует как верификатор SNARK, общественность должна иметь возможность проверить контракт и подтвердить, что он действительно проверяет доказательства SNARK соответствующих утверждений. Общественный контроль над смарт-контрактом также может потребоваться, чтобы гарантировать, что служба объединения не сможет подвергать цензуре своих собственных пользователей. Предлагаемые методы устойчивости к цензуре требуют наличия смарт-контракта накопительного пакета, позволяющего пользователям принудительно выводить свои средства, если служба накопительного пакета не может обработать их транзакции. 

Учитывая сложную природу этих протоколов, такая парадигма общественного контроля возлагает на экспертов определенную нагрузку, связанную с открытым и откровенным обсуждением безопасности развернутых контрактов. 

Но при использовании PQ-SNARK даже экспертам может быть сложно определить уровень безопасности развернутого протокола по той же причине, по которой безопасность и производительность верификатора находятся под напряжением для этих SNARK: уровень безопасности (и затраты на верификатор) зависят от внутренних параметров протокола. СНАРК. По крайней мере, для StarkWare. умные контракты, эти параметры, вызовd logBlowupFactor,proofOfWorkBits и n_Queries не указываются напрямую в коде смарт-контракта, а передаются в смарт-контракт как общедоступные данные. Насколько мне известно, самый простой способ определить эти параметры из информации в цепочке — это четырехэтапный процесс: 

1. просмотреть соответствующий смарт-контракт в обозревателе блоков, таком как Etherscan, 
2. нажмите на соответствующая транзакция «проверить доказательство», 
3. декодировать входные данные транзакции и
4. выяснить, как интерпретировать декодированные входные данные для изучения ключевых параметров SNARK, которые в совокупности определяют уровень безопасности. 

Этот последний шаг требует поиска соответствующего кода Solidity, реализующего транзакцию, что само по себе может оказаться сложной задачей. (Когда я готовил , переговоры этим летом Etherscan смог декодировать соответствующие входные данные для транзакций верификатора SHARP, как описано выше в шаге 2. Но, похоже, это уже не работает.)

Предложение 1: Проверка 

Имея это в виду, мое первое предложение сообществу web3 — значительно упростить проверку уровня безопасности развернутых постквантовых SNARK. Вероятно, это потребует улучшения инструментов для понимания данных в цепочке и повышения прозрачности самих проектов при раскрытии этих параметров. 

Предложение 2: Более строгие нормы

80 бит безопасности — это слишком мало, особенно слабая версия, в которой 2⁷⁰ хеш-оценок достаточно для успешной атаки с вероятностью около 1/1000 — тем более, учитывая долгую историю неожиданных атак на криптографические примитивы. Один из них, упомянутый выше, представляет собой лучшую атаку на удобные для спаривания эллиптические кривые, такие как altbn128. Более известный пример — SHA-1, который был стандартизирован на уровне 80 бит безопасности, но в конечном итоге было показано, что он обеспечивает только около 60 бит. Учитывая эту историю, разработчики PQ-SNARK должны оставить себе более 10 бит пространства для маневра при настройке уровня безопасности, особенно если анализ безопасности включает в себя сильные предположения о статистической безопасности относительно новых протоколов, таких как FRI.

Даже для PQ-SNARK соответствующий уровень безопасности всегда можно достичь, просто увеличив затраты на проверку. Например, увеличение безопасности верификатора SHARP с 80 до 128 бит (при предположениях о статистической достоверности FRI) увеличит затраты на газ примерно в два раза, с чуть более 5 миллионов до чуть более 10 миллионов. Если бы не домыслы по поводу FRI, стоимость газа увеличилась бы еще в два раза, превысив 20 миллионов. 

Мое следующее предложение заключается в том, что сообщество web3 должно разработать более строгие нормы в отношении соответствующих уровней безопасности для развернутых SNARK. Моя личная рекомендация — не менее 100 бит и не менее 128, если безопасность СНАРК основана на нестандартных предположениях. Я не первый, кто сделать такое предложение.

Здесь я готов отнести к «стандартному предположению» безусловную безопасность в случайная модель оракула, если случайный оракул в развернутом SNARK создается с помощью стандартной хэш-функции, такой как KECCAK-256. Модель случайного оракула — это идеализированная настройка, предназначенная для отслеживания поведения хорошо спроектированных криптографических хеш-функций. Его часто используют для анализа безопасности PQ-SNARK. 

Примером нестандартных предположений являются предположения (описанные ниже) относительно количественной обоснованности такого протокола, как FRI, либо в интерактивном режиме, либо в качестве неинтерактивного протокола в модели случайного оракула.

Разработчики SNARK внедряют множество интересных инноваций, некоторые из которых могут выйти за рамки возможного с точки зрения безопасности – например, используя дружественные к SNARK хеш-функции, которые не подвергались такому тщательному криптоанализу, как более стандартные хеш-функции. Я не призываю прекратить подобные усилия – вовсе нет. Но эти примитивы должны быть созданы на уровнях безопасности, которые превышают известные возможные атаки более чем на 10 бит. 

Объединения с использованием SNARK обычно описываются как наследующие безопасность своего L1. Но это сложно сделать, если они настроены на гораздо более низкие уровни безопасности, чем любые криптографические примитивы, используемые L1. Поскольку SNARKs становятся все более популярными, мы должны убедиться, что используем их способами, соответствующими тому, как мы о них говорим. Пока SNARK тщательно анализируются, правильно настраиваются и правильно реализуются, они так же безопасны, как и любой криптографический примитив, используемый сегодня. 

Отступление: еще более глубокое погружение в безопасность PQ-SNARK.

80 бит безопасности в PQ-SNARK от StarkWare учитываются следующим образом. Эти PQ-SNARK используют схему полиномиального обязательства, называемую ПТ, а верификатор SHARP от StarkWare, как предполагается, запускает FRI с 48-битной безопасностью. Грубо говоря, предполагается, что простая атака на надежность FRI оптимальна. В этой атаке мошеннический проверяющий, приложив небольшие усилия, генерирует «доказательство FRI», которое проходит случайно выбранные проверки проверяющего с вероятностью 2.^-48. 

StarkWare сочетает FRI с методом, называемым «шлифовка». Это требует от честного доказывающего предоставить 32-битное доказательство работы перед созданием доказательства FRI. Преимущество измельчения состоит в том, что оно резко увеличивает объем работы, необходимой проверяющему для выполнения простой атаки на FRI, упомянутой выше, примерно до 2³² хеш-оценки. 

Поскольку (в ожидании) 2⁴⁸ необходимы попытки простой атаки, прежде чем одна из них увенчается успехом, общий объем работы, которую должен проделать проверяющий, чтобы подделать доказательство FRI, составляет примерно 2⁴⁸ * 2³² = 2⁸⁰ хеш-оценки.

Наконец, давайте разберемся, как возникают 48 бит безопасности для FRI. Верификатор FRI выполняет «запросы» к зафиксированному полиному. Затраты на проверку FRI растут линейно с количеством запросов. Например, 36 запросов верификатора FRI примерно в 4 раза дороже, чем 9 запросов. Но больше запросов означает больше безопасности. Количество «битов безопасности на запрос» зависит от другого параметра FRI, называемого скоростью кода. 

В частности, FRI использует так называемый код скорости Рида-Соломона. r, Где r всегда является числом строго от 0 до 1. Затраты на доказывание FRI обратно пропорциональны r, поэтому скорость 1/16 приводит к тому, что прувер работает примерно в четыре раза медленнее и занимает больше места, чем скорость ¼. 

Верификатор SHARP использует FRI со скоростью кода 1/16 и 12 запросами верификатора.

StarkWare предполагает, что каждый запрос верификатора FRI добавляет журнал₂(1 /r) немного безопасности. Согласно этой гипотезе, 12 запросов верификатора дают 12 * log₂(16) = 48 бит безопасности.

Однако текущий анализ показывает лишь то, что каждый запрос верификатора добавляет немного меньше, чем журнал₂(1/r^1/2) биты безопасности. Таким образом, 12 запросов верификатора FRI дают менее 12 * log.₂(4) = 24 бита «доказуемой» безопасности. 

Предложение по смягчению противоречия между безопасностью и производительностью

Практические PQ-SNARK имеют затраты на верификатор, которые растут линейно с желаемым количеством бит безопасности. Одним из многообещающих методов смягчения этого противоречия является композиция SNARK, которую я описал в своем предыдущем посте как средство разрешения противоречия между затратами на проверяющее и проверяющее устройство, но оно также может способствовать обеспечению безопасности. 

Два примера 

Полигон Гермез составление PQ-SNARK с помощью PlonK. Идея состоит в том, что доказывающее устройство сначала генерирует доказательство PQ-SNARK π. Если PQ-SNARK настроен на быстрое средство проверки и адекватный уровень безопасности, тогда π будет большим. Таким образом, доказывающая не отправляет π проверяющему. Вместо этого он использует PlonK, чтобы доказать, что знает π. 

Это означает применение PlonK к схеме, которая принимает π в качестве входных данных и проверяет, примет ли верификатор PQ-SNARK π. Поскольку стоимость проверки PQ-SNARK является полилогарифмической, PlonK применяется к небольшой схеме, и, следовательно, средство проверки PlonK работает быстро. Поскольку доказательства PlonK небольшие и их проверка дешева, затраты на проверку невелики. 

К сожалению, использование PlonK разрушает прозрачность и постквантовую безопасность. Вместо этого можно рассмотреть возможность использования самого PQ-SNARK вместо PlonK для доказательства знания π (на самом деле PQ-SNARK, используемый Polygon, является самосоставным таким образом). 

В этом втором применении PQ-SNARK для доказательства знания π систему можно настроить для достижения адекватной безопасности с помощью доказательств разумного размера, например, выбрав очень небольшую скорость кода для использования в FRI. Ключевой момент заключается в том, что, хотя такая небольшая скорость кода плохо влияет на время проверки, второе применение PQ-SNARK применяется только к небольшой схеме, поэтому общее время проверки все равно должно быть небольшим.

Наше теоретическое понимание безопасности составных SNARK оставляет желать лучшего. Однако на них не известны атаки, которые были бы быстрее, чем атака на один из составляющих SNARK по отдельности. Например, при составлении PQ-SNARK с PlonK мы не знаем лучшей атаки, чем либо атаковать PQ-SNARK (т. е. найти доказательство PQ-SNARK π ложного утверждения), либо атаковать PlonK (т. е. найдите доказательство PlonK ложного утверждения «Я знаю доказательство PQ-SNARK π, которое верификатор принял бы».)

Такое составление SNARK становится все более популярным способом повышения производительности. Я надеюсь, что разработчики протоколов также используют его для повышения безопасности.

Джастин Талер является доцентом Джорджтаунского университета. Прежде чем присоединиться к Джорджтауну, он два года проработал научным сотрудником в Yahoo Labs в Нью-Йорке, а затем был научным сотрудником в Институт Саймонса по теории вычислений в Калифорнийском университете в Беркли. 

Монтажер: Тим Салливан @tim_org

Мнения, выраженные здесь, принадлежат отдельным цитируемым сотрудникам AH Capital Management, LLC («a16z») и не являются мнением a16z или ее аффилированных лиц. Определенная информация, содержащаяся здесь, была получена из сторонних источников, в том числе от портфельных компаний фондов, управляемых a16z. Хотя информация взята из источников, считающихся надежными, a16z не проводила независимую проверку такой информации и не делает никаких заявлений о неизменной точности информации или ее уместности в данной ситуации. Кроме того, этот контент может включать стороннюю рекламу; a16z не просматривал такие рекламные объявления и не поддерживает какой-либо рекламный контент, содержащийся в них.

Этот контент предоставляется только в информационных целях и не может рассматриваться как юридическая, деловая, инвестиционная или налоговая консультация. Вы должны проконсультироваться со своими советниками по этим вопросам. Ссылки на любые ценные бумаги или цифровые активы предназначены только для иллюстративных целей и не представляют собой инвестиционную рекомендацию или предложение предоставить консультационные услуги по инвестициям. Кроме того, этот контент не предназначен и не предназначен для использования какими-либо инвесторами или потенциальными инвесторами, и ни при каких обстоятельствах на него нельзя полагаться при принятии решения об инвестировании в какой-либо фонд, управляемый a16z. (Предложение инвестировать в фонд a16z будет сделано только в меморандуме о частном размещении, договоре о подписке и другой соответствующей документации любого такого фонда, и их следует читать полностью.) Любые инвестиции или портфельные компании, упомянутые, упомянутые или описанные не являются репрезентативными для всех инвестиций в транспортные средства, управляемые a16z, и нет никаких гарантий, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами, управляемыми Andreessen Horowitz (за исключением инвестиций, в отношении которых эмитент не предоставил разрешение на публичное раскрытие информации a16z, а также необъявленных инвестиций в публично торгуемые цифровые активы), доступен по адресу https://a16z.com/investments. /.

Диаграммы и графики, представленные в нем, предназначены исключительно для информационных целей, и на них не следует полагаться при принятии каких-либо инвестиционных решений. Прошлые показатели не свидетельствуют о будущих результатах. Содержание говорит только по состоянию на указанную дату. Любые прогнозы, оценки, прогнозы, цели, перспективы и/или мнения, выраженные в этих материалах, могут быть изменены без предварительного уведомления и могут отличаться или противоречить мнениям, выраженным другими. Пожалуйста, посетите https://a16z.com/disclosures для получения дополнительной важной информации.