О минимизации доверия и горизонтальном масштабировании

Ethereum - это всемирный компьютер без разрешений, обладающий(возможно) самой высокой степенью экономической безопасности на момент написания статьи, выступающий в качестве расчетной книги для огромного количества активов, приложений и услуг. У Ethereum есть свои ограничения - пространство блоков является дефицитным и дорогим ресурсом на первом уровне Ethereum (L1). Масштабирование второго уровня (L2) рассматривалось как решение этой проблемы, и в последние годы на рынок вышло множество проектов, в основном в форме ролл-апов. Однако роллапы в строгом смысле этого слова (подразумевается, что данные роллапов находятся на Ethereum L1) не позволяют Ethereum масштабироваться бесконечно, обеспечивая лишь до нескольких тысяч транзакций в секунду.

Trust-minimized - (особенность) системы L2 является trust-minimized, если она функционирует, не требуя доверия со стороны базовой системы L1.

Горизонтальное масштабирование - система является горизонтально масштабируемой, если экземпляры могут быть добавлены без возникновения глобальных узких мест.

В этой статье мы утверждаем, что системы с минимальным уровнем доверия и горизонтально масштабируемые системы являются наиболее перспективным способом масштабирования приложений блокчейн, однако в настоящее время они недостаточно изучены. Мы приводим аргументы, исследуя три вопроса:

1. Почему приложения должны быть минимизированы с точки зрения доверия?
2. Зачем создавать горизонтально масштабируемые системы?
3. Как добиться максимального снижения уровня доверия и горизонтальной масштабируемости?

(Отказ от ответственности: хотя в этой статье мы сосредоточимся на Ethereum как на базовом L1, большая часть того, что мы здесь обсуждаем, применима к децентрализованным уровням расчетов помимо Ethereum).

Почему приложения должны быть минимизированы с точки зрения доверия?

Приложения могут быть подключены к Ethereum доверенным образом - они могут писать в блокчейн Ethereum и читать из него, но при этом операторам доверяется правильное выполнение бизнес-логики. Централизованные биржи, такие как Binance и Coinbase, являются отличными примерами доверенных приложений. Подключение к Ethereum означает, что приложения могут подключиться к глобальной расчетной сети с разнообразным набором активов.

Доверие к сервисам вне цепочки связано со значительными рисками. Крах крупных бирж и сервисов в 2022 году, таких как FTX и Celsius, является отличным поучительным примером того, что происходит, когда доверенные сервисы ведут себя неправильно и не справляются со своей работой.

С другой стороны, приложения с минимальным уровнем доверия могут записывать в Ethereum и считывать из него информацию с высокой степенью достоверности. Примерами могут служить приложения для смарт-контрактов, такие как Uniswap, роллапы, такие как Arbitrum или zkSync, и сопроцессоры, такие как Lagrange и Axiom. В целом, доверие снижается по мере того, как приложения становятся защищенными сетью Ethereum, поскольку все больше функциональных возможностей (см. ниже) передается на L1. В результате, финансовые услуги с минимальным уровнем доверия могут предлагаться без рисков контрагента или хранителя.

Есть три ключевых свойства, которыми могут обладать приложения и сервисы, которые можно передать на аутсорсинг L1:

1. Оперативность (и упорядочивание): транзакции, поданные пользователем, должны быть включены (выполнены и урегулированы) своевременно.
2. Валидность: транзакции обрабатываются в соответствии с установленными правилами.
3. Доступность данных (и состояния): исторические данные, а также текущее состояние приложения становятся доступными для пользователя.

Для каждого из вышеперечисленных свойств мы можем подумать о том, какое предположение о доверии требуется; в частности, обеспечивает ли Eth L1 это свойство или требуется внешнее доверие. В таблице ниже приведена классификация для различных архитектурных парадигм.

Зачем создавать горизонтально масштабируемые системы?

Горизонтальное масштабирование относится к масштабированию путем добавления независимых или параллельных экземпляров системы, например. применение или сворачивание. Для этого не требуется наличие глобального узкого места. Горизонтальное масштабирование обеспечивает и облегчает экспоненциальный рост.

