Это первая версия личных учебных заметок @megaeth_labs. Если вам интересно, вы можете посмотреть. Будучи фактическим рубежом инноваций в области блокчейна, Ethereum заслуживает внимания. Мой личный уровень ограничен. Если есть какие-либо ошибки или упущения, пожалуйста, укажите и спасибо.
1. Три характеристики и текущие ограниченные случаи:
высокая пропускная способность транзакций, высокая пропускная способность
Лучший opBNB отличается чрезвычайно высокой скоростью передачи газа в 100 МГаз/с, но она все еще очень низка по сравнению с возможностями серверов web2. 100 МГаз/с эквивалентны 650 свопам uniswap или 3700 передачам ERC20 в секунду, в то время как современные серверы в расчете на один бит. второе. Может быть выполнено более 1 миллиона транзакций.
огромные вычислительные мощности, огромные вычислительные мощности
Сложные приложения не могут быть загружены в цепочку и в основном ограничены вычислительной мощностью. Если контракт EVM используется для расчета чисел n-Фибоначчи, требуется 5,5 миллиардов газов, что требует скорости вычислений 100 МГаз/с, что занимает 55 секунд. всей сети opbnb. Традиционно программа, написанная на языке C, занимает всего 30 мс. Скорость одноядерного процессора увеличилась в 1833 раза
и, что наиболее уникально, время отклика на уровне миллисекунд даже при большой нагрузке.
За исключением арбитража, другим основным блокчейнам второго уровня требуется более 1 секунды времени генерации блока для обновления статуса цепочки. Это невозможно для приложений, требующих высокой скорости обновления и быстрого цикла обратной связи. Например, самодельные миры и игры на цепочке требуют времени отклика в пределах 100 мс, а высокочастотная торговля требует времени отклика 10 мс для размещения или отмены ордеров, иначе ничего из этого достичь невозможно.
2. Как выйти за рамки производительности
Текущая архитектура блокчейна (L1)
Каждый блокчейн состоит из двух основных компонентов, включая консенсус и исполнение.
Консенсус определяет порядок пользовательских транзакций, а исполнение обрабатывает эти транзакции в установленном порядке для обновления состояния блокчейна. В большинстве блокчейнов L1 каждый узел выполняет одну и ту же задачу без специализации. Каждый узел участвует в распределенном протоколе, достигает консенсуса, а затем выполняет транзакции локально. Каждый L1 должен решить, насколько он может повысить требования к оборудованию для обычных пользователей, чтобы управлять узлами, не ставя под угрозу фундаментальные свойства блокчейна, такие как безопасность и устойчивость к цензуре.
Поэтому очень важны эксплуатационные требования полных узлов, связанные с безопасностью и устойчивостью к цензуре.
Новая парадигма уровня 2
Природа блокчейна L2 неоднородна и по своей сути различна. Различные узлы L2 специализируются на более эффективном выполнении конкретных задач.
megaETH делает еще один шаг вперед и отделяет (отключает) задачи выполнения транзакций от полных узлов. В частности, megaETH имеет три роли: секвенсоры (секвенсоры), пруверы (сертификаторы) и полные узлы (полные узлы).
Первый ключ — мощный централизованный сортировщик
Секвенсоры: отвечают за упорядочивание и выполнение транзакций, но megaeth отличается тем, что в любой момент времени существует только один активный секвенсор, что устраняет накладные расходы на согласование во время нормального выполнения. Большинство полных узлов получают различия состояний от этого заказа через сеть p2p, а затем применяют различия напрямую для обновления своего локального состояния, но они не выполняют транзакции повторно, а проверяют блоки косвенно посредством доказательств, предоставленных проверяющим. Опытные пользователи (операторы мостов и маркет-мейкеры) по-прежнему могут выполнять каждую транзакцию для достижения окончательности как можно быстрее, но это требует более высоких требований к оборудованию, чтобы не отставать от секвенсора. Наконец, проверяющие используют схему проверки без сохранения состояния для асинхронной и неупорядоченной проверки блоков.
Специализация узлов очень важна. Хотя генерация блоков более централизована, блокчейн более децентрализован. Например, для секвенсора требуется сервер более высокого класса, а сервер, необходимый для полного узла, стоит очень дешево.
Помимо мощных централизованных серверов существуют и более сложные инженерные реализации.
Если вы полагаетесь только на мощные серверы, в эксперименте Reth может достичь только 1000TPS, что составляет около 100 МГаз/с. В основном это связано с ограничением обновления MPT (структуры данных, используемой Ethereum) в каждом блоке, что быстрее, чем у Ethereum. расчет оформления самой сделки Стоимость в 10 раз выше.
Таким образом, мы все еще сталкиваемся со многими сложными ситуациями.
3. Дизайн мегаETH
измеряйте, затем стройте, сначала измеряйте, чтобы найти реальные проблемы, ограничения производительности, а затем проектируйте новую систему, чтобы решить все проблемы одновременно.
Стремится разрабатывать системы, достигающие аппаратных ограничений, не любит поэтапное проектирование и предпочитает новые конструкции, близкие к теоретическим ограничениям.
Ниже приведены несколько проблем и решений, возникших в процессе проектирования.
Исполнение транзакции Исполнение транзакции
Начнем с секвенсора. Многие говорят, что EVM является причиной плохой производительности и низкого tps L2, но это неверно. Согласно тесту megaeth, evm может достигать 14 000 tps, что и так очень много.
Однако этого недостаточно для блокчейна реального времени. Традиционная реализация EVM имеет три проблемы неэффективности, а именно.
Высокая задержка доступа к состоянию: доступ и чтение состояния блокчейна происходит медленно, поскольку оно хранится на жестком диске и требует многократного чтения.
Решение: Узел заказа оснащен достаточным объемом оперативной памяти для сохранения всего состояния блокчейна. В настоящее время объем оперативной памяти Ethereum составляет около 100 ГБ. Этот метод значительно ускоряет доступ к состоянию за счет устранения задержки чтения SSD.
Отсутствие параллельного выполнения: поскольку транзакции выполняются последовательно, чтобы обеспечить согласованность состояния и двойные расходы, параллельное выполнение затруднено.
Решение. Для этого сценария уже существуют обходные пути, но даже если он будет решен, фактическое ускорение, достижимое в реальном производстве, по своей сути ограничено параллелизмом, доступным в рабочей нагрузке. Согласно тестированию, фактический средний параллелизм Эфириума в последнее время составляет менее 2, что указывает на ограниченный параллелизм. На самом деле суть в том, что разные транзакции в Ethereum имеют большое количество зависимостей и даже чтение и запись объектов в одном и том же состоянии, что приводит к конфликтам в параллелизме. Эту проблему необходимо решить.
Накладные расходы интерпретатора: дополнительные накладные расходы, вызванные виртуальной машиной или интерпретатором при выполнении смарт-контрактов.
Решение: относительно большая часть опкодов уже встроена в Rust, поэтому получить выгоду от компиляции сложно, а максимальный коэффициент может быть только в 2 раза быстрее.
В дополнение к проблемам, с которыми сталкиваются эти три основных высокопроизводительных блокчейна, существуют еще две проблемы для достижения уровня блокчейна в реальном времени с уровнем 10 мс. Первая — это высокочастотное последовательное производство блоков, например, каждый блок генерируется. 10 мс. Во-вторых, механизм параллельного выполнения должен поддерживать определение приоритетов транзакций, чтобы критические транзакции могли обрабатываться без задержек в очереди даже в периоды пиковой перегрузки.
Государственная синхронизация
Синхронизация состояний — это процесс приведения полных узлов в соответствие с секвенсором, что является одним из наиболее сложных аспектов проектирования высокопроизводительного блокчейна.
Если передачи и транзакции uniswap передаются 100 000 раз в секунду, для них потребуется полоса пропускания 152,6 Мбит/с и 476,1 Мбит/с соответственно, что намного больше, чем полоса пропускания 100 Мбит/с полного узла. Более того, эти 100 Мбит/с, вероятно, будут использованы только на одну треть. Фактическая пропускная способность, используемая для синхронизации, может составлять всего 25 Мбит/с, что значительно отличается от реальных требований.
Обновить корень состояния
Концепция очень сложна. Согласно структуре данных MPT, для обновления корня состояния необходимо прочитать и записать множество конечных и дочерних узлов. Это рассчитывается с использованием 100 000 передач. Если вычисляется только чтение, около 6 миллионов не-. требуется время кэширования. Даже если предположить, что каждое чтение базы данных может быть обработано одним дисковым вводом-выводом, 6 миллионов операций ввода-вывода в секунду — это далеко за пределы возможностей любого потребительского твердотельного накопителя сегодня, и для этого расчета даже не требуется запись. операции во внимание.
Общая стратегия оптимизации для уменьшения дискового ввода-вывода состоит в том, чтобы сгруппировать несколько узлов дерева в поддерево и сохранить их на дисковой странице размером 4 КБ. Но все равно в 6 раз ниже, чем мы просили.
Блокировать лимит газа
Для безопасности и надежности блокчейна мы должны установить разумные ограничения на газ.
инфраструктура
Наконец, пользователи не взаимодействуют напрямую с узлами секвенсора, и большинство людей не запускают полные узлы дома. Вместо этого пользователи отправляют транзакции на сторонний узел RPC и полагаются на dApp или обозреватель блокчейна, такой как веб-интерфейс http://etherscan.io/, для подтверждения результатов транзакции.
Таким образом, реальный пользовательский опыт блокчейна во многом зависит от его поддерживающей инфраструктуры, такой как узлы RPC и индексаторы. Независимо от того, насколько быстро работает блокчейн в реальном времени, если узлы RPC не могут эффективно обрабатывать большое количество запросов на чтение в часы пик, быстро передавать транзакции на узлы сортировки или индексаторы не могут обновлять представления приложения достаточно быстро, чтобы не отставать, Тогда это не имеет значения.
Масштабирование блокчейна с принципиальным подходом
Привержен целостному и принципиальному подходу к исследованиям и разработкам. Проводя углубленный анализ производительности на раннем этапе, мы обеспечиваем сосредоточенность на решении проблем, которые приносят реальную пользу нашим пользователям. На самом деле, ключом является общий, глубокий и пользовательский взгляд.
4. Ожидаемые типы приложений
• игра
• Децентрализованная физическая инфраструктура (dePin), требующая вычислений в реальном времени.
• Автономный мировой двигатель
• Децентрализованная сеть VPN.
• Трансграничные платежи
• Используйте высокочастотную торговлю с чрезвычайно низкой задержкой (ончейн Binance?)
На самом деле, в прикладной части должно быть много места для воображения. Я прослушал множество подобных тем и чувствую, что мышление каждого все еще недостаточно хорошее.