Стратегии масштабирования Ethereum изначально делились на два типа: шардирование и протоколы второго уровня (Layer2). Шардирование позволяет каждому узлу проверять и хранить только часть транзакций, тогда как Layer2 строит сеть поверх Ethereum. Эти две стратегии в конечном итоге объединились, сформировав дорожную карту, сосредоточенную на Rollup, которая по-прежнему является стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простую специализацию: Ethereum L1 фокусируется на том, чтобы стать мощным и децентрализованным базовым уровнем, тогда как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе, как, например, судебная система (L1), которая защищает контракты и права собственности, а предприниматели (L2) строят на этой основе.
В этом году важные достижения были достигнуты в дорожной карте, сосредоточенной на Rollup: EIP-4844 блобы значительно увеличили пропускную способность данных Ethereum L1, несколько Rollup для Ethereum Virtual Machine вошли в первую стадию. Каждый L2 существует как «шардинг» с собственными правилами и логикой, разнообразие и многообразие способов реализации шардирования стали реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Наша задача сейчас - завершить дорожную карту, сосредоточенную на Rollup, решить эти проблемы, сохраняя при этом надежность и децентрализованность Ethereum L1.
В будущем Ethereum через L2 сможет достигать более 100000 TPS;
Поддержание децентрализации и надежности L1;
По крайней мере, некоторые L2 полностью унаследуют основные свойства Ethereum (: доверие, открытость, устойчивость к цензуре );
Ethereum должен восприниматься как единая экосистема, а не 34 разные блокчейна.
Обзор содержания
Парадокс треугольника масштабируемости
Дальнейшие достижения в выборке доступности данных
Сжатие данных
Обобщенный Plasma
Зрелая система доказательств L2
Улучшение межоперабельности между L2
Расширение выполнения на L1
Парадокс треугольника масштабируемости
Треугольная парадоксальность масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация ( низкая стоимость узлов ) масштабируемость ( обработка большого количества транзакций ) и безопасность ( злоумышленнику необходимо разрушить значительную часть узлов, чтобы одна транзакция провалилась ).
Треугольный парадокс не является теоремой, и пост, его представляющий, также не содержит математического доказательства. Он приводит эвристические аргументы: если децентрализованные дружелюбные узлы могут проверять N транзакций в секунду, у вас есть цепочка, обрабатывающая k*N транзакций в секунду, тогда: (i) каждая транзакция может быть увидена лишь 1/k узлом, злоумышленнику достаточно разрушить несколько узлов, чтобы провести злонамеренные транзакции, или (ii) ваши узлы станут сильнее, цепочка не будет децентрализованной. Статья не пытается доказать, что разрушить треугольный парадокс невозможно, а скорее показывает, что это трудно, нужно выйти за рамки мышления, подразумевающего этот аргумент.
На протяжении многих лет некоторые высокопроизводительные блокчейны утверждали, что они решили тройственный парадокс, не меняя архитектуру, обычно оптимизируя узлы с помощью программных инженерных приемов. Это всегда вводит в заблуждение, так как запуск узлов на этих блокчейнах сложнее, чем на Ethereum. В этой статье будет рассмотрено, почему это так, и почему только программная инженерия L1-клиента не может масштабировать Ethereum.
Тем не менее, сочетание выборки доступности данных с SNARKs действительно решает треугольный парадокс: оно позволяет клиентам загружать лишь небольшое количество данных и выполнять крайне незначительные вычисления, чтобы подтвердить доступность определенного объема данных и правильность выполнения определенных вычислительных шагов. SNARKs не требуют доверия. Выборка доступности данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики цепочки, не поддающейся масштабированию, так что даже атака на 51% не может заставить плохие блоки быть принятыми сетью.
Еще одним способом решения тройной проблемы является архитектура Plasma, которая ловко перекладывает ответственность за мониторинг доступности данных на пользователей. С 2017 по 2019 год, когда у нас были только доказательства мошенничества для расширения вычислительных мощностей, Plasma была сильно ограничена в безопасном выполнении, но с распространением SNARKs архитектура Plasma стала более жизнеспособной для более широких сценариев использования.
Дальнейшие достижения в выборке доступности данных
Какую проблему мы решаем?
13 марта 2024 года, когда будет запущено обновление Dencun, в блокчейне Ethereum каждые 12 секунд будет 3 слота по 125 кБ блобов, то есть доступная пропускная способность данных на слот составит около 375 кБ. Предположим, что данные транзакций публикуются непосредственно в сети, ERC20 перевод занимает примерно 180 байт, тогда максимальная TPS для Rollup в Ethereum составит: 375000 / 12 / 180 = 173.6 TPS
Максимальное значение теоретического calldata Ethereum (: 30 миллионов Gas за слот / 16 gas за байт = 1,875,000 байт за слот ), что будет равно 607 TPS. С использованием PeerDAS количество blob может вырасти до 8-16, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Среднесрочная цель состоит в том, чтобы каждая слот составляла 16 МБ, а в сочетании с улучшениями сжатия данных Rollup это приведет к ~58000 TPS.
Что это? Как это работает?
PeerDAS является относительно простым реализованием "1D sampling". В Ethereum каждый blob представляет собой 4096 многочленов над полем простых чисел размером 253. Мы транслируем shares многочлена, каждый из которых содержит 16 оценочных значений с 16 соседних координат из общего числа 8192 координат. Из этих 8192 оценочных значений любые 4096 ( в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов ) могут восстановить blob.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob, и запрашивает у одноранговых узлов в глобальной p2p сети (, кто будет слушать разные подсети ), чтобы запросить необходимые ему другие blob из подсетей. Более консервативная версия SubnetDAS использует только механизмы подсетей, без дополнительных запросов на уровне одноранговых узлов. Текущая предложенная схема позволяет узлам, участвующим в подтверждении доли, использовать SubnetDAS, в то время как другие узлы (, то есть клиенты ), используют PeerDAS.
Теоретически мы можем значительно увеличить масштаб "1D sampling": если увеличить максимальное количество blob до 256( с целью 128), мы сможем достичь цели в 16 МБ, а в образцах доступности данных каждый узел будет иметь 16 образцов * 128 blob * по 512 байт на каждый blob на каждый образец = 1 МБ пропускной способности данных на каждый слот. Это едва укладывается в пределы терпимости: это возможно, но означает, что клиенты с ограниченной пропускной способностью не смогут проводить выборку. Мы можем оптимизировать, уменьшив количество blob и увеличив размер blob, но это приведет к более высоким затратам на восстановление.
Таким образом, мы в конечном итоге хотим идти дальше и проводить 2D-выборку, которая будет случайной как внутри blob, так и между blob. Используя линейные свойства KZG-коммитментов, мы расширяем набор blob в блоке с помощью нового виртуального набора blob, где эти виртуальные blob кодируют одну и ту же информацию.
Важно отметить, что расширение вычислительных обязательств не требует наличия blob, поэтому этот подход изначально дружелюбен к распределенному построению блоков. Узлы, фактически строящие блоки, должны лишь иметь blob KZG обязательств, они могут полагаться на проверку доступности данных с помощью выборки доступности данных. Одномерная выборка доступности данных также по своей сути дружелюбна к распределенному построению блоков.
Что еще нужно сделать? Какие есть компромиссы?
Следующим шагом будет завершение внедрения и запуска PeerDAS. После этого будет постоянно увеличиваться количество blob на PeerDAS, а также внимательно следить за сетью и улучшать программное обеспечение для обеспечения безопасности, что является постепенным процессом. В то же время мы надеемся на большее количество научных работ, чтобы стандартизировать PeerDAS и другие версии DAS, а также изучить взаимодействие с такими вопросами, как безопасность правил выбора веток.
В будущем нам нужно будет больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасность. Мы также надеемся, что в конечном итоге сможем перейти от KZG к альтернативам, безопасным для квантовых технологий и не требующим доверенной настройки. В настоящее время неясно, какие кандидаты являются дружелюбными для распределенного построения блоков. Даже использование дорогой технологии "грубой силы", то есть использование рекурсивного STARK для генерации доказательств действительности, необходимых для восстановления строк и столбцов, не удовлетворяет требованиям, потому что, хотя технически размер STARK составляет O(log(n) * log(log(n)) хэш-значение ( с использованием STIR), на практике STARK почти такой же большой, как весь blob.
Я считаю, что долгосрочный реальный путь таков:
Реализация идеального 2D DAS;
Продолжайте использовать 1D DAS, жертвуя эффективностью полосы пропускания выборки, чтобы принять более низкий предел данных ради простоты и надежности.
Отказаться от DA и полностью принять Plasma в качестве нашей основной Layer2 архитектуры.
Пожалуйста, обратите внимание, что даже если мы решим непосредственно расширить выполнение на уровне L1, такой выбор также существует. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный способ проверки их правильности, поэтому нам придется использовать на уровне L1 такие же технологии, как Rollup(, такие как ZK-EVM и DAS).
Как взаимодействовать с другими частями дорожной карты?
Если реализовать сжатие данных, потребность в 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 представляется как 250,000,000,000,000,000 wei. Максимальная базовая комиссия и приоритетная комиссия также аналогичны. Таким образом, мы можем использовать настраиваемый десятичный формат с плавающей запятой для представления большинства валютных значений.
что еще нужно сделать, какие есть компромиссы?
Следующим шагом является фактическая реализация вышеупомянутого плана. Основные соображения включают в себя:
Переход на подпись BLS требует значительных усилий и снижает совместимость с надежными аппаратными чипами, которые могут повысить безопасность. Можно использовать другие схемы подписи, такие как упаковка ZK-SNARK, в качестве замены.
Динамическое сжатие ( Например, замена адресов ) на указатели усложнит код клиента.
Публикация различий в состоянии на блокчейн, а не в транзакциях, снизит аудитируемость, из-за чего многие программы (, такие как блокчейн-обозреватели ), не смогут работать.
Как взаимодействовать с другими частями дорожной карты?
Используя ERC-4337, и в конечном итоге включив его часть
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
24 Лайков
Награда
24
6
Поделиться
комментарий
0/400
LongTermDreamer
· 07-22 01:04
Через три года все будут смотреть на наше L2, накапливать не потеряешь.
Посмотреть ОригиналОтветить0
alpha_leaker
· 07-19 10:23
В бычий рынок нужно использовать L2, чтобы зарабатывать.
Посмотреть ОригиналОтветить0
GasDevourer
· 07-19 01:26
Не понял L2, потерял штаны!
Посмотреть ОригиналОтветить0
TrustlessMaximalist
· 07-19 01:21
Rollup действительно хорош, войти в позицию — это правильно.
Ethereum расширение: анализ The Surge и перспективы развития L2
Будущее Эфира: The Surge
Стратегии масштабирования Ethereum изначально делились на два типа: шардирование и протоколы второго уровня (Layer2). Шардирование позволяет каждому узлу проверять и хранить только часть транзакций, тогда как Layer2 строит сеть поверх Ethereum. Эти две стратегии в конечном итоге объединились, сформировав дорожную карту, сосредоточенную на Rollup, которая по-прежнему является стратегией масштабирования Ethereum.
Дорожная карта, сосредоточенная на Rollup, предлагает простую специализацию: Ethereum L1 фокусируется на том, чтобы стать мощным и децентрализованным базовым уровнем, тогда как L2 берет на себя задачу помощи в расширении экосистемы. Эта модель широко распространена в обществе, как, например, судебная система (L1), которая защищает контракты и права собственности, а предприниматели (L2) строят на этой основе.
В этом году важные достижения были достигнуты в дорожной карте, сосредоточенной на Rollup: EIP-4844 блобы значительно увеличили пропускную способность данных Ethereum L1, несколько Rollup для Ethereum Virtual Machine вошли в первую стадию. Каждый L2 существует как «шардинг» с собственными правилами и логикой, разнообразие и многообразие способов реализации шардирования стали реальностью. Но этот путь также сталкивается с некоторыми уникальными вызовами. Наша задача сейчас - завершить дорожную карту, сосредоточенную на Rollup, решить эти проблемы, сохраняя при этом надежность и децентрализованность Ethereum L1.
! Новости Виталика: возможное будущее Ethereum, всплеск
Всплеск: ключевая цель
Обзор содержания
Парадокс треугольника масштабируемости
Треугольная парадоксальность масштабируемости утверждает, что между тремя характеристиками блокчейна существует противоречие: децентрализация ( низкая стоимость узлов ) масштабируемость ( обработка большого количества транзакций ) и безопасность ( злоумышленнику необходимо разрушить значительную часть узлов, чтобы одна транзакция провалилась ).
Треугольный парадокс не является теоремой, и пост, его представляющий, также не содержит математического доказательства. Он приводит эвристические аргументы: если децентрализованные дружелюбные узлы могут проверять N транзакций в секунду, у вас есть цепочка, обрабатывающая k*N транзакций в секунду, тогда: (i) каждая транзакция может быть увидена лишь 1/k узлом, злоумышленнику достаточно разрушить несколько узлов, чтобы провести злонамеренные транзакции, или (ii) ваши узлы станут сильнее, цепочка не будет децентрализованной. Статья не пытается доказать, что разрушить треугольный парадокс невозможно, а скорее показывает, что это трудно, нужно выйти за рамки мышления, подразумевающего этот аргумент.
На протяжении многих лет некоторые высокопроизводительные блокчейны утверждали, что они решили тройственный парадокс, не меняя архитектуру, обычно оптимизируя узлы с помощью программных инженерных приемов. Это всегда вводит в заблуждение, так как запуск узлов на этих блокчейнах сложнее, чем на Ethereum. В этой статье будет рассмотрено, почему это так, и почему только программная инженерия L1-клиента не может масштабировать Ethereum.
Тем не менее, сочетание выборки доступности данных с SNARKs действительно решает треугольный парадокс: оно позволяет клиентам загружать лишь небольшое количество данных и выполнять крайне незначительные вычисления, чтобы подтвердить доступность определенного объема данных и правильность выполнения определенных вычислительных шагов. SNARKs не требуют доверия. Выборка доступности данных имеет тонкую модель доверия few-of-N, но сохраняет основные характеристики цепочки, не поддающейся масштабированию, так что даже атака на 51% не может заставить плохие блоки быть принятыми сетью.
Еще одним способом решения тройной проблемы является архитектура Plasma, которая ловко перекладывает ответственность за мониторинг доступности данных на пользователей. С 2017 по 2019 год, когда у нас были только доказательства мошенничества для расширения вычислительных мощностей, Plasma была сильно ограничена в безопасном выполнении, но с распространением SNARKs архитектура Plasma стала более жизнеспособной для более широких сценариев использования.
! Новости Виталика: Возможное будущее Ethereum, всплеск
Дальнейшие достижения в выборке доступности данных
Какую проблему мы решаем?
13 марта 2024 года, когда будет запущено обновление Dencun, в блокчейне Ethereum каждые 12 секунд будет 3 слота по 125 кБ блобов, то есть доступная пропускная способность данных на слот составит около 375 кБ. Предположим, что данные транзакций публикуются непосредственно в сети, ERC20 перевод занимает примерно 180 байт, тогда максимальная TPS для Rollup в Ethereum составит: 375000 / 12 / 180 = 173.6 TPS
Максимальное значение теоретического calldata Ethereum (: 30 миллионов Gas за слот / 16 gas за байт = 1,875,000 байт за слот ), что будет равно 607 TPS. С использованием PeerDAS количество blob может вырасти до 8-16, что обеспечит 463-926 TPS для calldata.
Это значительное улучшение для Ethereum L1, но этого недостаточно. Мы хотим больше масштабируемости. Среднесрочная цель состоит в том, чтобы каждая слот составляла 16 МБ, а в сочетании с улучшениями сжатия данных Rollup это приведет к ~58000 TPS.
Что это? Как это работает?
PeerDAS является относительно простым реализованием "1D sampling". В Ethereum каждый blob представляет собой 4096 многочленов над полем простых чисел размером 253. Мы транслируем shares многочлена, каждый из которых содержит 16 оценочных значений с 16 соседних координат из общего числа 8192 координат. Из этих 8192 оценочных значений любые 4096 ( в соответствии с текущими предложенными параметрами: любые 64 из 128 возможных образцов ) могут восстановить blob.
Работа PeerDAS заключается в том, чтобы каждый клиент слушал небольшое количество подсетей, где i-я подсеть транслирует i-й образец любого blob, и запрашивает у одноранговых узлов в глобальной p2p сети (, кто будет слушать разные подсети ), чтобы запросить необходимые ему другие blob из подсетей. Более консервативная версия SubnetDAS использует только механизмы подсетей, без дополнительных запросов на уровне одноранговых узлов. Текущая предложенная схема позволяет узлам, участвующим в подтверждении доли, использовать SubnetDAS, в то время как другие узлы (, то есть клиенты ), используют PeerDAS.
Теоретически мы можем значительно увеличить масштаб "1D sampling": если увеличить максимальное количество blob до 256( с целью 128), мы сможем достичь цели в 16 МБ, а в образцах доступности данных каждый узел будет иметь 16 образцов * 128 blob * по 512 байт на каждый blob на каждый образец = 1 МБ пропускной способности данных на каждый слот. Это едва укладывается в пределы терпимости: это возможно, но означает, что клиенты с ограниченной пропускной способностью не смогут проводить выборку. Мы можем оптимизировать, уменьшив количество blob и увеличив размер blob, но это приведет к более высоким затратам на восстановление.
Таким образом, мы в конечном итоге хотим идти дальше и проводить 2D-выборку, которая будет случайной как внутри blob, так и между blob. Используя линейные свойства KZG-коммитментов, мы расширяем набор blob в блоке с помощью нового виртуального набора blob, где эти виртуальные blob кодируют одну и ту же информацию.
Важно отметить, что расширение вычислительных обязательств не требует наличия blob, поэтому этот подход изначально дружелюбен к распределенному построению блоков. Узлы, фактически строящие блоки, должны лишь иметь blob KZG обязательств, они могут полагаться на проверку доступности данных с помощью выборки доступности данных. Одномерная выборка доступности данных также по своей сути дружелюбна к распределенному построению блоков.
Что еще нужно сделать? Какие есть компромиссы?
Следующим шагом будет завершение внедрения и запуска PeerDAS. После этого будет постоянно увеличиваться количество blob на PeerDAS, а также внимательно следить за сетью и улучшать программное обеспечение для обеспечения безопасности, что является постепенным процессом. В то же время мы надеемся на большее количество научных работ, чтобы стандартизировать PeerDAS и другие версии DAS, а также изучить взаимодействие с такими вопросами, как безопасность правил выбора веток.
В будущем нам нужно будет больше работы, чтобы определить идеальную версию 2D DAS и доказать ее безопасность. Мы также надеемся, что в конечном итоге сможем перейти от KZG к альтернативам, безопасным для квантовых технологий и не требующим доверенной настройки. В настоящее время неясно, какие кандидаты являются дружелюбными для распределенного построения блоков. Даже использование дорогой технологии "грубой силы", то есть использование рекурсивного STARK для генерации доказательств действительности, необходимых для восстановления строк и столбцов, не удовлетворяет требованиям, потому что, хотя технически размер STARK составляет O(log(n) * log(log(n)) хэш-значение ( с использованием STIR), на практике STARK почти такой же большой, как весь blob.
Я считаю, что долгосрочный реальный путь таков:
Пожалуйста, обратите внимание, что даже если мы решим непосредственно расширить выполнение на уровне L1, такой выбор также существует. Это связано с тем, что если уровень L1 должен обрабатывать большое количество TPS, блоки L1 станут очень большими, и клиентам потребуется эффективный способ проверки их правильности, поэтому нам придется использовать на уровне L1 такие же технологии, как Rollup(, такие как ZK-EVM и DAS).
Как взаимодействовать с другими частями дорожной карты?
Если реализовать сжатие данных, потребность в 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 представляется как 250,000,000,000,000,000 wei. Максимальная базовая комиссия и приоритетная комиссия также аналогичны. Таким образом, мы можем использовать настраиваемый десятичный формат с плавающей запятой для представления большинства валютных значений.
что еще нужно сделать, какие есть компромиссы?
Следующим шагом является фактическая реализация вышеупомянутого плана. Основные соображения включают в себя:
Переход на подпись BLS требует значительных усилий и снижает совместимость с надежными аппаратными чипами, которые могут повысить безопасность. Можно использовать другие схемы подписи, такие как упаковка ZK-SNARK, в качестве замены.
Динамическое сжатие ( Например, замена адресов ) на указатели усложнит код клиента.
Публикация различий в состоянии на блокчейн, а не в транзакциях, снизит аудитируемость, из-за чего многие программы (, такие как блокчейн-обозреватели ), не смогут работать.
Как взаимодействовать с другими частями дорожной карты?
Используя ERC-4337, и в конечном итоге включив его часть