RISE: высокопроизводительный ролл-ап
Samuel Battenally Hai Nguyen Thanh Nguyen
RISE Labs
Аннотация
Мы представляем RISE, инновационную платформу второго уровня (L2), разработанную для решения насущных проблем с производительностью в ролл-ап экосистеме Ethereum. Несмотря на заметные достижения, текущие решения Ethereum L2 отстают по пропускной способности транзакций, значительно уступая конкурентам, таким как Solana. RISE использует параллельную виртуальную машину Ethereum (EVM), конвейер непрерывного выполнения и новую архитектуру обеспечения доступа к состоянию, построенную на основе инфраструктуры нод Reth на языке программирования Rust, чтобы существенно повысить пропускную способность и производительность. Основной целью RISE является достижение цели The Surge [4], 100,000 транзакций в секунду (TPS), с возможностью дальнейшего масштабирования. В этом документе подробно рассматриваются проблемы существующих L2 технологий, архитектурные инновации RISE и будущие направления оптимизации масштабируемости и эффективности блокчейна. RISE обещает соответствовать и превосходить по производительности решения первого уровня (L1), устанавливая новый стандарт в блокчейн-технологиях.
1 Вступление
1.1 Технологический ландшафт
Когда в июле 2015 года Виталик Бутерин впервые запустил блокчейн Ethereum [1], он не только развивал основополагающую технологию, представленную биткоином [2], но и стал пионером глубоко инновационной концепции: смарт-контрактов. С тех пор смарт-контракты открыли возможности для применения и глобальной координации, о которых до их появления даже не мечтали. Очевидно, что мир осознает потенциал этой невероятной технологии, однако в ходе ее внедрения были выявлены проблемы масштабирования, которые в конечном итоге привели к разработке Ethereum Endgame, предложенной Виталиком Бутериным [3], которая переросла в дорожную карту Ethereum Roadmap [4]. Основным компонентом дорожной карты является The Surge, целью которого является достижение 100,000 транзакций в секунду и выше на роллапах. Arbitrum и Optimism сыграли значительную роль в достижении этой цели, продемонстрировав EVM роллапы как неоспоримое решение для масштабирования, но их пропускная способность оставляет желать лучшего [5][6]. Технология готова к появлению второго поколения роллапов, ориентированных на производительность, чтобы устранить этот пробел. Благодаря последним инновациям The Surge становится реальностью, Виталик утверждает, что мы достигаем экспоненциальной составляющей S-кривой возможностей [7]; RISE призван раскрыть эти быстрые изменения и открыть следующую волну приложений, о которых никто еще не мечтал.
1.2 Вступление
Ролл-ап экосистема Ethereum добилась значительных успехов в повышении блокчейн-масштабируемости, безопасной поддержке различных приложений и получении значительной рыночной стоимости. Однако даже несмотря на эти успехи, совокупная пропускная способность экосистемы второго уровня (L2) обычно обрабатывает около 100 транзакций в секунду (TPS)[8], что далеко не соответствует производительности конкурентов, таких как Solana, которая стабильно достигает более 1000 TPS, что в десять раз больше, чем у всех L2 вместе взятых[9]. Solana добилась этого благодаря приоритету масштабируемости над децентрализацией, меньшему количеству валидаторов и высокой эмиссии для финансирования дорогостоящей инфраструктуры, и ее внедрение свидетельствует о том, что рынок поддерживает прагматичный подход к масштабированию. Успех Solana и различие в производительности между Solana и L2 также дает понять, что существует спрос на высокопроизводительные и недорогие EVM L2, но этот спрос не удовлетворяется существующими на сегодняшний день технологиями.
Мы представляем RISE, следующее поколение оптимистичных Ethereum Virtual Machine (EVM) ролл-ап стеков. Разработанный с нуля, RISE ориентирован на максимизацию пропускной способности транзакций для достижения амбициозной цели в 100,000 транзакций в секунду (TPS), обозначенной в дорожной карте Ethereum. Исторически доступность данных (DA) была основным узким местом для роллапов, но последние достижения, такие как EigenDA и EIP-4844, значительно сгладили эту проблему. Теперь проблема переходит к производительности выполнения. Для решения проблемы производительности RISE объединяет лучшие технологии, предлагаемые современными исследованиями, и новые инновации, включая параллельное выполнение EVM, непрерывное исполнение блоков и инновационный дизайн для доступа к состоянию. Все это интегрировано в надежную инфраструктуру Reth-нод, основанную на Rust.
Стек RISE ориентирован на вокруг роллапное будущее; для обеспечения гибкости развертывания стеки Sequencing и DA не зависят друг от друга, что позволяет деплоерам приложений на RISE чейне выбирать индивидуальные стеки Sequencing и DA. Основой стека RISE является высокопроизводительное исполнение. Не только основная сеть RISE будет поддерживать пропускную способность, соответствующую самым производительным сетям первого уровня (L1), но и любое количество сетевых приложений RISE.
В данной статье представлен стек технологий исполнения RISE и его инновационные возможности в области производительности. Однако в ней не рассматривается взаимодействие RISE с помощью совместного секвенсирования; этот вопрос будет рассмотрен в будущих работах команды RISE Labs.
1.3 Состояние роллапов
Подход Ethereum к масштабированию, как утверждается, был успешным. С февраля 2024 года в L2 хранится более 40 миллиардов долларов, а средняя скорость транзакций в секунду (TPS) превышает 100 [2]. В настоящее время запущено более 40 роллапов, и мы являемся свидетелями первых дней горизонтального масштабирования Ethereum. Этот рост не был беспрепятственным: отсутствие общего состояния приводит к фрагментации приложений, пользователей и ликвидности. Учитывая рост горизонтального масштабирования в L2, справедливо заключить, что вертикальное масштабирование столкнулось с ограничениями и антисетевыми эффектами, замедляющими принятие и активность в отдельных роллапах.
Это становится еще более очевидным, когда мы сравниваем внедрение и производительность L2 с самым производительным конкурентом, Solana. В марте 2024 года средний показатель Solana составил около 1000 TPS [2], что в десять раз больше, чем у всех L2 на Ethereum вместе взятых. Arbitrum и Base достигли примечательных максимумов TPS - 532 TPS и 293 TPS. Однако во время пиковой перегрузки обе сети испытывали перебои, в то время как Solana стабильно поддерживает 2000+ TPS в одиночку. Solana добилась значительных успехов в Ethereum, несмотря на попутный ветер EVM, что еще больше укрепляет вывод о неудовлетворенном спросе на производительные L2.
1.4 Выбор виртуальной машины
Попутный ветер EVM очень мощный: в EVM больше живых продуктов, больше инвестиций, больше активных талантов и больше пользователей, чем в любой другой виртуальной машине для смарт-контрактов [10]. Создание технологии для поддержки 100,000 TPS не имеет смысла без принятия разработчиками и пользователями. В EVM есть конструктивные решения, которые делают масштабирование чрезвычайно сложным; однако с попутным ветром EVM слишком трудно бороться; поэтому RISE фокусируется исключительно на EVM-совместимом L2-стеке.
1.5 Нулевые знания против оптимизма
В последнее время zkEVM L2 добились значительного прогресса, внедрение находится на рекордно высоком уровне, а скорость тестирования стремится к максимуму. Целью RISE является начало The Surge [6] и достижение цели в 100,000 TPS. В будущем это станет возможным с помощью zkEVM, хотя для этого потребуются аппаратные решения, такие как zkASIC, которые должны стать доступными [x]. Однако при оптимистичном развитии событий мы уверены, что высокая пропускная способность может быть достигнута без необходимости в собственном аппаратном ускорении. В связи с этим команда RISE первоначально сосредоточится на оптимистичном стеке и перейдет на zkEVM, как только подходящее оборудование станет доступным.
1.6 Структура документа
В этом документе мы начинаем второй раздел с определения проблем производительности, с которыми приходится сталкиваться при создании высокопроизводительного роллап-стека; в третьем разделе мы представим подробное описание технологического стека RISE, а в четвертом разделе мы расскажем о дальнейшей работе и заключительных замечаниях.
2 Проблемы, связанные с производительностью
Основной проблемой производительности, с которой до сих пор сталкивались L2, была доступность данных (ДД). Однако благодаря инновациям во внешних ДД, таким как Celestia и eigenДД, и закрепленным решениям, таким как EIP-4844 [8], это уже не так важно. Теперь мы наблюдаем появление множества других узких мест, таких как сеть, исполнение, ограничения на размер блока, ограничения на доказательство мошенничества, меркелизация и ввод-вывод из хранилища. Казалось бы, за одну ночь производительность L2 превратилась в захватывающее и сложное пространство для проектирования с различными направлениями.
2.1 EVM исполнение
Большинство реализаций EVM исполнения являются однопоточными. Из-за этого сегодня максимальный предел производительности диктуется тактовой частотой одного процессора. Переход к параллельной модели исполнения также нетривиален, поскольку транзакции в блоке по своей природе последовательны.
2.2 Доступ к Ethereum состояниям
Ethereum требует наличия аутентифицированных структур данных, закодированных в виде модифицированных триз Меркла-Патриция (МПТ), для хранения и аутентификации своих данных типа «ключ-значение».
К сожалению, доступ к хранилищу в Ethereum медленный по нескольким причинам.
- Данные ключ-значение не хранятся в базе данных; они кодируются в МПТ, который хранится в базе данных. Поэтому чтение/запись ключа на уровне приложения усиливается до нескольких чтений/записей в бэкэнд базы данных. Такое усиление чтения/записи приводит к низкой скорости хранения, а значит, и к низкой пропускной способности.
- Операция записи требует многократного повторного вычисления хэша для всех внутренних нод на пути МПТ.
- И наконец, самое главное, ввод/вывод данных из хранилища является синхронным, то есть потоки выполнения должны дождаться завершения дорогостоящих операций чтения/записи, прежде чем продолжить обработку следующей транзакции.
Последствия этого весьма значительны. Раздутие состояния приводит к антисетевому эффекту. По мере роста состояния увеличивается и средняя глубина древа, что еще больше замедляет доступ к хранилищу. Кроме того, корень МПТ должен вычисляться заново в каждом блоке, в результате чего значительная часть времени выполнения уходит на Мерклеизацию.
2.3 Хранилище IO
Хранилище состояний не является явным элементом концепции EVM; клиенты нод могут свободно применять инновационные решения для хранения данных. LevelDB, PebbledDB и MDBX - все эти хранилища ключевых значений используются в Ethereum и клиентах второго уровня, однако они не являются встроенными хранилищами аутентифицированных ключевых значений (AKVS). Нативное AKVS-решение имело бы свои преимущества, однако на сегодняшний день подходящих FOSS-решений нет.
2.4 Размер блока
Очевидным ограничением Layer 2 является ограничение по количеству газа в блоке. Эта конфигурация легко увеличивается, если система может поддерживать более высокую пропускную способность. Однако увеличение лимита блоков может повлиять на систему защиты от мошенничества. Если претенденты будут предоставлять для доказательства мошенничества целый блок, они рискуют столкнуться с ограничениями на размер блока в Ethereum.
2.5 Производство блоков Layer 2
Все клиенты L2 изначально были клиентами Ethereum и часто продолжают придерживаться концепций L1. Конвейер производства блоков для L2 по своей сути отличается от L1. Это открывает возможности для оптимизации и распараллеливания конвейера производства блоков в секвенсоре L2 и клиенте исполнения.
2.6 Интероперабельность и децентрализация
Взаимодействие через совместное секвенирование станет значительным открытием для Layer 2, а децентрализация секвенсоров также является важным шагом. Каждый из них вводит ограничения на исполнение и секвенсор, которые необходимо учитывать при создании перспективной системы.
3 Системный дизайн RISE
3.1 Сетевая архитектура RISE
Система RISE переосмысливает статус-кво архитектуры сетей L2. Сегодня клиенты нод в сетях L2 осуществляют каждую транзакцию, проходящую через сеть. Однако этап выполнения не улучшает модель безопасности сети; ноды полагаются на систему защиты от мошенничества для обеспечения надежности. Изучая опыт Solana, RISE использует преимущества разнообразия вычислительных систем; клиенты нод RISE не выполняют ненужных транзакций, что позволяет использовать высокопроизводительный и дорогой секвенсор, или «исполнитель» (см. раздел 3.1.1), сохраняя при этом приемлемую стоимость нод.
3.1.1 «Исполнитель»
Сегодня в отрасли бытует ошибочное мнение, что компании Layer 2 получают свой доход за счет секвенсирования. Это правда, что в секвенсировании есть своя ценность, но она должна быть извлечена за счет пользователя через MEV. Сегодня ни один крупный L2 не участвует в извлечении ценности из своих пользователей по очевидным причинам. Доходы, получаемые сегодня роллапами, в основном связаны с исполнением; L2 предлагают исполнение как продукт. Здесь мы вводим термин «исполнитель» - сторона, ответственная за выполнение транзакций в блоках, поддержание состояния сети, генерирование корня состояния и предоставление различий в состоянии секвенсору и более широкой сети. Спецификации исполнителя настраиваются в соответствии с требованиями конкретного развертывания сети RISE, будь то сетевое приложерние или мейннет RISE.
3.1.2 Высокопроизводительный исполнитель
Разблокировав высокопроизводительный исполнитель, мы не только можем масштабировать производительность с помощью более высокой тактовой частоты и большего количества ядер, но и вспомнить о влиянии ввода-вывода из хранилища на производительность, а также устранить эти накладные расходы путем кэширования наиболее важных состояний в оперативной памяти.
3.2 Непрерывный конвейер блоков
Процесс производства блока в L2 состоит из следующих последовательных шагов [13]:
- Консенсус при формировании транзакций L1 и новых атрибутов блока
- Выполнение производных транзакций
- Получение транзакций из пула памяти и их выполнение
- Подготовка заголовка и вычисление корня состояния
Как правило, эти шаги выполняются последовательно; на рисунке ниже показан типичный конвейер создания блоков для L2 с односекундным временем блокировки и большим состоянием. Лимит газа в блоке будет ограничен тем, сколько газа может быть обработано за время, отведенное на выполнение; однако в этой системе на выполнение отводится лишь малая часть конвейера построения блока. На практике C потребляет 40-80 % времени блока, а по мере роста состояния R потребляет до 60 % оставшегося времени выполнения. В худшем случае на выполнение E и FE будет отводиться только 8 % времени блока, что является эффективным, а ограничения на газ в блоках должны тщательно учитывать худший сценарий, чтобы избежать временного дрифта в блоке и реорганизации.
RISE представляет Continuous Block Pipeline (CBP) - параллельный конвейер блоков с параллельными этапами и потоком непрерывного выполнения (CE). Поток CE отслеживает транзакции в мемпуле и выполняет их в нескольких сегментах блока, больше не ожидая консенсуса для запроса нового блока. Вспомним наихудший сценарий с 8%-ным исполнением; для сравнения, CBP выполняет транзакции почти 100% доступного времени. Вычисление корня состояния также происходит параллельно с выполнением.
3.3 Параллельное EVM исполнение
Здесь мы представляем еще один уровень распараллеливания, теперь уже на уровне исполнения. EVM требует последовательного исполнения; если это требование не выполняется, недетерминированные результаты нарушают консенсус. Однако в RISE большинство транзакций выполняется параллельно. В RISE используется Block-STM, впервые представленный Аптосом [11]. Основная техника Block-STM заключается в том, чтобы взять блок и оптимистично выполнить все транзакции параллельно, при этом одним из результатов является наличие зависимостей между транзакциями. Транзакции, не имеющие зависимостей, завершаются, а транзакции с общими зависимостями выполняются последовательно. В этом есть дополнительная сложность, хотя это и есть основная техника Block-STM.
3.3.1 Предварительная обработка мемпула
В отличие от предыдущих роллапов, которые упорядочивали транзакции по принципу «первым пришел - первым обслужен» или газовых аукционов, RISE использует новую структуру мемпулов, которая балансирует между задержкой и пропускной способностью. Цель заключается в предварительном упорядочивании транзакций, чтобы минимизировать общие состояния и максимизировать параллельное выполнение. Это имеет относительно схожий эффект с локальным рынком газовых комисий на Solana, где перегруженные контракты и состояния стоят дороже в отношении газа и ожидания. Поскольку количество потоков для выполнения транзакций гораздо меньше, чем предполагаемый TPS, мы все равно можем организовать выделенные потоки для последовательного выполнения контрактов с высоким трафиком, а остальные - параллельно в других потоках.
3.4 Уровневые МПТ
Напомним, что доступ к состоянию Ethereum существенно влияет на пропускную способность; наше первоначальное решение - хранить весь МПТ в памяти, чтобы уменьшить накладные расходы на чтение/запись. К сожалению, представление состояния может вырасти чрезвычайно большим. RISE будет обрабатывать сотни тысяч транзакций в секунду, поэтому состояние, скорее всего, будет расти очень быстро. По мере роста состояния хранение всего МПТ в памяти становится нецелесообразным, хотя хранение небольшой его части вполне возможно. Например, мы можем хранить часто используемые адреса (например, Uniswap, USDT, мосты и т. д.) в памяти для более быстрого чтения/записи.
Мы проводим ряд оптимизаций для обеспечения высокоскоростного доступа к памяти, таких как разделение операций чтения/записи и кэширование МПТ. Вместо того чтобы использовать единый МПТ для состояния, мы добавляем меньшие промежуточные МПТ в памяти поверх существующего МПТ на диске, чтобы уменьшить усиление операций чтения и записи от дискового хранилища с высокой задержкой. Наш дизайн, вдохновленный [11], состоит из трех различных МПТ, действующих как кэши для доступа к данным.
- Снепшот МПТ (СМПТ). СМПТ - это то же самое, что и обычный МПТ, используемый в клиенте Ethereum, за исключением того, что СМПТ хранит только снепшот блокчейн состояния высоты блока, а не наиболее свежее состояние блокчейна. СМПТ хранится на диске, поэтому доступ к СМПТ требует больших затрат.
- Промежуточный МПТ (ПМПТ). ПМПТ строится поверх СМПТ и хранится в памяти.
- Дельта МПТ (ДМПТ). ДМПТ строится поверх ИМПТ и также хранится в памяти. ДМПТ хранит самые последние данные блокчейна и является местом, где происходят новые обновления.
Рисунок. Имеется три МПТ, два из которых хранятся в памяти (зеленые), а самый большой - на диске (желтый). При записи данные обновляются в ДМПТ и периодически выгружаются на диск. Чтение сначала обращается к ДМПТ в поисках данных, если их нет, то запрашивает ПМПТ и доходит до СМПТ, если в первых двух МПТ нет запрашиваемых данных.
Записи операций обновляются на ДМПТ, который находится в памяти. В ДМПТ, скорее всего, хранятся данные наиболее часто используемых счетов, таких как USDT или Uniswap, поэтому обновления на этих счетах будут происходить очень быстро. При доступе на чтение запрос сначала обращается к ДМПТ. Если данные не найдены, он продолжит поиск в ПМПТ и, наконец, если данные не найдены в двух предыдущих МПТ, будет произведен поиск в СМПТ.
Чтобы ДМПТ и ПМПТ были достаточно эффективными и умещались в памяти, через заданный интервал времени обновления в этих древах сбрасываются на диск с помощью операций слияния. Операция слияния состоит из следующих шагов.
- Изменения в ПМПТ передаются в СМПТ для создания новой контрольной точки.
- ДМПТ становится новым ПМПТ.
- Новый ПМПТ очищается.
Обратите внимание, что выбор интервала влияет на производительность системы. Если интервал слишком мал, ДМПТ и ПМПТ будут слишком малы, чтобы вместить достаточно кэшированных данных, и операции слияния будут происходить очень часто. Если интервал слишком большой, ДМПТ и ПМПТ будут слишком большими, чтобы поместиться в памяти.
3.4 Дополнительные улучшения
Некоторые дополнительные сетевые возможности, которые вносят свой вклад в стеки RISE, включают альтернативные сети и JIT-компиляцию.
3.4.1 Сетевая работа
Исполнитель будет подключен к тысячам нод, и каждое из этих соединений имеет накладные расходы. В сети RISE используется протокол QUIC, альтернатива традиционному TCP, который, помимо прочего, обеспечивает более быстрое установление соединений и уменьшение задержек.
3.4.2 JIT-компиляция
Just-in-time допускает собственное выполнение VM, а не выполнение через интерпретатор. JIT будет оказывать инкрементное воздействие на этап выполнения EVM в стеке RISE.
4 Заключение
4.1 Будущая работа
Уровневые МПТ работают как кэш-слои для доступа к состоянию, чтобы помочь снизить коэффициент повышения частоты обращений к адресам ввода-вывода. Однако для дальнейшего раскрытия возможностей высокопроизводительных EVM неизбежно удаление дополнительных структур данных, таких как B-древа или LSM- древа. RISE DB является текущим исследовательским проектом в этом направлении. В идеале мы используем нативную структуру данных в виде древ в качестве индекса на диске, который никогда не нужно сжимать, в сочетании с несколькими низкоуровневыми оптимизациями доступа к диску, чтобы значительно снизить накладные расходы на ввод-вывод.
RISE строит будущее, ориентированное на роллапы, где роллап - это синоним сервера, а приложения обладают суверенитетом над своим пространством блоков. Рынок ценит пространство блоков гораздо больше, чем приложения, которые создают спрос на это пространство. Мы прогнозируем будущее, в котором приложения развертывают суверенные роллапы, владея своим пространством блоков и той ценностью, которую они привлекают к нему. Однако с сегодняшней технологией это невозможно: инфраструктура роллапов не поддерживает производительность и совместимость, необходимые многим приложениям. Отсутствие атомарной совместимости (Universal Synchronous Composability) между роллапами не позволяет приложениям использовать возможности смежных приложений в своих интересах. RISE стремится решить обе эти проблемы - непосредственно производительность и косвенно совместимость - путем совместной работы с другими новаторами в этой области. В этом документе речь идет исключительно о производительности; исследовательская группа RISE Labs будет работать над решением проблемы атомарной совместимости для роллапов.
4.2 Выводы
Разработка RISE представляет собой значительный шаг вперед в эволюции масштабируемости и блокчейн производительности. В этом документе рассматриваются проблемы, с которыми сталкиваются существующие технологии второго уровня в экосистеме Ethereum, и представляется RISE как инновационное решение, призванное преодолеть эти ограничения. Благодаря внедрению параллельного EVM, усовершенствованных процессов выполнения и инновационных дизайнов баз данных, RISE стремится к амбициозной пропускной способности в 100,000 TPS, устанавливая тем самым новый стандарт в области блокчейн-технологий.
Постоянное развитие RISE направлено не только на удовлетворение текущих потребностей, но и на прогнозирование и внедрение инноваций для решения будущих задач в блокчейн пространстве. Мы приглашаем сообщество присоединиться к нам в этом захватывающем путешествии, поскольку мы работаем над созданием более масштабируемой, эффективной и инклюзивной блокчейн экосистемы.
Выражение благодарности
Мы выражаем благодарность всем тем, кто проложил путь к развитию технологий Ethereum масштабируемости и роллап технологиям. В частности, мы отмечаем основополагающую работу и значительный вклад команд Arbitrum и Optimism. Их новаторские усилия в области оптимистичных роллапов доказали, что роллапы являются жизнеспособным вариантом масштабирования для Ethereum.
Мы также благодарны команде Reth за создание клиента исполнения, на котором строится RISE. Модульность и производительность, которые предлагает Reth, очень важны для RISE, а их команда является передовым лидером в этой области. Мы надеемся отплатить им взаимностью, внося свой вклад в развитие Reth по мере возможности.
Справочная информация
[1] Бутерин, В. (2014). Ethereum: Платформа следующего поколения для смарт-контрактов и децентрализованных приложений. Заимствовано с https://ethereum.org/content/whitepaper/whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2 014.pdf.
[2] Nakamoto, S. (2008). Bitcoin: одноранговая система электронных денег. Заимствовано с https://bitcoin.org/bitcoin.pdf
[3] Бутерин, В. (2021, 6 декабря). Конец игры. Взято с https://vitalik.eth.limo/general/2021/12/06/endgame.html
[4] Понимание дорожной карты развития Ethereum, Получено 10 апреля 2024 года, с https://www.blocknative.com/blog/ethereum-roadmap-guide
[5] Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S. M., & Felten, E. W. (2018). Arbitrum: Масштабируемые приватные смарт-контракты. Принстонский университет. Получено с сайта https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-kalodner.pdf
[6] TPS, Max TPS, TTF, Block Time & Governance Model. (2024). Получено 14 апреля 2024 г. с https://chainspect.app/dashboard?range=30d
[7] Бутерин, В. [@VitalikButerin]. (2024, 29 марта). Что это значит в более широком смысле? Я утверждаю, что теперь, когда слияние и EIP-4844 завершены, мы находимся на правой стороне S-кривой. Дальнейшие изменения L1 будут весьма значительными и существенными, но относительно более мягкими. [X Post]. Взято с https://x.com/VitalikButerin/status/1773356271300706507
[8] Value Locked (2024). Взято 10 апреля 2024 года с https://l2beat.com/scaling/summary.
[9] Бутерин, В., и Бейко, Т. (2024). EIP-4844: Транзакции шардов-блобов. Ethereum Improvement Proposals. Взято 2 апреля 2024 года с https://eips.ethereum.org/EIPS/eip-4844.
[10] Electric Capital. (2023). 2023 Crypto Developer Report.
[11] Choi, J., Beillahi, S., Singh, S., Michalopoulos, P., Li, P., Veneris, A., & Long, F. (2022). LMPT: Новая структура данных с аутентификацией для устранения узких мест в хранении данных для высокопроизводительных блокчейнов. IEEE.
[12] Ethereum Optimism. (2024). Оптимизм: Оптимистичный Ethereum. Заимствовано с https://github.com/ethereum-optimism/optimism.
[13] Gelashvili, R., Spiegelman, A., Xiang, Z., Danezis, G., Li, Z., Malkhi, D., Xia, Y., & Zhou, R. (2022). Block-STM: масштабирование исполнения блокчейна путем преобразования заказного проклятья в благословение производительности. arXiv preprint arXiv:2203.06871. https://doi.org/10.48550/arXiv.2203.06871