Треугольник масштабируемости утверждает, что между тремя характеристиками блокчейна: децентрализацией, масштабируемостью и безопасностью, существует противоречие. Это не строгое теорема, а скорее эвристический математический аргумент: если децентрализованный узел может проверять N транзакций в секунду, и у вас есть цепочка, обрабатывающая k*N транзакций в секунду, тогда либо каждая транзакция может быть увидена только 1/k узлами, что означает, что злоумышленнику достаточно разрушить несколько узлов, чтобы провести злонамеренную транзакцию; либо ваши узлы станут мощными, и ваша цепочка не будет децентрализованной.
На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что они решают тройственный парадокс, не меняя архитектуру в корне, обычно используя приемы программной инженерии для оптимизации узлов. Это всегда вводит в заблуждение, так как запуск узлов на этих цепях значительно сложнее, чем запуск узлов на Ethereum.
Однако сочетание выборки доступности данных и SNARKs действительно решает треугольный парадокс: это позволяет клиентам проверять, что определенное количество данных доступно, и что определенное количество вычислительных шагов выполнено правильно, при условии, что они загружают только небольшое количество данных и выполняют очень мало вычислений. SNARKs являются доверительными. Выборка доступности данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики недоступной цепочки, то есть даже атака на 51% не может заставить плохие блоки приниматься сетью.
Другим способом решения тройной проблемы является архитектура Plasma, которая использует хитрые технологии, чтобы в стимулирующем совместимом формате передать ответственность за доступность данных на мониторинг пользователям. С распространением SNARKs архитектура Plasma становится более жизнеспособной для более широких сценариев использования, чем когда-либо.
Дальнейшее развитие выборки доступности данных
Какую проблему мы решаем?
13 марта 2024 года, когда обновление Dencun будет запущено, на блокчейне Ethereum в каждом слоте каждые 12 секунд будет 3 блоба размером около 125 кБ, или доступная полоса пропускания данных в каждом слоте составит примерно 375 кБ. Предположим, что данные транзакций публикуются непосредственно в цепочке, тогда перевод ERC20 составляет около 180 байт, следовательно, максимальная TPS Rollup на Ethereum будет: 375000 / 12 / 180 = 173.6 TPS.
Если мы добавим calldata Эфира, то это будет 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель - 16 МБ на слот, что в сочетании с улучшениями компрессии данных Rollup приведет к ~58000 TPS.
PeerDAS является относительно простой реализацией "1D sampling". В Эфире каждый blob представляет собой многочлен степени 4096 в поле простых чисел с 253 битами. Мы передаем shares многочлена, каждый из которых содержит 16 оценок на соседних 16 координатах из общего числа 8192 координат. Из этих 8192 оценок любые 4096 могут быть восстановлены из blob.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob и запрашивает необходимые блобы в других подсетях у узлов, находящихся в глобальной p2p-сети. Более консервативная версия SubnetDAS использует только механизм подсетей без дополнительных запросов к пировому уровню. Текущая идея заключается в том, чтобы узлы, участвующие в механизме подтверждения доли, использовали SubnetDAS, а остальные узлы использовали PeerDAS.
С теоретической точки зрения, мы можем значительно расширить масштаб "1D sampling": если мы увеличим максимальное количество blob до 256, мы сможем достичь цели в 16MB, а в образцах доступности данных каждый узел получает 16 образцов * 128 blob * 512 байт на каждый образец = 1 MB полосы пропускания данных на каждый слот. Это едва укладывается в наши пределы допустимости: это осуществимо, но это означает, что клиенты с ограниченной пропускной способностью не могут выполнять выборку. Мы можем оптимизировать это в определенной степени, уменьшив количество blob и увеличив их размер, но это повысит стоимость восстановления.
Таким образом, мы в конечном итоге хотим сделать шаг дальше и провести 2D-выборку, этот метод включает в себя не только случайную выборку внутри blob, но и случайную выборку между blob. Используя линейные свойства KZG-коммитмента, мы расширяем набор blob в блоке с помощью группы новых виртуальных blob, которые избыточно кодируют ту же информацию.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому этот подход в основном является дружелюбным к распределенному построению блоков. Узлы, фактически строящие блоки, должны иметь только KZG-обязательства blob, и они могут полагаться на выборку доступности данных для проверки доступности блоков данных. Одномерная выборка доступности данных также по сути дружелюбна к распределенному построению блоков.
Что еще нужно сделать? Какие еще есть компромиссы?
Далее следует завершение внедрения и запуска PeerDAS. После этого необходимо постоянно увеличивать количество blob на PeerDAS, одновременно внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности, что является постепенным процессом. В то же время мы надеемся на большее количество научных работ, касающихся нормализации PeerDAS и других версий DAS, а также взаимодействия с вопросами безопасности, касающимися правил выбора форков.
На более дальних этапах в будущем нам необходимо будет провести больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также надеемся в конечном итоге перейти от KZG к альтернативе, которая будет квантово-устойчивой и не требовать доверенной настройки. В настоящее время нам неясно, какие кандидаты являются дружелюбными для распределенного построения блоков. Даже с использованием дорогостоящей технологии "грубой силы", то есть с использованием рекурсивного STARK для генерации доказательств корректности, необходимых для восстановления строк и столбцов, этого недостаточно, поскольку, хотя технически размер одного STARK составляет O(log(n) * log(log(n)) хэш-значений, на практике STARK почти такого же размера, как весь blob.
Я считаю, что долгосрочный реалистичный путь таков:
Реализация идеального 2D DAS;
Продолжать использовать 1D DAS, жертвуя эффективностью полосы пропускания выборки, принимая более низкий предел данных ради простоты и надежности.
Отказаться от DA и полностью принять Plasma как нашу основную архитектуру Layer2.
Обратите внимание, что даже если мы решим напрямую масштабировать выполнение на уровне L1, этот выбор также существует. Это потому, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам понадобится эффективный способ верификации их корректности, поэтому нам придется использовать ту же технологию на уровне L1, что и в Rollup.
Как взаимодействовать с другими частями дорожной карты?
Если будет реализована сжатие данных, потребность в 2D DAS уменьшится, или, по крайней мере, будет отложена, если Plasma будет широко использоваться, то потребность еще больше уменьшится. DAS также ставит перед протоколами и механизмами распределенного построения блоков вызовы: хотя DAS теоретически дружелюбен к распределенной реконструкции, на практике это требует сочетания с предложением списка включения пакетов и механизмами выбора ответвлений вокруг него.
Сжатие данных
Какую проблему мы решаем?
Каждая транзакция в Rollup занимает большое количество пространства на цепочке: передача ERC20 требует примерно 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протоколов Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем решить не только проблемы с числителем, но и проблемы со знаменателем, и сделать так, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение — это изображение двухлетней давности:
В сжатии нулевых байтов каждый длинный нулевой байтовый последовательность заменяется двумя байтами, указывающими, сколько нулевых байтов содержится. Более того, мы использовали специфические свойства транзакций:
Агрегация подписей: мы перешли от подписей ECDSA к подписям BLS. Особенностью подписей BLS является то, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить действительность всех оригинальных подписей. На уровне L1, даже несмотря на агрегацию, вычислительная стоимость верификации остается высокой, поэтому использование подписей BLS не рассматривается. Однако в L2, в такой среде, где данные дефицитны, использование подписей BLS имеет смысл. Агрегационные характеристики ERC-4337 предоставляют путь для реализации этой функции.
Замените адреса на указатели: если ранее использовался определенный адрес, мы можем заменить 20-байтовый адрес на 4-байтовый указатель, указывающий на определенное место в истории.
Кастомная сериализация значений交易------Большинство значений交易имеют небольшое количество знаков, например, 0,25 ETH представляется как 250000000000000000 wei. Максимальная базовая комиссия и приоритетная комиссия также аналогичны. Следовательно, мы можем использовать индивидуальный десятичный формат с плавающей точкой для представления большинства валютных значений.
что еще нужно сделать, какие есть компромиссы?
Следующим шагом будет фактическая реализация вышеуказанного плана. Основные компромиссы включают:
Переход на подпись BLS требует значительных усилий и снизит совместимость с надежными аппаратными чипами, которые могут повысить безопасность. Вместо этого можно использовать упаковку ZK-SNARK с другими схемами подписи.
2、Динамическое сжатие ( Например, замена адресов ) на указатели усложнит код клиента.
Публикация различий в состоянии на цепочке вместо транзакций снизит уровень аудита и сделает невозможной работу многих программ (, таких как блокчейн-браузеры ).
Как взаимодействовать с другими частями дорожной карты?
Использование ERC-4337 и окончательное включение его части в L2 EVM может значительно ускорить развертывание агрегирующих технологий. Размещение части ERC-4337 на L1 может ускорить его развертывание на L2.
Даже при использовании 16 МБ blob и сжатия данных, 58,000 TPS может не быть достаточно для полного удовлетворения потребностей потребителей в платежах, децентрализованных социальных сетях или других областях с высокой пропускной способностью, особенно когда мы начинаем учитывать факторы конфиденциальности, что может снизить масштабируемость в 3-8 раз. Для сценариев с высоким объемом транзакций и низкой стоимостью текущим вариантом является использование Validium, который хранит данные вне цепи и использует интересную модель безопасности: операторы не могут украсть средства пользователей, но они могут временно или навсегда заморозить все средства пользователей. Но мы можем сделать лучше.
Что это такое и как это работает?
Plasma является решением для масштабирования, которое включает в себя оператора, публикующего блоки вне цепочки и помещающего корень Меркла этих блоков в цепочку. Для каждого блока оператор отправляет каждому пользователю ветвь Меркла, чтобы подтвердить, какие изменения произошли с активами пользователя или не произошли. Пользователи могут извлекать свои активы, предоставляя ветвь Меркла. Важно, что эта ветвь не обязательно должна быть корнем для последнего состояния. Таким образом, даже если возникают проблемы с доступностью данных, пользователи все равно могут восстановить свои активы, извлекая свое доступное последнее состояние. Если пользователь подает недействительную ветвь, можно определить законное право на активы с помощью механизма оспаривания в цепочке.
Ранние версии Plasma могли обрабатывать только платежные случаи, и не могли эффективно расширяться. Однако если мы потребуем, чтобы каждый корень проверялся с помощью SNARK, то Plasma станет гораздо мощнее. Каждая игра с вызовом может быть значительно упрощена,
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
6 Лайков
Награда
6
6
Репост
Поделиться
комментарий
0/400
AltcoinMarathoner
· 17ч назад
в криптовалюте с 2016 года... масштабирование - это не спринт, это ультрамарафон. eth все еще ведущий в этой группе fr
Посмотреть ОригиналОтветить0
BoredApeResistance
· 23ч назад
Когда же слой 2 станет реальностью, эх?
Посмотреть ОригиналОтветить0
NeverVoteOnDAO
· 08-10 19:10
Снова говорят эти пустые слова, Узел не может работать.
Посмотреть ОригиналОтветить0
FancyResearchLab
· 08-10 18:58
Академическая ценность насоса, я зашёл в аккаунт, чтобы провести небольшой эксперимент.
Посмотреть ОригиналОтветить0
BlockchainThinkTank
· 08-10 18:51
Несмотря на любые красивые слова, данные никогда не обманут, неудачникам рекомендуется спокойно наблюдать за изменениями.
Посмотреть ОригиналОтветить0
FudVaccinator
· 08-10 18:44
Тройной парадокс все равно не обойти, с ним придется столкнуться.
Ethereum Прорыв: преодоление пределов масштабируемости
Будущее Ethereum: всплеск
Парадокс треугольника масштабируемости
Треугольник масштабируемости утверждает, что между тремя характеристиками блокчейна: децентрализацией, масштабируемостью и безопасностью, существует противоречие. Это не строгое теорема, а скорее эвристический математический аргумент: если децентрализованный узел может проверять N транзакций в секунду, и у вас есть цепочка, обрабатывающая k*N транзакций в секунду, тогда либо каждая транзакция может быть увидена только 1/k узлами, что означает, что злоумышленнику достаточно разрушить несколько узлов, чтобы провести злонамеренную транзакцию; либо ваши узлы станут мощными, и ваша цепочка не будет децентрализованной.
На протяжении многих лет некоторые высокопроизводительные цепочки утверждали, что они решают тройственный парадокс, не меняя архитектуру в корне, обычно используя приемы программной инженерии для оптимизации узлов. Это всегда вводит в заблуждение, так как запуск узлов на этих цепях значительно сложнее, чем запуск узлов на Ethereum.
Однако сочетание выборки доступности данных и SNARKs действительно решает треугольный парадокс: это позволяет клиентам проверять, что определенное количество данных доступно, и что определенное количество вычислительных шагов выполнено правильно, при условии, что они загружают только небольшое количество данных и выполняют очень мало вычислений. SNARKs являются доверительными. Выборка доступности данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики недоступной цепочки, то есть даже атака на 51% не может заставить плохие блоки приниматься сетью.
Другим способом решения тройной проблемы является архитектура Plasma, которая использует хитрые технологии, чтобы в стимулирующем совместимом формате передать ответственность за доступность данных на мониторинг пользователям. С распространением SNARKs архитектура Plasma становится более жизнеспособной для более широких сценариев использования, чем когда-либо.
Дальнейшее развитие выборки доступности данных
Какую проблему мы решаем?
13 марта 2024 года, когда обновление Dencun будет запущено, на блокчейне Ethereum в каждом слоте каждые 12 секунд будет 3 блоба размером около 125 кБ, или доступная полоса пропускания данных в каждом слоте составит примерно 375 кБ. Предположим, что данные транзакций публикуются непосредственно в цепочке, тогда перевод ERC20 составляет около 180 байт, следовательно, максимальная TPS Rollup на Ethereum будет: 375000 / 12 / 180 = 173.6 TPS.
Если мы добавим calldata Эфира, то это будет 607 TPS. Используя PeerDAS, количество blob может увеличиться до 8-16, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Наша среднесрочная цель - 16 МБ на слот, что в сочетании с улучшениями компрессии данных Rollup приведет к ~58000 TPS.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Что это? Как это работает?
PeerDAS является относительно простой реализацией "1D sampling". В Эфире каждый blob представляет собой многочлен степени 4096 в поле простых чисел с 253 битами. Мы передаем shares многочлена, каждый из которых содержит 16 оценок на соседних 16 координатах из общего числа 8192 координат. Из этих 8192 оценок любые 4096 могут быть восстановлены из blob.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob и запрашивает необходимые блобы в других подсетях у узлов, находящихся в глобальной p2p-сети. Более консервативная версия SubnetDAS использует только механизм подсетей без дополнительных запросов к пировому уровню. Текущая идея заключается в том, чтобы узлы, участвующие в механизме подтверждения доли, использовали SubnetDAS, а остальные узлы использовали PeerDAS.
С теоретической точки зрения, мы можем значительно расширить масштаб "1D sampling": если мы увеличим максимальное количество blob до 256, мы сможем достичь цели в 16MB, а в образцах доступности данных каждый узел получает 16 образцов * 128 blob * 512 байт на каждый образец = 1 MB полосы пропускания данных на каждый слот. Это едва укладывается в наши пределы допустимости: это осуществимо, но это означает, что клиенты с ограниченной пропускной способностью не могут выполнять выборку. Мы можем оптимизировать это в определенной степени, уменьшив количество blob и увеличив их размер, но это повысит стоимость восстановления.
Таким образом, мы в конечном итоге хотим сделать шаг дальше и провести 2D-выборку, этот метод включает в себя не только случайную выборку внутри blob, но и случайную выборку между blob. Используя линейные свойства KZG-коммитмента, мы расширяем набор blob в блоке с помощью группы новых виртуальных blob, которые избыточно кодируют ту же информацию.
Крайне важно, что расширение вычислительных обязательств не требует наличия blob, поэтому этот подход в основном является дружелюбным к распределенному построению блоков. Узлы, фактически строящие блоки, должны иметь только KZG-обязательства blob, и они могут полагаться на выборку доступности данных для проверки доступности блоков данных. Одномерная выборка доступности данных также по сути дружелюбна к распределенному построению блоков.
Что еще нужно сделать? Какие еще есть компромиссы?
Далее следует завершение внедрения и запуска PeerDAS. После этого необходимо постоянно увеличивать количество blob на PeerDAS, одновременно внимательно наблюдая за сетью и улучшая программное обеспечение для обеспечения безопасности, что является постепенным процессом. В то же время мы надеемся на большее количество научных работ, касающихся нормализации PeerDAS и других версий DAS, а также взаимодействия с вопросами безопасности, касающимися правил выбора форков.
На более дальних этапах в будущем нам необходимо будет провести больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасные свойства. Мы также надеемся в конечном итоге перейти от KZG к альтернативе, которая будет квантово-устойчивой и не требовать доверенной настройки. В настоящее время нам неясно, какие кандидаты являются дружелюбными для распределенного построения блоков. Даже с использованием дорогостоящей технологии "грубой силы", то есть с использованием рекурсивного STARK для генерации доказательств корректности, необходимых для восстановления строк и столбцов, этого недостаточно, поскольку, хотя технически размер одного STARK составляет O(log(n) * log(log(n)) хэш-значений, на практике STARK почти такого же размера, как весь blob.
Я считаю, что долгосрочный реалистичный путь таков:
Обратите внимание, что даже если мы решим напрямую масштабировать выполнение на уровне L1, этот выбор также существует. Это потому, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам понадобится эффективный способ верификации их корректности, поэтому нам придется использовать ту же технологию на уровне L1, что и в Rollup.
Как взаимодействовать с другими частями дорожной карты?
Если будет реализована сжатие данных, потребность в 2D DAS уменьшится, или, по крайней мере, будет отложена, если Plasma будет широко использоваться, то потребность еще больше уменьшится. DAS также ставит перед протоколами и механизмами распределенного построения блоков вызовы: хотя DAS теоретически дружелюбен к распределенной реконструкции, на практике это требует сочетания с предложением списка включения пакетов и механизмами выбора ответвлений вокруг него.
Сжатие данных
Какую проблему мы решаем?
Каждая транзакция в Rollup занимает большое количество пространства на цепочке: передача ERC20 требует примерно 180 байт. Даже при идеальной выборке доступности данных это ограничивает масштабируемость протоколов Layer. Каждый слот 16 МБ, мы получаем:
16000000 / 12 / 180 = 7407 TPS
Что если мы сможем решить не только проблемы с числителем, но и проблемы со знаменателем, и сделать так, чтобы каждая транзакция в Rollup занимала меньше байтов в цепочке?
Что это такое и как это работает?
На мой взгляд, лучшее объяснение — это изображение двухлетней давности:
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
В сжатии нулевых байтов каждый длинный нулевой байтовый последовательность заменяется двумя байтами, указывающими, сколько нулевых байтов содержится. Более того, мы использовали специфические свойства транзакций:
Агрегация подписей: мы перешли от подписей ECDSA к подписям BLS. Особенностью подписей BLS является то, что несколько подписей могут быть объединены в одну единую подпись, которая может подтвердить действительность всех оригинальных подписей. На уровне L1, даже несмотря на агрегацию, вычислительная стоимость верификации остается высокой, поэтому использование подписей BLS не рассматривается. Однако в L2, в такой среде, где данные дефицитны, использование подписей BLS имеет смысл. Агрегационные характеристики ERC-4337 предоставляют путь для реализации этой функции.
Замените адреса на указатели: если ранее использовался определенный адрес, мы можем заменить 20-байтовый адрес на 4-байтовый указатель, указывающий на определенное место в истории.
Кастомная сериализация значений交易------Большинство значений交易имеют небольшое количество знаков, например, 0,25 ETH представляется как 250000000000000000 wei. Максимальная базовая комиссия и приоритетная комиссия также аналогичны. Следовательно, мы можем использовать индивидуальный десятичный формат с плавающей точкой для представления большинства валютных значений.
что еще нужно сделать, какие есть компромиссы?
Следующим шагом будет фактическая реализация вышеуказанного плана. Основные компромиссы включают:
2、Динамическое сжатие ( Например, замена адресов ) на указатели усложнит код клиента.
Как взаимодействовать с другими частями дорожной карты?
Использование ERC-4337 и окончательное включение его части в L2 EVM может значительно ускорить развертывание агрегирующих технологий. Размещение части ERC-4337 на L1 может ускорить его развертывание на L2.
! Виталик Новая статья: Возможное будущее Ethereum, всплеск
Обобщенный Плазма
Какую проблему мы решаем?
Даже при использовании 16 МБ blob и сжатия данных, 58,000 TPS может не быть достаточно для полного удовлетворения потребностей потребителей в платежах, децентрализованных социальных сетях или других областях с высокой пропускной способностью, особенно когда мы начинаем учитывать факторы конфиденциальности, что может снизить масштабируемость в 3-8 раз. Для сценариев с высоким объемом транзакций и низкой стоимостью текущим вариантом является использование Validium, который хранит данные вне цепи и использует интересную модель безопасности: операторы не могут украсть средства пользователей, но они могут временно или навсегда заморозить все средства пользователей. Но мы можем сделать лучше.
Что это такое и как это работает?
Plasma является решением для масштабирования, которое включает в себя оператора, публикующего блоки вне цепочки и помещающего корень Меркла этих блоков в цепочку. Для каждого блока оператор отправляет каждому пользователю ветвь Меркла, чтобы подтвердить, какие изменения произошли с активами пользователя или не произошли. Пользователи могут извлекать свои активы, предоставляя ветвь Меркла. Важно, что эта ветвь не обязательно должна быть корнем для последнего состояния. Таким образом, даже если возникают проблемы с доступностью данных, пользователи все равно могут восстановить свои активы, извлекая свое доступное последнее состояние. Если пользователь подает недействительную ветвь, можно определить законное право на активы с помощью механизма оспаривания в цепочке.
Ранние версии Plasma могли обрабатывать только платежные случаи, и не могли эффективно расширяться. Однако если мы потребуем, чтобы каждый корень проверялся с помощью SNARK, то Plasma станет гораздо мощнее. Каждая игра с вызовом может быть значительно упрощена,