Автостопом по Ethereum

Перевод приготовил @gaserdblog - https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum

Основные выводы

- Ethereum - единственный крупный протокол, создающий масштабируемый унифицированный уровень расчетов и доступности данных

- Роллапы масштабируют вычисления, используя при этом безопасность Ethereum

- Все дороги ведут к конечной цели - централизованной добыче блоков, децентрализованной проверке блоков без доверия и противодействию цензуре.

- Такие инновации, как разделение предлагающего и строящего и слабая безгражданственность, позволяют разделить полномочия (строящего и проверяющего) для достижения масштабируемости без ущерба для безопасности и децентрализации.

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

- Danksharding объединяет множество направлений передовых исследований, чтобы обеспечить масштабируемый базовый слой, необходимый для дорожной карты Ethereum, ориентированной на роллап.

- Я ожидаю, что данкшардинг будет реализован в течение нашей жизни.

Введение

Я довольно скептически относился к срокам слияния с тех пор, как Виталик заявил, что вероятность того, что люди, родившиеся сегодня, доживут до 3000 года, составляет 50-75%, а он надеется стать бессмертным. Но какого черта, давайте немного повеселимся и заглянем еще дальше в амбициозную дорожную карту Ethereum.

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

Исследований по Ethereum очень много, но все в конечном итоге сплетается в одну всеобъемлющую цель - масштабирование вычислений без ущерба для децентрализованной проверки.

Надеюсь, вы знакомы со знаменитым "Эндшпилем" Виталика. Он признает, что для масштабирования необходима некоторая централизация. Слово на букву "Ц" пугает в блокчейне, но это правда. Нам просто нужно держать эту власть в узде с помощью децентрализованной и надежной проверки. Здесь нет компромиссов.

Специализированные участники будут создавать блоки для L1 и выше. Ethereum остается невероятно безопасным благодаря простой децентрализованной валидации, а роллапы наследуют свою безопасность от L1. Затем Ethereum обеспечивает расчеты и доступность данных, позволяя роллапам масштабироваться. Все исследования, проводимые здесь, в конечном итоге направлены на оптимизацию этих двух ролей и одновременное облегчение полной валидации цепочки.

Вот глоссарий для сокращения некоторых слов, которые будут встречаться ~43531756765713534 раз:

DA - Data Availability
DAS - выборка доступности данных
PBS - Proposer-builder Separation (разделение предложений и строителей)
PDS - прото-данкшертинг
DS - Данкшардинг
PoW - Proof of Work
PoS - Proof of Stake

Часть I - Дорога к Данкшардингу

Надеюсь, вы уже слышали, что Ethereum перешел на дорожную карту, ориентированную на роллапы. Больше никаких шардов исполнения - вместо этого Ethereum будет оптимизировать роллапы, требовательные к данным. Это достигается с помощью шардинга данных (план Ethereum, своего рода) или больших блоков (план Celestia).

Уровень консенсуса не интерпретирует данные шардинга. У него одна задача - обеспечить доступность данных.

Я предполагаю, что знаком с некоторыми базовыми понятиями, такими как роллапы, мошенничество и ZK-доказательства, и почему DA важен. Если вы не знакомы или вам просто нужно освежить в памяти эти понятия, в недавнем отчете Can's Celestia они рассматриваются.

Оригинальный дизайн шардинга данных - Отдельные предложения по шардингу

Дизайн, описанный здесь, был отброшен, но это ценный контекст. Для простоты я буду называть ее "шардинг 1.0".

В каждом из 64 блоков шардов были отдельные пропозиционеры и комитеты, ротируемые из набора валидаторов. Они индивидуально проверяли, что данные их шарда были доступны. Это изначально не было бы DAS - оно полагается на честное большинство валидаторов каждого шарда для полной загрузки данных.

Такая конструкция вносит ненужную сложность, ухудшает UX и создает векторы атак. Перетасовывать валидаторы между осколками очень сложно.

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

DS - это совершенно другое. Валидаторы проводят DAS для подтверждения наличия всех данных (больше нет отдельных комитетов по шардам). Специализированный строитель создает один большой блок с блоком Beacon и всеми данными шарда, подтвержденными вместе. Таким образом, PBS необходим для того, чтобы DS оставался децентрализованным (создание такого большого блока требует больших ресурсов).

Выборка доступности данных

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

Вместо этого DAS позволяет узлам (даже легким клиентам) легко и безопасно проверять, что все данные были доступны, без необходимости скачивать их все.

Наивное решение - просто проверить кучу случайных фрагментов из блока. Если все они проверены, я отписываюсь. Но что, если вы пропустите одну транзакцию, которая передаст все ваши ETH Сифу? Средства больше не являются Сифу.
Умное решение - сначала стираем данные. Расшифруйте данные с помощью кода Рида-Соломона. Это означает, что данные интерполируются в виде полинома, а затем мы оцениваем его в нескольких дополнительных местах. Это многословно, поэтому давайте разберемся.
Быстрый урок для всех, кто забыл уроки математики. (Я обещаю, что это не будет действительно страшная математика - мне пришлось посмотреть несколько видео Академии Хана, чтобы написать эти разделы, но даже я теперь все понимаю).

Быстрый урок для всех, кто забыл уроки математики. (Я обещаю, что это не будет действительно страшная математика - мне пришлось посмотреть несколько видео Академии Хана, чтобы написать эти разделы, но даже я теперь все понимаю).

Многочлены - это выражения, в которых суммируется любое конечное число членов вида cxk. Степень - это наибольшая экспонента. Например, 2x^3+6x^2+2x-4 - многочлен степени три. Любой многочлен степени d можно восстановить из любых d+1 координат, лежащих на этом многочлене.

Теперь конкретный пример. Ниже у нас есть четыре блока данных (от d0 до d3). Эти куски данных можно сопоставить с оценками многочлена f(X) в данной точке. Например, f(0) = d0. Теперь найдите полином минимальной степени, который проходит через эти оценки. Поскольку это четыре куска, мы можем найти многочлен степени три. Затем мы можем расширить эти данные и добавить еще четыре оценки (e0 - e3), которые лежат вдоль того же полинома.

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

Вернемся к нашей системе DAS. Теперь нам нужно убедиться, что доступны только 50% (4/8) данных, закодированных стиранием. По ним мы можем восстановить весь блок.

Таким образом, злоумышленнику придется скрыть >50% блока, чтобы успешно обмануть узлы DAS и заставить их думать, что данные были доступны, хотя это не так.

Вероятность того, что <50% будет доступно после многих успешных случайных выборок, очень мала. Если мы успешно произвели выборку данных с кодом стирания 30 раз, то вероятность того, что <50% будет доступно, равна 2^-30.

Обязательства KZG

Итак, мы сделали кучу случайных выборок, и все было доступно. Но у нас есть другая проблема - было ли стирание данных закодировано должным образом? Иначе, возможно, производитель блока просто добавил 50% мусора при расширении блока, а мы отобрали бессмыслицу. В этом случае мы не сможем восстановить данные.

Обычно мы просто фиксируем большие объемы данных, используя корень Меркла. Это эффективно для доказательства включения некоторых данных в набор.

