Измерение производительности SNARK: интерфейсы, серверные части и будущее

SNARK (краткие неинтерактивные аргументы знаний) — это важный криптографический примитив, находящий приложения для масштабируемости блокчейна (например, свертки L2) и конфиденциальности. SNARK позволяет кому-то доказать недоверчивому верификатору V (например, блокчейн Ethereum), что им известны некоторые данные (например, пакет действительных транзакций). Наивным способом доказать это было бы отправить данные в V, который затем может напрямую проверить его достоверность. SNARK достигает того же, но с меньшими затратами. V. В частности, доказательство SNARK должно быть короче, чем наивное доказательство, содержащее сами данные. (Более подробно см. черновик моего учебника, Доказательства, аргументы и нулевое знание. Введение в SNARKs см. в статье Сары Мейклджон. presentation в криптовалюте a16z Серия летних исследований.)

Затраты на проверку SNARK могут варьироваться, но они хорошо понятны и часто неплохи. Например, ПлонК доказательства стоят около 290,000 газ для проверки на Ethereum, в то время как доказательства StarkWare стоят около 5 миллионов газа. SNARK потенциально применимы в различных условиях даже за пределами блокчейна — например, позволяя использовать быстрые, но ненадежные серверы и аппаратные средства. 

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

Но сначала: как развертываются SNARK

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

Как правило, IR представляет собой своего рода экземпляр выполнимости схемы, который эквивалентен ф. Это означает, что цепь C принимает на вход данные w, а также некоторые дополнительные входные данные, обычно называемые «недетерминированным советом», и запускает ψ on w. Советы используются, чтобы помочь C пробег ψ, сохраняя C маленький. Например, каждый раз ψ делит два числа x и y, частное q и остаток r можно дать как совет Cкачества C можно просто проверить это x = qy + r. Эта проверка дешевле, чем изготовление C запустить алгоритм деления для вычисления q и r с нуля.

Наконец, SNARK для выполнимости схемы применяется к C, Это называется Серверная часть SNARK. Для нескольких высокоструктурированных задач, таких как умножение матриц, извилиныкачества несколько задач с графами, существуют известные SNARK, которые избегают этой парадигмы внешнего интерфейса и внутреннего интерфейса и, таким образом, обеспечивают гораздо более быстрое доказательство. Но основное внимание в этом посте уделяется SNARK общего назначения.

Как мы увидим, затраты на прувер серверной части SNARK растут вместе с C«s размер. Хранение C small может быть сложной задачей, потому что схемы — чрезвычайно ограниченный формат для выражения вычислений. Они состоят из ворота, связано Провода. Каждые ворота g получает некоторые значения и применяет очень простая функция для этих значений. Затем результат подается в ворота «ниже по течению» через провода, идущие от g.

Масштабируемость SNARK: сколько времени это действительно занимает?

Ключевой вопрос заключается в том, насколько больше времени требуется испытателю SNARK по сравнению с простым повторным выполнением. ψ по данным? Ответ прувер над головой СНАРК по отношению к непосредственная проверка свидетелей. Последнее выражение относится к тому факту, что в наивном доказательстве, в котором P посылает w в V, V проверки wдействительность путем выполнения ψ на ней. 

Полезно разбить накладные расходы прувера на «накладные расходы внешнего интерфейса» и «накладные расходы внутреннего интерфейса». Если оценивать цепь C ворота за воротами F раз дороже, чем бег ψ, тогда мы говорим, что накладные расходы внешнего интерфейса равны F. Если применить бэкэнд прувер к C is B раза дороже, чем оценка C ворота за воротами, то мы говорим, что внутренние накладные расходы составляют B. Общие накладные расходы прувера продукта, F·B. Эти мультипликативные накладные расходы могут быть значительными, даже если F и B индивидуально скромны. 

На практике, F и B оба могут быть примерно 1000 или больше. Это означает, что общие накладные расходы доказывающего по сравнению с прямой проверкой свидетелей могут составлять от 1 до 10 миллионов и более. Программа, которая выполняется на ноутбуке всего одну секунду, может легко привести к тому, что пруверу SNARK потребуются десятки или сотни дней вычислительного времени (однопоточный). К счастью, эту работу обычно можно распараллелить в разной степени (в зависимости от SNARK). 

Таким образом, если вы хотите использовать SNARK в приложении сегодня, то должно выполняться одно из трех условий:

1. Прямая проверка свидетелей занимает гораздо меньше одной секунды на ноутбуке.
2. Прямая проверка свидетелей особенно удобна для представления в цепи, поэтому накладные расходы внешнего интерфейса невелики.
3. Вы готовы ждать несколько дней, пока завершится проверка SNARK, и/или платить за огромные параллельные вычислительные ресурсы.

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

Разделение фронтенда и бэкенда

Полное отделение интерфейсов от серверов может оказаться сложной задачей, поскольку разные серверы поддерживают разные виды цепей. Следовательно, внешние интерфейсы могут различаться в зависимости от внутреннего интерфейса, с которым они должны взаимодействовать.

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

Большинство бэкендов на самом деле поддерживают обобщение арифметических схем, часто называемых экземплярами Rank-1 Constraint Satisfaction (R1CS). За заметным исключением Грот16 и его предшественники, эти SNARK также могут поддерживать другие IR. Например, StarkWare использует то, что называется алгебраическим промежуточным представлением (AIR), которое также похоже на понятие, называемое Арифметизация PlonKish который может поддерживаться PlonK и другими бэкэндами. Способность некоторых бэкендов поддерживать более общие IR может снизить нагрузку на внешние интерфейсы, создающие эти IR. 

Бэкенды также различаются по количеству полей, которые они изначально поддерживают. Я буду обсуждать это далее в следующем разделе.

Различные подходы к фронтендам

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

Один из популярных подходов к внешнему интерфейсу заключается в создании схем, которые по существу выполняют шаг за шагом какой-нибудь простой ЦП, также называемый виртуальной машиной (ВМ). Разработчики внешнего интерфейса задают набор «примитивных операций», аналогичных инструкциям по сборке для реальных компьютерных процессоров. Разработчики, которые хотят использовать внешний интерфейс, будут либо писать «программы проверки свидетелей» непосредственно на языке ассемблера, либо на каком-либо языке более высокого уровня, таком как Solidity, и автоматически компилировать свои программы в ассемблерный код. 

Например, StarkWare. Каир — это очень ограниченный язык ассемблера, в котором ассемблерные инструкции грубо разрешают сложение и умножение над конечным полем, вызовы функций, а также чтение и запись в неизменяемую (т. е. однократно записываемую) память. Cairo VM представляет собой архитектуру фон Неймана, что означает, что схемы, создаваемые внешним интерфейсом, по существу принимают программу Cairo в качестве общедоступных входных данных и «запускают» программу на свидетеле. Язык Cairo является полным по Тьюрингу — несмотря на его ограниченный набор инструкций, он может моделировать более стандартные архитектуры, хотя это может быть дорого. Внешний интерфейс Cairo превращает выполнение программ Cairo в T примитивные инструкции в то, что называется2 ВОЗДУХ с T ряды и о 50 колонны». какая именно это означает не важно для этого поста, но что касается пруверов SNARK, это соответствует схемам с от 50 до 100 вентилей для каждого из T шагов процессора Cairo. 

RISC-ноль использует аналогичный подход к Cairo, но с виртуальной машиной, являющейся так называемой Архитектура RISC-V, архитектура с открытым исходным кодом и богатая программная экосистема, популярность которой растет. Поскольку это очень простой набор инструкций, разработка эффективного внешнего интерфейса SNARK, поддерживающего его, может быть относительно легкой задачей (по крайней мере, в отношении сложных архитектур, таких как x86 или ARM). По состоянию на май RISC Zero переворачивает программы проведение T примитивные инструкции RISC-V в AIR степени 5 с 3T строк и 160 столбцы. Это соответствует схемам не менее 500 вентилей на шаг процессора RISC-V. Дальнейшие улучшения ожидаются в ближайшем будущем.

В различных проектах zkEVM (например, zkSync 2.0, Scroll, zkEVM от Polygon) виртуальная машина рассматривается как виртуальная машина Ethereum. Процесс превращения каждой инструкции EVM в эквивалентный «гаджет» (т. е. оптимизированную схему, реализующую инструкцию) значительно сложнее, чем для более простых архитектур Cairo и RISC-V. По этой и другим причинам, некоторые из проектов zkEVM не реализуют напрямую набор инструкций EVM, а скорее компилируют высокоуровневые программы Solidity на другие языки ассемблера, прежде чем превращать их в схемы. Ожидаются результаты работы по этим проектам.

