Расширение всегда было одной из тем, которых Эфириум не может избежать. Если Эфириум хочет стать настоящим «мировым компьютером», он должен быть одновременно масштабируемым, безопасным и децентрализованным. Но одновременное выполнение этих трех условий является обязательным. известный в отрасли как «Невозможный треугольник блокчейна», представляет собой большую проблему, которая не решена во всей отрасли.
Однако в конце 2021 года исследователь и разработчик Ethereum Данкрад Файст предложил Danksharding, новое решение для шардинга для Ethereum, которое, похоже, принесло революционное решение «невозможного треугольника блокчейна» и может даже переписать всю индустрию. .
В этом исследовательском отчете будет предпринята попытка четко объяснить на просторечии, что представляет собой новое решение для шардинга Ethereum Danksharding, а также его плюсы и минусы. Причина, по которой написан этот исследовательский отчет, заключается в том, что о Данкшардинге очень мало статей на китайском языке, и большинство из них требуют высокого уровня знаний. Поэтому Шпинат попытается раскрыть для вас сложные принципы, лежащие в основе Данкшардинга, и использовать для их написания простой разговорный язык. Новички в Web3 также могут понять новое решение для сегментирования Ethereum, Danksharding, и его интерфейсное решение, EIP-4844.
Автор: шпинат шпинат
Количество слов: этот исследовательский отчет превышает 10 000 слов, а расчетное время чтения составляет 21 минуту.
Оглавление
Почему Эфириуму необходимо расширяться?
Фон расширения Ethereum
Что такое невозможный треугольник блокчейна?
Каковы текущие решения масштабирования для Ethereum?
Первоначальное решение для шардинга Ethereum Sharding1.0
Как работает механизм консенсуса POS в Ethereum?
Как выглядит первоначальное решение для шардинга Sharding1.0?
Каковы недостатки первоначального решения для шардинга Sharding1.0?
Что такое Danksharding, новое решение для шардинга Ethereum?
Прототип EIP-4844: Proto-Danksharding — новый тип транзакции Blob
Данкшардинг — комплексное решение для расширения
Выборка доступности данных
Стирающее кодирование
Полиномиальное обязательство KZG (Обязательство KZG)
Разделение предлагающего/строителя
Список сопротивления цензуре (crList)
Двухслотовое разделение между предлагающим и строителем
Подвести итог
Ссылки
Почему Эфириуму необходимо расширяться?
После того, как основатель Ethereum Виталик Бутерин опубликовал в 2014 году официальный документ Ethereum «Смарт-контракты следующего поколения и децентрализованная платформа приложений», блокчейн открыл новую эру. Рождение смарт-контрактов позволяет людям создавать децентрализованные приложения (DApps) на Ethereum, а также привносит ряд инноваций в экосистему блокчейнов, таких как NFT, DeFi, GameFi и т. д.
Фон расширения Ethereum
По мере роста экосистемы в цепочке Ethereum все больше и больше людей начинают использовать Ethereum, и проблемы с производительностью Ethereum начинают проявляться. Когда много людей одновременно взаимодействуют с Ethereum, в блокчейне возникает «пробка», точно так же, как фиксировано время работы светофора на дороге, и количество транспортных средств в пределах определенного количества не будет вызывать пробки, но внезапно во время пика. часов. Когда светофор загорается зеленым, на эту дорогу выезжает много автомобилей. Количество транспортных средств, выезжающих с дороги, когда загорается зеленый свет, намного меньше, чем количество новых транспортных средств, выезжающих на дорогу в ожидании светофора. Это приведет к крупным дорожно-транспортным происшествиям. Затор. Время, необходимое всем транспортным средствам для проезда по этой дороге. Оно будет растянуто навсегда, и то же самое справедливо и для блокчейна. Время подтверждения каждого интерактивного запроса будет растянуто.
Но в блокчейне растянуто не только время, но и высокие комиссии за газ (комиссию за газ можно понимать как жесткую комиссию, выплачиваемую майнерам, которые отвечают за упаковку и обработку всех транзакций в блокчейне), потому что майнеры будут давать приоритет транзакциям с самыми высокими ставками, что приведет к тому, что каждый поднимет комиссию за газ, чтобы бороться за более быстрое подтверждение запроса на взаимодействие, что вызовет «Газовую войну». Одним из наиболее известных событий стал проект NFT в 2017 году — CryptoKitties. Популярность CryptoKitties увеличила комиссию за газ до сотен долларов за взаимодействие. Взаимодействие на Ethereum обходится в десятки или даже сотни долларов в виде комиссии за газ.
Основная причина таких высоких комиссий за газ заключается в том, что производительность Ethereum больше не может удовлетворять потребности взаимодействия существующих пользователей. С точки зрения вычислений производительности, Ethereum отличается от Биткойна. Биткойн использует только простой реестр для обработки информации о переводе, поэтому TPS фиксирован и может обрабатывать 7 транзакций в секунду, но в Ethereum он отличается.
Из-за существования смарт-контрактов в Ethereum содержимое каждой транзакции различно, поэтому количество транзакций (TPS), которые может обработать каждый блок, зависит от объема данных транзакций, содержащихся в блоке, и объема данных каждой транзакции. Размер определяется на основе спроса в реальном времени. Мы можем узнать о механизме производительности Ethereum: (Следующая информация полезна для понимания Danksharding, обязательно прочитайте ее ~)
Ethereum устанавливает верхний предел объема данных блока на основе платы за газ. Блок может переносить до 30 миллионов GAS данных.
Эфириум не хочет, чтобы объем данных в каждом блоке был слишком большим, поэтому каждый блок имеет Gas Target (целевой газ) в 15 миллионов Gas.
В Ethereum существует набор стандартов потребления данных Gas. Однако, по оценкам Спинача, размер каждого блока составляет около 5–160 КБ, а средний размер блока составляет около 60–70 КБ.
Как только потребление газа блока превысит целевое значение газа, составляющее 15 миллионов газа, базовая плата за следующий блок будет на 12,5% дороже. Если она ниже базовой комиссии, базовая плата будет снижена. Этот механизм представляет собой автоматизированный механизм динамической корректировки, который может продолжать увеличивать затраты, чтобы уменьшить перегрузку, когда транзакции достигают пика, и одновременно снижать затраты для привлечения большего количества транзакций, когда транзакции выполняются медленно.
Тогда, поняв вышеописанный механизм, мы сможем узнать, что TPS Эфириума является плавающим. **Мы можем рассчитать приблизительный TPS, просмотрев количество транзакций в каждом блоке через браузер блокчейна. Как видно из рисунка ниже, в среднем блок содержит около 160 транзакций, исходя из достижения целевого показателя газа с учетом Самый высокий может достигать более 300 транзакций. Учитывая время генерации блока, равное 12 секундам на блок, TPS составляет от 13 до 30 транзакций, но согласно известному на данный момент TPS Ethereum, он может достигать максимум 45 транзакций в секунду.
Источник: Mainnet | Beacon Chain Explorer (Phase 0) для Ethereum 2.0 – BeaconScan
Если взять в качестве примера производительность всемирно известной торговой системы VISA, которая может обрабатывать десятки тысяч транзакций в секунду, то производительность Ethereum, который хочет стать «мировым компьютером», и может обрабатывать до 45 транзакций в секунду действительно слишком слабо. Поэтому Ethereum срочно нуждается в расширении для решения проблем с производительностью, что связано с будущим Ethereum. Однако расширение — непростая задача, поскольку в индустрии блокчейнов существует «невозможный треугольник».
Что такое невозможный треугольник блокчейна?
«Невозможный треугольник блокчейна» относится к тому факту, что публичный блокчейн не может одновременно удовлетворять трем характеристикам: децентрализации, безопасности и масштабируемости.
Децентрализация: относится к степени децентрализации узлов. Чем больше узлов, тем более они рассредоточены и децентрализованы.
Безопасность: относится к безопасности всей сети блокчейна. Чем выше стоимость атаки, тем она безопаснее.
Масштабируемость: относится к производительности обработки транзакций блокчейна. Чем больше транзакций может быть обработано в секунду, тем более масштабируемым он является.
Если мы посмотрим на важность этих трех пунктов, мы обнаружим, что децентрализация и безопасность имеют наибольший вес. Децентрализация является краеугольным камнем Эфириума. Именно децентрализация обеспечивает нейтралитет Эфириума, устойчивость к цензуре, открытость, владение данными и практически нерушимую безопасность. . Важность безопасности, естественно, не нуждается в объяснении, но видение Ethereum заключается в достижении масштабируемости при условии децентрализации и безопасности. Трудность реализации можно себе представить, поэтому это также называется «невозможным треугольником блокчейна».
Источник изображения: Ethereum Vision |
Каковы текущие решения масштабирования для Ethereum?
Мы знаем, что в «невозможном треугольнике блокчейна» предпосылкой расширения Ethereum должно быть обеспечение децентрализации и безопасности. Чтобы обеспечить децентрализацию и безопасность, он не должен превышать предел при расширении. Улучшайте требования к возможностям узлов. Потому что узлы играют незаменимую роль в поддержании всей сети Ethereum. Узлы с высоким спросом не позволят большему количеству людей становиться узлами и становиться все более централизованными. Конечно, чем ниже порог для узлов, тем лучше. Участие большего количества людей делает Ethereum более децентрализованным и безопасным.
Таким образом, в настоящее время существует два решения для расширения Ethereum: Layer2 и Sharding — это автономное решение для расширения базового блокчейна (Layer1). Принцип заключается в размещении запросов в блокчейне в режиме Off-chain. Существует несколько решений уровня 2. В этом исследовательском отчете основное внимание уделяется только одному решению уровня 2 — Rollup: принцип Rollup заключается в том, чтобы упаковать сотни транзакций вне цепочки, как блины, в одну транзакцию и отправить их в Ethereum для достижения расширения. , каждый может очень дешево разделить стоимость загрузки в Ethereum и в то же время унаследовать безопасность Ethereum.
В настоящее время накопительный пакет делится на два типа: накопительный пакет оптимизма (оптимистический накопительный пакет) и ZK накопительный пакет (накопительный пакет с нулевым разглашением). Разница между этими двумя накопительными пакетами заключается в том, что все транзакции являются честными и заслуживающими доверия. и отправлен в Ethereum, после отправки пройдет определенный период времени (период проверки — в настоящее время одна неделя). Любой может задать вопрос и инициировать проверку подлинности транзакции, но если пользователь хочет передать ETH на OP). Сводка Если вы переключитесь на Ethereum, вам нужно дождаться окончания периода испытания, прежде чем вы сможете получить окончательное подтверждение.
ZK Rollup доказывает, что все транзакции действительны, создавая доказательство с нулевым разглашением, и загружает окончательные изменения состояния после выполнения всех транзакций в Ethereum. ZK Rollup более перспективен, чем Optimism Rollup. ZK Rollup не требует загрузки всех сжатых данных транзакций, как Optimism Rollup. Ему нужно только загрузить доказательство с нулевым разглашением и данные об изменении конечного состояния, что означает, что он может сжиматься. больше данных, чем OP Rollup, и не нужно ждать недельного периода испытаний, как OP Rollup. Однако самым большим недостатком ZK Rollup является то, что его чрезвычайно сложно разрабатывать, поэтому в краткосрочной перспективе Optimism Rollup будет. занимают большую часть рынка L2.
Помимо Layer2, существует еще одно решение для расширения — шардинг, главный герой этой статьи. Мы знаем, что Layer2 помещает транзакции в Ethereum в цепочку для обработки. Но независимо от того, как Layer2 обрабатывает данные, производительность самого Ethereum остается неизменной, поэтому эффект расширения, которого может достичь Layer2, на самом деле не так уж и значителен.
Шардинг предназначен для достижения расширения на уровне 1 Эфириума, но мы знаем, что необходимым условием для расширения Эфириума является обеспечение децентрализации и безопасности Эфириума, поэтому мы не можем слишком сильно увеличивать нагрузку на узлы.
Конкретная схема реализации шардинга всегда была темой постоянного обсуждения в сообществе Ethereum. Последняя схема — Danksharding, тема этой статьи. Также упоминается, что Danksharding — это новейшая схема шардинга. Прежде чем говорить о Danksharding, поговорим о шпинате. Также позвольте мне кратко представить, как выглядит старое решение по сегментированию и почему оно не принято.
Первоначальное решение для шардинга Ethereum Sharding1.0
Прежде чем говорить о решении шардинга 1.0, нам нужно сначала представить, как работает текущий механизм консенсуса POS в Ethereum, поскольку это необходимые предварительные знания для понимания решения шардинга 1.0 и Danksharding. Мы поговорим о решении шардинга 1.0 A. краткое изложение (просто примерно знайте, что делать).
Как работает механизм консенсуса POS в Ethereum? [7]
Механизм консенсуса — это система, которая позволяет всем узлам, поддерживающим сеть в блокчейне, достичь консенсуса, и его важность очевидна. 15 сентября 2022 года Ethereum завершил «слияние» на этапе обновления Ethereum 2.0, то есть основная сеть Ethereum для доказательства рабочей нагрузки POW и цепочка маяков механизма доказательства капитала POS были объединены, и механизм доказательства капитала POS был официально Он заменил механизм проверки рабочей нагрузки POW и стал консенсусным механизмом Ethereum.
Мы знаем, что в механизме доказательства рабочей нагрузки POW майнеры конкурируют за право производить блоки посредством объединения вычислительных мощностей. В механизме доказательства справедливости POS майнеры конкурируют за право производить блоки, обещая 32 ETH, чтобы стать узлом проверки. Права на блокировку Ethereum (метод стейкинга здесь описываться не будет).
Помимо изменений в механизме консенсуса, время блока Ethereum также изменилось с предыдущего времени плавающего блока на фиксированное время, которое разделено на две единицы: слот (Slot) и период (Epoch): слот составляет 12 секунд. и Эпоха — 6,4 минуты. Эпоха содержит 32 слота. Проще говоря, один блок создается за 12 секунд, а 32 блока производятся за 6,4 минуты за один цикл (Эпоха).
Когда майнер обещает 32 ETH, чтобы стать узлом проверки, цепочка маяков будет использовать случайный алгоритм для выбора узла проверки в качестве узла производства блока для упаковки блока. Каждый блок будет случайным образом выбирать узел производства блока. При этом в каждом цикле Эпохи цепочка маяков будет равномерно и случайным образом назначать все узлы проверки каждого блока группе «Комитетов», состоящей как минимум из 128 узлов проверки.
То есть каждому блоку будет назначена 1/32 числа узлов проверки всех узлов. «Комитеты», состоящие из этих узлов проверки, должны проверять и голосовать за блоки, упакованные блоком, производящим узлы каждого блока. Когда узел, производящий блок, упаковывает блок, более двух третей узлов проверки голосуют за успешное создание блока.
Как выглядит первоначальное решение для шардинга Sharding1.0? [7]
В концепции дизайна первоначального решения для шардинга Sharding1.0 Ethereum был спроектирован из исходной основной цепочки максимум в 64 цепочки шардирования, а расширение достигалось за счет добавления нескольких новых цепочек. В этом решении каждая цепочка шардов отвечает за обработку данных Ethereum и передачу их в цепочку маяков. Цепочка маяков отвечает за координацию всей сети Ethereum. Узлы и комитеты, производящие блоки каждой цепочки шардов, контролируются маяком. Цепочки назначаются случайным образом.
Цепочка маяков и цепочка сегментов связаны перекрестными связями. Блок цепочки маяков передаст хэш-значение блоку сегмента того же блока, а затем блок сегмента перенесет этот хэш, если значение будет передано следующему. блок маяка, перекрестные ссылки могут быть достигнуты. Если значение пропущено, оно будет передано следующему блоку маяка.
Каковы недостатки первоначального решения для шардинга Sharding1.0?
Проще говоря, решение шардинга 1.0 состоит в том, чтобы разделить Ethereum на множество цепочек сегментов для совместной обработки данных, а затем передать данные в цепочку маяков для достижения расширения. Однако у этого решения есть много недостатков:
**Трудности разработки:** Технически очень сложно разделить Ethereum на 64 шард-цепочки, обеспечив при этом нормальную работу, и чем сложнее система, тем больше вероятность возникновения каких-то непредсказуемых лазеек. Это также вызовет множество ошибок. неприятности, если возникают проблемы и их необходимо устранить.
**Проблема с синхронизацией данных:** Каждый цикл Эпохи в цепочке маяков будет заново нарушать работу «комитетов», ответственных за проверку, поэтому каждое перераспределение узлов проверки представляет собой синхронизацию данных крупномасштабной сети, потому что если это узлу назначена новая цепочка шардов, ему необходимо синхронизировать данные этой цепочки шардов. Из-за разной пропускной способности узлов трудно гарантировать, что синхронизация будет завершена в течение указанного времени. Однако если узлам будет разрешено напрямую синхронизировать данные всех цепочек шардов, это значительно увеличит нагрузку на узлы, что сделает Эфириум все более централизованным. [2]
**Проблема роста объёма данных:** Хотя скорость обработки Ethereum значительно улучшилась, одновременная обработка данных несколькими цепочками осколков также привела к значительному увеличению объёма хранимых данных. Скорость расширения объёма данных Ethereum будет расти. во много раз быстрее, чем раньше, требования к производительности хранилища для узлов будут продолжать расти, что приведет к большей централизации.
**Невозможно решить проблему MEV:** Максимальная извлекаемая ценность (MEV) — это сумма, которую можно извлечь из производства блоков сверх стандартной награды за блок и максимальной стоимости топлива. После того, как транзакция инициируется в Ethereum, транзакция будет помещена в мемпул (пул, в котором хранятся транзакции, которые должны быть выполнены) в ожидании упаковки майнерами. Затем майнеры смогут видеть все транзакции в мемпуле и права майнеров. Большие, майнеры осваивают включение, исключение и упорядочивание транзакций. Если кто-то получает прибыль, подкупая майнеров для корректировки порядка транзакций в пуле транзакций, платя больше комиссий за газ, это максимальная извлекаемая стоимость MEV. [6]
Например:
Существует метод MEV, называемый «сэндвич-атакой» или «клип-атакой». Этот метод извлечения MEV предназначен для мониторинга крупномасштабных транзакций DEX в цепочке. Например, кто-то хочет купить альткойны на сумму 1 миллион долларов США на Uniswap. , и этот метод Транзакция значительно повысит цену альткоина. Когда транзакция будет помещена в мемпул, робот-монитор может обнаружить транзакцию. В это время робот подкупит майнера, который упаковал блок, для передачи. Операция покупки этого альткоина происходит перед этим человеком, а затем выполняет операцию продажи после операции покупки этого человека. Это похоже на сэндвич, в котором находится человек, совершивший крупномасштабные транзакции DEX. Таким образом, «сэндвич» представляет собой «сэндвич». Запущенный человек, который «атаковал», получил альткойн из-за прибыли от транзакции на крупную сумму этого человека, а человек, совершивший транзакцию на крупную сумму, причинил убытки. [6]
Существование MEV всегда приносило некоторые негативные последствия для Ethereum, такие как потери и ухудшение пользовательского опыта, вызванные «сэндвич-атаками», перегрузка сети, вызванная конкуренцией среди лидеров, высокие комиссии за газ и даже проблемы с централизацией узлов. с большей ценностью MEV может продолжать занимать больше акций в сети за счет дохода, потому что больший доход = больше ETH = больше интересов по ставкам, плюс высокие затраты, вызванные MEV (перегрузка сети и высокий GAS, вызванный опережающим запуском), вызовут непрерывную потеря пользователей Ethereum. Даже если значение MEV значительно превысит вознаграждение за блок, это приведет к нестабильности консенсуса и безопасности всего Ethereum, что не может быть решено с помощью решения шардинга 1.0, что приводит к ряду проблем.
Когда в конце 2021 года исследователь и разработчик Ethereum Данкрад Файст предложил Danksharding, новое решение для шардинга для Ethereum, сообщество Ethereum единогласно сочло Danksharding лучшим решением для расширения шардинга и может даже открыть новую эру в Ethereum. революция.
Danksharding использует новый набор идей сегментирования для решения проблемы расширения Ethereum, то есть решение сегментирования, основанное на объединении уровня 2. Это новое решение сегментирования может обеспечить децентрализацию без значительного увеличения нагрузки на узел. Оно решает проблему масштабируемости, одновременно гарантируя. безопасность, а также устраняет негативное воздействие, вызванное MEV.
На рисунке ниже видно, что цели «The Surge» и «The Scourge» на следующих этапах обновления Ethereum заключаются в следующем: достичь 100 000+ TPS в Rollup и избежать централизации, связанной с риском MEV и других протоколов.
Изображение/Источник: Vitalik.eth Перевод: ethereum.cn
Так как же Данкшардинг решает проблему расширения Эфириума? Начнем с предварительного решения Danksharding EIP-4844: Proto-Danksharding.
Прототип EIP-4844: Proto-Danksharding — новый тип транзакции Blob
EIP-4844 представляет новый тип транзакции в Ethereum — транзакцию Blob. Этот новый тип транзакции Blob может предоставить дополнительную подключаемую базу данных для Ethereum:
Размер большого двоичного объекта составляет примерно 128 КБ.
Транзакция может содержать до двух больших двоичных объектов — 256 КБ.
Каждый блок имеет 8 целевых BLOB-объектов по 1 МБ и может содержать максимум 16 BLOB-объектов по 2 МБ (концепция Target упоминается в контексте расширения).
Данные больших двоичных объектов временно хранятся и будут удалены через определенный период времени (текущая рекомендация сообщества — 30 дней).
В настоящее время средний размер каждого блока в Ethereum составляет всего около 85 КБ. Дополнительное пространство для хранения, предоставленное Blob в Ethereum, огромно. Вы должны знать, что общий размер данных всех реестров Ethereum с момента рождения Ethereum составлял всего около 1 ТБ. BLOB-объекты могут ежегодно приносить в Ethereum 2,5–5 ТБ дополнительных данных, что в несколько раз превышает объем данных во всем реестре Ethereum.
Можно сказать, что транзакция Blob, представленная EIP-4844, специально разработана для Rollup. Данные Rollup загружаются в Ethereum в форме Blob. Дополнительное пространство данных может позволить Rollup достичь более высокого TPS и при этом снизить затраты. со временем оно будет. Блоковое пространство, первоначально занимаемое Rollup, будет передано большему количеству пользователей.
Поскольку данные Blob хранятся временно, внезапное увеличение объема данных не приведет к увеличению нагрузки на производительность хранилища узла. Если временно хранятся только данные Blob за месяц, объем синхронизированных данных будет необходим блочному узлу. для загрузки дополнительных данных на 1–2 МБ, что, похоже, не обременяет требования к пропускной способности узла. С точки зрения объема хранения данных узлам необходимо загружать и сохранять только фиксированный объем данных около 200–400 ГБ (месячный объем данных), что только увеличивает стоимость, обеспечивая при этом децентрализацию и безопасность за счет небольшого узла. нагрузки, увеличение TPS и снижение стоимости исчисляются в десятки, а то и сотни раз. Это просто отличное решение проблемы масштабируемости Ethereum.
Что делать, если данные удалены и пользователь хочет получить доступ к предыдущим данным?
Прежде всего, целью протокола консенсуса Ethereum не является обеспечение постоянного хранения всех исторических данных. Вместо этого цель состоит в том, чтобы предоставить высокозащищенную доску объявлений в реальном времени с долгосрочным пространством для хранения других децентрализованных протоколов. Существование доски объявлений предназначено для обеспечения того, чтобы данные, опубликованные на доске объявлений, оставались достаточно долго. Любой пользователь или протокол, которому нужны эти данные, имеет достаточно времени для захвата данных и их сохранения, поэтому ответственность за их сохранение лежит на BLOB-данных. переданы другим ролям, таким как участники проекта уровня 2, протоколы децентрализованного хранения и т. д. [3]
Данкшардинг — комплексное решение для расширения
EIP-4844 стал первым шагом в расширении Ethereum вокруг Rollup, но для Ethereum эффект расширения, достигнутый EIP-4844, далеко не достаточен. Полное решение Danksharding еще больше расширяет объем данных, которые может переносить Blob, с 1–2 МБ на блок до 16–32 МБ и предлагает новый механизм разделения производителей и упаковщиков блоков (PBS) для решения проблем, вызванных MEV.
Тогда нам нужно знать, какие трудности возникнут при дальнейшем расширении мощностей на базе EIP-4844:
**Нагрузка узла слишком велика:** Мы знаем, что размер Blob в EIP-4844 составляет всего 1–2 МБ, что вполне приемлемо для увеличения нагрузки на узел, но если объем данных Blob будет расширен 16 раз до 16~32 МБ, независимо от того, идет ли речь о синхронизации данных или хранении данных, нагрузка на узлы будет слишком велика, а степень децентрализации Ethereum снизится.
**Проблемы с доступностью данных:** Если узел не загружает все данные Blob, он столкнется с проблемами доступности данных, поскольку данные не открыты в цепочке и не доступны в любое время. Например, узел Ethereum имеет сомнения по поводу доступности данных. определенную транзакцию в Optimism Rollup Challenge, но Optimism Rollup не передает эти данные. Если вы не можете получить исходные данные, вы не можете доказать, что эта транзакция проблематична. Поэтому, чтобы решить проблему доступности данных, вы должны убедиться, что данные открыты и доступны в любое время.
Так как же Данкшардинг решает эти проблемы?
Выборка доступности данных
Данкшардинг предложил решение — выборку доступности данных — для снижения нагрузки на узлы и обеспечения доступности данных.
Идея выборки доступности данных (DAS) состоит в том, чтобы разрезать данные в Blob на фрагменты данных и позволить узлам перейти от загрузки данных Blob к случайной проверке фрагментов данных Blob, чтобы фрагменты данных Blob были разбросаны по каждый узел Эфириума, но полные данные Blob хранятся во всем реестре Эфириума, при условии, что узлы должны быть достаточно большими и децентрализованными.
Например: например, данные Blob разбиваются на 10 фрагментов, и во всей сети имеется 100 узлов. Каждый узел будет случайным образом проверять и загружать фрагмент данных и отправлять случайно проверенный номер фрагмента в блок. блок — это если все пронумерованные фрагменты можно собрать вместе, Ethereum по умолчанию будет считать, что данные этого BLOB-объекта доступны, и исходные данные можно восстановить, объединив фрагменты. Однако также будет очень низкая вероятность того, что 100 узлов не отрисуют фрагмент с определенным номером. В этом случае данные будут отсутствовать, что в определенной степени снижает безопасность, но с точки зрения вероятности это приемлемо.
Danksharding использует две технологии для реализации выборки доступности данных (DAS): кодирование стирания (Erasure Coding) и полиномиальное обязательство KZG (KZG Commitment).
Стирающее кодирование
Erasure Coding — это отказоустойчивая технология кодирования. Использование стирающего кодирования для вырезания данных может позволить всем узлам Ethereum восстановить исходные данные, когда у них есть только более 50% фрагментов данных, что значительно сокращает объем данных. Конкретный принцип реализации Вероятность промаха сложнее. Вот математическая формула, служащая примером для примерного объяснения принципа: [2]
Сначала постройте функцию f(x) = ax + b и возьмите любые 4 значения x.
Предположим, m = f(0) = b, n = f(1) = a + b, мы можем получить a = n – b, b = m.
Предположим, p = f(2), q = f(3), мы можем получить p = 2a + b = 2n – m, q = 3a + b = 3n – 2m.
Затем четыре фрагмента m, n, p, q разбрасываются по узлам всей сети.
Согласно математической формуле, нам нужно найти только два фрагмента, чтобы выяснить, что представляют собой два других фрагмента.
Если вы найдете n и m, вы можете напрямую вычислить q=3n-2m и p=2n-m.
Если вы нашли q и p, вы можете положить (2p=4n-2m)-(q=3n-2m), чтобы получить 2p-q=n, а затем вы можете напрямую вычислить m.
Проще говоря, стирающее кодирование использует математические принципы для разделения данных Blob на множество фрагментов данных. Узлам Ethereum не нужно собирать все фрагменты данных. Им нужно собрать только более 50% фрагментов для восстановления исходных данных Blob. Таким образом, это значительно снижает вероятность недостаточного сбора фрагментов, и ее вероятность можно игнорировать.
Полиномиальное обязательство KZG (Обязательство KZG)
Полиномиальное обязательство KZG (KZG Commitment) — это криптографическая технология, используемая для решения проблемы целостности данных при стирающем кодировании. Поскольку узел только случайным образом проверяет фрагменты данных, вырезанные кодом стирания, узел не знает, действительно ли фрагменты данных происходят из исходных данных Blob, поэтому роль, ответственная за кодирование, должна сгенерировать полиномиальное обязательство KZG, чтобы доказать это. стирание. Фрагменты данных кода действительно являются частью исходных данных. Функция KZG чем-то похожа на дерево Меркла, но форма другая. Все доказательства KZG основаны на одном и том же полиноме.
Danksharding реализует выборку доступности данных (DAS) посредством стирающего кодирования и полиномиального обязательства KZG, что значительно снижает нагрузку на узлы, когда объем дополнительных данных, переносимых Blob-объектами, увеличивается до 16–32 МБ. В настоящее время сообщество Ethereum также предложило метод под названием. Схема 2D KZG дополнительно сокращает фрагменты данных для снижения пропускной способности и вычислительных требований, но окончательный используемый алгоритм все еще находится в стадии бурного обсуждения в сообществе, включая конструкцию DAS, которая также постоянно оптимизируется и совершенствуется.
Для Ethereum Data Availability Sampling (DAS) решает проблему расширения размера данных Blob с 16 МБ до 32 МБ при одновременном снижении нагрузки на узлы, но, похоже, возникает проблема: кто будет кодировать исходные данные?
Если вы хотите закодировать исходные данные Blob, предполагается, что узел кодирования должен иметь полные исходные данные. Для этого к узлу будут предъявляться более высокие требования. Ранее Шпинат упоминал, что Данкшардинг предложил новый механизм **Разделение производителей и упаковщиков блоков (PBS)** для решения проблем, вызванных MEV. Фактически, это решение не только решает проблему MEV, но и решает проблему кодирования. проблемы.
Разделение предлагающего/строителя
Прежде всего, мы знаем, что выборка доступности данных (DAS) снижает нагрузку на узлы по проверке больших двоичных объектов и обеспечивает децентрализованную проверку с низким уровнем конфигурации. Однако для создания этого блока вам необходимо иметь полные данные больших двоичных объектов и закодировать их, что улучшает ситуацию. Существует множество требований к полным узлам Ethereum. Разделение Proposer-Bundler (PBS) предлагает разделить узлы на две роли: Builder и Proposer. Узлы с высокой производительностью могут стать Builders, а узлы с низкой производительностью — предлагающими.
В настоящее время в Ethereum существует два типа узлов: полные узлы и легкие узлы. Полные узлы должны синхронизировать все данные в Ethereum, такие как списки транзакций и тела блоков. Полные узлы играют две роли: упаковку блоков и проверку блоков. Поскольку полный узел может видеть всю информацию в блоке, он может изменять порядок, добавлять или удалять транзакции в блоке, чтобы получить значение MEV. Легким узлам не нужно синхронизировать все данные, им нужно только синхронизировать заголовок блока для проверки блока. [1]
После реализации разделения предлагающего и упаковщика (PBS):
Узлы с высокопроизводительной конфигурацией могут стать Builders. Строителям необходимо нести ответственность только за загрузку данных Blob, кодирование и создание блоков, а затем транслировать их другим узлам для выборочных проверок. Для Builders, поскольку объем синхронизируемых данных и требования к пропускной способности. высокий, он будет относительно централизованным.
Узлы с более низкой конфигурацией производительности могут стать предлагающими. Предлагающим необходимо только проверить достоверность данных, а также создать и транслировать заголовки блоков. Однако для предлагающих требуются меньшие требования к объему данных синхронизации и пропускной способности, поэтому они будут децентрализованы.
PBS реализует разделение работы между узлами путем разделения ролей упаковки и проверки. Узлы с конфигурацией высокой производительности отвечают за загрузку всех данных для кодирования и распространения, а узлы с конфигурацией низкой производительности отвечают за выборочные проверки и верификацию. проблема с МЭВ решена?
Список сопротивления цензуре (crList)
Поскольку PBS разделяет работу по упаковке и проверке, упаковщик (строитель) фактически имеет больше возможностей для просмотра транзакций. Упаковщик может намеренно игнорировать определенные транзакции, сортировать и вставлять транзакции, которые он хочет вставить, по своему желанию. -резистентный список (crList) решает эти проблемы.
Механизм цензурно-устойчивого списка (crList): [1]
Прежде чем Builder упакует блочную транзакцию, Proposer сначала опубликует список, устойчивый к цензуре (crList). Этот crList содержит все транзакции в мемпуле.
Упаковщик (строитель) может выбирать только упаковку и сортировку транзакций в crList, что означает, что упаковщик не может ни вставить свою собственную частную транзакцию для получения MEV, ни намеренно отклонить транзакцию (если лимит газа не заполнен).
После упаковки Builder передает окончательную версию хэша списка транзакций предлагающему. Предлагающий выбирает один из списков транзакций для создания заголовка блока и передает его.
Когда узел синхронизирует данные, он получит заголовок блока от предлагающего (Proposer), а затем получит тело блока от упаковщика (Builder), чтобы убедиться, что тело блока является окончательно выбранной версией.
Негативное воздействие MEV, такое как «сэндвич-атака», устраняется с помощью списка антицензуры (crList). Узлы больше не могут получать аналогичный MEV путем вставки частных транзакций.
Конкретный план реализации PBS в Ethereum все еще находится на стадии обсуждения. Текущий возможный предварительный план реализации — PBS с двумя слотами.
Двухслотовое разделение между предлагающим и строителем
PBS с двумя слотами использует модель торгов для определения блоков:[2]
После получения crList строитель создает заголовок блока списка транзакций и делает ставки.
Предлагающий выбирает заголовок блока и конструктор, который преуспеет в окончательной ставке, и предлагающий безоговорочно получает комиссию за выигравшую ставку (независимо от того, сгенерирован действительный блок или нет).
Верификационная комиссия (комитеты) подтверждает заголовок выигрышного блока.
Строитель раскрывает тело выигрышного блока
Верификационная комиссия (Комитеты) подтверждает выигравшее Тело блока и проводит проверочное голосование (в случае его прохождения блок будет произведен. Если упаковщик умышленно не отдает Тело блока, будет считаться, что блок не существует)
Хотя Строитель по-прежнему может получать MEV, корректируя последовательность транзакций, механизм торгов двухслотовой PBS вызывает «инволюцию» среди этих Строителей. Когда всем приходится делать ставки, чтобы конкурировать за блоки, прибыль, полученная централизованными упаковщиками через MEV, будет постоянно сокращаться, а окончательная прибыль будет распределяться среди децентрализованных предлагающих (предлагающих). Это решает проблему централизованных упаковщиков. становится все более централизованным за счет приобретения MEV.
Однако двухслотовая PBS имеет конструктивный недостаток: мы видим, что в названии этой конструкции есть «Двухслотовый», что означает наличие двух слотов, а это означает, что в этой схеме эффективное время генерации блока равно. продлено до 24 секунд (один слот = 12 секунд), и сообщество Ethereum активно обсуждает, как решить эту проблему.
Подвести итог
Danksharding предлагает преобразующее решение для Ethereum, позволяющее решить «невозможный треугольник блокчейна»: добиться масштабируемости, одновременно гарантируя децентрализацию и безопасность Ethereum:
Благодаря интерфейсному решению EIP-4844: Proto-Danksharding представлен новый тип транзакции Blob. Дополнительный объем данных размером 1–2 МБ, переносимый Blob, может помочь Ethereum достичь более высокого TPS и снижения затрат на объединение.
Выборка доступности данных (DAS) реализуется посредством стирающего кодирования и полиномиального обязательства KZG, поэтому узлам необходимо только случайным образом проверять некоторые фрагменты данных, чтобы проверить доступность данных и снизить нагрузку на узлы.
Благодаря реализации выборки доступности данных (DAS) дополнительный объем данных Blob увеличивается до 16–32 МБ, что поднимает эффект расширения на более высокий уровень.
Благодаря разделению предлагающего и упаковщика (PBS) работа по проверке и упаковке блоков разделяется на две роли узлов, реализуя децентрализацию узлов упаковки и децентрализацию узлов проверки.
Негативное влияние MEV значительно снижается благодаря списку антицензуры (crList) и PBS с двумя слотами. Упаковщик не может вставлять частные транзакции или подвергать цензуре определенную транзакцию.
Во всяком случае, интерфейсное решение Danksharding EIP-4844 будет официально реализовано в обновлении Cancun после обновления Ethereum Shanghai. Наиболее прямым преимуществом после внедрения решения EIP-4844 является объединение и объединение на уровне 2. Экология. Более высокий TPS и более низкая стоимость очень подходят для высокочастотных приложений в цепочке. С таким же успехом мы можем предположить, что могут появиться некоторые «убийственные приложения». Централизованная генерация блоков + децентрализованная проверка + устойчивость к цензуре, достигнутая Данкшардингом, принесет новый виток повествования о публичной цепи в Эфириуме. В дополнение к Уровню 2, модульный блокчейн и Эфириум после Данкшардинга столкнутся, чтобы создать какую химическую реакцию?
Шпинат считает, что внедрение Данкшардинга перепишет все правила игры, а Эфириум выведет индустрию блокчейнов в новую эру!
Ссылки
[1] Доступность данных, расширение хранилища блокчейна.
[2] Понимание нового плана обновления Ethereum в одной статье Danksharding
[3] FAQ по Proto-Danksharding – HackMD
[4] Что такое «Данкшардинг» в научно-популярной версии V?
[5] Рекомендовано V God丨. Чтобы получить более глубокое представление о дорожной карте шардинга Ethereum, этого отчета достаточно.
[6] Статья Buidler DAO: Как спасти NFT от хакеров после кражи кошелька?
[7] История повторяется? Подробное объяснение Ethereum 2.0 и хард-форков.