Введение

Блокчейны - это глобально распределенные реестры, которые приходят к согласию относительно глобального состояния. Некоторые блокчейны оснащены полностью универсальной средой выполнения, которая обеспечивает программирование поверх этого глобального состояния. Программы, ориентированные на среды выполнения блокчейнов, называются смарт-контрактами, а основные блокчейны называются платформами смарт-контрактов. Ethereum, Solana и Avalanche - это некоторые из наиболее широко известных платформ смарт-контрактов. Мы можем рассматривать платформы смарт-контрактов как распределенные компьютеры, где среда выполнения (или виртуальная машина) действует как ЦПУ, а состояние выполняет роль хранилища.

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

Эта статья исследует сопроцессоры с первых принципов, нацеленных на уточнение их важности и мета-свойств. Затем мы сравниваем их с роллапами, демонстрируя, как эти два концепта, хотя и различны, тесно связаны. Мы также приводим примеры, когда роллапы и сопроцессоры могут использоваться совместно друг с другом. Например, даже все могущественный роллап или L1 могут потребовать сопроцессор для выполнения тяжелых задач.

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

Как мы попали сюда:

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

Как уже упоминалось, Эфириум можно представить как децентрализованный глобальный компьютер во многих аспектах. Это сеть узлов, работающих на программном обеспечении, предоставляющем вычислительные ресурсы для выполнения смарт-контрактов. Блокчейн Ethereum хранит информацию о состоянии и код, аналогично хранению и памяти компьютера. И виртуальная машина Ethereum (EVM) работает на каждом узле, обрабатывая транзакции и выполняя код, как процессор. Однако Ethereum является разрешенным и децентрализованным, используя консенсус между недоверенными узлами. Если некоторые узлы выходят из строя, сеть продолжает работать. Чтобы обеспечить правильность операций EVM, проверяющие на сетях с использованием доказательства о ставке (PoS), таких как Ethereum, должны выполнять все переходы состояния для их верификации. Это ограничивает скорость сети PoS до ее самых медленных узлов, ограничивая количество вычислений, доступных разработчикам приложений.

В отличие от обычного компьютера, Ethereum ограничивает вычисления и хранение данных, чтобы предотвратить злоупотребление сети. За каждую операцию взимаются комиссионные сборы, что делает финансово непрактичными бесконечные циклы. Такой подход позволяет снизить барьеры для входа, позволяя использовать обычное аппаратное обеспечение, такое как Raspberry Pi, для запуска сетевых узлов. Ограничения обеспечивают включающую систему, где любой может помочь в работе децентрализованной сети Ethereum.

Из-за этих вычислительных ограничений узлов Ethereum сложные приложения, такие как модели машинного обучения, игры или научные вычисления, сегодня не могут работать непосредственно на Ethereum.

Это компромисс, чтобы сделать Ethereum широкодоступным, безопасным и устойчивым как основу для базовых приложений. Но неизбежно существуют некоторые ограничения по сравнению с вычислительно неограниченным компьютером. У него есть ограничения даже по сравнению с даже таким древним процессором, как Pentium 5:

Нет сложной математики с плавающей запятой - EVM поддерживает только основные математические и логические операции. Продвинутые числовые вычисления, такие как нейронные сети, неосуществимы. (Интересным моментом является неспособность обрабатывать числа с плавающей запятой, что также затрудняет обмен активами с переоценкой, такими как Ampleforth, и т. д., в недавней истории и иногда даже несовместимо с некоторыми DEXs).

Ограниченное вычисление на блок - Сборы за газ метрируют вычисления, поэтому сложное программное обеспечение, такое как игры, было бы чрезвычайно дорогим. Предел газа на блок составляет 30 миллионов газа.

Ограниченная память - Смарт-контракты имеют ограниченные постоянные пределы хранения, что затрудняет создание больших программ.

Нет постоянного хранения файлов - Нет способа хранить файлы, такие как графика, аудио или видео, на блокчейне.

Медленная скорость - Скорость транзакций на Ethereum в настоящее время составляет около 15 TPS, на много порядков медленнее, чем у ЦПУ.

В конечном итоге, ограниченное хранение и вычисления ограничивают степень свободы, доступную приложениям (эти ограничения различаются от блокчейна к блокчейну, но всегда существуют). Люди сравнивают блокчейны с вычислительно ограниченными средами 1970-1980-х годов, но мы считаем, что между этими двумя существуют значительные различия:

Рост вычислений в 1970-1980-х годах был стремительным (счет транзисторов в микропроцессорах за это время вырос с ~1,000 до ~1,000,000). Но этот рост не означал, что люди часто покупали или обновляли свои компьютеры. Поскольку платформы смарт-контрактов ограничены своими самыми медленными узлами, ускорение на передовой компьютеров не обязательно приведет к тому, что блокчейны увидят пропорциональный рост вычислительных скоростей. Ускорение может произойти только в том случае, если базовые требования для узлов на блокчейне будут обновлены.

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