Однако нам также необходимо знать, что все исходные и расширенные данные лежат на одном и том же многочлене низкой степени. Корень Меркла этого не доказывает. Поэтому если вы используете эту схему, вам также нужны доказательства мошенничества на случай, если она была сделана неправильно.

Разработчики подходят к этому с двух сторон:

1/ Celestia идет по пути доказательства мошенничества. Кто-то должен следить, и если блок закодирован неправильно, он отправит доказательство мошенничества, чтобы предупредить всех. Это требует стандартного предположения о честном меньшинстве и предположения о синхронности (то есть, помимо того, что кто-то отправит мне доказательство мошенничества, мне также нужно предположить, что я подключен и получу его в течение конечного времени).

2/ Ethereum и Polygon Avail идут новым путем - KZG-обязательства (они же Kate-обязательства). Это устраняет предположения о честном меньшинстве и синхронности для обеспечения безопасности в отношении доказательств мошенничества (хотя они все еще существуют для реконструкции, о чем мы расскажем в ближайшее время).

Существуют и другие решения, но они активно не разрабатываются. Например, можно использовать ZK-доказательства. К сожалению, они непрактичны с вычислительной точки зрения (пока). Однако в ближайшие несколько лет ожидается их усовершенствование, поэтому Ethereum, скорее всего, перейдет на STARK, поскольку KZG-обязательства не являются квантово-устойчивыми.

Вернемся к обязательствам KZG - они представляют собой разновидность полиномиальной схемы обязательств.

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

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

Вот ключевые моменты:

• У нас есть "многочлен" f(X).
• Доказатель берет на себя "обязательство" C(f) в отношении этого многочлена.
• Это основано на криптографии эллиптических кривых с доверенной установкой. Для получения более подробной информации о том, как это работает, вот отличная тема от Bartek
• Для любой "оценки" y = f(z) этого полинома проверяющий может вычислить "доказательство" π(f,z).
• Учитывая обязательство C(f), доказательство π(f,z), любую позицию z и оценку y многочлена на z, проверяющий может подтвердить, что действительно f(z) = y.
• Перевод: проверяющий дает эти части любому верификатору, и тот может подтвердить, что оценка некоторой точки (где оценка представляет исходные данные) правильно лежит на многочлене, который был зафиксирован.
• Это доказывает, что исходные данные были расширены правильно, поскольку все оценки лежат на одном и том же многочлене
• Обратите внимание, что верификатору не нужен полином f(X).
• Важное свойство - это имеет O(1) размер обязательства, O(1) размер доказательства и O(1) время проверки. Даже для верификатора объем обязательств и генерация доказательства масштабируются только на O(d), где d - степень многочлена.
• Перевод: даже при увеличении n (числа значений в X) (т.е. при увеличении набора данных с большими блобами осколков) - обязательства и доказательства остаются постоянного размера, и проверка занимает постоянное количество усилий.
• Обязательство C(f) и доказательство π(f,z) являются одним элементом эллиптической кривой на кривой, дружественной к сопряжению (здесь будет использоваться BL12-381). В этом случае они будут занимать всего 48 байт каждый (очень мало).
• Таким образом, проверяющий берет на себя обязательства по передаче огромного количества исходных и расширенных данных (представленных в виде множества оценок вдоль полинома) всего за 48 байт, и доказательство также будет занимать всего 48 байт.
• TLDR - это очень масштабируемо.

Корень KZG (полиномиальное обязательство) является аналогом корня Меркла (который является векторным обязательством):

Исходными данными является многочлен f(X), оцененный в точках f(0) - f(3), затем мы расширяем его, оценивая многочлен в точках f(4) - f(7). Все точки от f(0) до f(7) гарантированно находятся на одном и том же полиноме.

Итог: DAS позволяет нам проверить, что данные, закодированные стиранием, были доступны. Обязательства KZG доказывают нам, что исходные данные были расширены должным образом и фиксируют все данные.

Молодцы, это все для сегодняшней алгебры.

Обязательства KZG против доказательств мошенничества

Сделаем шаг назад и сравним эти два подхода теперь, когда мы понимаем, как работает KZG.

Недостатки KZG - он не будет постквантовой безопасностью, и он требует доверенной установки. Это не вызывает беспокойства. STARK обеспечивают постквантовую альтернативу, а доверенная установка (в которой можно участвовать) требует только одного честного участника.

Преимущества KZG - более низкая задержка, чем при доказательстве мошенничества (хотя, как уже отмечалось, GASPER все равно не будет иметь быстрого финала), и он обеспечивает правильное кодирование стирания без введения предположений о синхронности и честном меньшинстве, присущих доказательствам мошенничества.

Однако учтите, что Ethereum все равно вернет эти допущения для восстановления блока, так что на самом деле вы их не устраните. Уровни DA всегда должны планировать сценарий, при котором блок был доступен изначально, но затем узлам необходимо связаться друг с другом, чтобы собрать его воедино. Эта реконструкция требует двух предположений:

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

Валидаторы Ethereum полностью загружают блобы шардов в PDS, а в DS они будут проводить только DAS (загрузку назначенных строк и столбцов). Celestia потребует от валидаторов загружать весь блок.

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

Преимущество KZG в задержке проявится, если Celestia когда-нибудь захочет перейти от требования к валидаторам загружать все данные к использованию только DAS (хотя в настоящее время такой переход не планируется). Тогда им также потребуется реализовать обязательства KZG - ожидание доказательств мошенничества означало бы значительное увеличение интервалов между блоками, а опасность того, что валидаторы проголосуют за неправильно закодированный блок, была бы слишком высока.

Для более глубокого изучения того, как работают KZG-обязательства, я рекомендую следующие статьи:

A (Relatively Easy To Understand) Primer on Elliptic Curve Cryptography (относительно легкий для понимания)
Изучение сопряжений эллиптических кривых - Виталик
KZG полиномиальные обязательства - Данкрад
Как работают доверенные установки? - Виталик

Внутрипротокольное разделение пропозиционеров и валидаторов

Узлы консенсуса сегодня (майнеры) и после слияния (валидаторы) выполняют две роли. Они создают фактический блок, затем предлагают его другим узлам консенсуса, которые подтверждают его. Майнеры "голосуют", строя поверх предыдущего блока, а валидаторы после слияния будут напрямую голосовать за блоки как за действительные или недействительные.

PBS разделяет их - она явно создает новую роль строителя внутри протокола. Специализированные строители будут составлять блоки и предлагать оферентам (валидаторам) выбрать их блок. Это борется с централизующей силой MEV.

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

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

Точная реализация PBS еще обсуждается, но двухслотовая PBS может выглядеть следующим образом:

1\ Строители обязуются предоставить заголовки блоков вместе со своими предложениями
2\ Предлагающий блок маяка выбирает выигрышный заголовок и ставку.

3\ Предложивший оплачивает выигравшую ставку безоговорочно, даже если застройщик не смог представить тело блока
4\ Комитет аттестаторов подтверждает победивший заголовок
5\ Строитель раскрывает тело победителя
6\ Отдельные комитеты аттестаторов выбирают выигравшее тело (или голосуют, что оно отсутствовало, если выигравший строитель скрывает его)

