Написал: 0XNATALIE

В последнем выпуске подкаста Bankless основатель Monad Кеоне Хон и соучредитель MegaETH Лэй Ян обсуждают архитектуру Monad и MegaETH и то, как они улучшат производительность Ethereum. Этот подкаст посвящен будущему виртуальной машины Ethereum и отвечает на ряд ключевых вопросов, включая сравнение скорости Monad и MegaETH, децентрализации и устойчивости к цензуре.

Но после выступления основатель Monad все еще был недоволен и продолжал поднимать вопросы об определении «полного узла» для MegaETH на X и, наконец, пригласил Виталика принять участие в обсуждении.

Монада — это уровень 1, который обеспечивает пропускную способность более 10 000 транзакций в секунду благодаря технологии параллельного выполнения и уникальному механизму консенсуса. MegaETH — это уровень 2, который использует технологию параллельного выполнения для достижения времени отклика в миллисекунды с целью обработки более 100 000 транзакций Ethereum в секунду.

Суть спора: должны ли полные узлы выполнять все транзакции

В подкасте Лэй Ян упомянул, что полные узлы в MegaETH относятся к тем узлам, которые поддерживают и обновляют последнее состояние блокчейна, а не к узлам, которые выполняют и проверяют все транзакции. В ответ на это Кеоне Хон разместил в Твиттере сообщение, в котором подверг сомнению определение MegaETH «полного узла», поскольку полный узел в традиционном смысле относится к узлу, который может независимо выполнять и проверять все транзакции. Полный узел, предложенный MegaETH, получает обновления статуса только от централизованного секвенатора и не проверяет транзакции самостоятельно. Кеоне обеспокоен тем, что такие узлы могут не обеспечивать адекватную безопасность при обработке крупных реальных транзакций.

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

Кеоне предложил сценарий практического применения: если предположить, что биржа интегрирует MegaETH и управляет таким полным узлом, как биржа может определить, что депозитная транзакция пользователя действительно подтверждена? Как долго мне следует ждать зачисления денег на счет пользователя? Нужно ли биржам ждать 7-дневного периода защиты от мошенничества, чтобы гарантировать, что транзакции не будут отменены, и тем самым обеспечить безопасность депозитов?

Точка зрения Виталика: В центре внимания — гарантия подтверждения транзакции

В обсуждении также принял участие основатель Ethereum Виталик Бутерин. Он считает, что основное внимание уделяется не тому, выполняет ли полный узел все транзакции, а тому, смогут ли пользователи получить достаточные гарантии подтверждения транзакций. Виталик считает, что самое важное для пользователей L2 — подтвердить, были ли приняты их транзакции, а не выполнил ли каждый узел все транзакции. Пока существуют механизмы, обеспечивающие это, пользователям не обязательно запускать свои собственные полные узлы, которые выполняют все транзакции.

Виталик отметил, что существует два механизма подтверждения транзакций:

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

  2. Подтверждение L1. Транзакции в L2 в конечном итоге могут быть подтверждены через L1 (например, Ethereum). Если с транзакцией на L2 возникла проблема, L1 может откатить транзакцию и исправить ошибку. Даже если на уровне L2 существует риск, пользователи все равно могут рассчитывать на окончательное подтверждение от уровня L1 в целях безопасности.

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

Однако Кеоне считает, что MegaETH не будет использовать технологию ZK на ранних стадиях. Хотя технология ZK имеет огромный потенциал, она все еще имеет определенные ограничения с точки зрения производительности. Вычислительный процесс генерации доказательств с нулевым разглашением является сложным и трудоемким, особенно когда необходимо обработать большое количество транзакций. Таким образом, проекты блокчейнов, такие как MegaETH, которые ориентированы на высокую производительность и высокую пропускную способность, не будут использовать технологию ZK на ранних стадиях, чтобы избежать проблем с производительностью, влияющих на взаимодействие с пользователем.

MegaETH отвечает: несколько методов подтверждения транзакции

Позже Лэй Ян написал в Твиттере в ответ на дискуссию об архитектуре узла MegaETH, прояснив некоторые недоразумения. Он отметил, что у пользователей MegaETH есть три варианта подтверждения транзакций:

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

  2. Узлы, ожидающие истечения срока действия окна доказательства мошенничества: то же, что и 1, но пользователям необходимо дождаться завершения окна доказательства мошенничества и блока MegaETH, в котором находится транзакция, в Ethereum. Этот вариант обеспечивает «полную безопасность Ethereum» (т. е. обеспечивает ту же безопасность и необратимость, что и транзакции Ethereum) и подходит для сценариев, когда пользователи не хотят проверять транзакции локально, но включают крупные транзакции. Этот вариант использования встречается редко.

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

Лэй Ян подчеркнул, что MegaETH поддерживает полные узлы, которые могут проверять каждую транзакцию. В предыдущем обсуждении могло возникнуть недоразумение, что узлы MegaETH могут только получать обновления статуса, но не могут проверять транзакции. Это неправильно. И далее объясняется, что если узел решит проверять все транзакции, он может проверять транзакции более эффективно, чем секвенсор, с помощью средств оптимизации (таких как использование данных-свидетелей, предоставляемых секвенсором), без необходимости обрабатывать всю информацию о транзакциях с нуля, тем самым сокращая аппаратное обеспечение. нуждаться. Пользователи могут выбирать между различными методами подтверждения в зависимости от своих потребностей.

Эти дебаты весьма интересны, поскольку Лао Бай, партнер инвестиционного исследовательского агентства ABCDE, сказал: «Имеют ли эти дебаты смысл? Абсолютно! В этих дискуссиях медленно продвигается технологическая эволюция всей отрасли. Кто победит? Важно ли проиграть ? Абсолютно нет! Потому что окончательный победитель зависит от ресурсов, опыта разработчиков/пользователей и от того, кто первым сможет запустить 1-2 популярных приложения, а не от того, каково определение и обязанности «полного узла».