Все это говорит о том, что с годами процессоры совершенствовались, и мы получили больше ядер процессора на каждом устройстве, что позволяет нам выполнять все более сложные задачи. Если мы думаем, что блокчейн-компьютеры не будут ускоряться так же быстро, как традиционные вычисления (из-за требований к базовым узлам), то имеет смысл попытаться найти альтернативные источники вычислений. Интересная аналогия заключается в том, что центральные процессоры в традиционных вычислениях не справлялись с задачами графической обработки, что привело к появлению графических процессоров почти в каждом компьютере. Точно так же, поскольку блокчейны сосредоточены на том, чтобы быть безопасными хранилищами состояния с включенными простыми вычислительными батареями, существует явная возможность для вычислений вне цепочки расширить пространство для разработки приложений. Сегодня блокчейны имеют смысл только для приложений с низкой вычислительной мощностью, которым нужны такие свойства, как открытый доступ, суверенитет, устойчивость к цензуре и компонуемость. Чтобы разместить в блокчейне большее разнообразие приложений, нам нужно снять ограничения, которые мы накладываем на разработчиков приложений. Мы говорим об этом с пониманием того, что эти ограничения также были благом для экспериментов. Например, CLOB не могли эффективно работать на Ethereum из-за ограничений вычислений, поэтому были приняты AMM, которые с тех пор достигли триллиона долларов в объеме.

Существуют два распространенных подхода к увеличению доступности вычислительных ресурсов для блокчейн-приложений:

Относительно часто увеличивайте базовые требования для узлов. Это примерно тот путь, который берут высокопроизводительные блокчейны, такие как Solana и Sui. Высокий базовый уровень для узлов позволяет им строить очень быстрый блокчейн и также устраняет некоторые ограничения дизайна приложений. Феникс, биржа с лимитным ордерным стаканом на Solana, не могла бы быть построена на Ethereum (или любом L2) сегодня. Обратная сторона увеличения базовых требований заключается в том, что если они постоянно растут, то запуск узлов может быть целесообразен только для профессиональных поставщиков инфраструктуры. Исторические требования к оперативной памяти довольно наглядно демонстрируют, как постоянно увеличиваются аппаратные требования на Solana:

Веб-архив (Примечание: мы используем медианные требования к ОЗУ с 2020 года)

Перенос вычислений вне блокчейна третьим сторонам. Это была стратегия, принятая экосистемой Ethereum. Эти третьи стороны сами могут быть блокчейнами (в случае роллапов), проверяемыми вычислительными устройствами вне блокчейна (т. е. сопроцессорами) или доверенными третьими сторонами (как в случае с вычислениями вне сети, такими как книга ордеров dydx).

К объединению вычислений вне цепи

Недавно стало много разговоров о копроцессорах, которые обеспечивают вычисления за пределами цепи. Копроцессоры могут быть реализованы различными способами, включая, но не ограничиваясь, доказательствами в нулевом знании или доверенными исполнительными средами (TEEs). Некоторые примеры:

ZK копроцессоры: Axiom, Risc Zero’s Bonsai.

TEEs: Устрица Марлина,

Одновременно, когда речь идет о выгрузке вычислений, дорожная карта Ethereum, ориентированная на rollup, выгружает вычисления на различные rollups, которые урегулированы на Ethereum. За последние несколько лет постоянный поток разработчиков и пользователей переходит на rollups из-за сочетания более дешевых, более быстрых транзакций и стимулов, предоставляемых rollups. В идеальном мире rollups позволяют Ethereum масштабировать свою общую вычислительную мощность путем выполнения вычислений вне цепи без добавления доверительных предположений. Дополнительные вычисления не относятся только к выполнению большего количества транзакций, но и к выполнению более выразительных вычислений на одну транзакцию. Новые типы транзакций расширяют доступное пространство проектирования для приложений, а более высокая пропускная способность снижает стоимость выполнения этих выразительных транзакций, обеспечивая доступ к более высокому классу приложений по доступной цене.

Прежде чем мы пойдем дальше, давайте кратко определим как rollups, так и coprocessors, чтобы избежать путаницы:

Rollups: Rollups поддерживают постоянное, разделенное состояние, отличное от их базовых/хостовых цепочек, но все равно наследуют свойства безопасности своей базы, публикуя данные/доказательства на нее. Перемещая состояние с хостовой цепи, rollups могут использовать дополнительные ресурсы для выполнения переходов состояния перед публикацией доказательств целостности этих переходов состояния на хосте. Rollups наиболее полезны для пользователей, которые не хотят платить высокие комиссии Ethereum, но хотят получить доступ к свойствам безопасности Ethereum.

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