Предложения выбираются из набора валидаторов с помощью стандартного механизма RANDAO. Затем мы используем схему commit-reveal, при которой полное тело блока не раскрывается до тех пор, пока заголовок блока не будет подтвержден комитетом.

Схема commit-reveal более эффективна (пересылка сотен полных тел блоков может превысить пропускную способность p2p-уровня), а также предотвращает кражу MEV. Если бы разработчики отправляли свой полный блок, другой разработчик мог бы увидеть его, понять эту стратегию, включить ее и быстро опубликовать лучший блок. Кроме того, искушенные разработчики могут обнаружить используемую стратегию MEV и скопировать ее без компенсации строителю. Если бы такое воровство MEV стало равновесием, это стимулировало бы слияние строителя и автора предложения, поэтому мы избегаем этого с помощью commit-reveal.

После того, как победивший блокчейн был выбран автором предложения, комитет подтверждает его и закрепляет в правиле выбора форка. Затем победивший строитель публикует свой полный текст "блока строителя". Если он был опубликован вовремя, следующий комитет подтверждает это. Если они не успевают опубликовать его вовремя, они все равно платят полную ставку предложившему (и теряют все MEV и сборы). Такая безусловная оплата устраняет необходимость для предлагающего доверять строителю.

Недостатком этой "двухслотовой" конструкции является задержка. Блоки после слияния будут иметь фиксированное время 12 секунд, поэтому здесь нам потребуется 24 секунды для полного времени блока (два 12-секундных слота), если мы не хотим вводить никаких новых допущений. Использование 8 секунд для каждого слота (16-секундное время блока) представляется безопасным компромиссом, хотя исследования продолжаются.

Список противодействия цензуре (crList)

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

Списки crLists ограничивают эту мощность. Точная реализация снова является открытым пространством для проектирования, но "гибридный PBS", похоже, является фаворитом. Предлагающие указывают список всех подходящих транзакций, которые они видят в mempool, и строитель будет вынужден включить их (если блок не переполнен):

1\ Предлагающий публикует crList и crList summary, которые включают все правомочные транзакции
2\ Строитель создает предлагаемое тело блока, затем подает заявку, которая включает хэш сводки crList, доказывающий, что он ее видел.
3\ Организатор принимает предложение победителя и заголовок блока (тело блока пока не видно).
4\ Строитель публикует свой блок и включает доказательство того, что он включил все транзакции из crList или что блок был полным. В противном случае блок не будет принят по правилу выбора форка.
5\ Аттестованные лица проверяют достоверность опубликованного тела блока

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

Двумерная KZG-схема

Мы увидели, как KZG-обязательства позволяют нам зафиксировать данные и доказать, что они были расширены должным образом. Однако я упростил то, что на самом деле будет делать Ethereum. Он не будет фиксировать все данные в одном KZG-обязательстве - один блок будет использовать множество KZG-обязательств.

У нас уже есть специализированные разработчики, так почему бы им просто не создать одно гигантское KZG-обязательство? Проблема в том, что для этого потребуется мощный суперузел для реконструкции. Мы нормально относимся к требованию суперноды для начального строительства, но здесь нам нужно избежать такого предположения для реконструкции. Нам нужны сущности с меньшими ресурсами, чтобы справиться с реконструкцией, и разделение ее на множество обязательств KZG делает это осуществимым. Реконструкция может даже быть довольно распространенным или базовым предположением в этом проекте, учитывая объем данных, находящихся под рукой.

Чтобы облегчить реконструкцию, каждый блок будет включать m осколков, закодированных в m KZG-обязательствах. Если делать это наивно, то это приведет к тонне выборок - вы будете проводить DAS на каждом блобе шарда, чтобы узнать, что все они доступны (m*k выборок, где k - количество выборок на блок).

Вместо этого в Ethereum будет использоваться двухмерная схема KZG. Мы снова используем код Рида-Соломона, чтобы расширить m обязательств до 2m обязательств:

Мы превращаем ее в двумерную схему, расширяя дополнительные KZG-обязательства (256-511 здесь), которые лежат на том же полиноме, что и 0-255. Теперь мы просто проводим DAS по таблице выше, чтобы обеспечить доступность данных на всех шардах.

Требование 2D-выборки о том, что ≥75% данных должны быть доступны (по сравнению с 50% ранее), означает, что мы делаем немного большее количество фиксированных выборок. Ранее я упоминал о 30 выборках для DAS в простой схеме 1D, но здесь потребуется 75 выборок, чтобы обеспечить те же вероятностные шансы на восстановление доступного блока.

Sharding 1.0 (в котором использовалась схема 1D KZG commitment) требовал только 30 выборок, но для проверки полного DA вам потребуется 64 шарда при 1920 общих выборках. Каждый образец имеет размер 512 B, поэтому для этого потребуется:

(512 Б x 64 шарда x 30 образцов) / 16 секунд = 60 КБ/с пропускной способности.

В реальности валидаторы просто перемешивались, никогда не проверяя все шарды по отдельности.

Теперь объединение блоков со схемой обязательств 2D KZG делает проверку полного DA тривиальной. Для этого требуется всего 75 образцов одного объединенного блока:

(512 Б x 1 блок x 75 образцов) / 16 секунд = 2,5 КБ/с пропускной способности.

Данкшардинг

Изначально PBS был разработан для того, чтобы ослабить централизующие силы MEV в наборе валидаторов. Однако недавно Данкрад воспользовался преимуществами этой конструкции, поняв, что она открывает гораздо лучшую конструкцию шардинга - DS.

DS использует специализированный конструктор для создания более тесной интеграции блока исполнения Beacon Chain и шардов. Теперь у нас есть один строитель, создающий весь блок вместе, один автор предложения и один комитет, голосующий за него одновременно. DS был бы неосуществим без PBS - обычные валидаторы не смогли бы справиться с огромной пропускной способностью блока, заполненного блоками данных роллапов:

Шардинг 1.0 включал 64 отдельных комитета и предлагающих, поэтому каждый шард мог быть недоступен по отдельности. Более тесная интеграция здесь позволяет нам обеспечить DA в совокупности за один раз. Данные все еще "шардируются" под капотом, но с практической точки зрения данкшардинг начинает больше походить на большие блоки, что очень здорово.

Данкшардинг - Проверка честного большинства

Валидаторы подтверждают наличие данных следующим образом:

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

Обратите внимание, что это отличается от 75 случайных выборок, которые мы обсуждали ранее. Частная случайная выборка - это то, как люди с низкими ресурсами смогут легко проверить доступность (например, я могу запустить легкий узел DAS и узнать, что блок доступен). Однако валидаторы будут продолжать использовать подход "строк и столбцов" для проверки доступности и ведущей реконструкции блока.

Данкшардинг - реконструкция

