Оригинальное название: Клеевые и сопроцессорные архитектуры.
Автор: Виталик, основатель Ethereum. Составитель: Дэн Тонг, Golden Finance;
Особая благодарность Джастину Дрейку, Георгиосу Константопулосу, Андрею Карпати, Майклу Гао, Таруну Читре и различным участникам Flashbots за их отзывы и комментарии.
Если вы проанализируете достаточно подробно любые ресурсоемкие вычисления, происходящие в современном мире, вы снова и снова обнаружите одну особенность: вычисления можно разделить на две части:
Относительно небольшое количество сложной, но не требующей больших вычислений «бизнес-логики»;
Много интенсивной, но высокоструктурированной «дорогой работы».
Эти две формы вычислений лучше всего реализовывать по-разному: первая, чья архитектура может быть менее эффективной, но должна быть очень общей; вторая, чья архитектура может быть менее общей, но должна быть очень эффективной.
Каковы примеры такого разного подхода на практике?
Во-первых, давайте посмотрим на среду, с которой я наиболее знаком: виртуальную машину Ethereum (EVM). Вот трассировка отладки geth для недавней транзакции Ethereum, которую я совершил: Обновление хеша IPFS моего блога на ENS. Эта транзакция потребила в общей сложности 46924 газа и может быть классифицирована следующим образом:
Базовая стоимость: 21 000.
Данные о звонках: 1556
Исполнение EVM: 24 368
Код операции SLOAD: 6400
Код операции SSTORE: 10 100
Код операции журнала: 2149
Другие: 6719
EVM-трассировка обновлений хеша ENS. Предпоследний столбец – расход газа.
Мораль этой истории такова: большая часть выполнения (около 73%, если вы посмотрите только на EVM, около 85%, если включить базовую часть затрат, которая включает в себя вычисления) сосредоточена в очень небольшом количестве структурированных дорогостоящих операций: чтение данных из хранилища. и запись, логирование и шифрование (базовая стоимость включает 3000 за проверку подписи платежа, EVM также включает 272 за хеширование платежа). Остальная часть выполнения представляет собой «бизнес-логику»: замена битов данных вызова для извлечения идентификатора записи, которую я пытаюсь установить, и хэша, который я ее устанавливаю, и т. д. При передаче токенов это будет включать в себя добавление и вычитание остатков, в более продвинутых приложениях это может включать ротацию и т. д.
В EVM эти две формы исполнения обрабатываются по-разному. Бизнес-логика высокого уровня пишется на языке более высокого уровня, обычно Solidity, который компилируется в EVM. Дорогостоящая работа по-прежнему выполняется из-за кодов операций EVM (SLOAD и т. д.), но более 99 % реальных вычислений выполняется в специальных модулях, написанных непосредственно внутри клиентского кода (или даже библиотек).
Чтобы лучше понять этот шаблон, давайте рассмотрим его в другом контексте: код искусственного интеллекта, написанный на Python с использованием torch.
Прямой проход блока модели трансформатора
Что мы здесь видим? Мы увидели относительно небольшое количество «бизнес-логики», написанной на Python, которая описывает структуру выполняемых операций. В реальном приложении будет другой тип бизнес-логики, который определяет такие детали, как, например, как получить входные данные и что делать с выходными данными. Однако, если мы углубимся в каждую отдельную операцию (отдельные шаги внутри self.norm, torch.cat, +, *, self.attn...), мы увидим векторизованные вычисления: одни и те же операции выполняются массово в параллельных значениях. . Как и в первом примере, небольшая часть вычислений используется для бизнес-логики, а большая часть вычислений используется для выполнения больших структурированных матричных и векторных операций — по сути, большинство из них представляют собой просто умножения матриц.
Как и в примере с EVM, эти два типа работы выполняются двумя разными способами. Код бизнес-логики высокого уровня написан на Python, очень универсальном и гибком языке, но в то же время очень медленном, и мы просто принимаем его неэффективность, поскольку он требует лишь небольшой части общих затрат на вычисления. Между тем, интенсивные операции записываются высокооптимизированным кодом, часто кодом CUDA, который выполняется на графическом процессоре. Все чаще мы даже начинаем видеть, как вывод LLM выполняется на ASIC.
Современная программируемая криптография, такая как SNARK, снова следует аналогичной схеме на двух уровнях. Во-первых, доказывающее устройство может быть написано на языке высокого уровня, где тяжелая работа выполняется с помощью векторизованных операций, как в примере с ИИ выше. Это демонстрирует циклический код STARK. Во-вторых, сами программы, выполняемые с использованием криптографии, могут быть написаны таким образом, чтобы отделить общую бизнес-логику от высокоструктурированной дорогостоящей работы.
Чтобы понять, как это работает, мы можем взглянуть на одну из последних тенденций, продемонстрированную STARK. Чтобы быть универсальными и простыми в использовании, команды все чаще создают проверяющие устройства STARK для широко распространенных минимальных виртуальных машин, таких как RISC-V. Любая программа, выполнение которой необходимо доказать, может быть скомпилирована в RISC-V, а затем проверяющая сторона может доказать выполнение этого кода RISC-V.
Схема из документации RiscZero
Это очень удобно: это означает, что нам нужно написать логику доказательства только один раз, и с этого момента любая программа, нуждающаяся в доказательстве, может быть написана на любом «традиционном» языке программирования (например, RiskZero поддерживает Rust). Однако есть проблема: этот подход требует больших накладных расходов. Программируемое шифрование уже непомерно дорого; дополнительные затраты на выполнение кода в интерпретаторе RISC-V слишком велики. Поэтому разработчики придумали хитрость: определить конкретные дорогостоящие операции, составляющие основную часть вычислений (обычно хэши и подписи), а затем создать специализированные модули для очень эффективного доказательства этих операций. Затем вы просто объединяете неэффективную, но общую систему доказательств RISC-V с эффективной, но специализированной системой доказательств и получаете лучшее от обоих миров.
Программируемое шифрование, отличное от ZK-SNARK, такое как многостороннее вычисление (MPC) и полностью гомоморфное шифрование (FHE), может быть оптимизировано с использованием аналогичных методов.
В целом, что это за явление?
Современные вычисления все чаще следуют тому, что я называю связующей архитектурой и сопроцессорной архитектурой: у вас есть некий центральный «связывающий» компонент, который очень универсален, но неэффективен и отвечает за выполнение задач между одним или несколькими компонентами сопроцессора. Эти компоненты сопроцессора имеют низкую универсальность, но высокую эффективность передачи. данные между ними.
Это упрощение: на практике кривая компромисса между эффективностью и универсальностью почти всегда имеет более двух уровней. Графические процессоры и другие микросхемы, часто называемые в отрасли «сопроцессорами», менее универсальны, чем центральные процессоры, но более универсальны, чем ASIC. Выбор специализации сложен и зависит от прогнозов и интуиции относительно того, какие части алгоритма останутся прежними через пять лет, а какие изменятся через шесть месяцев. В архитектуре доказательства ZK мы часто видим аналогичные несколько уровней специализации. Но для широких ментальных моделей достаточно рассмотреть два уровня. Подобные ситуации существуют во многих областях вычислений:
Судя по приведенным выше примерам, то, что вычисления можно разделить таким образом, кажется естественным законом. Фактически, вы можете найти примеры компьютерной специализации, охватывающие десятилетия. Однако я думаю, что это разделение увеличивается. Я думаю, что этому есть причина:
Лишь недавно мы достигли пределов улучшения тактовой частоты ЦП, поэтому дальнейшего увеличения можно добиться только за счет распараллеливания. Однако о распараллеливании сложно рассуждать, поэтому разработчикам зачастую более практично продолжать рассуждения последовательно и позволить распараллеливанию происходить на внутренней стороне, завернутой в специализированные модули, созданные для конкретных операций.
Скорость вычислений лишь недавно стала настолько высокой, что вычислительные затраты на бизнес-логику стали поистине незначительными. В этом мире также имеет смысл оптимизировать виртуальные машины, на которых работает бизнес-логика, для достижения целей, отличных от вычислительной эффективности: удобства для разработчиков, знакомства, безопасности и других подобных целей. Между тем, специализированные «сопроцессорные» модули могут по-прежнему разрабатываться с учетом эффективности и обеспечивать свою безопасность и удобство для разработчиков благодаря относительно простому «интерфейсу» с клеем.
Становится все более ясно, какие операции являются наиболее важными и дорогостоящими. Это наиболее очевидно в криптографии, где чаще всего будут использоваться определенные виды дорогостоящих операций: операции над модулями, линейные комбинации эллиптических кривых (также известные как мультискалярное умножение), быстрые преобразования Фурье и так далее. Это также становится все более очевидным в области искусственного интеллекта, где на протяжении более двух десятилетий большинство вычислений сводилось «в основном к умножению матриц» (хотя и с разным уровнем точности). Подобные тенденции возникают и в других областях. В (интенсивных) вычислениях гораздо меньше неизвестных неизвестных, чем 20 лет назад.
что это значит?
Ключевым моментом является то, что склеивающие устройства должны быть оптимизированы так, чтобы они были хорошими склеивающими устройствами, а сопроцессоры должны быть оптимизированы так, чтобы они были хорошими сопроцессорами. Мы можем изучить последствия этого в нескольких ключевых областях.
ЭВМ
Виртуальная машина блокчейна (например, EVM) не обязательно должна быть эффективной, она просто должна быть знакомой. Просто добавив правильные сопроцессоры (так называемые «предварительные компиляции»), вычисления в неэффективной виртуальной машине могут фактически быть столь же эффективными, как и вычисления в изначально эффективной виртуальной машине. Например, накладные расходы, связанные с 256-битными регистрами EVM, относительно невелики, в то время как преимущества от знакомства с EVM и существующей экосистемы разработчиков существенны и долгосрочны. Команды разработчиков, оптимизирующие EVM, даже обнаружили, что отсутствие распараллеливания часто не является серьезным препятствием для масштабируемости.
Лучшим способом улучшить EVM может быть (i) добавление более качественных предварительно скомпилированных или специализированных кодов операций, например, может быть разумной некоторая комбинация EVM-MAX и SIMD, и (ii) улучшение структуры памяти, например, деревьев Веркла. Изменение , как побочный эффект, значительно снижает стоимость доступа к слотам хранения, расположенным рядом друг с другом.
Оптимизация хранилища в предложении дерева Ethereum Verkle, размещение соседних ключей хранилища вместе и корректировка стоимости газа, чтобы отразить это. Подобные оптимизации в сочетании с лучшей предварительной компиляцией могут быть более важными, чем настройка самого EVM.
Безопасные вычисления и открытое оборудование
Одной из проблем повышения безопасности современных вычислений на аппаратном уровне является их слишком сложная и запатентованная природа: чипы разрабатываются так, чтобы быть эффективными, что требует собственной оптимизации. Бэкдоры легко скрыть, а уязвимости побочных каналов обнаруживаются постоянно.
Продолжаются усилия по поиску более открытых и безопасных альтернатив с разных точек зрения. Некоторые вычисления все чаще выполняются в доверенных средах выполнения, в том числе на телефонах пользователей, что повышает безопасность пользователей. Продолжается стремление к большему количеству потребительского оборудования с открытым исходным кодом, и в последнее время были достигнуты некоторые успехи, такие как ноутбуки RISC-V под управлением Ubuntu.
Ноутбук RISC-V под управлением Debian
Однако эффективность остается проблемой. Автор статьи по ссылке выше пишет:
Новые конструкции чипов с открытым исходным кодом, такие как RISC-V, вряд ли смогут конкурировать с уже существующими процессорными технологиями, которые совершенствовались десятилетиями. Прогресс всегда имеет отправную точку.
Более параноидальные идеи, такие как создание компьютера RISC-V на FPGA, сопряжены с большими накладными расходами. Но что, если склеивание и архитектура сопроцессора означают, что эти накладные расходы на самом деле не имеют значения? Если мы признаем, что открытые и защищенные чипы будут работать медленнее, чем проприетарные, то даже откажемся от обычных оптимизаций, таких как спекулятивное выполнение и предсказание ветвей, если это необходимо, но попытаемся компенсировать это добавлением (при необходимости проприетарных) модулей ASIC, которые используются в большинстве интенсивных конкретные виды расчетов, а что насчет этого? Чувствительные вычисления могут выполняться в «главном чипе», который будет оптимизирован с точки зрения безопасности, дизайна с открытым исходным кодом и устойчивости к побочным каналам. Более интенсивные вычисления (например, доказательства ZK, AI) будут выполняться в модулях ASIC, которые будут знать меньше информации о выполняемых вычислениях (возможно, за счет криптографического ослепления, в некоторых случаях даже нулевой информации).
криптография
Еще одним ключевым моментом является то, что все это очень оптимистично в отношении криптографии, особенно программируемой криптографии, которая становится мейнстримом. Мы видели некоторые гипероптимизированные реализации некоторых высокоструктурированных вычислений в SNARK, MPC и других настройках: некоторые хэш-функции всего в несколько сотен раз дороже, чем непосредственное выполнение вычислений, а искусственный интеллект (в основном умножение матриц) также очень низкий. Дальнейшие улучшения, такие как GKR, могут еще больше снизить этот уровень. Полностью универсальное выполнение виртуальной машины, особенно при выполнении в интерпретаторе RISC-V, может по-прежнему приносить примерно в десять тысяч раз больше накладных расходов, но по причинам, описанным в этой статье, это не имеет значения: до тех пор, пока используются эффективные специализированные методы. Обрабатывая наиболее трудоемкие части, можно контролировать общую стоимость.
Упрощенная диаграмма MPC, посвященная умножению матриц, крупнейшему компоненту вывода модели ИИ. См. эту статью для получения более подробной информации, в том числе о том, как сохранить конфиденциальность вашей модели и входных данных.
Исключением из идеи, что «связывающие слои должны быть только знакомыми, а не эффективными», является задержка и, в меньшей степени, пропускная способность данных. Если вычисления включают в себя тяжелые операции с одними и теми же данными десятки раз (как в криптографии и искусственном интеллекте), то любые задержки, вызванные неэффективными связующими слоями, могут стать основным узким местом во время выполнения. Поэтому к клеевым линиям также предъявляются требования по эффективности, хотя эти требования более специфичны.
в заключение
В целом, я считаю, что вышеуказанные тенденции являются очень позитивными событиями с разных точек зрения. Во-первых, это логичный способ максимизировать вычислительную эффективность, оставаясь при этом удобным для разработчиков, а возможность получить больше и того, и другого хороша для всех. В частности, это улучшает нашу способность выполнять конфиденциальные и требовательные к производительности вычисления (например, доказательства ZK, вывод LLM) локально на оборудовании пользователя, позволяя специализироваться на стороне клиента для большей эффективности. Во-вторых, это создает огромное окно возможностей для обеспечения того, чтобы стремление к эффективности не ставило под угрозу другие ценности, в первую очередь безопасность, открытость и простоту: безопасность побочного канала и открытость компьютерного оборудования, снижение сложности схемы в ZK-SNARK и уменьшение сложность виртуальных машин. Исторически сложилось так, что стремление к эффективности заставляло эти другие факторы отходить на второй план. Благодаря связующей архитектуре и сопроцессору в этом больше нет необходимости. Одна часть машины оптимизирует эффективность, другая — универсальность и другие ценности, и они работают вместе.
Эта тенденция также очень хороша для криптографии, которая сама по себе является ярким примером «дорогих структурированных вычислений», и эта тенденция ускоряет эту тенденцию. Это добавляет еще одну возможность улучшить безопасность. Повышенная безопасность также возможна в мире блокчейна: мы можем меньше беспокоиться об оптимизации виртуальной машины и больше сосредоточиться на оптимизации предварительной компиляции и других функциях, которые сосуществуют с виртуальной машиной.
В-третьих, эта тенденция предоставляет возможности для участия более мелким и новым игрокам. Если вычисления станут менее монолитными и более модульными, это значительно снизит барьер для входа. Даже использование ASIC для одного типа вычислений потенциально может иметь значение. Это также верно в области доказательств ZK и оптимизации EVM. Написание кода с почти ультрасовременной эффективностью становится проще и доступнее. Аудит и формальная верификация такого кода становится проще и доступнее. Наконец, поскольку эти очень разные области вычислений сходятся по некоторым общим закономерностям, между ними появляется больше возможностей для сотрудничества и обучения.