Максимальный размер данных контракта ограничен (например, 24KB на контракт в настоящее время и был установлен в EIP 170). Хранение больших файлов превысило бы это. (*Не решается и сопроцессорами)

Чтение/запись хранения контракта медленнее, чем файловая система или база данных. Доступ к 1КБ данных может стоить миллионы газов.

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

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

Решения вокруг этого:

Большие файлы могут быть разделены на более мелкие части, чтобы уместиться в ограничениях хранения контракта.

Ссылки на файлы могут быть храниться on-chain, сами файлы хранятся off-chain в системах, таких как IPFS.

Coprocessors: Coprocessors не поддерживают состояние сами по себе; они ведут себя как лямбда-функции на AWS, где приложения могут отправлять вычислительную задачу на них, и они возвращают результат с доказательством вычислений. Копроцессоры фундаментально увеличивают доступные вычисления для любой данной транзакции, но так как доказательство на копроцессорах также происходит на основе транзакции, их использование будет более дорогим, чем использование роллапов. Учитывая затраты, копроцессоры могут быть полезны для протоколов или пользователей, которые хотят выполнять сложные одноразовые задачи в проверяемом виде. Еще одно преимущество копроцессоров заключается в том, что они позволяют приложениям, использующим вычисления вне цепи, также получать доступ ко всему историческому состоянию Ethereum без добавления каких-либо доверительных предположений к самому приложению; это невозможно с использованием обычного смарт-контракта сегодня.

Чтобы продемонстрировать разницу между роллапами и копроцессорами, давайте обратимся к ZK-вариантам обоих этих примитивов. ZK-роллапы обеспечивают как возможность верификации, так и аспект сжатия доказательств нулевого знания, что позволяет им фундаментально увеличить пропускную способность для своей экосистемы. Копроцессоры, с другой стороны, обращаются только к свойству верификации zk-доказательств, что означает, что общая пропускная способность системы остается прежней. Кроме того, ZK-роллапы требуют схем, которые могут доказать любую программу, которая нацеливается на виртуальную машину для этого роллапа (например, роллапы на Ethereum имеют встроенные zkEVM для контрактов, нацеленных на EVM). В отличие от этого, ZK-копроцессоры должны строить схемы только для задач, которые им предстоит выполнить.

Таким образом, кажется, что два самых больших различия между роллапами и копроцессорами заключаются в:

Rollups поддерживают разделенное постоянное состояние, а копроцессоры нет (они используют состояние хост-цепи).

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

Недавно были предложены роллапы Booster, которые выполняют транзакции, как если бы они работали непосредственно на цепочке-хосте, имея доступ ко всему состоянию хоста. Тем не менее, у роллапов Booster также есть свое хранилище, что позволяет масштабировать вычисления и хранение как на хосте, так и на роллапе. Предложение о роллапе Booster указывает на то, что существует спектр в конструкции вычислений вне цепи, где традиционные роллапы и сопроцессоры находятся на обоих концах этого спектра. Роллапы, роллапы Booster и сопроцессоры предоставляют доступ к большему количеству вычислений и отличаются только тем, сколько состояния они удерживают отделенным от своего базового L1.

На Modular Summit 2023 в выступлении под названием «Shielded Transactions Are Rollups» Генри Де Валенс рассказал об этой концепции и представил очень простое изображение для определения роллапа:

Речь утверждает, что любое выполнение, переданное основной цепи третьей стороне, является rollup. По его определению, копроцессоры также будут rollups. Это немного отличается от нашего взгляда на объединение rollups и копроцессоров под знаменем off-chain проверяемого вычисления, но общее настроение остается прежним!

В своем видении Финала игры Виталик обсуждает будущее, где производство блоков централизовано, а проверка блоков децентрализована и высоко децентрализована. Мы считаем, что это приблизительно правильная модель для понимания того, что происходит сейчас. В zk-rollup производство блоков и вычисление перехода состояния централизовано. Однако доказательства позволяют сделать проверку дешевой и децентрализованной. Аналогично, у zk-сопроцессора нет производства блоков; он только обращается к историческим данным и вычисляет переходы состояния по этим данным. Вероятно, вычисления на zk-сопроцессоре всегда будут выполняться на централизованной машине; тем не менее, доказательство правильности, возвращаемое вместе с результатом, позволяет любому проверить результаты перед их использованием. Возможно, правильно переформулировать видение Виталика как: "будущее, где вычисление централизовано, но проверка централизованного вычисления децентрализована и высоко децентрализована."

То же самое, но по-другому