До тех пор, пока 50% отдельной строки или столбца доступны, они могут быть полностью восстановлены валидатором выборки. По мере того, как они восстанавливают все недостающие фрагменты своих строк/столбцов, они перераспределяют эти фрагменты по ортогональным линиям. Это помогает другим валидаторам при необходимости восстановить недостающие фрагменты из пересекающихся строк и столбцов.

Предположения безопасности для реконструкции доступного блока здесь следующие:

1\ Достаточное количество узлов для выполнения запросов на выборку, чтобы они в совокупности имели достаточно данных для реконструкции блока
2\ предположение о синхронности между узлами, которые передают свои отдельные части блока.

Итак, сколько узлов достаточно? По приблизительным оценкам, это ~64,000 отдельных экземпляров (на сегодняшний день уже более ~380,000). Это также очень пессимистичный расчет, который предполагает отсутствие пересечения узлов, управляемых одним и тем же валидатором (что далеко не так, поскольку узлы ограничены 32 экземплярами ETH). Если вы выбираете более 2 строк и столбцов, вы увеличиваете вероятность того, что вы сможете коллективно получить их из-за кроссовера. Это начинает масштабироваться квадратично - если валидаторы работают, скажем, на 10 или 100 валидаторов, то 64 000 можно уменьшить на порядки.

Если количество валидаторов в сети начинает становиться некомфортно низким, DS можно настроить на автоматическое уменьшение количества блоков данных шарда. Таким образом, предположение о безопасности будет снижено до безопасного уровня.

Данкшардинг - безопасность злоумышленного большинства с частной случайной выборкой

Мы видели, что проверка DS полагается на честное большинство для подтверждения наличия блоков. Я, как частное лицо, не могу доказать себе, что блок доступен, просто загрузив пару строк и столбцов. Однако частная случайная выборка может дать мне такую гарантию, не доверяя никому. Именно здесь узлы проверяют те 75 случайных выборок, о которых говорилось ранее.

DS изначально не будет включать частную случайную выборку, потому что это просто очень сложная проблема для решения со стороны сети (PSA: возможно, им действительно пригодится ваша помощь!).

Обратите внимание, что "частная" - это важно, потому что если злоумышленник деанонимизировал вас, он сможет обмануть небольшое количество узлов выборки. Они могут просто вернуть вам именно те фрагменты, которые вы запросили, а остальное утаить. Таким образом, вы не сможете узнать из собственной выборки, что все данные были предоставлены.

Данкшардинг - основные выводы

Помимо того, что DS - это приятное название, оно еще и невероятно интересное. Он наконец-то реализует видение Ethereum о едином уровне расчетов и DA. Это тесное соединение блока Beacon и шардов по сути притворяется, что не является шардингом.

На самом деле, давайте определим, почему он вообще считается "шардированным". Единственным остатком "шардинга" является тот факт, что валидаторы не отвечают за загрузку всех данных. Вот и все.

Так что вы не сошли с ума, если уже задались вопросом, действительно ли это все еще шардинг. Именно поэтому PDS (о которой мы расскажем в ближайшее время) не считается "шардингом" (несмотря на то, что в его названии есть слово "шардинг", да, я знаю, что это сбивает с толку). PDS требует, чтобы каждый валидатор полностью загрузил все блобы шарда, чтобы подтвердить их доступность. DS затем вводит выборку, так что отдельные валидаторы загружают только части.

Минимальный шардинг, к счастью, означает гораздо более простой дизайн по сравнению с шардингом 1.0 (поэтому быстрая доставка, верно? верно?). Упрощения включают:

• Возможно, на сотни строк меньше кода в спецификации DS по сравнению со спецификацией шардинга 1.0 (на тысячи строк меньше в клиентах).
• Нет больше инфраструктуры комитетов шардов, комитетам нужно только голосовать по основной цепочке
• Нет необходимости отслеживать подтверждения отдельных блобов шардов, теперь все они либо подтверждаются в основной цепочке, либо нет.
• Один из лучших результатов этого - объединенный рынок платежей за данные. Шардинг 1.0 с отдельными блобами, сделанными отдельными оферентами, раздробил бы его.

Устранение комитетов шардов также усиливает сопротивление взяточничеству. Валидаторы DS голосуют один раз за эпоху по всему блоку, поэтому данные сразу получают подтверждение от 1/32 всего набора валидаторов (32 слота за эпоху). Валидаторы Sharding 1.0 также голосовали раз в эпоху, но на каждом шарде был свой собственный комитет, который тасовался по кругу. Таким образом, каждый шард подтверждался только 1/2048 валидаторов (1/32 распределяется на 64 шарда).

Объединение блоков со схемой обязательств 2D KZG также делает DAS гораздо более эффективной, как уже говорилось. Шардинг 1.0 потребовал бы пропускной способности 60 КБ/с для проверки полного DA всех шардов. DS требует только 2,5 КБ/с.

Еще одна захватывающая возможность, сохранившаяся благодаря DS, - синхронные вызовы между ZK-роллапами и L1 Ethereum-исполнением. Транзакции из шард-блоба могут немедленно подтверждаться и записываться в L1, поскольку все производится в одном и том же блоке Beacon Chain. Шардинг 1.0 устранил бы эту возможность из-за отдельных подтверждений шардов. Это позволяет создать захватывающее пространство для проектирования, которое может быть невероятно ценным для таких вещей, как общая ликвидность (например, dAMM).

Данкшардинг - пределы масштабируемости блокчейна

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

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

Выход за пределы рассматриваемой здесь пропускной способности DA, безусловно, возможен, но трудно сказать, где окажется этот максимум. Здесь нет четкой красной линии, а скорее область, где некоторые предположения начнут чувствовать себя неуютно:

• Хранение данных - Это связано с DA против возможности извлечения данных. Роль уровня консенсуса не заключается в том, чтобы гарантировать доступность данных на неопределенное время. Его роль заключается в том, чтобы сделать его доступным в течение времени, достаточного для того, чтобы любой желающий мог его загрузить, удовлетворяя нашим предположениям безопасности. Затем они сбрасываются в хранилище в любом месте - это удобно, поскольку история - это 1 из N предположений о доверии, и мы не говорим о большом количестве данных в большой схеме вещей. Однако через несколько лет, когда пропускная способность увеличится на порядки, это может стать неудобной территорией.
• Валидаторы - DAS требует достаточного количества узлов для коллективной реконструкции блока. В противном случае злоумышленник может ждать и отвечать только на те запросы, которые он получает. Если этих запросов недостаточно для реконструкции блока, злоумышленник может не ответить на остальные, и нам не повезет. Чтобы безопасно увеличить пропускную способность, нам нужно добавить больше узлов DAS или увеличить их требования к пропускной способности. Это не является проблемой для обсуждаемой здесь пропускной способности. Однако, опять же, это может стать неудобным, если пропускная способность увеличится на порядок по сравнению с данной конструкцией.

Обратите внимание, что сборщик не является узким местом. Вам нужно будет быстро генерировать KZG-доказательства для 32 МБ данных, так что ожидайте GPU или довольно мощный CPU плюс пропускная способность не менее 2,5 ГБит/с. В любом случае, это специализированная роль, для которой это незначительная стоимость ведения бизнеса.

