AO можно понимать как сеть с бесконечным шардингом, бесконечным масштабированием. Каждый процесс является шардингом.
Автор: 0xmiddle
Рецензия: Сэнди
Источник: Совет по контенту - Исследование инвестиций
!
AO - это не традиционная блокчейн-система. Его необычный и нетрадиционный дизайн может сбить с толку исследователей, только что познакомившихся с AO, особенно тех, кто пытается описать AO в терминах традиционной блокчейн-архитектуры:
-
Не PoS, не PoW, в чем же суть механизма консенсуса, о котором говорит AO, называемого “голографическим консенсусом”?
-
Без хэш-цепи, даже без блоков, как AO обеспечивает неизменность данных?
-
Без центрального координационного центра, как AO гарантирует согласованность глобального состояния?
-
Нет механизма избыточных вычислений, кто гарантирует надежность вычислений? Что делать в случае ошибки вычислений?
-
Нет общей безопасности, как обеспечить взаимодействие между процессами?
Я буду использовать 3 точки зрения, чтобы помочь вам перейти от известного к неизвестному, сделать неизвестное известным на чувственном уровне, используя уже знакомые концепции в блокчейне.
Видение шардинга
После обучения на платформах Ethereum 2.0, Polkadot, Near и других публичных блокчейнах, вы, наверное, уже знакомы с термином «Шардинг».
Концепция шардинга: В блокчейне шардинг является решением для повышения масштабируемости сети. Он разбивает сеть на несколько шардингов, каждый из которых независимо проверяет и обрабатывает транзакции, а также генерирует собственные блоки, что повышает эффективность всей сети. Внутри каждого шардинга может быть реализовано синхронное взаимодействие, а между шардингами - асинхронное взаимодействие с помощью определенного протокола связи.
Polkadot - это самая типичная архитектура Шардинга. В Polkadot каждая параллельная цепь является Шардингом, параллельные цепи независимо собирают и упаковывают свои собственные блокчейны, и ими управляет цепь-посредник, случайным образом назначающая группу проверяющих. Между параллельными цепями используется единый формат сообщения XCM для общения и обеспечения взаимодействия.
Экстремальный шардинг АО
С точки зрения Шардинга, AO можно рассматривать как идеальный Шардинг: каждый процесс является Шардингом. Представьте себе, что про каждый смарт-контракт Ethereum запущен отдельный Шардинг - каково это будет? Верно, это и есть AO. Каждый процесс является независимым, вызовы между процессами осуществляются с помощью сообщений, полностью асинхронно.
Модулярная перспектива
Но мы обнаружили ключевой момент в дизайне Polkadot: существует «релейная цепь», а в ETH2.0 также есть «якорная цепь», которые служат единой слоем консенсуса, обеспечивая общую безопасность. Единый слой консенсуса должен быть ответственным за предоставление прямых или косвенных проверочных услуг для всех Шардингов и передачи сообщений между ними. Но похоже, что в AO нет такого компонента, так как организован слой консенсуса AO?
Консенсусный уровень AO фактически является Arweave. С точки зрения модульности, AO можно рассматривать как L2 Arweave, Rollup с Arweave в качестве L1. Все журналы сообщений, создаваемые в процессе работы сети AO, загружаются в постоянное хранилище Arweave, то есть на Arweave есть неизменная запись работы сети AO. Тогда вы можете спросить, Arweave - это децентрализованная платформа хранения данных, которая не обладает большой вычислительной мощностью. Как Arweave проверяет данные, загруженные в сеть AO?
Ответ: Arweave не проводит проверку, а сама сеть AO имеет оптимистичный арбитражный механизм. Arweave принимает все входящие сообщения от сети AO, каждое сообщение содержит идентификатор процесса отправителя и подпись CU (вычислительного блока), который его запустил, а также подпись SU (сортировочного блока), который упорядочивает его. В случае споров можно полагаться на неизменную запись сообщений в Arweave, введя больше узлов для повторного вычисления и создания правильной ветки, отвергая неправильные ветки и штрафуя за ошибки CU или SU в правильной ветке. Здесь стоит отметить, что MU отвечает только за сбор ожидающих отправки сообщений процесса и передачу их SU, он не является доверенным, не требует залога и не подвергается штрафу.
AO очень похож на оптимистичный роллап на основе Arweave в качестве L1, за исключением того, что процесс проверки вызова происходит не на L1, а в самой сети AO.
Однако здесь есть одна проблема: невозможно ждать, пока каждое сообщение будет включено в Arweave, прежде чем подтвердить, фактическое время формирования окончательного подтверждения Arweave превышает полчаса. Поэтому у AO есть свой собственный уровень мягкого согласия, подобно Rollups в Ethereum, большинство транзакций не будут ждать подтверждения L1, а будут зачислены на счёт.
Process в AO фактически самостоятельно определяет степень проверки.
Как получатель сообщения процесс должен решить, следует ли обрабатывать это сообщение только после подтверждения Arweave или обрабатывать его сразу после подтверждения в мягком консенсусном слое. Даже на этапе подтверждения в мягком консенсусном слое процесс может принять гибкую стратегию: обрабатывать только после подтверждения одним CU или обрабатывать после резервирования нескольких CU и перекрестной проверки. Количество резервирования также определяется процессом.
В реальном применении уровень проверки часто зависит от суммы транзакции, например
- Мелкие сделки обрабатываются с использованием стратегии быстрой проверки и обрабатываются после подтверждения одной точки
- Средневзвешенная торговля, в зависимости от конкретной суммы, принимает стратегию обработки с множественным подтверждением с различной степенью избыточности
- При крупных сделках применяется осторожная стратегия проверки, обработка происходит после подтверждения в сети Arweave
Это то, что называется AO “голографическим консенсусом” + “эластичной проверкой”. Путем разделения “проверяемости” и самого поведения проверки AO подходит к проблеме консенсуса совершенно по-другому, обязанность проверки сообщений также не лежит в сети самой по себе, а в процессе получателя или, скажем, у разработчиков приложений.
Только благодаря такой модели консенсуса AO может применять модель без центра и без ограничений в «крайнем шардинге».
Конечно, эластичная проверка приводит к различной степени проверки разных процессов, что может привести к разрыву цепочки доверия в сложных взаимодействиях, отказу отдельных звеньев в длинной цепочке вызовов может привести к сбою или ошибке в общей транзакции. Фактически, такие проблемы уже проявились на тестовой сети AO. Я считаю, что AO должен установить минимальную степень проверки для всех задач проверки, и мы с нетерпением ждем нового дизайна AO на предстоящей основной сети.
Ресурсная перспектива
В традиционной системе блокчейн ресурсы абстрагируются как “блочное пространство”, которое можно понимать как совокупность ресурсов хранения, вычислений и передачи, предоставляемых узлами, и органически объединенных в блоках цепи, обеспечивая основу для работы приложений на цепи. Блочное пространство - это ограниченный ресурс, и в традиционном блокчейне различные приложения должны бороться за блочное пространство и оплачивать его, а узлы зарабатывают на этой оплате.
В AO нет понятия блока и, естественно, понятия «пространства блока». Однако, как и смарт-контракты на других цепочках, каждому процессу на AO при выполнении также требуются ресурсы. Он нуждается в узлах для временного хранения транзакций и данных состояния, а также требует ресурсов узлов для выполнения вычислительных задач. Его сообщения должны быть переданы MU и SU в целевой процесс.
В AO узлы делятся на три типа: CU (вычислительные блоки), MU (блоки сообщений) и SU (блоки сортировки), причем CU представляет собой ядро, выполняющее вычислительные задачи. MU и SU выполняют задачи связи. Когда процессу нужно взаимодействовать с другими процессами, он генерирует сообщение, которое сохраняется в очереди исходящих сообщений. Выполняющий CU этот процесс подписывает сообщение, MU извлекает это сообщение из очереди исходящих сообщений и передает его SU, который присваивает сообщению уникальный номер и загружает его в постоянное хранилище Arweave. Затем MU передает сообщение в очередь входящих сообщений целевого процесса, завершая доставку сообщения. MU можно рассматривать как сборщика и доставщика сообщений, а SU - как сортировщика и загрузчика сообщений.
Что касается ресурсов хранения, MU в сети AO должен хранить только временные данные, необходимые для вычислений, которые можно удалить после завершения расчетов. Arweave отвечает за постоянное хранение, и хотя Arweave не может масштабироваться горизонтально, его потолок производительности хранения очень высок, и потребности сети AO в хранении в ближайшем будущем не смогут достичь потолка Arweave.
Мы обнаружили, что вычислительные ресурсы, транспортные ресурсы и ресурсы хранения в сети AO являются декомпозированными, за исключением единого ресурса хранения, предоставляемого Arweave. Вычислительные ресурсы и ресурсы передачи могут масштабироваться горизонтально без ограничений.
Чем больше и производительнее узлов CU присоединяется к сети, тем выше вычислительная мощность у сети, что позволяет запускать больше процессов; также чем больше и производительнее узлов MU и SU присоединяется к сети, тем выше скорость передачи данных в сети. Другими словами, в AO может непрерывно создаваться «блочное пространство». Для приложений можно как приобретать услуги общедоступных узлов CU, MU и SU на открытом рынке, так и запускать частные узлы для обслуживания своих приложений. Если бизнес приложения расширяется, то можно повысить производительность, просто масштабируя собственные узлы, как это делается в приложениях Web2. Это невозможно себе представить в традиционных блокчейнах.
На уровне ценообразования ресурсов AO можно гибко регулировать поставку и спрос, что позволяет регулировать предложение ресурсов в соответствии с потребностями. Это регулирование очень чувствительно, и присоединение и выход узлов могут происходить очень быстро. Если мы посмотрим на Ethereum, мы увидим, что когда спрос на ресурсы резко возрастает, кроме как терпеть высокую плату за газ, у нас нет другого выбора, потому что Ethereum не может повысить свою производительность путем увеличения количества узлов.
Вывод
Вышеуказанные принципы позволяют нам начать с понятий, хорошо известных большинству исследователей в области криптографии, таких как “Шардинг”, “модульность”, “Rollup”, “пространство блоков” и т. д., и перейти к принципам и механизмам AO, чтобы помочь всем понять, как AO практически бесконечно масштабируется через дисруптивные инновации.
Теперь, когда мы вернулись к начальным вопросам, вы все поняли?
1. Не PoS, не PoW, что такое механизм согласия, о котором говорит AO, под названием ‘голографическое согласие’?
Консенсусный механизм AO на самом деле является дизайном, близким к Op Rollup. На уровне жесткого консенсуса он зависит от Arweave, а на уровне программного консенсуса каждый процесс может самостоятельно решать о силе проверки и о том, сколько узлов CU должно выполнять избыточные вычисления.
- Нет хеш-цепочки, даже нет блоков, как AO обеспечивает неизменяемость данных?
Данные DA, загруженные на Arweave, являются неизменными и обеспечивают проверяемость всех вычислений и передачи данных на AO. AO сам по себе не ограничивает обрабатываемую емкость в единицу времени, поэтому не требуется настройка блоков. В отличие от цепочек хешей и блоков, используемых для обеспечения неизменности данных, Arweave предоставляет собственную структуру цепочки.
- Без централизованной координационной центральной системы, как AO обеспечивает согласованность глобального состояния?
Каждый Process является отдельным ‘Шардинг’, управляющим своими собственными транзакциями и состоянием, взаимодействуя через сообщения. Поэтому нет необходимости в глобальной консистентности состояния. Постоянное хранение Arweave обеспечивает глобальную верифицируемость и возможность исторического отслеживания, что в сочетании с оптимистичным механизмом вызова может использоваться для разрешения споров.
4. Отсутствие механизма избыточных вычислений, кто гарантирует надежность вычислений? Что делать в случае ошибки вычислений?
AO не имеет глобального принудительного механизма избыточности, каждый процесс может самостоятельно решать, как проверять надежность каждого полученного сообщения. Если произойдет ошибка вычислений, это можно обнаружить и исправить в форме оптимистичного вызова.
5. Как обеспечить взаимодействие между процессами без общей безопасности?
Process должен самостоятельно управлять авторизацией каждого взаимодействующего с ним процесса, применять различные уровни проверки для процессов различных уровней безопасности. Для сложных взаимодействий в цепочке вызовов, чтобы избежать высоких затрат на исправление из-за разрыва цепи доверия, АО может потребовать минимальную степень проверки.