Вертикальное масштабирование - это масштабирование за счет увеличения пропускной способности монолитной системы, такой как Eth L1 или уровень доступности данных. Когда горизонтальное масштабирование сталкивается с узкими местами на таком общем ресурсе, часто требуется вертикальное масштабирование.

Утверждение 1: (Транзакционные данные) рулонные системы не могут горизонтально масштабироваться, потому что они могут быть ограничены доступностью данных (DA). Вертикальное масштабирование DA-решений требует компромиссов в отношении децентрализации.

Доступность данных (DA) остается узким местом для сворачивания. В настоящее время максимальный размер каждого блока L1 составляет ~1 МБ (85 КБ/с). С EIP-4844 будет доступно еще ~2 МБ (171 КБ/с) (в долгосрочной перспективе). Благодаря данкшардингу Eth L1 может в конечном итоге поддерживать пропускную способность DA до 1,3 МБ/с. Eth L1 DA - это общий ресурс, за который конкурируют многие приложения & сервисы. Поэтому, хотя использование L1 для DA обеспечивает наилучшую безопасность, оно ограничивает потенциальную масштабируемость таких систем. Системы, использующие L1 для DA, (как правило) не смогут горизонтально масштабироваться и будут иметь экономию от масштаба. Альтернативные уровни DA, такие как Celestia или EigenDA, также имеют ограничения по пропускной способности (хотя и большие - 6,67 МБ/с и 15 МБ/с, соответственно). Но это происходит за счет переноса предположения о доверии с Ethereum на другую (часто менее децентрализованную) сеть, что ставит под угрозу (экономическую) безопасность.

Утверждение 2: Единственный способ горизонтального масштабирования сервисов с минимизацией доверия - это получение (близких к нулю) предельных данных L1 на транзакцию. Два известных подхода - это сворачивание по состоянию (SDR) и валидиум.

Роллапы с разницей состояний (SDR) - это роллапы, которые публикуют разницу состояний в агрегированной партии транзакций в Ethereum L1. Для EVM, по мере увеличения количества транзакций, количество данных, размещаемых на L1, уменьшается до постоянной величины, которая намного меньше, чем при сворачивании данных транзакций.

Например, во время стресс-теста с большим количеством надписей в системе zkSync наблюдалось снижение количества калькированных данных на транзакцию до 10 байт на транзакцию. В отличие от этого, в таких системах с транзакционными данными, как Arbitrum, Optimism и Polygon zkEVM, на одну транзакцию обычно приходится около 100 байт при нормальном трафике.

Валидиум - это система, которая размещает в Ethereum доказательства достоверности переходов состояний, не связывая их с данными транзакций или состоянием. Валидиумы обладают высокой горизонтальной масштабируемостью даже в условиях низкого трафика. Это особенно актуально, поскольку расчеты по разным валидам могут быть агрегированы.

Помимо горизонтальной масштабируемости, валидиум может также обеспечивать приватность на цепи (от публичных наблюдателей). Валидиум с частным DA имеет централизованную и закрытую доступность данных и состояния, что означает, что пользователи должны аутентифицироваться перед доступом к данным и что оператор может обеспечить хорошие меры конфиденциальности. Это обеспечивает уровень пользовательского опыта, схожий с традиционными веб- или финансовыми услугами - действия пользователя скрыты от посторонних глаз, но есть доверенный хранитель пользовательских данных, в данном случае - оператор validium.

Как насчет централизованных и децентрализованных секвенсоров? Чтобы системы были горизонтально масштабируемыми, очень важно создавать независимые секвенсоры, как централизованные, так и децентрализованные. Примечательно, что хотя системы, использующие общие секвенсоры, обладают атомарной <a href="https://hackmd.io/@EspressoSystems/SharedSequencing"> композитностью, они не могут горизонтально масштабироваться, поскольку секвенсор может стать узким местом по мере добавления новых систем.