Прото-данкшардинг (EIP-4844)

DS - это здорово, но нам придется потерпеть. Цель PDS - дать нам время - он реализует необходимые совместимые с DS шаги в ускоренные сроки (ориентированные на шанхайский хард-форк), чтобы обеспечить масштабирование на порядки в промежуточный период. Однако в нем еще не реализовано разделение данных (т.е. валидаторы должны индивидуально загружать все данные).

Сегодня роллапы используют L1 "calldata" для хранения данных, которые сохраняются на цепочке вечно. Однако роллапы нуждаются в DA только в течение некоторого разумного периода времени, чтобы любой заинтересованный имел достаточно времени для загрузки.

EIP-4844 вводит новый формат транзакций с блобами, который роллапы будут использовать для хранения данных в будущем. Блобы несут большой объем данных (~125 КБ), и они могут быть намного дешевле, чем аналогичные объемы calldata. Данные блобов удаляются с узлов через месяц, что снижает требования к хранению. Этого времени достаточно, чтобы удовлетворить наши предположения о безопасности DA.

Для контекста масштаба, текущие блоки Ethereum в среднем составляют ~90 КБ (calldata составляет ~10 КБ от этого). PDS высвобождает гораздо большую пропускную способность DA (целевая ~1 МБ и максимальная ~2 МБ) для блоков, поскольку они обрезаются через месяц. Они не являются постоянной нагрузкой на узлы.

Блоб - это вектор из 4096 полевых элементов по 32 байта каждый. PDS допускает максимум 16 на блок, а DS увеличит это число до 256.

Пропускная способность PDS DA = 4096 x 32 x 16 = 2 МиБ на блок, целевой объем - 1 МиБ.

Пропускная способность DS DA = 4096 x 32 x 256 = 32 МиБ на блок, целевое значение - 16 МиБ.

С каждым шагом масштабирование увеличивается на порядки. PDS по-прежнему требует консенсус-узлов для полной загрузки данных, поэтому она более консервативна. DS распределяет нагрузку по хранению и распространению данных между валидаторами.

Вот некоторые из преимуществ, представленных EIP-4844 на пути к DS:

• Формат транзакций, несущих блобы данных
• KZG-обязательства для блобов
• Вся логика уровня исполнения, необходимая для DS
• Вся логика перекрестной верификации исполнения / консенсуса, необходимая для DS
• Разделение уровней между верификацией BeaconBlock и блобами DAS
• Большая часть логики BeaconBlock, необходимой для DS
• Саморегулирующаяся независимая цена на газ для блоков (многомерный EIP-1559 с экспоненциальным правилом ценообразования)

И далее DS добавляет:

• PBS
• DAS
• 2D KZG схема
• Доказательство хранения или аналогичное внутрипротокольное требование для каждого валидатора подтверждать доступность определенной части данных шардирования в каждом блоке (возможно, в течение примерно месяца).
  

Обратите внимание, что эти блоки данных вводятся как новый тип транзакции в цепочке исполнения, но они не обременяют сторону исполнения дополнительными требованиями. EVM просматривает только обязательства, прикрепленные к блобам. Изменения уровня исполнения, вносимые в EIP-4844, также совместимы с DS, и больше никаких изменений с этой стороны не потребуется. Обновление с PDS до DS требует только изменений на уровне консенсуса.

Сгустки данных полностью загружаются клиентами консенсуса в PDS. Теперь блобы ссылаются, но не полностью кодируются, в теле блока Beacon. Вместо встраивания полного содержимого в тело блока, содержимое блобов распространяется отдельно, в виде "бокового блока". В каждом блоке есть один сайд-кар блоба, который полностью загружается в PDS, а затем с помощью валидаторов DS на нем проводится DAS.

Ранее мы обсуждали, как фиксировать блобы с помощью полиномиальных фиксаций KZG. Однако вместо того, чтобы использовать KZG напрямую, EIP-4844 реализует то, что мы на самом деле используем - его версионный хэш. Это один байт 0x01 (представляющий версию), за которым следует последний 31 байт SHA256 хэша KZG.

Мы делаем это для облегчения совместимости с EVM и дальнейшей совместимости:

• Совместимость с EVM - KZG-обязательства состоят из 48 байт, в то время как EVM более естественно работает с 32-байтными значениями.
• Перспективная совместимость - если мы когда-нибудь перейдем от KZG к чему-то другому (STARKs для квантовой устойчивости), обязательства могут продолжать быть 32 байтами.

Многомерный EIP-1559

PDS наконец-то создает специализированный уровень данных - блобы данных получат свой собственный отдельный рынок сборов с отдельными плавающими ценами на газ и лимитами. Таким образом, даже если какой-то проект NFT продает кучу обезьяньей земли на L1, ваши затраты на данные в рулонах не вырастут (хотя затраты на расчеты по доказательствам вырастут). Это признает, что доминирующей статьей расходов для любого роллапа сегодня является размещение данных на L1 (а не доказательств).

Рынок платы за газ остается неизменным, и данные добавляются как новый рынок:

Плата за блобы взимается в газе, но это переменная сумма, регулируемая на основе собственного механизма EIP-1559. В долгосрочной перспективе среднее количество блобов на блок должно быть равно целевому.

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

Есть несколько интересных идей. Например, возможно, имеет смысл изменить текущие механизмы ценообразования на газ и блобы с линейного EIP-1559 на новый экспоненциальный механизм EIP-1559. Текущая реализация на практике не обеспечивает усреднение до наших целевых размеров блоков. Базовая плата сегодня стабилизируется нестабильно, в результате чего наблюдаемый средний расход газа на блок превышает целевой показатель в среднем на ~3%.

Часть II - История и государственное управление

Здесь мы кратко расскажем о некоторых основах:

• История - все, что когда-либо происходило в цепи. Вы можете просто записать ее на жесткий диск, поскольку она не требует быстрого доступа. 1 из N честных предположений в долгосрочной перспективе.
• Состояние - моментальный снимок всех текущих балансов счетов, смарт-контрактов и т.д. Полные узлы (в настоящее время) нуждаются в этом для подтверждения транзакций. Он слишком велик для оперативной памяти, а жесткий диск слишком медленный - он помещается в SSD. Блокчейны с высокой пропускной способностью вздувают свое состояние, разрастаясь намного больше того, что мы, обычные пользователи, можем держать на своих ноутбуках. Если обычные пользователи не могут хранить состояние, они не могут полностью подтвердить его, так что прощай децентрализация.

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

Сокращение затрат на газ Calldata с помощью общего лимита Calldata (EIP-4488)

PDS является отличным шагом на пути к DS, который проверяет многие из возможных требований. Внедрение PDS в разумные сроки может отодвинуть сроки реализации DS.

Более простым в реализации пластырем может стать EIP-4488. Он не столь элегантен, но, тем не менее, он решает проблему чрезвычайной платы. К сожалению, он не реализует шаги на пути к DS, поэтому все неизбежные изменения все равно потребуются позже. Если начнет казаться, что PDS будет проходить немного медленнее, чем хотелось бы, может иметь смысл быстро провести EIP-4488 (это всего лишь пара строк изменений в коде), а затем перейти к PDS, скажем, еще через полгода. Сроки здесь все еще в движении.