Проекты «эмулятора ЦП», такие как RISC-V и Cairo, создают единую схему, которая может обрабатывать все программы на соответствующем языке ассемблера. Альтернативные подходы похожи на ASIC, создавая разные схемы для разных программ. Этот подход, подобный ASIC, может привести к меньшим схемам для некоторых программ, особенно когда инструкция сборки, которую программа выполняет на каждом временном шаге, не зависит от входных данных программы. Например, он потенциально может полностью избежать накладных расходов внешнего интерфейса для прямолинейных программ, таких как наивное умножение матриц. Но подход ASIC также кажется весьма ограниченным; насколько мне известно, неизвестно, как использовать его для поддержки циклов без заранее определенных границ итераций. 

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

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

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

Некоторые проекты решили работать с полями с особенно быстрой арифметикой. Например, Плонки2 а другие используют поле характеристики 2⁶⁴ -2³² +1, потому что арифметика в этой области может быть реализована в несколько раз быстрее, чем в менее структурированных полях. Однако использование такой маленькой характеристики может привести к проблемам с эффективным представлением целочисленной арифметики с помощью полевых операций (например, умножение двух 32-битных целых чисел без знака может дать результат, превышающий характеристику поля). 

 Но несмотря ни на что, для того, чтобы все популярные сегодня SNARK достигли 128-битной безопасности (без значительного увеличения затрат на проверку), им приходится работать над полем размером более 2¹²⁸. Насколько я могу судить, это означает, что для каждой полевой операции потребуется не менее десяти 64-битных машинных умножений и значительно больше сложений и побитовых операций. Следовательно, следует учитывать, по крайней мере, на порядок величины накладные расходы внешнего интерфейса из-за необходимости схем, которые работают с конечными полями. 

Подводя итог, можно сказать, что существующие интерфейсы, использующие абстракцию виртуальной машины, создают схемы с числом вентилей от 100x до 1000x на шаг виртуальной машины и, возможно, больше для более сложных виртуальных машин. Кроме того, арифметика конечных полей как минимум в 10 раз медленнее, чем аналогичные инструкции на современных процессорах (с возможным исключением, если процессор имеет встроенную поддержку определенных полей). «Внешний интерфейс ASIC» может уменьшить некоторые из этих накладных расходов, но в настоящее время он ограничен в программах, которые он может поддерживать.

Каковы узкие места бэкэнда?

SNARK для цепной выполнимости обычно разрабатываются путем объединения информационно-теоретически безопасного протокола, называемого «полиномиальное ВГД" с криптографическим протоколом, называемым "полиномиальная схема обязательств». В большинстве случаев узким местом прувера является полиномиальная схема фиксации. В частности, эти SNARK имеют доказывающую криптографическую фиксацию одного или нескольких полиномов, степень которых (по крайней мере) |C|, количество ворот в цепи C. 

В свою очередь, конкретное узкое место в схеме полиномиальной фиксации будет зависеть от используемой схемы и размера схемы. Но это всегда будет одна из следующих трех операций: вычисление БПФ, возведение в степень в криптографической группе или Меркл-хеширование. Хеширование Меркла обычно является узким местом, только если схема небольшая, поэтому мы не будем обсуждать это дальше. 

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

В полиномиальных обязательствах, основанных на сложности задачи дискретного логарифмирования в криптографической группе G (КЗГ, Bulletproofs, солнечниккачества Hyrax-коммит), доказывающий должен вычислить Приверженность вектору Педерсена к коэффициентам многочлена. Это включает в себя многократное возведение в степень, размер которого равен степени многочлена. В SNARK эта степень обычно равна размеру |C| контура C.

Сделано наивно, мультивозведение в степень размера |C| требуется около 1.5·|C|·журнал |G| ≈ 400·|C| групповые операции, где |G| обозначает количество элементов в группе G. Однако существует подход, называемый алгоритмом Пиппенджера, который может уменьшить это примерно в логарифмический раз. |C|. Для больших цепей (скажем, |C| ≥ 225), этот журнал |C| Фактор может быть 25 или более, то есть для больших цепей мы ожидаем, что векторное обязательство Педерсена может быть вычислено с немногим более 10·|C| групповые операции. Каждая групповая операция, в свою очередь, имеет тенденцию быть (как очень приблизительный пример) примерно в 10 раз медленнее, чем операция с конечным полем. SNARK, использующие эти полиномиальные обязательства, столь же дороги для P около 100·|C| полевые операции. 

