Понимание монады

Средний5/21/2024, 2:17:47 AM
Масштабируемость транзакций всегда была актуальной темой, и в этой статье рассматривается, как Monad помогает расширить TPS (транзакции в секунду), а также подробное объяснение его работы. Узким местом не является повторное выполнение; узким местом является доступ к памяти Ethereum. Метод Ethereum хранения состояния в базе данных затрудняет доступ к состоянию (занимает много времени и, следовательно, дорого), что также является улучшением от Monad.

Привет,

Про масштабируемость транзакций говорит весь город. Мы изучаем, как Monad помогает увеличить TPS за последние несколько недель.

Примечание ниже - это разбор того, как работает Monad, написанный @desh_saurabh. Рассмотрите возможность регистрации наДецентрализованный.coесли вам нравится читать информацию, основанную на данных, о всем, что касается Web3. Увидимся на другой стороне!

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

Что мы делаем, если хотим увеличить TPS?

  1. Один из подходов - построить совершенно новую систему, как сделала Solana. Она жертвует совместимостью с EVM в пользу скорости. Она использует многопоточное выполнение вместо однопоточного (подумайте о многоядерном ЦП против одноядерного ЦП), параллельно выполняет транзакции и использует другой механизм консенсуса.
  2. Второй подход заключается в использовании внеблокчейн-исполнения и масштабировании Ethereum с централизованными последователями.
  3. Третий - это разбить EVM на отдельные компоненты и оптимизировать их для улучшения масштабируемости.

Манада, новый совместимый с EVM уровень 1, который недавно привлек $225 миллионов, строит EVM с нуля, а не использует его как есть. Он выбрал этот третий подход для увеличения масштабируемости.

Мы обсуждаем несколько значительных изменений, которые Monad вносит в игру.

Параллельное выполнение

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

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

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

То же самое относится к командам сортировки, сборки и погрузки. Как только грузовик разгружен, он перемещается на площадку погрузки и ожидает, когда команда погрузит собранные мотоциклы. Таким образом, склад с одной платформой и зоной погрузки/выгрузки выполняет все последовательно, а склад с 4 платформами и различными зонами погрузки/выгрузки параллелизует операции.

Рассмотрим Monad как инфраструктуру, эквивалентную складу с несколькими грузовыми платформами, но не такой простой. Сложность возрастает, когда грузовики зависят друг от друга. Например, что, если у одного грузовика нет всех деталей для изготовления 50 мотоциклов? Транзакции могут не всегда быть независимыми. Поэтому, когда Monad выполняет их параллельно, ему приходится иметь дело с транзакциями, зависящими друг от друга.

Как? Он выполняет что-то, называемое оптимистичным параллельным выполнением. Протокол может выполнять только независимые транзакции параллельно. Например, рассмотрим 4 транзакции с балансом Джоэла в 1 ETH -

  1. Joel отправляет 0.2 ETH Saurabh.
  2. Сид создает NFT.
  3. Джоэл отправляет 0.1 ETH Сиду.
  4. Шлок покупает PEPE.

Все эти транзакции выполняются параллельно с ожидающими результатами, которые фиксируются поочередно. Транзакции повторно выполняются, если ожидаемые результаты конфликтуют с исходными данными любой другой транзакции. Транзакции 2 и 4 не имеют ожидающих результатов, конфликтующих с данными других транзакций, поскольку они независимы друг от друга. Но 1 и 3 не являются независимыми.

Обратите внимание, что поскольку все 4 транзакции начинаются с одного и того же состояния, та, которая здесь важна, - это баланс Джоэла в 1 ETH. Результат отправки Джоэлом 0.2 ETH составляет 0.8 ETH. После того как Джоэл отправляет 0.1 ETH Сиду, его баланс составляет 0.9 ETH. Результаты фиксируются по одному, обеспечивая отсутствие конфликтов между любыми из входных данных. После фиксации ожидаемого результата 1 новый баланс Джоэла составляет 0.8 ETH.

Этот вывод конфликтует с вводом 3. Теперь 3 повторно выполняется с вводом 0,8 ETH. После выполнения 3 баланс Джоэла составляет 0,7 ETH.

MonadDb

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

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

Solana имеет 50k TPS на своей тестовой сети, но сейчас делает примерно 1k на основной сети. Monad утверждает, что достигла 10k реальных TPS на своей внутренней тестовой сети. Хотя это не всегда является показателем реальной производительности, мы с нетерпением ждем, чтобы увидеть, как работает Monad на свободе.

Утверждение:

  1. Эта статья, изначально названная «Понимание Монады», воспроизведена из [chaincatcher]. Все авторские права принадлежат оригинальному автору [Децентрализованный.Ко]. Если у вас есть возражения против перепечатки, пожалуйста, свяжитесь с Команда Gate LearnКоманда обработает это как можно скорее.

  2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционными советами.

  3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.

Понимание монады