EIP-4488 состоит из двух основных компонентов:

• Снизить стоимость calldata с 16 газов за байт до 3 газов за байт.
• Добавить ограничение в 1 МБ calldata на блок плюс дополнительные 300 байт на транзакцию (теоретический максимум ~1,4 МБ в сумме).

Ограничение необходимо добавить для предотвращения наихудшего сценария - блок, заполненный calldata, достигнет 18 МБ, что намного превышает возможности Ethereum. EIP-4488 увеличивает среднюю емкость данных Ethereum, но его емкость серийных данных фактически немного уменьшится из-за этого ограничения на calldata (30 миллионов газов / 16 газов на байт calldata = 1,875 МБ).

Устойчивая нагрузка EIP-4488 намного выше, чем у PDS, потому что это все еще калдаты против блоков данных, которые могут быть обрезаны через месяц. Рост истории значительно ускорится при использовании EIP-4488, что сделает его узким местом для работы узла. Даже если EIP-4444 реализован в тандеме с EIP-4488, это позволит обрезать историю полезной нагрузки только через год. Более низкая устойчивая нагрузка PDS явно предпочтительнее.

Ограничение исторических данных в клиентах исполнения (EIP-4444)

EIP-4444 предоставляет клиентам возможность локально обрезать исторические данные (заголовки, тела и квитанции) старше одного года. Он требует, чтобы клиенты прекратили передавать эти обрезанные исторические данные на уровень p2p. Обрезка истории позволяет клиентам сократить потребность пользователей в дисковом хранилище (в настоящее время это сотни гигабайт и продолжает расти).

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

История нужна для полной синхронизации цепочки, но она не нужна для проверки новых блоков (для этого требуется только состояние). Поэтому после того, как клиент синхронизировался с вершиной цепочки, исторические данные извлекаются только при явном запросе через JSON-RPC или при попытке коллеги синхронизировать цепочку. При реализации EIP-4444 нам придется искать альтернативные решения для этих случаев.

Клиенты не смогут "полностью синхронизироваться" с помощью devp2p, как они это делают сегодня - вместо этого они будут "синхронизироваться по контрольной точке" с контрольной точки слабой субъективности, которую они будут рассматривать как блок генезиса.

Обратите внимание, что слабая субъективность не будет дополнительным допущением - она в любом случае присуща переходу на PoS. Это требует, чтобы для синхронизации использовались действительные контрольные точки слабой субъективности из-за возможности дальних атак. Здесь предполагается, что клиенты не будут синхронизироваться с недействительной или старой контрольной точки слабой субъективности. Эта контрольная точка должна быть в пределах периода, когда мы начинаем обрезать исторические данные (т.е. в пределах одного года), иначе уровень p2p не сможет предоставить необходимые данные.

Поскольку все больше клиентов используют облегченные стратегии синхронизации, это также снизит использование пропускной способности сети.

Восстановление исторических данных

Хорошо звучит, что EIP-4444 обрезает исторические данные через год, а PDS обрезает блобы еще быстрее (примерно через месяц). Они нам определенно нужны, потому что мы не можем требовать от узлов хранить все это и оставаться децентрализованными:

• EIP-4488 - в долгосрочной перспективе может включать ~1 МБ на слот, что добавляет ~2,5 ТБ хранения в год.
• PDS - при цели ~1 МБ на слот добавляет ~2,5 ТБ хранения в год
• DS - при целевом уровне ~16 МБ на слот добавляет ~40 ТБ хранения в год.
  

Но куда деваются эти данные? Разве они нам все еще не нужны? Да, но обратите внимание, что потеря исторических данных не является риском для протокола - только для отдельных приложений. В таком случае в обязанности основного протокола Ethereum не должно входить постоянное хранение всех этих данных, по которым он приходит к консенсусу.

Итак, кто будет хранить его? Вот некоторые потенциальные вкладчики:

• Индивидуальные и институциональные добровольцы
• Исследователи блокчейна (например, etherscan.io), поставщики API и другие сервисы данных.
• Сторонние протоколы индексирования, такие как TheGraph, могут создавать стимулированные рынки, где клиенты платят серверам за исторические данные вместе с доказательствами Меркла
• Клиенты сети Portal Network (в настоящее время разрабатывается) могут хранить произвольные фрагменты истории цепочки, а сеть Portal Network будет автоматически направлять запросы на данные к узлам, у которых они есть.
• BitTorrent, например, автоматическая генерация и распространение файла размером 7 ГБ, содержащего данные блобов из блоков за каждый день.
  Протоколы, ориентированные на конкретные приложения (например, роллапы), могут требовать от узлов хранить часть истории, относящуюся к их приложению.

Проблема долгосрочного хранения данных является относительно простой проблемой, поскольку это предположение о доверии 1 из N, как мы обсуждали ранее. Нам еще много лет до того, как это станет окончательным ограничением масштабируемости блокчейна.

Слабая безгосударственность

Итак, мы хорошо разобрались с управлением историей, но что насчет состояния? На самом деле это основное узкое место в повышении TPS Ethereum в настоящее время.

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

Вводим statelessness - отсутствие необходимости иметь состояние на руках для выполнения какой-то роли. Ethereum стремится к "слабой безстатичности", то есть состояние не требуется для подтверждения блока, но оно требуется для создания блока. Верификация становится чистой функцией - дайте мне блок в полной изоляции, и я смогу сказать, действителен он или нет. По сути, это следующее:

Допустимо, что строителям все еще требуется государство из-за PBS - они все равно будут более централизованными сущностями с высоким ресурсом. Сосредоточьтесь на децентрализации валидаторов. Слабая безгосударственность дает строителям немного больше работы, а валидаторам - намного меньше. Отличный компромисс.

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

Давайте рассмотрим пример. Алиса хочет отправить 1 ETH Бобу. Чтобы верифицировать блок с этой транзакцией, мне нужно знать:

• До транзакции у Алисы был 1 ETH
• открытый ключ Алисы - чтобы я мог сказать, что подпись верна
• nonce Алисы - чтобы я мог сказать, что транзакция была отправлена в правильном порядке.
• После выполнения транзакции - у Боба на 1 ETH больше, у Алисы на 1 ETH меньше.

В мире со слабой безгражданственностью создатель добавляет к блоку вышеуказанные данные свидетеля и доказательство его достоверности. Валидатор получает блок, выполняет его и решает, является ли он действительным. Вот и все!

Вот последствия с точки зрения валидатора:

• Исчезнут огромные потребности в SSD для хранения состояния - это ключевое узкое место для масштабирования сегодня.
• Требования к пропускной способности немного возрастут, поскольку теперь вы также загружаете данные свидетелей и доказательства. Это узкое место в деревьях Меркла-Патриция, но в попытках Веркла оно будет незначительным и не станет узким местом.
• Вы все равно выполняете транзакцию для полной валидации.
• Безгражданственность признает тот факт, что в настоящее время это не является узким местом для масштабирования Ethereum.

