Основное преимущество заключается в уменьшении объема данных, хранящихся в Ethereum, что снижает стоимость транзакций пользователей на L2.
**Автор: **OneTrueKirk
Составлено: Ивонн, MarsBit
Исходный пост от OneTrueKirk на ethresear.ch
Это мой первый пост в этой теме, поэтому прошу прощения, если чем-то вас обидел. Я думал об этой идее (накопительные пакеты без сохранения состояния) в основном для специальных накопительных пакетов для нашего протокола кредитования, но, надеюсь, это может быть общеприменимым, любые отзывы приветствуются.
TLDR：
Публикуется только корень состояния, а не данные вызова.
(Примечание MarsBit: Calldata — это значение части данных в транзакции контракта, которое нельзя изменить.)
деталь
Что, если вместо использования Ethereum в качестве уровня доступности данных, опубликовать полное состояние как calldata и опубликовать только корень состояния в основной сети? Основное преимущество заключается в уменьшении объема данных, хранящихся в Ethereum, тем самым снижая стоимость транзакций пользователей на L2. Даже с EIP-4844 blobace не является бесплатным.
Основным риском является атака с удержанием данных, когда предлагающий публикует действительный корень состояния, но скрывает полные данные от других узлов объединения, чтобы монополизировать будущее производство блоков или удерживать средства в заложниках. Чтобы предотвратить это, честные узлы должны подвергать сомнению любое обновление состояния, для которого ни один из узлов не может предоставить данные. Интерактивные доказательства мошенничества в стиле Arbitrum могут использоваться, чтобы заставить предлагающих раскрыть полное состояние в основной сети, но все же привести к сбою вызова, если корень действителен, поэтому даже в случае сбоя стоимость вызова низка.
(Примечание MarsBit: атака с удержанием данных означает, что злоумышленник намеренно не возвращает все данные или возвращает неверные данные при доступе к защищенным данным, чтобы достичь цели обмана или уничтожения.
Если стоимость неудачного вызова невелика, честные предлагающие могут пострадать, заставив их платить за публикацию всех данных о состоянии в основной сети в защиту вызова, даже если они правильно распространяли данные о состоянии от точки к точке. Стоимость инициирования вызова должна быть пропорциональна стоимости защиты, чтобы гарантировать, что честные предлагающие не могут быть атакованы таким образом.
В худшем случае, если злоумышленник может потратить 1 доллар, чтобы обойти честного предлагающего 1 доллар, он может заставить предлагающего сдаться и вернуть свой блок. Затем новый честный предлагающий может сделать ставку, и если злоумышленник не сможет повторить атаку на всех потенциальных честных предлагающих, включая всех, у кого есть средства, он не может вызвать необратимое время простоя. Можно добавить еще один пункт, в котором стоимость вызова возрастает, если прошло слишком много времени с момента завершения действительного блока. Таким образом, легко бросить вызов нечестному предлагающему, но невозможно надолго остановить переходы между состояниями.
Более оптимистично, если узлы распределяют данные между одноранговыми узлами, они могут выбирать свои собственные решения для резервного копирования данных и доступности, а пользователям лучше локально хранить данные, которые им нужны для их собственных переходов состояний. В контексте одного конкретного приложения я подумал о том, чтобы кодировать состояние свертки совершенно иначе, чем EVM, чтобы оптимизировать для этого. Все состояние, связанное с конкретной учетной записью пользователя, может быть закодировано в один и тот же хэш, чтобы пользователям было легче проверять изменения в своей учетной записи, не зная глобального состояния (т. е. подтверждая, что вы получили количество токенов, не беспокоясь о том, откуда они пришли).
Подведем итог
Я хотел бы услышать ваши мысли, и был бы признателен за ссылки на связанные работы. В отличие от обычного оптимистического свертывания, в оптимистическом сворачивании легко определить, соответствуют ли отправленные данные вызова корневому состоянию основной сети и являются ли они действительными, но невозможно узнать, действительно ли обновление, исходя только из корня состояния, поэтому необходимо Тщательно рассмотреть экономику периодов вызовов и грифинга (т.е. злонамеренного поведения).
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Краткий обзор преимуществ и потенциальных проблем объединения без сохранения состояния
**Автор: **OneTrueKirk
Составлено: Ивонн, MarsBit
Исходный пост от OneTrueKirk на ethresear.ch
Это мой первый пост в этой теме, поэтому прошу прощения, если чем-то вас обидел. Я думал об этой идее (накопительные пакеты без сохранения состояния) в основном для специальных накопительных пакетов для нашего протокола кредитования, но, надеюсь, это может быть общеприменимым, любые отзывы приветствуются.
TLDR：
Публикуется только корень состояния, а не данные вызова.
(Примечание MarsBit: Calldata — это значение части данных в транзакции контракта, которое нельзя изменить.)
деталь
Что, если вместо использования Ethereum в качестве уровня доступности данных, опубликовать полное состояние как calldata и опубликовать только корень состояния в основной сети? Основное преимущество заключается в уменьшении объема данных, хранящихся в Ethereum, тем самым снижая стоимость транзакций пользователей на L2. Даже с EIP-4844 blobace не является бесплатным.
Основным риском является атака с удержанием данных, когда предлагающий публикует действительный корень состояния, но скрывает полные данные от других узлов объединения, чтобы монополизировать будущее производство блоков или удерживать средства в заложниках. Чтобы предотвратить это, честные узлы должны подвергать сомнению любое обновление состояния, для которого ни один из узлов не может предоставить данные. Интерактивные доказательства мошенничества в стиле Arbitrum могут использоваться, чтобы заставить предлагающих раскрыть полное состояние в основной сети, но все же привести к сбою вызова, если корень действителен, поэтому даже в случае сбоя стоимость вызова низка.
(Примечание MarsBit: атака с удержанием данных означает, что злоумышленник намеренно не возвращает все данные или возвращает неверные данные при доступе к защищенным данным, чтобы достичь цели обмана или уничтожения.
Если стоимость неудачного вызова невелика, честные предлагающие могут пострадать, заставив их платить за публикацию всех данных о состоянии в основной сети в защиту вызова, даже если они правильно распространяли данные о состоянии от точки к точке. Стоимость инициирования вызова должна быть пропорциональна стоимости защиты, чтобы гарантировать, что честные предлагающие не могут быть атакованы таким образом.
В худшем случае, если злоумышленник может потратить 1 доллар, чтобы обойти честного предлагающего 1 доллар, он может заставить предлагающего сдаться и вернуть свой блок. Затем новый честный предлагающий может сделать ставку, и если злоумышленник не сможет повторить атаку на всех потенциальных честных предлагающих, включая всех, у кого есть средства, он не может вызвать необратимое время простоя. Можно добавить еще один пункт, в котором стоимость вызова возрастает, если прошло слишком много времени с момента завершения действительного блока. Таким образом, легко бросить вызов нечестному предлагающему, но невозможно надолго остановить переходы между состояниями.
Более оптимистично, если узлы распределяют данные между одноранговыми узлами, они могут выбирать свои собственные решения для резервного копирования данных и доступности, а пользователям лучше локально хранить данные, которые им нужны для их собственных переходов состояний. В контексте одного конкретного приложения я подумал о том, чтобы кодировать состояние свертки совершенно иначе, чем EVM, чтобы оптимизировать для этого. Все состояние, связанное с конкретной учетной записью пользователя, может быть закодировано в один и тот же хэш, чтобы пользователям было легче проверять изменения в своей учетной записи, не зная глобального состояния (т. е. подтверждая, что вы получили количество токенов, не беспокоясь о том, откуда они пришли).
Подведем итог
Я хотел бы услышать ваши мысли, и был бы признателен за ссылки на связанные работы. В отличие от обычного оптимистического свертывания, в оптимистическом сворачивании легко определить, соответствуют ли отправленные данные вызова корневому состоянию основной сети и являются ли они действительными, но невозможно узнать, действительно ли обновление, исходя только из корня состояния, поэтому необходимо Тщательно рассмотреть экономику периодов вызовов и грифинга (т.е. злонамеренного поведения).