Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола будут увеличиваться с течением времени. Это происходит в двух местах:
Исторические данные: все транзакции, проведенные в любой момент времени в прошлом, и любые созданные аккаунты должны быть постоянно хранимы всеми клиентами и загружены любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к постоянному увеличению нагрузки на клиента и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функция протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долго существовать, нам нужно оказать сильное противодействие этим двум тенденциям, со временем снижая сложность и расширение. Но при этом нам нужно сохранить одну из ключевых характеристик, которая делает блокчейн великим: долговечность. Вы можете разместить NFT, любовное письмо в данных транзакции или смарт-контракт на 1 миллион долларов в сети, зайти в пещеру на десять лет, а когда выйдете, обнаружите, что он все еще там, ожидая вашего чтения и взаимодействия. Чтобы DApp могли спокойно полностью децентрализоваться и удалить ключи для обновления, им нужно быть уверенными, что их зависимости не обновятся разрушительным для них образом - особенно сам L1.
Если мы решим сбалансировать эти две потребности и при этом минимизировать или обратить вспять избыточность, сложность и упадок, сохраняя непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют со временем, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы цепи сигналов хранили максимум шесть месяцев старых данных. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату — это конечная задача долгосрочной масштабируемости Ethereum, технологической устойчивости и даже безопасности.
Снизить требования к хранилищу клиента, уменьшая или устраняя необходимость для каждого узла постоянно хранить всю историю и даже конечное состояние.
Снижение сложности протокола за счет устранения ненужных функций.
Содержание статьи:
Историческая запись истекла(
Состояние истечения)статус истечения(
Feature cleanup)Очистка функций(
) История истечения
Какую проблему это решает?
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для выполнения клиента, а также несколько сотен ГБ дискового пространства для клиента консенсуса. Большая часть этого пространства связана с историей: данными о исторических блоках, транзакциях и квитанциях, большинство из которых имеют многолетнюю историю. Это означает, что даже если ограничение Gas вовсе не увеличивается, размер узла будет продолжать увеличиваться на несколько сотен ГБ каждый год.
Ключевым упрощенным признаком проблемы хранения истории является то, что каждый блок связан с предыдущим блоком через хэш ### и другие структуры (, поэтому достаточно согласовать текущее состояние, чтобы согласовать историю. Если сеть согласна с последним блоком, любой исторический блок, транзакция или состояние ), такие как баланс счета, случайное число, код, хранилище (, могут быть предоставлены любым отдельным участником и подтверждены с помощью доказательства Меркла, которое позволяет любому другому участнику проверить его правильность. Консенсус – это модель доверия N/2 из N, а история – это модель доверия N из N.
Это дает нам много вариантов того, как хранить исторические записи. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных. Так работает сеть семян на протяжении десятилетий: хотя сеть в общей сложности хранит и распределяет миллионы файлов, каждый участник хранит и распределяет лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает устойчивость данных. Если, сделав работу узлов более экономичной, мы сможем создать сеть из 100 000 узлов, где каждый узел хранит случайные 10% исторических записей, то каждая запись будет копироваться 10 000 раз - что абсолютно эквивалентно сети из 10 000 узлов с коэффициентом копирования, где каждый узел хранит все содержимое.
Теперь Ethereum начал избавляться от модели, в которой все узлы хранят всю историю навсегда. Консенсусный блок ) связан с частью консенсуса на основе доказательства доли (, которая хранится только около 6 месяцев. Blob хранится только около 18 дней. EIP-4444 предназначен для введения однолетнего срока хранения для исторических блоков и записей. Долгосрочная цель - создать унифицированный период, возможно, около 18 дней ), в течение которого каждый узел отвечает за хранение всего, а затем создать пиринговую сеть, состоящую из узлов Ethereum, которая будет хранить старые данные распределенным образом.
Коды стирания могут быть использованы для повышения надежности, при этом сохраняя одинаковый коэффициент репликации. На самом деле, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и размещение данных выполнения и согласования блока также в blob.
(# Какие связи существуют с существующими исследованиями?
ЭИП-4444;
Торренты и EIP-4444;
Портал сети;
Портал сети и EIP-4444;
Распределенное хранение и извлечение объектов SSZ в Portal;
Как повысить лимит газа ) Paradigm ###.
(# Что еще нужно сделать, что нужно взвесить?
Остальная основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включает консенсус и blob. Самое простое решение - это )i### простое внедрение существующей библиотеки torrent, а также (ii) называемого Portal сети нативного решения Ethereum. Как только мы внедрим одно из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл одновременно включить его для всех клиентов, иначе существует риск сбоя клиентского программного обеспечения из-за ожидания загрузки полной истории при подключении к другим узлам, но фактически не получая ее.
Основные компромиссы связаны с тем, как мы стараемся предоставить "древние" исторические данные. Самое простое решение заключается в том, чтобы завтра прекратить хранение древней истории и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет положение Эфира как места для постоянной записи. Более сложный, но более безопасный путь — это сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубоко мы интегрируем историческое хранилище в протокол?
Крайне параноидальный подход к ( будет включать в себя доказательство хранения: фактически требует от каждого валидатора на основе доли хранить определенный процент истории и регулярно проверять, делают ли они это в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процентного соотношения истории, хранящейся каждым клиентом.
Что касается ), базовая реализация включает только ту работу, которая уже выполнена сегодня: Портал уже сохранил файл ERA, содержащий всю историю Ethereum. Более полная реализация будет включать фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не доступны онлайн, они смогут сделать это напрямую через синхронизацию с сетью портала.
(# Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов была предельно простой, то сокращение требований к историческому хранилищу можно считать более важным, чем безсостояние: из 1,1 ТБ, необходимых узлу, около 300 ГБ являются состоянием, а оставшиеся примерно 800 ГБ стали историей. Только реализовав безсостояние и EIP-4444, можно осуществить видение о запуске узла Ethereum на смарт-часах, которое можно настроить всего за несколько минут.
Ограничение исторического хранения также делает более новыми узлы Ethereum более жизнеспособными, поддерживающими только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, так как все пустые слоты хранения, созданные во время атаки DoS в 2016 году, были удалены. Теперь, когда переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством выполнения работы.
) Состояние истечения срока
(# Какую проблему решить?
Даже если мы устраним необходимость в хранении истории на клиенте, потребность в хранении клиента продолжит расти, примерно на 50 ГБ в год, так как состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут оплатить единовременную плату, тем самым навсегда возложив бремя на текущие и будущие клиенты Ethereum.
Состояние сложнее "исторического" "истечение срока", потому что EVM в корне был спроектирован на основе предположения: как только объект состояния создан, он всегда будет существовать и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не так уж плоха: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все остальные узлы ) даже включая генерацию списков! ### могут работать без состояния. Однако есть точка зрения, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим, чтобы сохранить децентрализованность Ethereum.
Сегодня, когда вы создаете новый объект состояния, ) может произойти одним из следующих трех способов: (i ) отправить ETH на новую учетную запись, ###ii ( создать новую учетную запись с помощью кода, (iii ) установить ранее не затрагиваемый слот хранения (, этот объект состояния навсегда остается в этом состоянии. Напротив, мы хотим, чтобы объект автоматически устаревал со временем. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большое количество дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователей: если кто-то зайдет в пещеру на пять лет и вернется, они не должны потерять доступ к позициям ETH, ERC20, NFT, CDP...
Дружественность к разработчикам: разработчики не обязаны переключаться на совершенно незнакомую модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально функционировать.
Неудовлетворение этих целей легко решает проблему. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения ), который можно продлить за счет сжигания ETH, что может происходить автоматически при чтении или записи в любое время (, и есть процесс, который проходит по состояниям для удаления объектов состояния с истекшими сроками. Однако это вводит дополнительные вычислительные ) и даже требования к хранению ), и это определенно не может удовлетворить требования к удобству для пользователя. Разработчикам также трудно рассуждать о крайних случаях, когда хранимые значения иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения в пределах контракта, это технически упрощает жизнь разработчикам, но делает экономику более сложной: разработчикам необходимо учитывать, как "перенести" постоянные расходы на хранение на пользователей.
Эти вопросы являются предметом многолетних усилий ядра разработчиков Ethereum, включая такие предложения, как "блокчейн-аренда" и "возрождение". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих известных решений":
Решение для устаревших статусов
Рекомендации по истечению состояния на основе адресного цикла.
Некоторые предложения по истечению срока действия состояния следуют одинаковым принципам. Мы делим состояние на блоки. Каждый навсегда хранит "верхнюю карту", где блок пустой или непустой. Только когда наибольший
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
24 Лайков
Награда
24
5
Поделиться
комментарий
0/400
0xSherlock
· 07-28 16:14
Слишком сложно, кто может понять, поднимите руку.
Посмотреть ОригиналОтветить0
WalletDetective
· 07-25 22:52
Это тоже большая проблема, хе-хе~
Посмотреть ОригиналОтветить0
DeFiGrayling
· 07-25 22:51
Блокчейн胀的比токен价还快
Посмотреть ОригиналОтветить0
0xLuckbox
· 07-25 22:51
Компромисс проще, чем инновации.
Посмотреть ОригиналОтветить0
CryptoFortuneTeller
· 07-25 22:50
ДиДи, первый раз синхронизация действительно похожа на беговую дорожку, никогда не заканчивается.
Будущее Ethereum: Как The Purge изменит экосистему Блокчейн
Возможное будущее Ethereum: чистка
Одной из проблем, с которыми сталкивается Ethereum, является то, что по умолчанию расширение и сложность любого блокчейн-протокола будут увеличиваться с течением времени. Это происходит в двух местах:
Исторические данные: все транзакции, проведенные в любой момент времени в прошлом, и любые созданные аккаунты должны быть постоянно хранимы всеми клиентами и загружены любым новым клиентом, чтобы полностью синхронизироваться с сетью. Это приведет к постоянному увеличению нагрузки на клиента и времени синхронизации с течением времени, даже если емкость цепочки остается неизменной.
Функция протокола: добавление новых функций гораздо проще, чем удаление старых, что приводит к увеличению сложности кода с течением времени.
Чтобы Ethereum мог долго существовать, нам нужно оказать сильное противодействие этим двум тенденциям, со временем снижая сложность и расширение. Но при этом нам нужно сохранить одну из ключевых характеристик, которая делает блокчейн великим: долговечность. Вы можете разместить NFT, любовное письмо в данных транзакции или смарт-контракт на 1 миллион долларов в сети, зайти в пещеру на десять лет, а когда выйдете, обнаружите, что он все еще там, ожидая вашего чтения и взаимодействия. Чтобы DApp могли спокойно полностью децентрализоваться и удалить ключи для обновления, им нужно быть уверенными, что их зависимости не обновятся разрушительным для них образом - особенно сам L1.
Если мы решим сбалансировать эти две потребности и при этом минимизировать или обратить вспять избыточность, сложность и упадок, сохраняя непрерывность, это абсолютно возможно. Организмы могут это сделать: хотя большинство организмов стареют со временем, немногие счастливчики этого не делают. Даже социальные системы могут иметь очень долгий срок службы. В некоторых случаях Ethereum уже добился успеха: доказательство работы исчезло, операция SELFDESTRUCT в основном исчезла, узлы цепи сигналов хранили максимум шесть месяцев старых данных. Найти этот путь для Ethereum более универсальным образом и двигаться к долгосрочному стабильному конечному результату — это конечная задача долгосрочной масштабируемости Ethereum, технологической устойчивости и даже безопасности.
! Виталик: возможное будущее для Ethereum, чистка
The Purge:Основная цель.
Снизить требования к хранилищу клиента, уменьшая или устраняя необходимость для каждого узла постоянно хранить всю историю и даже конечное состояние.
Снижение сложности протокола за счет устранения ненужных функций.
Содержание статьи:
Историческая запись истекла(
Состояние истечения)статус истечения(
Feature cleanup)Очистка функций(
) История истечения
Какую проблему это решает?
На момент написания этой статьи полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для выполнения клиента, а также несколько сотен ГБ дискового пространства для клиента консенсуса. Большая часть этого пространства связана с историей: данными о исторических блоках, транзакциях и квитанциях, большинство из которых имеют многолетнюю историю. Это означает, что даже если ограничение Gas вовсе не увеличивается, размер узла будет продолжать увеличиваться на несколько сотен ГБ каждый год.
! [Виталик: Возможное будущее Ethereum, Чистка]###https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(
)# Что это такое и как это работает?
Ключевым упрощенным признаком проблемы хранения истории является то, что каждый блок связан с предыдущим блоком через хэш ### и другие структуры (, поэтому достаточно согласовать текущее состояние, чтобы согласовать историю. Если сеть согласна с последним блоком, любой исторический блок, транзакция или состояние ), такие как баланс счета, случайное число, код, хранилище (, могут быть предоставлены любым отдельным участником и подтверждены с помощью доказательства Меркла, которое позволяет любому другому участнику проверить его правильность. Консенсус – это модель доверия N/2 из N, а история – это модель доверия N из N.
Это дает нам много вариантов того, как хранить исторические записи. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных. Так работает сеть семян на протяжении десятилетий: хотя сеть в общей сложности хранит и распределяет миллионы файлов, каждый участник хранит и распределяет лишь несколько из них. Возможно, вопреки интуиции, этот подход даже не обязательно снижает устойчивость данных. Если, сделав работу узлов более экономичной, мы сможем создать сеть из 100 000 узлов, где каждый узел хранит случайные 10% исторических записей, то каждая запись будет копироваться 10 000 раз - что абсолютно эквивалентно сети из 10 000 узлов с коэффициентом копирования, где каждый узел хранит все содержимое.
Теперь Ethereum начал избавляться от модели, в которой все узлы хранят всю историю навсегда. Консенсусный блок ) связан с частью консенсуса на основе доказательства доли (, которая хранится только около 6 месяцев. Blob хранится только около 18 дней. EIP-4444 предназначен для введения однолетнего срока хранения для исторических блоков и записей. Долгосрочная цель - создать унифицированный период, возможно, около 18 дней ), в течение которого каждый узел отвечает за хранение всего, а затем создать пиринговую сеть, состоящую из узлов Ethereum, которая будет хранить старые данные распределенным образом.
Коды стирания могут быть использованы для повышения надежности, при этом сохраняя одинаковый коэффициент репликации. На самом деле, Blob уже использует коды стирания для поддержки выборки доступности данных. Самым простым решением, вероятно, будет повторное использование этих кодов стирания и размещение данных выполнения и согласования блока также в blob.
(# Какие связи существуют с существующими исследованиями?
ЭИП-4444;
Торренты и EIP-4444;
Портал сети;
Портал сети и EIP-4444;
Распределенное хранение и извлечение объектов SSZ в Portal;
Как повысить лимит газа ) Paradigm ###.
(# Что еще нужно сделать, что нужно взвесить?
Остальная основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения истории ------ по крайней мере, истории выполнения, но в конечном итоге также включает консенсус и blob. Самое простое решение - это )i### простое внедрение существующей библиотеки torrent, а также (ii) называемого Portal сети нативного решения Ethereum. Как только мы внедрим одно из них, мы сможем открыть EIP-4444. Сам EIP-4444 не требует жесткого форка, но действительно требует новой версии сетевого протокола. Поэтому имеет смысл одновременно включить его для всех клиентов, иначе существует риск сбоя клиентского программного обеспечения из-за ожидания загрузки полной истории при подключении к другим узлам, но фактически не получая ее.
Основные компромиссы связаны с тем, как мы стараемся предоставить "древние" исторические данные. Самое простое решение заключается в том, чтобы завтра прекратить хранение древней истории и полагаться на существующие архивные узлы и различные централизованные провайдеры для копирования. Это легко, но это ослабляет положение Эфира как места для постоянной записи. Более сложный, но более безопасный путь — это сначала построить и интегрировать торрент-сеть для распределенного хранения исторических данных. Здесь "насколько мы стараемся" имеет два измерения:
Как мы можем гарантировать, что максимальный набор узлов действительно хранит все данные?
Насколько глубоко мы интегрируем историческое хранилище в протокол?
Крайне параноидальный подход к ( будет включать в себя доказательство хранения: фактически требует от каждого валидатора на основе доли хранить определенный процент истории и регулярно проверять, делают ли они это в зашифрованном виде. Более мягкий подход заключается в установлении добровольного стандарта для процентного соотношения истории, хранящейся каждым клиентом.
Что касается ), базовая реализация включает только ту работу, которая уже выполнена сегодня: Портал уже сохранил файл ERA, содержащий всю историю Ethereum. Более полная реализация будет включать фактическое подключение к процессу синхронизации, так что, если кто-то захочет синхронизировать полный исторический узел хранения или архивный узел, даже если другие архивные узлы не доступны онлайн, они смогут сделать это напрямую через синхронизацию с сетью портала.
(# Как это взаимодействует с другими частями дорожной карты?
Если мы хотим, чтобы запуск или работа узлов была предельно простой, то сокращение требований к историческому хранилищу можно считать более важным, чем безсостояние: из 1,1 ТБ, необходимых узлу, около 300 ГБ являются состоянием, а оставшиеся примерно 800 ГБ стали историей. Только реализовав безсостояние и EIP-4444, можно осуществить видение о запуске узла Ethereum на смарт-часах, которое можно настроить всего за несколько минут.
Ограничение исторического хранения также делает более новыми узлы Ethereum более жизнеспособными, поддерживающими только последние версии протокола, что упрощает их. Например, теперь можно безопасно удалить множество строк кода, так как все пустые слоты хранения, созданные во время атаки DoS в 2016 году, были удалены. Теперь, когда переход на доказательство доли стал историей, клиенты могут безопасно удалить весь код, связанный с доказательством выполнения работы.
) Состояние истечения срока
(# Какую проблему решить?
Даже если мы устраним необходимость в хранении истории на клиенте, потребность в хранении клиента продолжит расти, примерно на 50 ГБ в год, так как состояние продолжает расти: балансы счетов и случайные числа, код контрактов и хранилище контрактов. Пользователи могут оплатить единовременную плату, тем самым навсегда возложив бремя на текущие и будущие клиенты Ethereum.
Состояние сложнее "исторического" "истечение срока", потому что EVM в корне был спроектирован на основе предположения: как только объект состояния создан, он всегда будет существовать и может быть прочитан в любое время любой транзакцией. Если мы введем безсостояние, некоторые считают, что эта проблема может быть не так уж плоха: только специализированные классы строителей блоков должны фактически хранить состояние, в то время как все остальные узлы ) даже включая генерацию списков! ### могут работать без состояния. Однако есть точка зрения, что мы не хотим слишком полагаться на безсостояние, и в конечном итоге мы можем захотеть сделать состояние устаревшим, чтобы сохранить децентрализованность Ethereum.
![Виталик: возможное будущее Эфира, Очищение]###https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp###
(# Что это такое, как это работает
Сегодня, когда вы создаете новый объект состояния, ) может произойти одним из следующих трех способов: (i ) отправить ETH на новую учетную запись, ###ii ( создать новую учетную запись с помощью кода, (iii ) установить ранее не затрагиваемый слот хранения (, этот объект состояния навсегда остается в этом состоянии. Напротив, мы хотим, чтобы объект автоматически устаревал со временем. Ключевая задача заключается в том, чтобы сделать это таким образом, чтобы достичь трех целей:
Эффективность: не требуется большое количество дополнительных вычислений для выполнения процесса истечения.
Удобство для пользователей: если кто-то зайдет в пещеру на пять лет и вернется, они не должны потерять доступ к позициям ETH, ERC20, NFT, CDP...
Дружественность к разработчикам: разработчики не обязаны переключаться на совершенно незнакомую модель мышления. Кроме того, устаревшие и не обновляемые приложения должны продолжать нормально функционировать.
Неудовлетворение этих целей легко решает проблему. Например, вы можете заставить каждый объект состояния также хранить счетчик даты истечения ), который можно продлить за счет сжигания ETH, что может происходить автоматически при чтении или записи в любое время (, и есть процесс, который проходит по состояниям для удаления объектов состояния с истекшими сроками. Однако это вводит дополнительные вычислительные ) и даже требования к хранению ), и это определенно не может удовлетворить требования к удобству для пользователя. Разработчикам также трудно рассуждать о крайних случаях, когда хранимые значения иногда сбрасываются на ноль. Если вы устанавливаете таймер истечения в пределах контракта, это технически упрощает жизнь разработчикам, но делает экономику более сложной: разработчикам необходимо учитывать, как "перенести" постоянные расходы на хранение на пользователей.
Эти вопросы являются предметом многолетних усилий ядра разработчиков Ethereum, включая такие предложения, как "блокчейн-аренда" и "возрождение". В конечном итоге мы объединили лучшие части предложений и сосредоточились на двух категориях "наименее плохих известных решений":
! [Виталик: возможное будущее Ethereum, чистка] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
(# Частичное истечение состояния
Некоторые предложения по истечению срока действия состояния следуют одинаковым принципам. Мы делим состояние на блоки. Каждый навсегда хранит "верхнюю карту", где блок пустой или непустой. Только когда наибольший