Слабая безгражданственность также позволяет Ethereum ослабить самоограничения на пропускную способность выполнения, поскольку разбухание состояния больше не является насущной проблемой. Увеличение лимитов газа в ~3 раза может быть разумным.

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

Попытки Веркле

Мы упустили из виду, как на самом деле работают эти свидетели. В настоящее время Ethereum использует дерево Меркла-Патриция для состояния, но требуемые доказательства Меркла будут слишком большими, чтобы эти свидетели были выполнимы.

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

Сначала давайте вспомним, как выглядит дерево Меркла. Для начала каждая транзакция хэшируется - эти хэши в нижней части называются "листьями". Все хэши называются "узлами", и они являются хэшами двух "дочерних" узлов, расположенных под ними. Итоговый хэш является "корнем Меркла".

Это полезная структура данных для доказательства включения транзакции без необходимости загружать все дерево. Например, если вы хотите проверить, что транзакция H4 включена, вам достаточно иметь H12, H3 и H5678 в доказательстве Меркла. У нас есть H12345678 из заголовка блока. Поэтому легкий клиент может запросить эти хэши у полного узла, а затем хэшировать их вместе в соответствии с маршрутом в дереве. Если результатом будет H12345678, то мы успешно доказали, что H4 находится в дереве.

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

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

Именно здесь на помощь приходят эффективные векторные преобразования. Обратите внимание, что хэши, используемые в деревьях Меркла, на самом деле являются векторными обязательствами - это просто плохие хэши, которые эффективно фиксируют только два элемента. Поэтому нам нужны векторные обязательства, для проверки которых нам не нужно получать всех братьев и сестер. Получив это, мы можем сделать деревья шире и уменьшить их глубину. Так мы получаем эффективные размеры доказательств - уменьшая количество информации, которую необходимо предоставить.

Тройка Веркле похожа на дерево Меркле, но она фиксирует свои дочерние элементы с помощью эффективного векторного обязательства (отсюда и название "Веркле"), а не простого хэша. Основная идея заключается в том, что для каждого узла можно иметь много детей, но мне не нужны все дети для проверки доказательства. Это доказательство постоянного размера, независимо от ширины.

Мы уже рассматривали отличный пример одной из этих возможностей - KZG-обязательства могут также использоваться как векторные обязательства. Фактически, именно это разработчики Ethereum первоначально планировали использовать здесь. С тех пор они переключились на обязательства Педерсена для выполнения аналогичной роли. Они будут основаны на эллиптической кривой (в данном случае Bandersnatch) и будут фиксировать по 256 значений (гораздо лучше, чем два!).

Так почему бы тогда не иметь дерево глубиной один, как можно более широкое? Это было бы замечательно для верификатора, у которого теперь есть суперкомпактное доказательство. Но есть практический компромисс: проверяющему нужно иметь возможность вычислить это доказательство, и чем оно шире, тем сложнее это сделать. Поэтому эти попытки Verkle будут лежать между крайностями при ширине 256 значений.

Истечение срока действия состояния

Слабая безграмотность снимает ограничения на раздувание состояния с валидаторов, но состояние не исчезает волшебным образом. Транзакции обходятся в конечную сумму, но они накладывают постоянный налог на сеть, увеличивая состояние. Рост состояния по-прежнему является постоянной нагрузкой на сеть. Необходимо что-то сделать, чтобы решить основную проблему.

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

Если вам когда-нибудь понадобится воскресить просроченное состояние, вам нужно будет просто показать доказательство и снова активировать его. Это возвращается к предположению о хранении 1 из N. До тех пор, пока у кого-то остается полная история (исследователи блоков и т.д.), вы можете получить от них то, что вам нужно.

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

Часть III - Это все MEV

PBS был необходим для безопасной реализации DS, но вспомните, что на самом деле сначала он был разработан для борьбы с централизующими силами MEV. Вы заметите повторяющуюся тенденцию в исследованиях Ethereum сегодня - MEV теперь на первом месте в криптоэкономике.

Проектирование блокчейн с учетом MEV имеет решающее значение для сохранения безопасности и децентрализации. Основной подход на уровне протокола заключается в следующем:

1\ Максимально смягчить вредное воздействие MEV (например, окончательность одного слота, выборы лидера с одним секретом).
2\ Демократизировать остальное (например, MEV-Boost, PBS, сглаживание MEV).

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

Цепочка поставок MEV сегодня

Сегодняшняя последовательность событий выглядит следующим образом:

Майнинговые пулы играют здесь роль строителя. Поисковики MEV передают пулы транзакций (с соответствующими заявками) майнинговым пулам через флешботы. Оператор майнингового пула собирает полный блок и передает заголовок блока отдельным майнерам. Майнер подтверждает его PoW, что дает ему вес в правиле выбора форка.

Flashbots возникли для предотвращения вертикальной интеграции по всему стеку - это открыло бы дверь для цензуры и других неприятных внешних эффектов. Когда Flashbots появился, майнинговые пулы уже начали заключать эксклюзивные сделки с торговыми фирмами для добычи MEV. Вместо этого Flashbots дал им простой способ агрегировать заявки на MEV и избежать вертикальной интеграции (реализовав MEV-geth).

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

MEV-Boost

К сожалению, внутрипротокольный PBS просто не будет готов к слиянию. Flashbots снова приходит на помощь со ступенчатым решением - MEV-Boost.

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

Но ваша мама и папа валидатор понятия не имеют, как добывать MEV, как мы обсуждали, поэтому Flashbots предлагает альтернативу. MEV-boost будет подключаться к вашему консенсус-клиенту, позволяя вам передать на аутсорсинг создание специализированных блоков. Важно отметить, что вы сохраняете возможность использовать свой собственный клиент исполнения в качестве запасного варианта.

Поисковики MEV будут продолжать играть ту же роль, что и сегодня. Они будут запускать определенные стратегии (stat arb, atomic arb, sandwiches и т.д.) и делать ставки на включение своих блоков. Затем строители объединяют все пачки, которые они видят, а также любой частный поток заказов (например, от Flashbots Protect) в оптимальный полный блок. Строитель передает валидатору только заголовок через реле, работающее на MEV-Boost. Flashbots намерен запустить ретранслятор и билдер с планами децентрализации со временем, но белый список дополнительных билдеров, вероятно, будет медленным.

MEV-Boost требует, чтобы валидаторы доверяли ретрансляторам - клиент консенсуса получает заголовок, подписывает его, и только после этого раскрывается тело блока. Цель ретранслятора - подтвердить предлагающему тело, что оно действительно и существует, так что валидаторам не нужно доверять непосредственно строителям.

Когда внутрипротокольная PBS будет готова, она кодифицирует то, что предлагает MEV-Boost в промежуточный период. PBS обеспечивает такое же разделение полномочий, позволяет более легкую децентрализацию строителей и устраняет необходимость для предлагающих доверять кому-либо.

Сглаживание MEV, управляемое комитетом

PBS также открывает дверь для другой классной идеи - сглаживания MEV, управляемого комитетом.