К сожалению, существующие SNARK имеют дополнительные накладные расходы сверх 100-кратного коэффициента, указанного выше. Например:

• спартанскийдоказательство, использующее полиномиальное обязательство Хайракса, должно делать |C|^½ много мультиэкспоненциаций каждого размера |C|^½, ослабив ускорение алгоритма Пиппенджера примерно в два раза. 
• In Грот16, P должны работать в группе, дружественной к сопряжению, операции которой обычно как минимум в 2 раза медленнее, чем в группах, не дружественных к сопряжению. P также должен выполнять 3 мультиэкспоненциации, а не 1. В совокупности это приводит как минимум к дополнительному 6-кратному замедлению по сравнению со 100·|C| оценка выше. 
• Marlin и ПлонК также требуют, чтобы пары и их доказывающие использовали значительно больше, чем 3 полинома. 
• Для любого SNARK, использующего Bulletproofs (например, Halo2, что примерно соответствует PlonK, но с Bulletproofs, а не с полиномиальными обязательствами KZG), доказывающий должен логарифмически вычислить множество мультиэкспоненциаций во время «открывающей» фазы схемы обязательств, и это в значительной степени стирает любое ускорение Pippenger. 

Таким образом, известные SNARK, использующие векторные обязательства Педерсена, по-видимому, имеют накладные расходы на серверную часть как минимум в 200 раз и до 1000 раз или более. 

Другие полиномиальные обязательства

Для SNARK, использующих другие полиномиальные обязательства (такие как ПТ и Лигеро-коммит), узким местом является то, что прувер должен выполнять большие БПФ. Например, в AIR степени 2 производства Каира (с 51 колонкой и T строки, по одной на шаг ЦП Cairo), развернутый прувер StarkWare выполняет как минимум 2 БПФ на столбец длиной между 16 ·T и 32 ·T. Константы 16 и 32 зависят от внутренних параметров FRI, установленных StarkWare, и их можно уменьшить, но за счет увеличения затрат на проверку. 

Оптимально, БПФ длины 32·T занимает около 64·T·журнал (32T) умножения полей. Это означает, что даже при относительно небольших значениях T (например, T ≥ 2²⁰), количество полевых операций на столбец не менее 64·25·T= 1600·T. Таким образом, накладные расходы на серверную часть исчисляются как минимум тысячами. Кроме того, возможно, что большие БПФ еще более ограничены пропускной способностью памяти, чем полевыми операциями. 

В некоторых контекстах накладные расходы на серверную часть SNARK, которые выполняют большие БПФ, можно уменьшить с помощью метода, называемого агрегированием доказательств. Для сводок это будет означать, что P (служба объединения) разбивает большой пакет транзакций, скажем, на 10 меньших пакетов. За каждую маленькую партию i, P производит доказательство SNARK πi годности партии. Но P не публикует эти доказательства в Ethereum, так как это привело бы к почти 10-кратному увеличению стоимости газа. Вместо этого снова применяется SNARK, на этот раз для получения доказательства. π установление этого P знает π₁ , ...,π₁₀. То есть свидетель, P утверждает, что знает десять доказательств π₁,…,π₁₀, а прямая проверка свидетелей применяет процедуру проверки SNARK к каждому из доказательств. Это единственное доказательство π публикуется в Ethereum. 

В полиномиальных обязательствах, таких как FRI и Ligero-commit, существует сильное противоречие между P время и V затраты, а внутренние параметры действуют как ручка, которая может обменивать одно на другое. С π₁ ,…,π₁₀ не публикуются в Ethereum, ручку можно настроить таким образом, чтобы эти доказательства большие, и производить их быстрее. Только в окончательном приложении SNARK для агрегирования π₁ ,…,π₁₀ в единое доказательство π, нужно ли настроить схему фиксации, чтобы обеспечить небольшое доказательство. 

StarkWare планирует развернуть агрегацию доказательств в ближайшее время. Этому также посвящены такие проекты, как Плонки2.

Каковы другие узкие места в масштабируемости SNARK?

