Партнер Multicoin Capital Кайл Самани подробно останавливается на 7 причинах, по которым модульные блокчейны переоценены.
Автор: Кайл Самани, партнер Multicoin Capital
Составитель: Луффи, Foresight News
В последние два года дебаты о масштабируемости блокчейна были сосредоточены на центральной теме «дебаты между модульностью и интеграцией».
Обратите внимание, что дискуссии о криптовалютах часто смешивают «единые» и «интегрированные» системы. Технические дебаты об интегрированных системах и модульных системах продолжаются уже 40 лет. Этот разговор в криптовалютном пространстве должен рассматриваться через ту же призму, что и история, и это далеко не новая дискуссия.
При рассмотрении модульности и интеграции наиболее важным проектным решением, которое может принять блокчейн, является степень, в которой сложность стека доступна разработчикам приложений. Клиентами блокчейна являются разработчики приложений, поэтому окончательные проектные решения должны учитывать их точку зрения.
Сегодня модульность широко рассматривается как основной способ масштабирования блокчейнов. В этой статье я оспорю это предположение с точки зрения основных принципов, раскрою культурные мифы и скрытые издержки модульных систем, а также поделюсь выводами, которые я сделал, размышляя об этих дебатах в течение последних шести лет.
Модульные системы усложняют разработку
Безусловно, самая большая скрытая стоимость модульных систем — это дополнительная сложность процесса разработки.
Модульные системы значительно увеличивают сложность, с которой приходится справляться разработчикам приложений, как в контексте собственных приложений (техническая сложность), так и в контексте взаимодействия с другими приложениями (социальная сложность).
В контексте криптовалют модульные блокчейны теоретически допускают большую специализацию, но за счет создания новой сложности. Эта сложность (как техническая, так и социальная по своей природе) передается разработчикам приложений, что в конечном итоге затрудняет создание приложений.
Например, рассмотрим стек OP. На данный момент это, кажется, самая популярная модульная структура. OP Stack заставляет разработчиков выбирать между принятием Закона цепочек (который приносит много социальных сложностей) или их форкованием и управлением ими по отдельности. Оба варианта создают значительные сложности для строителей. Если вы решите создать форк, получите ли вы техническую поддержку от других участников экосистемы (CEX, fiat on-ramp и т. д.), которым придется нести расходы для соответствия новым технологическим стандартам? Если вы решите следовать Закону цепей, какие правила и ограничения будут наложены на вас сегодня и завтра?
Источник: модель OSI.
Современные операционные системы (ОС) — это большие и сложные системы, содержащие сотни подсистем. Современные операционные системы обрабатывают уровни 2–6 на диаграмме выше. Это классический пример интеграции модульных компонентов для управления сложностью стека, с которой сталкиваются разработчики приложений. Разработчики приложений не хотят иметь дело ни с чем, что находится ниже уровня 7, поэтому существуют операционные системы: операционная система управляет сложностью нижних уровней, чтобы разработчики приложений могли сосредоточиться на уровне 7. Следовательно, модульность должна быть не целью сама по себе, а средством достижения цели.
Каждая крупная программная система в современном мире — облачные серверы, операционные системы, механизмы баз данных, игровые движки и т. д. — высокоинтегрирована и состоит из множества модульных подсистем. Программные системы имеют тенденцию быть высокоинтегрированными для максимизации производительности и снижения сложности разработки. То же самое верно и для блокчейна.
Эфириум, кстати, снижает сложность, возникшую в эпоху форка Биткойна в 2011-2014 годах. Сторонники модульности часто подчеркивают модель взаимодействия открытых систем (OSI), утверждая, что доступность данных (DA) и выполнение должны быть разделены, однако этот аргумент широко понимается неправильно; Правильное понимание рассматриваемой проблемы приводит к противоположному выводу: к аргументу о том, что OSI представляет собой интегрированную, а не модульную систему.
Модульные цепочки не могут выполнять код быстрее
По замыслу общее определение «модульной цепочки» — это разделение доступности данных (DA) и выполнения: один набор узлов отвечает за DA, а другой набор (или наборы) узлов отвечает за выполнение. Коллекции узлов не обязательно должны перекрываться, но могут.
На практике разделение DA и выполнения по своей сути не улучшает производительность ни того, ни другого, скорее, какое-то оборудование где-то в мире должно выполнять DA, а какое-то оборудование где-то должно реализовывать выполнение; Разделение этих функций не улучшает производительность ни одной из них. Хотя разделение может снизить вычислительные затраты, его можно уменьшить только за счет централизации выполнения.
Еще раз повторю: независимо от модульной или интегрированной архитектуры, какое-то оборудование где-то должно выполнять работу, а разделение DA и выполнения на отдельное оборудование по своей сути не ускоряет и не увеличивает общую производительность системы.
Некоторые утверждают, что модульность позволяет нескольким EVM работать параллельно в виде объединения, обеспечивая горизонтальное масштабирование выполнения. Хотя теоретически это верно, на самом деле эта точка зрения подчеркивает ограничения EVM как однопоточного процессора, а не основную предпосылку разделения DA и выполнения в контексте масштабирования общей пропускной способности системы.
Модульность сама по себе не увеличивает пропускную способность.
Модульность увеличивает транзакционные издержки для пользователей.
По определению, каждый L1 и L2 представляют собой независимый реестр активов со своим собственным состоянием. Эти отдельные части состояния могут взаимодействовать, хотя и с более длительными задержками транзакций и большей сложностью для разработчиков и пользователей (через межцепочные мосты, такие как LayerZero и Wormhole).
Чем больше реестров активов, тем более фрагментированным становится глобальное состояние всех счетов. Это ужасно как для сетей, так и для пользователей в нескольких цепочках. Фрагментация государства может привести к ряду последствий:
Снижение ликвидности, что приводит к увеличению проскальзывания в торговле;
Увеличение общего потребления газа (межсетевые транзакции требуют как минимум двух транзакций как минимум в двух реестрах активов);
Увеличение двойного счета в реестрах активов (таким образом, снижается общая пропускная способность системы): когда цена ETH-USDC меняется на Binance или Coinbase, возникают арбитражные возможности в каждом пуле ETH-USDC во всех реестрах активов (вы можете легко представить себе В мире, где каждый раз, когда цена ETH-USDC меняется на Binance или Coinbase, в различных реестрах активов происходит более 10 транзакций. Поддержание согласованности цен во фрагментированном состоянии требует крайне низкой эффективности использования пространства блоков.
Важно понимать, что создание большего количества реестров активов значительно увеличивает затраты по всем этим измерениям, особенно по тем, которые связаны с DeFi.
Основными входными данными для DeFi является состояние цепочки (т. е. кто какими активами владеет). Когда команды запускают цепочки приложений/коллапы, они естественным образом создают фрагментацию состояния, что очень вредно для DeFi, как для разработчиков, управляющих сложностью приложения (мосты, кошельки, задержки, межцепочечный MEV и т. д.), так и для пользователей ( Проскальзывание, задержки расчетов).
Самым идеальным условием для DeFi является то, что активы выпускаются в едином реестре активов и торгуются в рамках единого государственного автомата. Чем больше реестр активов, тем сложнее приходится разработчикам приложений и тем выше затраты, которые приходится нести пользователям.
App Rollup не создаст новых возможностей монетизации для разработчиков
Сторонники AppChain/Rollup полагают, что стимулы заставят разработчиков приложений разрабатывать накопительные пакеты, а не опираться на L1 или L2, чтобы приложения могли сами получать ценность MEV. Однако эта идея ошибочна, поскольку запуск объединения приложений — не единственный способ вернуть MEV в токены уровня приложения, и в большинстве случаев это не лучший способ. Токены прикладного уровня могут возвращать MEV в свои собственные токены, просто закодировав логику в смарт-контрактах в общей цепочке. Давайте рассмотрим несколько примеров:
Ликвидация: если Compound или Aave DAO хотят захватить часть MEV, поступающую в ликвидационный бот, они могут просто обновить свои соответствующие контракты, чтобы часть комиссий, в настоящее время поступающих ликвидатору, выплачивалась их собственному DAO, без необходимости для новой цепочки/роллапа.
Oracle: токены Oracle могут захватывать MEV, предоставляя услуги резервного копирования. В дополнение к обновлениям цен оракулы также могут объединять любые произвольные внутрисетевые транзакции, которые гарантированно выполняются сразу после обновления цен. Таким образом, оракулы могут захватывать MEV, предоставляя услуги резервного копирования поисковикам, строителям блоков и т. д.
Минтинг NFT: Минтинг NFT изобилует ботами-скальперами. Это можно легко смягчить, просто закодировав перераспределение снижающейся прибыли. Например, если кто-то попытается перепродать свой NFT в течение двух недель после его чеканки, 100% выручки вернется эмитенту или DAO. Этот процент может меняться со временем.
Не существует универсального ответа на вопрос о записи MEV в токены прикладного уровня. Однако, немного подумав, разработчики приложений могут легко вернуть MEV обратно в свои токены в универсальной цепочке. Запуск совершенно новой сети просто не нужен и создаст дополнительные технические и социальные сложности для разработчиков, а также дополнительные проблемы с кошельком и ликвидностью для пользователей.
Накопительный пакет приложений не может решить проблемы перегрузки между приложениями
Многие считают, что цепочка/агрегирование приложений гарантирует, что приложения не будут подвержены всплескам газа, вызванным другими действиями в цепочке, такими как популярный выпуск NFT. Эта точка зрения отчасти верна, но по большей части ошибочна.
Это историческая проблема, и основная причина — в однопоточной природе EVM, а не в том, что нет разделения DA и исполнения. Все L2 платят комиссию L1, а комиссию L1 можно увеличить в любое время. Во время повального увлечения мемкоинами в начале этого года комиссии за транзакции на Arbitrum и Optimism ненадолго превысили 10 долларов. Комиссии Optimism также недавно взлетели до небес после запуска Worldcoin.
Единственными решениями для устранения скачков комиссий являются: 1) максимизировать L1 DA, 2) максимально усовершенствовать рынок комиссий:
Если ресурсы L1 ограничены, скачки использования отдельных уровней L2 будут передаваться на уровень L1, что повлечет за собой более высокие затраты на все остальные уровни L2. Таким образом, цепочка приложений/агрегат не защищена от всплесков газа.
Сосуществование множества EVM L2 — это всего лишь грубый способ опробовать рынок платной локализации. Это лучше, чем помещать рынок комиссий в одну EVM L1, но это не решает основную проблему. Когда вы понимаете, что решение представляет собой локализованный рынок комиссий, логической конечной точкой является рынок комиссий для каждого штата (а не рынок комиссий для каждого уровня 2).
Другие сети уже пришли к такому выводу. Solana и Aptos естественным образом локализуют рынки комиссий. Это потребовало обширной инженерной работы в течение многих лет для соответствующих сред выполнения. Большинство сторонников модульности сильно недооценивают важность и сложность разработки местных рынков сборов.
Запуская несколько цепочек, разработчики не получают реального прироста производительности. Когда есть приложения, которые приводят к увеличению объема транзакций, это влияет на затраты всех цепочек L2.
Гибкость переоценена
Сторонники модульных цепочек утверждают, что модульная архитектура более гибкая. Это утверждение, очевидно, верно, но имеет ли оно большое значение?
В течение шести лет я пытался найти разработчиков приложений, для которых универсальный уровень L1 не мог обеспечить значительную гибкость. Но до сих пор, за исключением трех очень конкретных случаев использования, никто не смог сформулировать, почему гибкость важна и как она напрямую помогает масштабированию. Три конкретных случая использования, в которых я считаю, что гибкость важна:
Приложения, использующие «горячее» состояние. Горячее состояние — это состояние, необходимое для координации некоторого набора операций в реальном времени, но оно будет передано в цепочку только временно и не будет существовать вечно. Несколько примеров тепловых состояний:
Лимитные ордера на DEX, таких как dYdX и Sei (многие лимитные ордера в конечном итоге отменяются).
Поток заказов координируется и идентифицируется в режиме реального времени с помощью dFlow, протокола, который обеспечивает децентрализованный рынок потоков заказов между маркет-мейкерами и кошельками.
Оракулы, такие как Pyth, оракул с малой задержкой. Pyth работает как автономная цепочка SVM. Pyth генерирует так много данных, что основная команда Pyth решила, что лучше всего отправлять высокочастотные обновления цен в отдельную цепочку, а затем использовать Wormhole для связи цен с другими цепочками по мере необходимости.
Измените цепочку консенсуса. Лучшими примерами являются Osmosis (где все транзакции шифруются перед отправкой валидаторам) и Thorchain (где приоритет транзакций внутри блока определяется на основе уплаченных комиссий).
Требуется инфраструктура, которая каким-то образом использует схему пороговой подписи (TSS). Некоторыми примерами этого являются Sommelier, Thorchain, Osmosis, Wormhole и Web3Auth.
За исключением Pyth и Wormhole, все примеры, перечисленные выше, созданы с использованием Cosmos SDK и выполняются как автономные цепочки. Это красноречиво говорит о применимости и масштабируемости Cosmos SDK для всех трех вариантов использования: «горячих» состояний, консенсусных модификаций и систем пороговой схемы подписи (TSS).
Однако большинство проектов в трех приведенных выше вариантах использования являются не приложениями, а инфраструктурой.
Pyth и dFlow — это не приложения, это инфраструктура. Sommelier, Wormhole, Sei и Web3Auth — это не приложения, а инфраструктура. Среди них есть только один конкретный тип приложений, ориентированных на пользователя: DEX (dYdX, Osmosis, Thorchain).
В течение шести лет я расспрашивал сторонников Cosmos и Polkadot о вариантах использования, возникающих в результате предлагаемой ими гибкости. Думаю, данных достаточно, чтобы сделать некоторые выводы:
Прежде всего, примеры инфраструктуры не должны существовать в виде накопительных пакетов, потому что они либо создают слишком много малоценных данных (например, «горячие» состояния, а весь смысл «горячих» состояний в том, что данные не передаются обратно в L1), либо потому, что они выполняют что-то намеренно несовместимое с активами в реестре, связанными с обновлением статуса (например, все варианты использования TSS).
Во-вторых, единственное приложение, которое я видел, которое могло бы выиграть от изменения конструкции ядра системы, — это DEX. Потому что DEX переполнен MEV, а универсальные цепочки не могут соответствовать задержке CEX. Консенсус является основой качества выполнения транзакций и MEV, поэтому изменения, основанные на консенсусе, естественным образом откроют для DEX множество инновационных возможностей. Однако, как упоминалось ранее в этой статье, основным фактором, влияющим на спотовую DEX, является торгуемый актив. DEX конкурируют за активы и, следовательно, за эмитентов активов. В рамках этой структуры независимые цепочки DEX вряд ли добьются успеха, поскольку при выпуске активов эмитенты активов рассматривают в первую очередь не MEV, связанный с DEX, а общую функциональность смарт-контрактов и включение этой функциональности в соответствующие приложения разработчиков.
Однако децентрализованным биржам деривативов не нужно конкурировать за эмитентов активов. Они в основном полагаются на обеспечение, такое как USDC и цены оракулов, и, по сути, должны блокировать активы пользователей для обеспечения позиций по деривативам. Таким образом, что касается независимых цепочек DEX, они, скорее всего, будут работать с DEX, ориентированными на деривативы, такими как dYdX и Sei.
Давайте рассмотрим распространенные интегрированные приложения L1, существующие сегодня, в том числе: игры, системы DeSoc (такие как Farcaster и Lens), протоколы DePIN (такие как Helium, Hivemapper, Render Network, DIMO и Daylight), звук, обмен NFT и многое другое. . Ни одна из них не получает особой выгоды от гибкости, обеспечиваемой изменением консенсуса, а их соответствующие реестры активов имеют довольно простой, очевидный и общий набор требований: низкие комиссии, низкая задержка, доступ к спотовым DEX, доступ к стейблкоинам и доступ к фиатные каналы, такие как CEX.
Я считаю, что теперь у нас есть достаточно данных, чтобы в некоторой степени сказать, что подавляющее большинство приложений, ориентированных на пользователя, имеют одинаковые общие требования, перечисленные в предыдущем абзаце. Хотя некоторые приложения могут оптимизировать другие переменные с помощью пользовательских функций в стеке, компромиссы, связанные с этими настройками, обычно того не стоят (больше мостов, меньшая поддержка кошелька, меньшая поддержка программ индексирования / запросов, сокращение легальной валюты). каналы и др.).
Внедрение новых реестров активов является одним из способов достижения гибкости, но оно редко повышает ценность и почти всегда приводит к техническим и социальным сложностям, не принося в конечном итоге особой выгоды разработчикам приложений.
Расширенный DA не требует повторной ипотеки
Вы также услышите, как сторонники модульности говорят о перезакладывании в контексте масштабирования. Это наиболее умозрительный аргумент сторонников модульных цепочек, но его стоит обсудить.
В нем примерно говорится, что из-за рестейкинга (например, с помощью таких систем, как EigenLayer) вся криптоэкосистема может перестейкинг ETH бесконечное количество раз, расширяя возможности неограниченного количества уровней DA (например, EigenDA) и уровней исполнения. Таким образом, обеспечивая повышение стоимости ETH, масштабируемость решается со всех сторон.
Несмотря на огромную неопределенность между текущей ситуацией и теоретическим будущим, мы считаем само собой разумеющимся, что все предположения стратификации работают так, как рекламируется.
DA Ethereum в настоящее время составляет около 83 КБ/с. С появлением EIP-4844 позднее в этом году эта скорость может примерно удвоиться и составить примерно 166 КБ/с. EigenDA может добавить дополнительные 10 МБ/с, но требует другого набора предположений о безопасности (не все ETH будут повторно обеспечены EigenDA).
Для сравнения, Solana в настоящее время предлагает скорость DA около 125 МБ/с (32 000 фрагментов на блок, 1280 байт на фрагмент, 2,5 блока в секунду). Solana намного эффективнее Ethereum и EigenDA. Кроме того, DA Соланы со временем расширяется в соответствии с законом Нельсона.
Существует много способов расширить DA посредством повторного залога и модульности, но эти механизмы сегодня просто не нужны и создают значительные технические и социальные сложности.
Создано для разработчиков приложений
После многих лет размышлений я пришел к выводу, что модульность не должна быть самоцелью.
Блокчейн должен обслуживать своих клиентов (то есть разработчиков приложений), поэтому блокчейн должен абстрагировать сложность уровня инфраструктуры, чтобы разработчики могли сосредоточиться на создании приложений мирового класса.
Модульность — это здорово. Но ключом к созданию выигрышной технологии является выяснение того, какие части стека необходимо интегрировать, а какие оставить другим. На данный момент интеграция DA и цепочек выполнения по своей сути обеспечивает более простой опыт работы с конечными пользователями и разработчиками и в конечном итоге обеспечит лучшую основу для лучших в своем классе приложений.
Исходная ссылка
Эта статья перепечатана из Foresight News с разрешения.
Эта статья Мультикоин-партнер учреждения венчурного капитала: почему модульный блокчейн переоценен впервые появилась на Zombit.