Мы видели, что возможность извлекать MEV является централизующей силой для набора валидаторов, но и распределение тоже. Высокая изменчивость вознаграждения MEV от блока к блоку стимулирует объединение множества валидаторов для сглаживания ваших доходов с течением времени (как мы видим в майнинговых пулах сегодня, хотя и в меньшей степени здесь).

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

Это решает и другую проблему - взятки за пределами диапазона. Предложившие могут получить стимул представить неоптимальный блок и просто взять взятку за пределами диапазона, чтобы, например, скрыть свои платежи от делегатов. Такая аттестация сдерживает предложения.

Внутрипротокольное PBS является необходимым условием для реализации сглаживания MEV. Необходимо иметь представление о рынке застройщиков и явных подаваемых заявках. Здесь есть несколько открытых исследовательских вопросов, но это захватывающее предложение снова критически важно для обеспечения децентрализованных валидаторов.

Однослотовая окончательность

Быстрое завершение - это здорово. Ожидание ~15 минут неоптимально с точки зрения UX или межцепочечной коммуникации. Более того, это вопрос реорганизации MEV.

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

Однослотовая окончательность устраняет эту угрозу. Для отмены финализированного блока потребуется как минимум треть всех валидаторов, и они немедленно сократят свою долю (миллионы ETH).

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

В сегодняшнем протоколе консенсуса (без однослотовой окончательности) Ethereum требует, чтобы только 1/32 валидаторов подтвердили каждый слот (~12 000 из более чем ~380 000 в настоящее время). Растягивание этого голосования до полного набора валидаторов с агрегацией подписей BLS в одном слоте требует большей работы. Это позволит сжать сотни тысяч голосов в одну проверку:

Виталик разбирает некоторые интересные решения здесь.

Единые секретные выборы лидера

SSLE стремится устранить еще один вектор MEV-атаки, с которым мы столкнемся после слияния.

Список валидаторов Beacon Chain и список предстоящих выборов лидеров являются публичными, и их довольно легко деанонимизировать и сопоставить их IP-адреса. Вы, вероятно, можете увидеть эту проблему здесь.

Более сложные валидаторы могут использовать трюки, чтобы лучше скрыть себя, но мелкие валидаторы будут особенно восприимчивы к тому, что их могут вычислить и впоследствии подвергнуть DDOSd. Это может быть легко использовано для MEV.

Допустим, вы предлагаете на блоке n, а я предлагаю на блоке n+1. Если я знаю ваш IP-адрес, я могу дешево подвергнуть вас DDOS-атаке, так что вы выйдете из тайм-аута и не сможете выдать свой блок. Теперь я получаю MEV обоих наших слотов и удваиваю свое вознаграждение. Это усугубляется эластичным размером блока в EIP-1559 (максимальный газ на блок вдвое больше целевого размера), так что я могу впихнуть транзакции, которые должны были быть в два блока, в свой единственный блок, который теперь вдвое длиннее.

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

Часть IV - Слияние: Под колпаком

Ладно, чтобы было понятно, я пошутил перед этим. Я действительно думаю (надеюсь), что слияние произойдет относительно скоро.

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

Клиенты после слияния

Сегодня вы запускаете один монолитный клиент (например, Go Ethereum, Nethermind и т.д.), который управляет всем. В частности, полные узлы выполняют обе задачи:

• Выполнение - выполнение каждой транзакции в блоке для обеспечения достоверности. Берут корень до состояния, выполняют все транзакции и проверяют, что полученный корень после состояния является правильным.
• Консенсус - проверка того, что вы находитесь в самой тяжелой (с наивысшим PoW) цепочке с наибольшим количеством проделанной работы (т.е. консенсус Накамото).

Они неразделимы, потому что полные узлы не только следуют самой тяжелой цепочке, они следуют самой тяжелой действительной цепочке. Вот почему они являются полными, а не легкими узлами. Полные узлы не будут принимать недействительные транзакции даже в случае атаки 51%.

В настоящее время цепочка маяков запускает консенсус только для тестового запуска PoS. Без исполнения. В конечном итоге будет принято решение о конечной общей сложности, и тогда текущие блоки выполнения Ethereum сольются с блоками Beacon Chain, образовав единую цепь:

Однако на полных узлах будут работать два отдельных клиента, которые будут взаимодействовать друг с другом:

• Execution client (f.k.a. "Eth1 client") - Текущие клиенты Eth 1.0 продолжают обрабатывать выполнение. Они обрабатывают блоки, поддерживают mempools, управляют и синхронизируют состояние. Материал PoW вычеркивается.
• Клиент консенсуса (f.k.a. "клиент Eth2") - Текущие клиенты Beacon Chain продолжают обрабатывать консенсус PoS. Они отслеживают голову цепи, сплетничают и подтверждают блоки, а также получают вознаграждения от валидаторов.

Клиенты получают блоки Beacon Chain, клиенты исполнения выполняют транзакции, затем клиенты консенсуса следуют за этой цепочкой, если все подтверждается. Вы сможете смешивать и сочетать клиентов исполнения и консенсуса по вашему выбору, все они будут совместимы. Для взаимодействия клиентов друг с другом будет введен новый API Engine:

Альтернатива:

Консенсус после слияния

Сегодняшний консенсус Накамото прост. Майнеры создают новые блоки и добавляют их в самую тяжелую из наблюдаемых действующих цепочек.

После слияния Ethereum переходит к GASPER - сочетанию Casper FFG (инструмент окончательности) плюс LMD GHOST (правило выбора вилки) для достижения консенсуса. В двух словах - это консенсус, благоприятствующий эффективности, в отличие от консенсуса, благоприятствующего безопасности.

Различие заключается в том, что алгоритмы консенсуса в пользу безопасности (например, Tendermint) останавливаются, когда они не получают необходимого количества голосов (⅔ набора валидаторов здесь). Цепочки, поддерживающие принцип Liveness (например, PoW + Nakamoto Consensus), продолжают строить оптимистичную бухгалтерскую книгу независимо от этого, но они не могут достичь окончательного результата без достаточного количества голосов. Биткойн и Ethereum сегодня никогда не достигают окончательности - вы просто предполагаете, что после достаточного количества блоков перестройка не произойдет.

Однако Ethereum также достигнет окончательности путем периодической контрольной точки при достаточном количестве голосов. Каждый экземпляр из 32 ETH является отдельным валидатором, и уже существует более 380 000 валидаторов Beacon Chain. Эпохи состоят из 32 слотов, при этом все валидаторы делятся на части и аттестуют один слот в рамках данной эпохи (что означает ~12 000 аттестаций на слот). Правило выбора вилки LMD Ghost затем определяет текущую главу цепочки на основе этих аттестаций. Новый блок добавляется каждый слот (12 секунд), поэтому эпохи составляют 6,4 минуты. Финальность достигается при наличии необходимых голосов, как правило, через две эпохи (таким образом, каждые 64 слота, хотя это может занять до 95).

Заключительные мысли

Все дороги ведут к конечной цели - централизованной добыче блоков, децентрализованной проверке блоков без доверия и противодействию цензуре. Дорожная карта Ethereum нацелена на это видение.

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

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

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