Этот пост посвящен пруверу время, но другие затраты на прувер также могут быть узким местом масштабируемости. Например, для многих бэкендов SNARK прувер должен хранить несколько элементов поля для каждого вентиля в C, и эта стоимость пространства может быть огромной. Например, программа ψ выполнение за одну секунду на ноутбуке может выполнить, возможно, миллиард примитивных операций на современном процессоре. Как мы видели, вообще следует ожидать C для каждой такой операции требуется более 100 ворот. Это означает 100 миллиардов ворот, что, в зависимости от SNARK, может означать десятки или сотни терабайт пространства для хранения. P. 

Другой пример: многие популярные SNARK (например, ПлонК, Marlin, Грот16) требуют сложной «церемонии доверенной настройки» для создания структурированного «ключ проверки», который должен быть сохранен прувером. Насколько мне известно, крупнейшая такая церемония сгенерировал проверочный ключ, способный поддерживать схемы с примерно 2²⁸≈250 миллионов ворот. Ключ проверки имеет размер в несколько десятков гигабайт. 

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

Забегая вперед: перспективы более масштабируемых SNARK

Как внешние, так и внутренние накладные расходы могут составлять три порядка и более. Можем ли мы ожидать, что они существенно снизятся в ближайшем будущем? 

Я думаю, что мы будем — до точки. Во-первых, самые быстрые серверные части на сегодняшний день (например, спартанский и Торможениеи другие SNARK, которые сочетают в себе протокол проверки суммы с полиномиальными обязательствами) имеют большие доказательства — обычно квадратный корень из размера схемы — поэтому люди на самом деле их не используют. Я ожидаю, что размер доказательства и время проверки будут значительно уменьшены в ближайшем будущем за счет композиции глубины один с небольшими SNARK. Подобно агрегации доказательств, это означает, что доказывающий должен сначала создать доказательство SNARK. π с помощью SNARK «быстропроверка, большая доказательство», но не отправлять π в V, Скорее, P будет использовать SNARK с малым доказательством для получения доказательства π" что он знает π, и отправить π" в V. Это может на порядок сократить накладные расходы на серверную часть популярных сегодня SNARK. 

Во-вторых, может помочь аппаратное ускорение. Очень грубое общее правило заключается в том, что графические процессоры могут купить 10-кратное ускорение по сравнению с центральными процессорами, а ASIC — 10-кратное ускорение по сравнению с графическими процессорами. Однако у меня есть три опасения по этому поводу. Во-первых, большие БПФ могут быть ограничены пропускной способностью памяти, а не полевыми операциями, поэтому SNARK, выполняющие такие БПФ, могут получить ограниченное ускорение от специализированного оборудования. Во-вторых, хотя этот пост посвящен узкому месту полиномиальной фиксации, многие SNARK требуют, чтобы доказывающий выполнял другие операции, которые лишь немного дешевле. Таким образом, преодоление узкого места полиномиального обязательства (например, ускорение мультиэкспоненциации в SNARK на основе дискретного журнала) может оставить новую операцию узкого места, которая ненамного лучше старой. (Например, SNARK, включая Groth16, Marlin и PlonK, также заставляют доказывающую выполнять БПФ, в дополнение к множественному возведению в степень.) Наконец, поля и эллиптические кривые, которые приводят к наиболее эффективным SNARK, могут продолжать развиваться в течение некоторого времени, и это может создать проблемы для ускорения пруверов на основе ASIC.

Что касается внешнего интерфейса, мы все чаще обнаруживаем, что подход «эмулятор ЦП» в таких проектах, как Cairo, RISC Zero, zkEVM и других, на самом деле достаточно хорошо масштабируется (с точки зрения производительности) со сложностью наборов инструкций ЦП. Ведь именно на это и надеются различные проекты zkEVM. Это может означать, что, хотя накладные расходы внешнего интерфейса остаются на три порядка и более, внешние интерфейсы могут поддерживать виртуальные машины, которые все больше соответствуют реальной архитектуре ЦП. Уравновешивающая проблема заключается в том, что внешние интерфейсы могут стать сложными и трудными для аудита, поскольку гаджеты с ручным кодом, реализующие все более сложные инструкции, распространяются. Формальные методы проверки, вероятно, будут играть важную роль в решении этой проблемы. 

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

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

Благодарности: я благодарен Елена Бургер за предложение темы этого поста и Арасу Арун, Жозеф Боннокачества Сэм Рэгсдейл за дельные комментарии. Отдельное спасибо моему редактору, Тим Салливан.

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

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

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