Средний5/21/2024, 2:17:47 AM
Масштабируемость транзакций всегда была актуальной темой, и в этой статье рассматривается, как Monad помогает расширить TPS (транзакции в секунду), а также подробное объяснение его работы. Узким местом не является повторное выполнение; узким местом является доступ к памяти Ethereum. Метод Ethereum хранения состояния в базе данных затрудняет доступ к состоянию (занимает много времени и, следовательно, дорого), что также является улучшением от Monad.

Привет,

Про масштабируемость транзакций говорит весь город. Мы изучаем, как Monad помогает увеличить TPS за последние несколько недель.

Примечание ниже - это разбор того, как работает Monad, написанный @desh_saurabh. Рассмотрите возможность регистрации наДецентрализованный.coесли вам нравится читать информацию, основанную на данных, о всем, что касается Web3. Увидимся на другой стороне!

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

Что мы делаем, если хотим увеличить TPS?

  1. Один из подходов - построить совершенно новую систему, как сделала Solana. Она жертвует совместимостью с EVM в пользу скорости. Она использует многопоточное выполнение вместо однопоточного (подумайте о многоядерном ЦП против одноядерного ЦП), параллельно выполняет транзакции и использует другой механизм консенсуса.
  2. Второй подход заключается в использовании внеблокчейн-исполнения и масштабировании Ethereum с централизованными последователями.
  3. Третий - это разбить EVM на отдельные компоненты и оптимизировать их для улучшения масштабируемости.

Манада, новый совместимый с EVM уровень 1, который недавно привлек $225 миллионов, строит EVM с нуля, а не использует его как есть. Он выбрал этот третий подход для увеличения масштабируемости.

Мы обсуждаем несколько значительных изменений, которые Monad вносит в игру.

Параллельное выполнение

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

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

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

То же самое относится к командам сортировки, сборки и погрузки. Как только грузовик разгружен, он перемещается на площадку погрузки и ожидает, когда команда погрузит собранные мотоциклы. Таким образом, склад с одной платформой и зоной погрузки/выгрузки выполняет все последовательно, а склад с 4 платформами и различными зонами погрузки/выгрузки параллелизует операции.

Рассмотрим Monad как инфраструктуру, эквивалентную складу с несколькими грузовыми платформами, но не такой простой. Сложность возрастает, когда грузовики зависят друг от друга. Например, что, если у одного грузовика нет всех деталей для изготовления 50 мотоциклов? Транзакции могут не всегда быть независимыми. Поэтому, когда Monad выполняет их параллельно, ему приходится иметь дело с транзакциями, зависящими друг от друга.

Как? Он выполняет что-то, называемое оптимистичным параллельным выполнением. Протокол может выполнять только независимые транзакции параллельно. Например, рассмотрим 4 транзакции с балансом Джоэла в 1 ETH -

  1. Joel отправляет 0.2 ETH Saurabh.
  2. Сид создает NFT.
  3. Джоэл отправляет 0.1 ETH Сиду.
  4. Шлок покупает PEPE.

Все эти транзакции выполняются параллельно с ожидающими результатами, которые фиксируются поочередно. Транзакции повторно выполняются, если ожидаемые результаты конфликтуют с исходными данными любой другой транзакции. Транзакции 2 и 4 не имеют ожидающих результатов, конфликтующих с данными других транзакций, поскольку они независимы друг от друга. Но 1 и 3 не являются независимыми.

Обратите внимание, что поскольку все 4 транзакции начинаются с одного и того же состояния, та, которая здесь важна, - это баланс Джоэла в 1 ETH. Результат отправки Джоэлом 0.2 ETH составляет 0.8 ETH. После того как Джоэл отправляет 0.1 ETH Сиду, его баланс составляет 0.9 ETH. Результаты фиксируются по одному, обеспечивая отсутствие конфликтов между любыми из входных данных. После фиксации ожидаемого результата 1 новый баланс Джоэла составляет 0.8 ETH.

Этот вывод конфликтует с вводом 3. Теперь 3 повторно выполняется с вводом 0,8 ETH. После выполнения 3 баланс Джоэла составляет 0,7 ETH.

MonadDb

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

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

Solana имеет 50k TPS на своей тестовой сети, но сейчас делает примерно 1k на основной сети. Monad утверждает, что достигла 10k реальных TPS на своей внутренней тестовой сети. Хотя это не всегда является показателем реальной производительности, мы с нетерпением ждем, чтобы увидеть, как работает Monad на свободе.

Утверждение:

  1. Эта статья, изначально названная «Понимание Монады», воспроизведена из [chaincatcher]. Все авторские права принадлежат оригинальному автору [Децентрализованный.Ко]. Если у вас есть возражения против перепечатки, пожалуйста, свяжитесь с Команда Gate LearnКоманда обработает это как можно скорее.

  2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционными советами.

  3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.

Розпочати зараз
Зареєструйтеся та отримайте ваучер на
$100
!