А как насчет совместимости? Горизонтально масштабируемые системы могут взаимодействовать без дополнительного доверия, если все они производят расчеты на одном и том же уровне L1, поскольку сообщения могут передаваться от одной системы к другой через общий уровень расчетов. Существует компромисс между стоимостью работы и задержкой передачи сообщений (который потенциально может быть решен на уровне приложений).

Минимизация доверия для горизонтально масштабируемых систем

Можем ли мы еще больше минимизировать требования к доверию для обеспечения оперативности, упорядоченности и доступности данных в горизонтально масштабируемых системах?

Примечательно, что ценой горизонтальной масштабируемости мы знаем, как спасти недоверчивую оперативность и доступность данных. Например, транзакции L2 могут быть инициированы с L1 для гарантированного включения. Volition может предложить пользователям опциональную доступность состояния L1.

Другое решение - просто децентрализовать (но не полагаться на L1). Вместо одного секвенсора системы могут стать более децентрализованными за счет использования децентрализованных секвенсоров (таких как Espresso Systems или Astria), что позволит свести к минимуму доверие, необходимое для обеспечения оперативности, упорядочивания и доступности данных. Это накладывает ограничения по сравнению с однооператорными решениями: (1) производительность может быть ограничена производительностью распределенной системы, и (2) для валидиумов с приватным DA гарантия приватности по умолчанию теряется, если децентрализованная сеть секвенсоров не имеет разрешения.

Насколько мы можем дополнительно минимизировать доверие к валидаторам с одним оператором или SDR? Здесь есть несколько открытых направлений.

Открытое направление 1: Доступность данных в валидиумах с минимальным уровнем доверия. Plasma решает проблему доступности состояния в определенной степени - она решает проблему либо для снятия средств только для определенных моделей состояния (к которым относится модель состояния UTXO), либо требует, чтобы пользователи периодически были онлайн(Plasma Free).

Открытое направление 2: Ответственные предварительные подтверждения в SDR и валидиумах. Цель состоит в том, чтобы предоставить пользователям быстрое предварительное подтверждение включения транзакции от секвенсора, и это подтверждение должно позволить пользователю оспорить и сократить экономическую долю секвенсора, если обещание о включении не будет выполнено. Проблема здесь заключается в том, что доказательство невключения (необходимое для слэшинга), скорее всего, потребует от пользователя дополнительных данных, которые секвенсор может просто не предоставить. Поэтому разумно предположить, что мы, по крайней мере, требуем, чтобы SDR или validium использовали (потенциально разрешенный) комитет по доступности данных для своих полных данных о звонках или истории транзакций, что позволит тому же комитету предоставить доказательства невключения (предварительно подтвержденных транзакций) по запросу пользователя.

Открытое направление 3: Быстрое восстановление после сбоев в работе. Системы с одним оператором могут страдать от сбоев в работе (например. Arbitrum был отключен во время события надписи). Можем ли мы разработать системы, обеспечивающие минимальные перебои в обслуживании при таком сценарии? В некотором смысле L2, допускающие самопоследовательность и предложения состояний, действительно обеспечивают гарантии от длительных сбоев в режиме liveness. Разработка однооператорных систем, более устойчивых к кратковременным сбоям, в настоящее время недостаточно изучена. Одно из потенциальных решений здесь - сделать неудачи с промедлением ответственными, обеспечив слэш-тестирование против неудач с промедлением. Другое возможное решение - просто сократить период задержки (который в настоящее время составляет около недели), прежде чем произойдет поглощение.

Заключение

Масштабирование глобальной расчетной книги при сохранении минимизации доверия - сложная проблема. В современном мире сворачивания и доступности данных не было четкого разграничения между вертикальным и горизонтальным масштабированием. Чтобы действительно масштабировать системы с минимальным уровнем доверия для всех жителей Земли, нам нужно построить системы с минимальным уровнем доверия и горизонтально масштабируемые системы.

Благодарности

Большое спасибо Виталику Бутерину и Терри Чангу за отзывы и обсуждения, а также Диане Биггс за редакторские комментарии.

声明：

Отказ от ответственности：

1. Эта статья перепечатана из[Mirror]. Все авторские права принадлежат оригинальному автору[1kx]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Предупреждение об ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.