! [Масштабируемость DA: текущее состояние Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
По мере того, как пользователи начинают интегрировать Avail в свои блокчейны, часто возникает вопрос: «Сколько транзакций может обрабатывать Aval?». В этом посте мы сравним пропускную способность Ethereum и Avail на основе текущей архитектуры двух цепочек.
Это первая статья из серии статей о масштабируемости Avail, в которой обсуждается текущая производительность Avail и его способность масштабироваться в ближайшей и долгосрочной перспективе.
Avail против Ethereum
Блоки Ethereum могут содержать до 1,875 МБ данных и иметь время блока около 13 секунд. Однако блоки Ethereum обычно не заполняются. Почти каждый блок не достигнет верхнего предела данных, потому что он достигает предела газа, потому что и выполнение, и расчет потребляют газ. В результате объем данных, хранящихся в каждом блоке, является переменным.
Необходимость объединения выполнения, расчетов и доступности данных в одном блоке является центральной проблемой единой архитектуры блокчейна. Роллапы L2 положили начало движению за модульные блокчейны, позволяющие выполнять операции в одной цепочке, а блоки цепочки предназначены для исполнения. Avail делает еще один шаг вперед, применяя модульную структуру, которая также разделяет доступность данных, позволяя блокам цепочки быть выделенными для доступности данных.
! [Масштабируемость DA: текущее состояние Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
В настоящее время время блока Avail составляет 20 секунд, и каждый блок может содержать около 2 МБ данных. Предполагая, что средний размер транзакции составляет 250 байт, каждый блок Avail может содержать около 8 400 транзакций (420 транзакций в секунду).
Более того, Avail всегда может заполнить блоки до предела хранилища и увеличить размер по мере необходимости. У нас есть ряд рычагов, которые можно быстро настроить, чтобы увеличить количество транзакций на блок до более чем 500 000 (25 000 транзакций в секунду), когда это необходимо.
Можем ли мы увеличить пропускную способность?
Чтобы увеличить пропускную способность (особенно количество транзакций в секунду), архитекторам цепочки необходимо увеличить размер блока или уменьшить время блока.
Чтобы быть добавленным в цепочку, каждый блок должен генерировать обязательства, создавать доказательства, распространять их и заставлять все остальные узлы проверять эти доказательства. Эти шаги всегда требуют времени, что устанавливает естественную верхнюю границу времени, необходимого для создания и подтверждения блоков.
Поэтому мы не можем просто сократить время блока, скажем, до одной секунды. У него просто не хватает времени, чтобы генерировать обязательства, генерировать доказательства и распространять эти части среди всех участников сети. За теоретическое время блока в одну секунду, даже если каждый участник сети запустит самую мощную машину, способную мгновенно выдавать обязательства и доказательства, узким местом будет распространение данных. Из-за ограничений скорости интернета сеть не может достаточно быстро уведомить все полные узлы о блокировках. Таким образом, мы должны убедиться, что время блока достаточно велико, чтобы данные могли быть распределены по сети после достижения консенсуса.
И наоборот, также можно увеличить пропускную способность, увеличив размер блока, т.е. увеличив объем данных, которые мы можем содержать в каждом блоке.
Текущая архитектура: Добавление блока в цепочку
Во-первых, давайте рассмотрим шаги, необходимые для добавления блока в цепочку. Есть три основных шага, необходимых для добавления каждого блока в цепочку. Сюда входит время, необходимое для создания блока, его распространения и проверки.
! [Масштабируемость DA: текущее состояние Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Генерация блоков
Этот шаг включает в себя время, необходимое для сбора и сортировки транзакций Avail, создания обязательств и масштабирования (стирающего кодирования) матрицы данных.
Генерация блока измеряет время, необходимое для создания блока, так как это всегда занимает по крайней мере некоторое время. Поэтому мы должны учитывать не только время в лучшем случае, но и среднюю ситуацию и время в худшем случае на разных машинах.
Самая слабая машина, которая может участвовать в генерации новых блоков, — это та, которая в среднем достигает предела производительности. Все более медленные машины в конечном итоге будут отставать, потому что они не смогут догнать более быстрые машины.
2. Задержка распространения
Задержка распространения — это мера времени, необходимого для распространения блока от производителя к валидатору и одноранговой сети.
В настоящее время размер блока Avail составляет 2 МБ. В рамках текущего 20-секундного ограничения по времени блока такой размер блока может быть распространен. Большие размеры блоков усложняют распространение.
Например, если мы увеличим Avail до поддержки блока размером 128 МБ, вычисления могут масштабироваться (около 7 секунд). Однако узким местом становится время, необходимое для отправки и загрузки этих блоков в сети.
Отправка блока размером 128 МБ по одноранговой сети за 5 секунд может быть пределом того, что достижимо в настоящее время.
Ограничение в 128 МБ не имеет ничего общего с доступностью данных или нашим сценарием обязательств, а скорее связано с ограничениями пропускной способности связи.
Эта необходимость учитывать задержку распространения дает нам текущее теоретическое ограничение размера блока Avail.
3. Проверка блоков
После распространения участвующие валидаторы не просто доверяют блокам, предоставленным им инициатором блока — им необходимо убедиться, что созданный блок действительно содержит данные, заявленные производителем.
Между этими тремя шагами существует определенное напряжение. Мы можем сделать всех валидаторов мощными машинами и плотно связанными отличной сетью в одном дата-центре – это сократит время производства и валидации, а также позволит нам распространять гораздо больше данных. Однако, поскольку мы также хотим иметь децентрализованную, разнообразную сеть с различными типами участников, это не идеальный подход.
Вместо этого увеличение пропускной способности будет достигнуто за счет понимания шагов, необходимых для добавления блоков в цепочку Avail, и того, какие шаги можно оптимизировать.
! [Масштабируемость DA: текущее состояние Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
В настоящее время валидаторы, использующие Avail, берут весь блок и копируют все обязательства, сгенерированные инициатором для проверки блока. Это означает, что производители блоков и все валидаторы должны выполнить каждый из шагов, описанных в таблице выше.
В одном блокчейне каждый валидатор по умолчанию реконструирует весь блок. Однако в такой цепочке, как Avail, где транзакции не выполняются, такое перестроение не требуется. Таким образом, один из способов оптимизации Avail заключается в том, чтобы позволить валидаторам достигать своих собственных гарантий доступности данных с помощью выборки, а не путем реконструкции блоков. Это менее ресурсоемко для валидаторов, чем требование повторить все обязательства. Подробнее об этом в следующей статье.
Как работает выборка доступности исследовательских данных?
В Avail легкие клиенты используют три основных инструмента для подтверждения доступности данных: выборки, обязательства и доказательства.
В настоящее время легкие клиенты выполняют примеры операций, которые запрашивают значение конкретной ячейки и связанное с ней подтверждение действительности из сети Avail. Чем больше образцов они берут, тем больше они уверены в том, что все данные доступны.
Обязательства генерируются инициаторами блоков и суммируют целую строку данных в блоке Avail. (Подсказка: этот шаг мы оптимизируем далее в этой серии.) ）
Каждая ячейка в сети генерирует доказательство. Легкие клиенты используют аттестации и промисы, чтобы убедиться в правильности значений предоставленных им ячеек.
Используя эти инструменты, облегченный клиент выполняет три шага.
Решение: Требуемая уверенность в доступности определяет количество выборок для выполнения на упрощенном клиенте. Им не требуется много образцов (8-30 образцов), чтобы гарантировать доступность более 99,95%.
Загрузка: Затем легкий клиент запрашивает эти образцы и связанные с ними доказательства и загружает их из сети (полный узел или другой легкий клиент).
Проверка: Они смотрят на промис в заголовке блока (который всегда доступен для легких клиентов) и проверяют доказательство каждой ячейки на соответствие промису.
Только с помощью этого легкие клиенты могут подтвердить доступность всех данных в блоке без необходимости скачивать большую часть содержимого блока. Другие шаги, предпринимаемые легкими клиентами, также вносят свой вклад в безопасность Avail, но не перечислены здесь. Например, легкие клиенты могут обмениваться образцами и доказательствами, которые они загружают, с другими легкими клиентами, если им это необходимо. Но это процедура для легких клиентов для подтверждения доступности данных!
Во второй части этой серии статей мы рассмотрим способы увеличения пропускной способности Avail в краткосрочной перспективе. Мы объясним, почему мы считаем, что Avail может удовлетворить потребности любой сети в наступающем году, и как мы можем улучшить сеть, чтобы справиться с проблемами предстоящих лет.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Масштабируемость DA: текущее состояние Avail
! [Масштабируемость DA: текущее состояние Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
По мере того, как пользователи начинают интегрировать Avail в свои блокчейны, часто возникает вопрос: «Сколько транзакций может обрабатывать Aval?». В этом посте мы сравним пропускную способность Ethereum и Avail на основе текущей архитектуры двух цепочек.
Это первая статья из серии статей о масштабируемости Avail, в которой обсуждается текущая производительность Avail и его способность масштабироваться в ближайшей и долгосрочной перспективе.
Avail против Ethereum
Блоки Ethereum могут содержать до 1,875 МБ данных и иметь время блока около 13 секунд. Однако блоки Ethereum обычно не заполняются. Почти каждый блок не достигнет верхнего предела данных, потому что он достигает предела газа, потому что и выполнение, и расчет потребляют газ. В результате объем данных, хранящихся в каждом блоке, является переменным.
Необходимость объединения выполнения, расчетов и доступности данных в одном блоке является центральной проблемой единой архитектуры блокчейна. Роллапы L2 положили начало движению за модульные блокчейны, позволяющие выполнять операции в одной цепочке, а блоки цепочки предназначены для исполнения. Avail делает еще один шаг вперед, применяя модульную структуру, которая также разделяет доступность данных, позволяя блокам цепочки быть выделенными для доступности данных.
! [Масштабируемость DA: текущее состояние Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
В настоящее время время блока Avail составляет 20 секунд, и каждый блок может содержать около 2 МБ данных. Предполагая, что средний размер транзакции составляет 250 байт, каждый блок Avail может содержать около 8 400 транзакций (420 транзакций в секунду).
Более того, Avail всегда может заполнить блоки до предела хранилища и увеличить размер по мере необходимости. У нас есть ряд рычагов, которые можно быстро настроить, чтобы увеличить количество транзакций на блок до более чем 500 000 (25 000 транзакций в секунду), когда это необходимо.
Можем ли мы увеличить пропускную способность?
Чтобы увеличить пропускную способность (особенно количество транзакций в секунду), архитекторам цепочки необходимо увеличить размер блока или уменьшить время блока.
Чтобы быть добавленным в цепочку, каждый блок должен генерировать обязательства, создавать доказательства, распространять их и заставлять все остальные узлы проверять эти доказательства. Эти шаги всегда требуют времени, что устанавливает естественную верхнюю границу времени, необходимого для создания и подтверждения блоков.
Поэтому мы не можем просто сократить время блока, скажем, до одной секунды. У него просто не хватает времени, чтобы генерировать обязательства, генерировать доказательства и распространять эти части среди всех участников сети. За теоретическое время блока в одну секунду, даже если каждый участник сети запустит самую мощную машину, способную мгновенно выдавать обязательства и доказательства, узким местом будет распространение данных. Из-за ограничений скорости интернета сеть не может достаточно быстро уведомить все полные узлы о блокировках. Таким образом, мы должны убедиться, что время блока достаточно велико, чтобы данные могли быть распределены по сети после достижения консенсуса.
И наоборот, также можно увеличить пропускную способность, увеличив размер блока, т.е. увеличив объем данных, которые мы можем содержать в каждом блоке.
Текущая архитектура: Добавление блока в цепочку
Во-первых, давайте рассмотрим шаги, необходимые для добавления блока в цепочку. Есть три основных шага, необходимых для добавления каждого блока в цепочку. Сюда входит время, необходимое для создания блока, его распространения и проверки.
! [Масштабируемость DA: текущее состояние Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Генерация блоков
Этот шаг включает в себя время, необходимое для сбора и сортировки транзакций Avail, создания обязательств и масштабирования (стирающего кодирования) матрицы данных.
Генерация блока измеряет время, необходимое для создания блока, так как это всегда занимает по крайней мере некоторое время. Поэтому мы должны учитывать не только время в лучшем случае, но и среднюю ситуацию и время в худшем случае на разных машинах.
Самая слабая машина, которая может участвовать в генерации новых блоков, — это та, которая в среднем достигает предела производительности. Все более медленные машины в конечном итоге будут отставать, потому что они не смогут догнать более быстрые машины.
2. Задержка распространения
Задержка распространения — это мера времени, необходимого для распространения блока от производителя к валидатору и одноранговой сети.
В настоящее время размер блока Avail составляет 2 МБ. В рамках текущего 20-секундного ограничения по времени блока такой размер блока может быть распространен. Большие размеры блоков усложняют распространение.
Например, если мы увеличим Avail до поддержки блока размером 128 МБ, вычисления могут масштабироваться (около 7 секунд). Однако узким местом становится время, необходимое для отправки и загрузки этих блоков в сети.
Отправка блока размером 128 МБ по одноранговой сети за 5 секунд может быть пределом того, что достижимо в настоящее время.
Ограничение в 128 МБ не имеет ничего общего с доступностью данных или нашим сценарием обязательств, а скорее связано с ограничениями пропускной способности связи.
Эта необходимость учитывать задержку распространения дает нам текущее теоретическое ограничение размера блока Avail.
3. Проверка блоков
После распространения участвующие валидаторы не просто доверяют блокам, предоставленным им инициатором блока — им необходимо убедиться, что созданный блок действительно содержит данные, заявленные производителем.
Между этими тремя шагами существует определенное напряжение. Мы можем сделать всех валидаторов мощными машинами и плотно связанными отличной сетью в одном дата-центре – это сократит время производства и валидации, а также позволит нам распространять гораздо больше данных. Однако, поскольку мы также хотим иметь децентрализованную, разнообразную сеть с различными типами участников, это не идеальный подход.
Вместо этого увеличение пропускной способности будет достигнуто за счет понимания шагов, необходимых для добавления блоков в цепочку Avail, и того, какие шаги можно оптимизировать.
! [Масштабируемость DA: текущее состояние Avail] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
В настоящее время валидаторы, использующие Avail, берут весь блок и копируют все обязательства, сгенерированные инициатором для проверки блока. Это означает, что производители блоков и все валидаторы должны выполнить каждый из шагов, описанных в таблице выше.
В одном блокчейне каждый валидатор по умолчанию реконструирует весь блок. Однако в такой цепочке, как Avail, где транзакции не выполняются, такое перестроение не требуется. Таким образом, один из способов оптимизации Avail заключается в том, чтобы позволить валидаторам достигать своих собственных гарантий доступности данных с помощью выборки, а не путем реконструкции блоков. Это менее ресурсоемко для валидаторов, чем требование повторить все обязательства. Подробнее об этом в следующей статье.
Как работает выборка доступности исследовательских данных?
В Avail легкие клиенты используют три основных инструмента для подтверждения доступности данных: выборки, обязательства и доказательства.
Используя эти инструменты, облегченный клиент выполняет три шага.
Только с помощью этого легкие клиенты могут подтвердить доступность всех данных в блоке без необходимости скачивать большую часть содержимого блока. Другие шаги, предпринимаемые легкими клиентами, также вносят свой вклад в безопасность Avail, но не перечислены здесь. Например, легкие клиенты могут обмениваться образцами и доказательствами, которые они загружают, с другими легкими клиентами, если им это необходимо. Но это процедура для легких клиентов для подтверждения доступности данных!
Во второй части этой серии статей мы рассмотрим способы увеличения пропускной способности Avail в краткосрочной перспективе. Мы объясним, почему мы считаем, что Avail может удовлетворить потребности любой сети в наступающем году, и как мы можем улучшить сеть, чтобы справиться с проблемами предстоящих лет.