Несмотря на их общие сходства, роллапы и сопроцессоры сегодня обслуживают совершенно разные рынки. Кто-то может спросить: "Если мы можем просто использовать сопроцессор на ETH L1 и получить доступ к его ликвидности, зачем нам нужны роллапы?" Хотя это справедливый вопрос, мы считаем, что есть несколько причин, почему роллапы по-прежнему имеют смысл (и представляют гораздо большую рыночную возможность, чем сопроцессоры сегодня):

Как уже упоминалось, копроцессоры позволяют получить доступ к большему объему вычислений в одной и той же транзакции, чем L1. Но они не могут помочь увеличить количество транзакций, которые могут быть выполнены блокчейном, вызывающим копроцессор (если вы думаете о пакетной обработке, вуаля, вы пришли к роллапу). Поддерживая разделенное постоянное состояние, роллапы могут увеличить количество транзакций, доступных людям, которые хотят получить доступ к блокчейну с характеристиками безопасности Ethereum. Это возможно, потому что роллапы публикуются в Ethereum только каждые n блоков и не требуют, чтобы все валидаторы Ethereum проверяли, что произошло изменение состояния. Заинтересованные стороны могут просто полагаться на доказательство.

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

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

Еще один важный момент, который следует отметить здесь, заключается в том, что большинство ликвидности сегодня находится на ETH L1, поэтому для многих протоколов, которые полагаются на ликвидность для улучшения своих продуктов, может быть разумным все еще запускаться на основной сети Ethereum. Приложение на основной сети Ethereum может получить доступ к большему объему вычислений, периодически выполняя транзакции на копроцессоре. Например, DEX, такие как Ambient или Uniswap v4, могут использовать хуки в сочетании с копроцессорами, чтобы выполнять сложную логику по изменению комиссий или даже модификации формы кривой ликвидности на основе рыночных данных.

Одна интересная аналогия сравнивает взаимодействие между роллапами и сопроцессорами с императивным и функциональным программированием. Императивное программирование фокусируется на изменяемых состояниях и побочных эффектах, указывая шаг за шагом, как выполнять задачи. Функциональное программирование подчеркивает неизменяемые данные и чистые функции, избегая изменения состояния и побочных эффектов. Точно так же роллапы похожи на императивные программы, которые изменяют состояние, которое они удерживают, в то время как сопроцессоры похожи на функциональные программы, в которых они не изменяют состояние, но производят результат вместе с доказательствами вычислений. Более того, как и в императивном и функциональном программировании, у роллапов и сопроцессоров есть своё место и их следует использовать соответственно.

Будущее на основе доказательств

Если мы оказываемся в мире, где вычисления централизованы, но проверка централизованных вычислений надежна и высоко децентрализована, что это означает для Ethereum? Будет ли мировой компьютер сведен к простой базе данных? Это плохо?

В конечном счете, цель Ethereum — предоставить своим пользователям доступ к надежным вычислениям и хранилищам. В прошлом единственным способом получить доступ к надежным вычислениям в Ethereum было выполнение вычислений и их проверка всеми узлами. С развитием методов доказательства (особенно доказательств с нулевым разглашением) мы можем перенести большую часть вычислений, которые происходили на узлах валидаторов, во внецепочечные вычисления и позволить валидаторам проверять результаты только в блокчейне. Это, по сути, превращает Ethereum в неизменяемую мировую доску объявлений. Доказательства вычислений позволяют нам проверить, что транзакция была выполнена правильно, и, отправив их в Ethereum, мы получаем временную метку и неизменяемое историческое хранилище для этих доказательств. По мере того, как доказательства с нулевым разглашением становятся более эффективными при произвольных вычислениях, вполне вероятно, что в какой-то момент стоимость выполнения вычислений в ZK будет значительно меньше, чем стоимость выполнения их в блокчейне (возможно, даже в цепочке CometBFT из 100 валидаторов). В таком мире трудно представить, что ZK-доказательства не станут доминирующим способом доступа к вычислениям, не требующим доверия. Подобные мысли недавно высказал и Дэвид Вонг:

Будущее, в котором любые вычисления могут быть доказаны, также позволяет нам строить инфраструктуру для тех видов бездоверительных приложений, на которые есть спрос пользователей, вместо того чтобы пытаться адаптировать базовый уровень Ethereum для того, чтобы стать домом для этих приложений. В идеальном случае настроенная инфраструктура создаст более безшовные пользовательские впечатления и будет масштабироваться вместе с приложениями, построенными на ее основе. Это, надеюсь, позволит веб3-приложениям конкурировать со своими веб2-аналогами и ввести в действие бездоверительное, основанное на доказательствах будущее, о котором всегда мечтали киберпанки.

В целом, мы считаем, что движемся к следующей парадигме:

————————————————————Не доверяйте, проверьте————————————————————-

Отказ от ответственности:

1. Эта статья взята из [Gateзеркало]. Все авторские права принадлежат оригинальному автору [Джейкоб Ко]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они быстро справятся с этим.
2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.