Перейти к основному контенту

Страница в последний раз обновлялась: 16 февраля 2026 г.

Данкшардинг

Данкшардинг — это способ, благодаря которому Ethereum станет по-настоящему масштабируемым блокчейном, но для этого потребуется несколько обновлений протокола. Протоданкшардинг — это промежуточный шаг на этом пути. Обе технологии нацелены на то, чтобы сделать транзакции на Леер 2 как можно более дешевыми для пользователей, и должны масштабировать Ethereum до >100 000 транзакций в секунду.

Что такое протоданкшардинг?

Протоданкшардинг, также известный как EIP-4844 (opens in a new tab), — это способ для ролл-апов добавлять более дешевые данные в блоки. Название происходит от двух исследователей, которые предложили идею: Protolambda и Dankrad Feist. Исторически возможности ролл-апов по удешевлению транзакций для пользователей были ограничены тем, что они размещали свои транзакции в CALLDATA.

Это дорого, потому что они обрабатываются всеми узлами Ethereum и остаются в цепочке навсегда, несмотря на то, что данные роллапам нужны только в течение короткого времени. Протоданкшардинг добавляет BLOB-объекты с данными, которые можно отправлять и прикреплять к блокам. Данные в этих BLOB-объектах не доступна виртуальной машине Ethereum и автоматически удаляется через определенное время (на момент написания это время составляет 4096 эпох, или 18 дней). Это означает, что роллапы могут отправлять свои данные гораздо дешевле, что в свою очередь удешевит транзакции для конечных пользователей.

Роллапы являются способом масштабирования Ethereum путем пакетирования транзакций вне цепочки и размещения результатов в Ethereum. Роллап, по сути, состоит из двух частей: данные и проверка выполнения. Эти данные представляют собой полную последовательность транзакций, которые обрабатываются роллапом для получения изменений состояния, которые, в свою очередь, публикуются в Ethereum. Проверка выполнения — это повторное выполнение этих транзакций каким-либо честным субъектом (проверяющим), чтобы гарантировать правильность предлагаемого изменения состояния. Данные о транзакции должны быть доступны достаточно долго, чтобы любой желающий мог их скачать и проверить. Это означает, что любое нечестное поведение секвенсора роллапа может быть идентифицировано и оспорено доказывающим. Однако нет необходимости, чтобы они были доступны вечно.

Ролл-апы публикуют обязательства по данным своих транзакций ончейн, а также делают фактические данные доступными в блобах данных. Это означает, что проверяющие могут проверять действительность фиксаций или оспаривать данные, которые они считают неправильными. На уровне узлов BLOB-объекты с данными хранятся в клиенте консенсуса. Клиенты консенсуса подтверждают, что они видели данные и что они были распространены по сети. Если бы данные хранились вечно, размер этих клиентов раздувался бы, что приводило бы к большим требованиям к оборудованию для работающих узлов. Вместо этого данные автоматически удаляются из узла каждые 18 дней. Подтверждения клиентов консенсуса показывают, что у доказывающих была достаточная возможность проверить данные. Фактические данные могут храниться вне цепочки операторами роллапов, пользователями или другими лицами.

Как проверяются данные BLOB-объектов?

Роллапы размещают выполняемые транзакции в BLOB-объектах с данными. Они также размещают в данных фиксацию. Для этого они подгоняют данные под полиномиальную функцию. Затем эту функцию можно оценить в различных точках. Например, если мы определим очень простую функцию f(x) = 2x-1, мы можем вычислить ее для x = 1, x = 2, x = 3 и получить результаты 1, 3, 5. Проверяющий применяет ту же функцию к данным и оценивает их в тех же точках. Если исходные данные будут изменены, функция не будет идентичной, как и значения оценки в каждой точке. На практике фиксация и доказательство являются более сложными процессами, так как они упакованы в криптографические функции.

Что такое KZG?

KZG — это аббревиатура от Kate-Zaverucha-Goldberg — имен трех оригинальных авторов (opens in a new tab) схемы, которая сжимает блоб данных до небольшого криптографического «обязательства» (opens in a new tab). BLOB-объект с данными, отправленный роллапом, необходимо проверить, чтобы убедиться, что в нем нет нарушений. Этот процесс подразумевает повторное выполнение транзакций в BLOB-объекте для проверки действительности фиксации. Концептуально этот процесс аналогичен проверке действительности транзакций Ethereum на уровне 1 с помощью доказательств Меркла. KZG — это альтернативное доказательство, которое подгоняет данные под полиномиальное уравнение. Фиксация оценивает полином в некоторых секретных точках данных. Проверяющий подгоняет данные под тот же полином и оценивает его при тех же значениях, проверяя, совпадает ли результат. Этот способ проверки данных совместим с методами нулевого разглашения, используемыми некоторыми роллапами, а впоследствии и другими частями протокола Ethereum.

Что представляла собой церемония KZG?

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

Церемония KZG EIP-4844 была открытой для всех и десятки тысяч участников добавили свою собственную энтропию. Всего было сделано более 140 000 пожертвований, благодаря чему эта церемония стала крупнейшей в мире в своем роде. Чтобы эта церемония была сорвана, 100 % участников должны были бы быть активно нечестными. С точки зрения участников нет необходимости доверять другому человеку, если они знают, что сами были честны, и понимают, как обезопасили церемонию (они самостоятельно выполнили требование по наличию хотя бы одного честного участника).

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

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

Что такое данкшардинг?

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

Для этого количества BLOB-объектов, прикрепленных к блокам, будет увеличено с шести (6) в протоданкшардинге до 64 в полном данкшардинге. Остальные необходимые изменения — это все обновления того, как работают клиенты консенсуса, чтобы они могли обрабатывать новые большие BLOB-объекты. Некоторые из этих изменений уже на дорожной карте для других целей, независимо от данкшардинга. Например, данкшардинг требует реализации разделения предлагающих и строителей. Это обновление, которое разделяет задачи по строительству и предложению блоков между различными валидаторами. Аналогично, выборка доступности данных необходима для данкшардинга, но она также необходима для разработки очень легких клиентов, которые не хранят много исторических данных («клиенты без состояния Ethereum»).

Разделение предлагающих и строителей требуется для предотвращения того, чтобы отдельные валидаторы создавали дорогостоящие обязательства и доказательства для 32 Мб данных BLOB-объекта. Это создаст слишком большую нагрузку для людей, которые участвуют в стейкинге в домашних условиях, и потребует от них инвестиций в более мощное оборудование, что вредит децентрализации. Вместо этого специализированные строители блоков берут на себя ответственность за эту дорогую вычислительную работу. Затем они делают свои блоки доступными для просмотра предлагающим блоков. Предлагающий блока просто выбирает блок, который является наиболее выгодным. Любой может проверить BLOB-объекты дешево и быстро, то есть любой нормальный валидатор может убедиться, что строители блоков ведут себя честно. Это позволяет обрабатывать большие BLOB-объекты, не жертвуя децентрализацией. Недобросовестные строители блоков могут быть просто выброшены из сети и подвергнуться сокращению: другие займут их место, потому что строительство блоков является прибыльным видом деятельности.

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

Текущий прогресс

Полный данкшардинг наступит через несколько лет. Тем временем церемония KZG завершилась, собрав более 140 000 вкладов, и EIP (opens in a new tab) для протоданкшардинга был доработан. Это предложение было полностью реализовано во всех тестовых сетях и запущено в основной сети в ходе обновления Cancun-Deneb («Dencun») в марте 2024 года.

Дополнительные материалы

Последнее обновление страницы: 16 февраля 2026 г.

Была ли эта статья полезной?