81 запись с тегом "блокчейн"

Представьте себе мир, где пользователи могут беспрепятственно взаимодействовать с вашим dApp, не имея нативных токенов (SUI). Это больше не далёкая мечта. С помощью Gas Station Sui (также известного как Paymaster) разработчики могут покрывать комиссии за газ от имени своих пользователей, полностью устраняя один из самых больших барьеров для новичков в Web3 и обеспечивая по-настоящему беспрепятственный ончейн-опыт.

Эта статья представляет собой полное руководство по обновлению вашего dApp до безгазового состояния. Мы подробно рассмотрим основные концепции Sui Paymaster, его архитектуру, шаблоны реализации и лучшие практики.

1. Предыстория и основные концепции: Что такое спонсируемая транзакция?​

В мире блокчейна каждая транзакция требует сетевой комиссии, или «газа». Для пользователей, привыкших к бесшовному опыту Web2, это является значительным когнитивным и операционным препятствием. Sui решает эту проблему на уровне протокола с помощью спонсируемых транзакций.

Основная идея проста: позволить одной стороне (Спонсору) оплачивать комиссии за газ SUI для транзакции другой стороны (Пользователя). Таким образом, даже если у пользователя нет SUI в кошельке, он всё равно может успешно инициировать ончейн-действия.

Paymaster ≈ Газовая станция​

В экосистеме Sui логика спонсирования транзакций обычно обрабатывается офчейн- или ончейн-сервисом, называемым Gas Station или Paymaster. Его основные обязанности включают:

1. Оценка транзакции: Он получает данные безгазовой транзакции пользователя (GasLessTransactionData).
2. Предоставление газа: Он блокирует и выделяет необходимую комиссию за газ для транзакции. Обычно это управляется через газовый пул, состоящий из множества объектов SUI Coin.
3. Генерация подписи спонсора: После одобрения спонсорства Gas Station подписывает транзакцию своим приватным ключом (SponsorSig), подтверждая свою готовность оплатить комиссию.
4. Возврат подписанной транзакции: Он отправляет обратно TransactionData, которая теперь включает данные о газе и подпись спонсора, чтобы дождаться окончательной подписи пользователя.

Короче говоря, Gas Station действует как служба заправки для пользователей вашего dApp, гарантируя, что их «транспортные средства» (транзакции) могут беспрепятственно перемещаться по сети Sui.

2. Высокоуровневая архитектура и поток взаимодействия​

Типичная безгазовая транзакция включает координацию между пользователем, фронтендом dApp, Gas Station и полной нодой Sui. Последовательность взаимодействия следующая:

Разбор потока:

1. Пользователь выполняет действие в пользовательском интерфейсе dApp, которое формирует пакет данных транзакции без какой-либо информации о газе.
2. dApp отправляет эти данные в свою назначенную Gas Station для запроса спонсорства.
3. Gas Station проверяет действительность запроса (например, проверяет, имеет ли пользователь право на спонсорство), затем заполняет транзакцию Gas Coin и своей подписью, возвращая полузавершенную транзакцию dApp.
4. Пользователь видит полные детали транзакции в своём кошельке (например, «Купить один NFT») и предоставляет окончательную подпись. Это важный шаг, который гарантирует, что пользователь сохраняет согласие и контроль над своими действиями.
5. dApp транслирует полную транзакцию, содержащую подписи как пользователя, так и спонсора, в полную ноду Sui.
6. После завершения транзакции в сети Gas Station может подтвердить это, прослушивая ончейн-события или квитанции, а затем уведомить бэкенд dApp через вебхук, чтобы завершить бизнес-процесс.

3. Три основные модели взаимодействия​

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

Модель 1: Инициировано пользователем → Одобрено спонсором (наиболее распространённая)​

Это стандартная модель, подходящая для подавляющего большинства взаимодействий внутри dApp.

1. Пользователь формирует GasLessTransactionData: Пользователь выполняет действие внутри dApp.
2. Спонсор добавляет GasData и подписывает: Бэкенд dApp отправляет транзакцию в Gas Station, которая одобряет её, прикрепляет Gas Coin и добавляет свою подпись.
3. Пользователь просматривает и даёт окончательную подпись: Пользователь подтверждает окончательные детали транзакции в своём кошельке и подписывает её. Затем dApp отправляет её в сеть.

Эта модель обеспечивает отличный баланс между безопасностью и пользовательским опытом.

Модель 2: Аирдропы/стимулы, инициированные спонсором​

Эта модель идеально подходит для аирдропов, пользовательских стимулов или пакетного распределения активов.

1. Спонсор предварительно заполняет TransactionData + подписывает: Спонсор (обычно команда проекта) предварительно формирует большую часть транзакции (например, аирдроп NFT на определённый адрес) и прикрепляет свою спонсорскую подпись.
2. Вторая подпись пользователя делает её действительной: Пользователю достаточно подписать эту «предварительно одобренную» транзакцию один раз, чтобы она была выполнена.

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

Модель 3: Wildcard GasData (модель кредитной линии)​

Это более гибкая модель, основанная на разрешениях.

1. Спонсор передаёт объект GasData: Спонсор сначала создаёт один или несколько объектов Gas Coin с определённым бюджетом и передаёт право собственности непосредственно пользователю.
2. Пользователь свободно тратит в пределах бюджета: Затем пользователь может свободно использовать эти Gas Coins для оплаты любых транзакций, которые он инициирует, в пределах лимитов бюджета и срока действия.
3. Gas Coin возвращается: После исчерпания или истечения срока действия объект Gas Coin может быть разработан таким образом, чтобы автоматически уничтожаться или возвращаться Спонсору.

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

4. Типичные сценарии применения​

Сила Sui Paymaster заключается не только в решении проблемы комиссий за газ, но и в его способности глубоко интегрироваться с бизнес-логикой для создания новых возможностей.

Сценарий 1: Платные стены (Paywalls)​

Многие контентные платформы или dApp-сервисы требуют от пользователей соответствия определённым критериям (например, владение VIP NFT, достижение определённого уровня членства) для доступа к функциям. Paymaster может идеально реализовать эту логику.

• Поток: Пользователь запрашивает действие → бэкенд dApp проверяет квалификацию пользователя (например, владение NFT) → если пользователь соответствует требованиям, он вызывает Paymaster для спонсирования комиссии за газ; в противном случае он просто отклоняет запрос на подписание.
• Преимущество: Эта модель по своей природе устойчива к ботам и злоупотреблениям. Поскольку решение о спонсорстве принимается на бэкенде, злоумышленники не могут обойти проверку квалификации, чтобы истощить газовые средства.

Сценарий 2: Оформление заказа в один клик​

В сценариях электронной коммерции или внутриигровых покупок упрощение процесса оплаты имеет решающее значение.

• Поток: Пользователь нажимает «Купить сейчас» на странице оформления заказа. dApp формирует транзакцию, которая включает бизнес-логику (например, transfer_nft_to_user). Пользователю нужно только подписать, чтобы одобрить бизнес-транзакцию в своём кошельке, не беспокоясь о газе. Комиссия за газ покрывается Спонсором dApp.
• Преимущество: Вы можете закодировать бизнес-параметры, такие как order_id, непосредственно в ProgrammableTransactionBlock, что позволяет точно атрибутировать ончейн-данные для бэкенд-заказов.

Сценарий 3: Атрибуция данных​

Точное отслеживание данных является основополагающим для оптимизации бизнеса.

• Поток: При формировании транзакции запишите уникальный идентификатор (например, order_hash) в параметры транзакции или в событие, которое будет сгенерировано при выполнении.
• Преимущество: Когда Gas Station получает ончейн-квитанцию об успешной транзакции, она может легко извлечь этот order_hash, анализируя данные события или транзакции. Это позволяет точно сопоставлять изменения ончейн-состояния с конкретными бэкенд-заказами или действиями пользователя.

5. Скелет кода (на основе Rust SDK)​

Вот упрощённый фрагмент кода, демонстрирующий основные шаги взаимодействия.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Для полной реализации обратитесь к официальному Руководству по Gas Station в документации Sui, которое предлагает готовые примеры кода.

6. Риски и защита​

Хотя Gas Station является мощным инструментом, развёртывание его в производственной среде требует тщательного рассмотрения следующих рисков:

• Двусмысленность (двойная трата): Злоумышленник может попытаться использовать один и тот же Gas Coin для нескольких транзакций параллельно, что приведёт к блокировке Gas Coin сетью Sui. Это можно эффективно смягчить, назначая уникальный Gas Coin для каждого пользователя или транзакции, ведя чёрный список и ограничивая частоту запросов на подписание.
• Управление газовым пулом: В сценариях с высокой конкуренцией один Gas Coin большой стоимости может стать узким местом производительности. Сервис Gas Station должен быть способен автоматически разделять крупные SUI Coin на множество Gas Coin меньшей стоимости и эффективно возвращать их после использования. Профессиональные поставщики Gas Station, такие как Shinami, предлагают зрелые, управляемые решения для этого.
• Авторизация и ограничение скорости: Вы должны установить строгие политики авторизации и ограничения скорости. Например, управлять лимитами и частотой спонсорства на основе IP-адреса пользователя, адреса кошелька или токенов API, чтобы предотвратить истощение сервиса злоумышленниками.

7. Инструменты экосистемы​

Экосистема Sui уже предлагает богатый набор инструментов для упрощения разработки и развёртывания Paymaster:

• Официальные SDK (Rust/TypeScript): Включают высокоуровневые API, такие как sponsor_transaction_block(), значительно снижая сложность интеграции.
• Shinami Gas Station: Предоставляет комплексный управляемый сервис, включающий автоматическое разделение/возврат Gas Coin, детальный мониторинг метрик и уведомления через вебхуки, что позволяет разработчикам сосредоточиться на бизнес-логике.
• Enoki / Mysten Demos: Сообщество и Mysten Labs также предоставляют реализации Paymaster с открытым исходным кодом, которые можно использовать в качестве эталона для создания собственного сервиса.

8. Контрольный список реализации​

Готовы обновить свой dApp до безгазовой эры? Пройдите по этому контрольному списку, прежде чем начать:

• Спланируйте поток финансирования: Определите источник финансирования Спонсора, бюджет и стратегию пополнения. Настройте мониторинг и оповещения для ключевых метрик (например, баланс газового пула, скорость потребления).
• Зарезервируйте поля атрибуции: При разработке параметров транзакции обязательно зарезервируйте поля для бизнес-идентификаторов, таких как order_id или user_id.
• Разверните политики борьбы со злоупотреблениями: Вы должны внедрить строгие механизмы авторизации, ограничения скорости и логирования перед запуском.
• Отрепетируйте в Testnet: Независимо от того, создаёте ли вы свой собственный сервис или интегрируете сторонний Gas Station, всегда сначала проводите тщательное тестирование параллелизма и стресс-тестирование в тестовой сети (testnet) или сети разработки (devnet).
• Постоянно оптимизируйте: После запуска постоянно отслеживайте показатели успешности транзакций, причины сбоев и затраты на газ. Корректируйте свой бюджет и стратегии на основе данных.

Заключение​

Sui Paymaster (Gas Station) — это больше, чем просто инструмент для покрытия комиссий за газ для пользователей. Это мощная парадигма, которая элегантно сочетает пользовательский опыт «ноль SUI в сети» с бизнес-потребностью в «атрибуции на уровне заказа в сети» в рамках одной атомарной транзакции. Он открывает путь пользователям Web2 в Web3 и предоставляет разработчикам беспрецедентную гибкость для настройки бизнеса.

С постоянно развивающейся экосистемой инструментов и текущими низкими затратами на газ в сети Sui, сейчас самое подходящее время для обновления платёжных и интерактивных потоков вашего dApp до безгазовой эры.

Мы рады объявить о запуске стейкинга токенов SUI на BlockEden.xyz! Начиная с сегодняшнего дня, вы можете стейкать свои токены SUI непосредственно через нашу платформу и зарабатывать 2.08% годовых, поддерживая при этом безопасность и децентрализацию сети SUI.

Что нового: Беспрепятственный опыт стейкинга SUI​

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

Ключевые особенности​

Стейкинг в один клик Стейкинг SUI никогда не был таким простым. Просто подключите свой кошелек Suisplash, введите сумму SUI, которую вы хотите стейкать, и подтвердите транзакцию. Вы начнете получать вознаграждения почти сразу, без каких-либо сложных процедур.

Конкурентные вознаграждения Зарабатывайте конкурентоспособные 2.08% годовых на ваших застейканных SUI. Наша комиссия в размере 8% прозрачна, что гарантирует, что вы точно знаете, чего ожидать. Вознаграждения распределяются ежедневно по завершении каждой эпохи.

Надежный валидатор Присоединяйтесь к растущему сообществу, которое уже застейкало более 22 миллионов SUI с валидатором BlockEden.xyz. У нас есть проверенный опыт надежных услуг валидации, поддерживаемый инфраструктурой корпоративного уровня, которая обеспечивает 99.9% времени бесперебойной работы.

Гибкое управление Ваши активы остаются гибкими. Стейкинг мгновенен, что означает, что ваши вознаграждения начинают накапливаться сразу же. Если вам потребуется доступ к вашим средствам, вы можете начать процесс отмены стейкинга в любое время. Ваши SUI будут доступны после стандартного периода разблокировки сети SUI в 24-48 часов. Вы можете отслеживать свои стейки и вознаграждения в режиме реального времени через нашу панель управления.

Почему стоит стейкать SUI с BlockEden.xyz?​

Выбор валидатора — это критически важное решение. Вот почему BlockEden.xyz — это разумный выбор для ваших потребностей в стейкинге.

Надежность, которой вы можете доверять​

BlockEden.xyz является краеугольным камнем блокчейн-инфраструктуры с момента нашего основания. Наша инфраструктура валидатора обеспечивает работу корпоративных приложений и поддерживает исключительное время бесперебойной работы в нескольких сетях, обеспечивая постоянное получение вознаграждений.

Прозрачно и честно​

Мы верим в полную прозрачность. Нет скрытых комиссий — только четкая комиссия в размере 8% от полученных вами вознаграждений. Вы можете отслеживать производительность вашего стейкинга с помощью отчетов в реальном времени и проверять активность нашего валидатора в блокчейне.

• Открытый адрес валидатора: 0x3b5664bb0f8bb4a8be77f108180a9603e154711ab866de83c8344ae1f3ed4695

Бесшовная интеграция​

Наша платформа разработана для простоты. Нет необходимости создавать учетную запись; вы можете стейкать прямо из своего кошелька. Опыт оптимизирован для кошелька Suisplash, а наш чистый, интуитивно понятный интерфейс создан как для новичков, так и для экспертов.

Как начать​

Начать стейкинг SUI на BlockEden.xyz занимает менее двух минут.

Шаг 1: Посетите страницу стейкинга​

Перейдите на blockeden.xyz/dash/stake. Вы можете начать процесс немедленно без какой-либо регистрации учетной записи.

Шаг 2: Подключите свой кошелек​

Если у вас его еще нет, установите кошелек Suisplash. Нажмите кнопку "Подключить кошелек" на нашей странице стейкинга и подтвердите подключение в расширении кошелька. Ваш баланс SUI будет отображен автоматически.

Шаг 3: Выберите сумму стейка​

Введите сумму SUI, которую вы хотите стейкать (минимум 1 SUI). Вы можете использовать кнопку "МАКС", чтобы удобно застейкать весь ваш доступный баланс, оставив небольшую сумму для оплаты комиссий за газ. В сводке будет показана сумма вашего стейка и предполагаемые годовые вознаграждения.

Шаг 4: Подтвердите и начните зарабатывать​

Нажмите "Стейкать SUI" и подтвердите окончательную транзакцию в вашем кошельке. Ваш новый стейк появится на панели управления в режиме реального времени, и вы начнете накапливать вознаграждения немедленно.

Экономика стейкинга: Что вам нужно знать​

Понимание механики стейкинга является ключом к эффективному управлению вашими активами.

Структура вознаграждений​

• Базовый APY: 2.08% годовых
• Частота вознаграждений: Распределяется каждую эпоху (приблизительно 24 часа)
• Комиссия: 8% от заработанных вознаграждений
• Компаундинг: Вознаграждения добавляются в ваш кошелек и могут быть повторно застейканы для достижения сложного роста.

Примеры заработка​

Вот простой расчет потенциального заработка на основе 2.08% годовых, после 8% комиссии.

Примечание: Это оценки. Фактические вознаграждения могут варьироваться в зависимости от условий сети.

Соображения по рискам​

Стейкинг сопряжен с определенными рисками, о которых вам следует знать:

• Период разблокировки: Когда вы отменяете стейкинг, ваши SUI подлежат периоду разблокировки в 24-48 часов, в течение которого они недоступны и не приносят вознаграждений.
• Риск валидатора: Хотя мы поддерживаем высокие стандарты, любой валидатор несет операционные риски. Выбор надежного валидатора, такого как BlockEden.xyz, важен.
• Сетевой риск: Стейкинг является формой участия в сети и подвержен присущим рискам базового блокчейн-протокола.
• Рыночный риск: Рыночная стоимость токена SUI может колебаться, что повлияет на общую стоимость ваших застейканных активов.

Техническое превосходство​

Корпоративная инфраструктура​

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

Открытый исходный код и прозрачность​

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

Поддержка экосистемы SUI​

Стейкая с BlockEden.xyz, вы делаете больше, чем просто зарабатываете вознаграждения. Вы активно способствуете здоровью и росту всей сети SUI.

• Безопасность сети: Ваш стейк увеличивает общую сумму, обеспечивающую безопасность сети SUI, делая ее более устойчивой к потенциальным атакам.
• Децентрализация: Поддержка независимых валидаторов, таких как BlockEden.xyz, повышает устойчивость сети и предотвращает централизацию.
• Рост экосистемы: Комиссионные сборы, которые мы получаем, реинвестируются в поддержание и развитие критически важной инфраструктуры.
• Инновации: Доход поддерживает наши исследования и разработку новых инструментов и услуг для блокчейн-сообщества.

Безопасность и лучшие практики​

Пожалуйста, уделяйте приоритетное внимание безопасности ваших активов.

Безопасность кошелька​

• Никогда не делитесь своими приватными ключами или сид-фразой ни с кем.
• Используйте аппаратный кошелек для хранения и стейкинга больших сумм.
• Всегда проверяйте детали транзакции в вашем кошельке перед подписанием.
• Обновляйте программное обеспечение вашего кошелька до последней версии.

Безопасность стейкинга​

• Если вы новичок в стейкинге, начните с небольшой суммы, чтобы ознакомиться с процессом.
• Рассмотрите возможность диверсификации вашего стейка между несколькими надежными валидаторами для снижения риска.
• Регулярно отслеживайте свои застейканные активы и вознаграждения.
• Убедитесь, что вы понимаете период разблокировки, прежде чем вкладывать свои средства.

Присоединяйтесь к будущему стейкинга SUI​

Запуск стейкинга SUI на BlockEden.xyz — это больше, чем просто новая функция; это ворота к активному участию в децентрализованной экономике. Независимо от того, являетесь ли вы опытным пользователем DeFi или только начинаете свой путь, наша платформа предоставляет простой и безопасный способ получения вознаграждений, одновременно способствуя будущему сети SUI.

Готовы начать зарабатывать?

Посетите blockeden.xyz/dash/stake и застейкайте свои первые токены SUI сегодня!

О BlockEden.xyz​

BlockEden.xyz — ведущий поставщик блокчейн-инфраструктуры, предлагающий надежные, масштабируемые и безопасные услуги разработчикам, предприятиям и широкому сообществу Web3. От API-сервисов до операций валидатора, мы стремимся заложить основу для децентрализованного будущего.

• Основан: 2021
• Поддерживаемые сети: 15+ блокчейн-сетей
• Корпоративные клиенты: 500+ компаний по всему миру
• Общая заблокированная стоимость: $100M+ во всех сетях

Следите за нами в Twitter, присоединяйтесь к нашему Discord и изучайте полный спектр наших услуг на BlockEden.xyz.

Отказ от ответственности: Этот пост в блоге предназначен только для информационных целей и не является финансовой консультацией. Стейкинг криптовалют сопряжен с рисками, включая потенциальную потерю основной суммы. Пожалуйста, проведите собственное исследование и учтите свою толерантность к риску перед стейкингом.

Введение​

Децентрализованные рынки ИИ-выводов/обучения призваны использовать глобальные вычислительные ресурсы и общедоступные модели без необходимости доверия. Такие проекты, как Bittensor, Gensyn и Cuckoo Network (Cuckoo AI), демонстрируют, как блокчейн-технологии могут обеспечивать работу открытых ИИ-маркетплейсов. Каждая платформа токенизирует ключевые ИИ-активы — вычислительную мощность, модели машинного обучения, а иногда и данные — в ончейн-экономические единицы. Далее мы углубимся в технические архитектуры, лежащие в основе этих сетей, способы токенизации ресурсов, их структуры управления и стимулирования, методы отслеживания владения моделями, механизмы распределения доходов и возникающие поверхности атаки (например, атаки Сивиллы, сговор, фрирайдерство, отравление данных). Сравнительная таблица в конце подытоживает все ключевые аспекты Bittensor, Gensyn и Cuckoo AI.

Технические архитектуры​

Bittensor: Децентрализованный «Нейронный Интернет» на подсетях​

Bittensor построен на основе кастомного блокчейна уровня 1 (цепочка Subtensor, основанная на Substrate), который координирует сеть узлов ИИ-моделей в многочисленных специализированных подсетях. Каждая подсеть представляет собой независимую мини-сеть, ориентированную на конкретную ИИ-задачу (например, подсеть для генерации языка, другая — для генерации изображений и т. д.). Участники Bittensor выполняют различные роли:

• Майнеры — они запускают модели машинного обучения на своем оборудовании и предоставляют ответы на запросы (или даже выполняют обучение) для задачи подсети. По сути, майнер — это узел, размещающий ИИ-модель, которая будет отвечать на запросы.
• Валидаторы — они запрашивают модели майнеров с помощью промптов и оценивают качество ответов, формируя мнение о том, какие майнеры вносят ценные результаты. Валидаторы эффективно оценивают производительность майнеров.
• Владельцы подсетей — они создают и определяют подсети, устанавливая правила для выполнения задач и проведения валидации в этой подсети. Владелец подсети может, например, указать, что подсеть предназначена для определенного набора данных или модальности, и определить процедуру валидации.
• Делегаторы — держатели токенов, которые не запускают узлы, могут делегировать (стейкать) свои токены Bittensor (TAO) майнерам или валидаторам, чтобы поддержать лучших исполнителей и получить долю вознаграждения (аналогично стейкингу в сетях Proof-of-Stake).

Механизм консенсуса Bittensor является новаторским: вместо традиционной валидации блоков Bittensor использует консенсус Yuma, который является формой «доказательства интеллекта». В консенсусе Yuma оценки валидаторов майнеров агрегируются в ончейне для определения распределения вознаграждений. Каждые 12 секунд сеть выпускает новые токены TAO и распределяет их в соответствии с консенсусом валидаторов относительно того, какие майнеры выполнили полезную работу. Оценки валидаторов объединяются по схеме медианы, взвешенной по стейку: выбросы мнений отсекаются, и преобладает честное большинство. Это означает, что если большинство валидаторов согласны с тем, что майнер был высококачественным, этот майнер получит значительное вознаграждение; если валидатор сильно отклоняется от других (возможно, из-за сговора или ошибки), этот валидатор наказывается меньшим заработком. Таким образом, блокчейн Bittensor координирует петлю обратной связи между майнером и валидатором: майнеры соревнуются за создание лучших ИИ-выводов, а валидаторы курируют и ранжируют эти выводы, при этом обе стороны зарабатывают токены пропорционально ценности, которую они добавляют. Эта архитектура часто описывается как «децентрализованная нейронная сеть» или «глобальный мозг», где модели учатся на сигналах друг друга и коллективно развиваются. Примечательно, что Bittensor недавно обновил свою цепь для поддержки совместимости с EVM (для смарт-контрактов) и представил dTAO, систему токенов и стейкинга для конкретных подсетей (объясняется позже) для дальнейшей децентрализации контроля над распределением ресурсов.

Gensyn: Протокол доверенных распределенных вычислений​

Gensyn подходит к децентрализованному ИИ с точки зрения протокола распределенных вычислений для машинного обучения. Его архитектура соединяет разработчиков (отправителей), у которых есть ИИ-задачи (например, обучение модели или выполнение задачи вывода), с поставщиками вычислений (решателями) по всему миру, у которых есть свободные ресурсы GPU/TPU. Первоначально Gensyn планировал цепь Substrate L1, но затем перешел на создание на Ethereum в качестве роллапа для повышения безопасности и ликвидности. Таким образом, сеть Gensyn является уровнем 2 Ethereum (роллап Ethereum), который координирует размещение заданий и платежи, в то время как вычисления происходят вне цепи на оборудовании поставщиков.

Ключевым нововведением в дизайне Gensyn является его система верификации для офчейн-работы. Gensyn использует комбинацию оптимистической верификации (доказательства мошенничества) и криптографических методов для обеспечения того, что когда решатель заявляет о выполнении задачи обучения/вывода, результат является правильным. На практике протокол включает несколько ролей участников:

• Отправитель — сторона, запрашивающая задание (например, тот, кому нужно обучить модель). Они оплачивают комиссию сети и предоставляют модель/данные или спецификацию задачи.
• Решатель — узел, который делает ставки на выполнение ML-задачи на своем оборудовании и выполняет ее. Он будет обучать модель или выполнять вывод по запросу, а затем представит результаты и доказательство вычислений.
• Верификатор/Челленджер — узлы, которые могут проверять или выборочно проверять работу решателя. Gensyn реализует схему в стиле Truebit, где по умолчанию результат решателя принимается, но верификатор может оспорить его в течение определенного окна, если подозревает неправильное вычисление. В случае оспаривания используется интерактивный «бинарный поиск» по шагам вычисления (протокол доказательства мошенничества) для выявления любых расхождений. Это позволяет цепи разрешать споры, выполняя только минимальную критическую часть вычисления в ончейне, а не повторяя всю дорогостоящую задачу.

Важно отметить, что Gensyn разработан для избежания массовой избыточности наивных подходов. Вместо того чтобы множество узлов повторяли одну и ту же ML-задачу (что уничтожило бы экономию средств), подход Gensyn «доказательство обучения» использует метаданные обучения для проверки того, что был достигнут прогресс в обучении. Например, решатель может предоставить криптографические хеши или контрольные точки промежуточных весов модели и краткое доказательство того, что они прогрессировали в соответствии с обновлениями обучения. Это вероятностное доказательство обучения может быть проверено гораздо дешевле, чем повторный запуск всего обучения, что позволяет осуществлять доверенную верификацию без полного дублирования. Только если верификатор обнаружит аномалию, в крайнем случае будет запущено более тяжелое ончейн-вычисление. Этот подход значительно снижает накладные расходы по сравнению с проверкой методом грубой силы, делая децентрализованное ML-обучение более осуществимым. Таким образом, архитектура Gensyn сильно акцентирует внимание на криптоэкономическом игровом дизайне: решатели вносят стейк или залог, и если они обманывают (представляют неверные результаты), они теряют этот стейк в пользу честных верификаторов, которые их поймают. Объединяя координацию блокчейна (для платежей и разрешения споров) с офчейн-вычислениями и умной верификацией, Gensyn создает маркетплейс для ML-вычислений, который может использовать простаивающие GPU в любой точке мира, сохраняя при этом отсутствие доверия. Результатом является гипермасштабируемый «протокол вычислений», где любой разработчик может получить доступ к доступной, глобально распределенной вычислительной мощности по требованию.

Cuckoo AI: Полнофункциональная децентрализованная платформа ИИ-сервисов​

Cuckoo Network (или Cuckoo AI) использует более вертикально интегрированный подход, стремясь предоставлять сквозные децентрализованные ИИ-сервисы, а не просто сырые вычисления. Cuckoo построил свой собственный блокчейн (первоначально уровень 1 под названием Cuckoo Chain на Arbitrum Orbit, фреймворке роллапов, совместимом с Ethereum) для оркестрации всего: он не только сопоставляет задания с GPU, но также размещает ИИ-приложения и обрабатывает платежи в одной системе. Дизайн является полнофункциональным: он сочетает блокчейн для транзакций и управления, децентрализованный уровень ресурсов GPU/CPU и пользовательские ИИ-приложения и API сверху. Другими словами, Cuckoo интегрирует все три уровня — блокчейн, вычисления и ИИ-приложения — в рамках единой платформы.

Участники Cuckoo делятся на четыре группы:

• Разработчики ИИ-приложений (Координаторы) — это разработчики, которые развертывают ИИ-модели или сервисы на Cuckoo. Например, разработчик может разместить генератор изображений Stable Diffusion или чат-бота LLM в качестве сервиса. Они запускают Узлы-координаторы, которые отвечают за управление своим сервисом: прием пользовательских запросов, разделение их на задачи и назначение этих задач майнерам. Координаторы стейкают нативный токен ($CAI), чтобы присоединиться к сети и получить право использовать майнеров. По сути, они действуют как оркестраторы уровня 2, которые взаимодействуют между пользователями и поставщиками GPU.
• Майнеры GPU/CPU (Узлы задач) — это поставщики ресурсов. Майнеры запускают клиент Cuckoo для задач и предоставляют свое оборудование для выполнения задач вывода для ИИ-приложений. Например, майнеру может быть назначен запрос на генерацию изображения (с заданной моделью и промптом) координатором, и он использует свой GPU для вычисления результата. Майнеры также должны стейкать $CAI для обеспечения обязательств и хорошего поведения. Они зарабатывают токен-вознаграждения за каждую правильно выполненную задачу.
• Конечные пользователи — потребители ИИ-приложений. Они взаимодействуют через веб-портал Cuckoo или API (например, генерируют искусство через CooVerse или общаются с ИИ-персонажами). Пользователи могут либо платить криптовалютой за каждое использование, либо, возможно, предоставлять свои собственные вычисления (или стейк) для компенсации затрат на использование. Важным аспектом является устойчивость к цензуре: если один координатор (поставщик услуг) заблокирован или выходит из строя, пользователи могут переключиться на другого, обслуживающего то же приложение, поскольку несколько координаторов могут размещать аналогичные модели в децентрализованной сети.
• Стейкеры (Делегаторы) — члены сообщества, которые не запускают ИИ-сервисы или майнинговое оборудование, все еще могут участвовать, стейкая $CAI на тех, кто это делает. Голосуя своим стейком за доверенных координаторов или майнеров, они помогают сигнализировать о репутации и взамен получают долю сетевых вознаграждений. Этот дизайн создает уровень репутации Web3: хорошие акторы привлекают больше стейка (и, следовательно, доверия и вознаграждений), в то время как плохие акторы теряют стейк и репутацию. Даже конечные пользователи могут стейкать в некоторых случаях, что соответствует их интересам в успехе сети.

Цепочка Cuckoo (сейчас находится в процессе перехода от автономной цепи к роллапу с общей безопасностью) отслеживает все эти взаимодействия. Когда пользователь вызывает ИИ-сервис, узел-координатор создает ончейн-назначения задач для майнеров. Майнеры выполняют задачи офчейн и возвращают результаты координатору, который их проверяет (например, проверяет, что выходное изображение или текст не является бессмыслицей) и доставляет окончательный результат пользователю. Блокчейн обрабатывает расчеты по платежам: за каждую задачу смарт-контракт координатора платит майнеру в $CAI (часто агрегируя микроплатежи в ежедневные выплаты). Cuckoo подчеркивает отсутствие доверия и прозрачность — все участники стейкают токены, и все назначения и выполнения задач записываются, поэтому мошенничество пресекается угрозой потери стейка и публичной видимостью производительности. Модульный дизайн сети означает, что новые ИИ-модели или варианты использования могут быть легко добавлены: хотя она начиналась с генерации текста в изображение в качестве доказательства концепции, ее архитектура достаточно универсальна для поддержки других ИИ-нагрузок (например, вывод языковых моделей, транскрипция аудио и т. д.).

Примечательным аспектом архитектуры Cuckoo является то, что она изначально запустила свой собственный блокчейн уровня 1 для максимизации пропускной способности для ИИ-транзакций (достигая 300 тыс. ежедневных транзакций во время тестирования). Это позволило выполнить пользовательские оптимизации для планирования ИИ-задач. Однако команда обнаружила, что поддержание автономного L1 является дорогостоящим и сложным, и по состоянию на середину 2025 года они решили прекратить поддержку собственной цепи и перейти на модель роллапа/AVS (Active Validated Service) на Ethereum. Это означает, что Cuckoo будет наследовать безопасность от Ethereum или L2, такого как Arbitrum, вместо того чтобы запускать свой собственный консенсус, но продолжит управлять своим децентрализованным ИИ-маркетплейсом на этом уровне общей безопасности. Изменение призвано улучшить экономическую безопасность (используя надежность Ethereum) и позволить команде Cuckoo сосредоточиться на продукте, а не на низкоуровневом обслуживании цепи. В итоге, архитектура Cuckoo создает децентрализованную платформу для обслуживания ИИ, где любой может подключить оборудование или развернуть сервис ИИ-модели, а пользователи по всему миру могут получить доступ к ИИ-приложениям с меньшими затратами и меньшей зависимостью от инфраструктуры Big Tech.

Механизмы токенизации активов​

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

• Вычислительная мощность: Все три платформы превращают вычислительную работу в токены вознаграждения. В Bittensor полезные вычисления (вывод или обучение, выполненные майнером) количественно оцениваются с помощью оценок валидаторов и вознаграждаются токенами TAO за каждый блок. По сути, Bittensor «измеряет» внесенный интеллект и выпускает TAO как товар, представляющий этот вклад. Gensyn явно рассматривает вычисления как товар — его протокол создает маркетплейс, где время GPU является продуктом, а цена устанавливается спросом и предложением в токенах. Разработчики покупают вычисления, используя токен, а поставщики зарабатывают токены, продавая свои аппаратные циклы. Команда Gensyn отмечает, что любой цифровой ресурс (вычисления, данные, алгоритмы) может быть представлен и продан на аналогичном доверенном рынке. Cuckoo токенизирует вычисления с помощью токена ERC-20 $CAI, выпускаемого в качестве оплаты за выполненные задачи. Поставщики GPU, по сути, «майнят» CAI, выполняя работу по ИИ-выводу. Система Cuckoo создает ончейн-записи задач, поэтому можно рассматривать каждую выполненную задачу GPU как атомарную единицу работы, оплачиваемую токенами. Предпосылка для всех трех заключается в том, что иначе простаивающая или недоступная вычислительная мощность становится токенизированным, ликвидным активом — либо через эмиссию токенов на уровне протокола (как в Bittensor и раннем Cuckoo), либо через открытый рынок ордеров на покупку/продажу вычислительных заданий (как в Gensyn).

• ИИ-модели: Представление ИИ-моделей в виде ончейн-активов (например, NFT или токенов) все еще находится на ранней стадии. Bittensor не токенизирует сами модели — модели остаются офчейн во владении майнеров. Вместо этого Bittensor косвенно оценивает модели, вознаграждая те, которые хорошо работают. По сути, «интеллект» модели превращается в заработок TAO, но нет NFT, который бы представлял веса модели или позволял другим использовать модель. Gensyn фокусируется на вычислительных транзакциях, а не на явном создании токенов для моделей. Модель в Gensyn обычно предоставляется разработчиком офчейн (возможно, с открытым исходным кодом или проприетарная), обучается решателями и возвращается — нет встроенного механизма для создания токена, который владеет моделью или ее ИС. (Тем не менее, маркетплейс Gensyn потенциально может облегчить торговлю артефактами или контрольными точками моделей, если стороны выберут это, но сам протокол рассматривает модели как содержимое вычислений, а не как токенизированный актив.) Cuckoo находится где-то посередине: он говорит об «ИИ-агентах» и моделях, интегрированных в сеть, но в настоящее время нет невзаимозаменяемого токена, представляющего каждую модель. Вместо этого модель развертывается разработчиком приложения, а затем обслуживается через сеть. Права на использование этой модели неявно токенизируются тем, что модель может зарабатывать $CAI при использовании (через координатора, который ее развертывает). Все три платформы признают концепцию токенизации моделей — например, предоставление сообществам владения моделями через токены — но практические реализации ограничены. В отрасли токенизация ИИ-моделей (например, в виде NFT с правами собственности и долей прибыли) все еще исследуется. Подход Bittensor, при котором модели обмениваются ценностью друг с другом, является формой «маркетплейса моделей» без явного токена для каждой модели. Команда Cuckoo отмечает, что децентрализованное владение моделями обещает снизить барьеры по сравнению с централизованным ИИ, но требует эффективных методов проверки выходов и использования моделей в ончейне. В итоге, вычислительная мощность немедленно токенизируется (легко платить токенами за выполненную работу), тогда как модели токенизируются косвенно или в перспективе (вознаграждаются за свои выходы, возможно, представлены стейком или репутацией, но пока не рассматриваются как передаваемые NFT на этих платформах).

• Данные: Токенизация данных остается самой сложной. Ни Bittensor, ни Gensyn, ни Cuckoo не имеют полностью обобщенных ончейн-маркетплейсов данных (где наборы данных торгуются с принудительными правами использования). Узлы Bittensor могут обучаться на различных наборах данных, но эти наборы данных не являются частью ончейн-системы. Gensyn может позволить разработчику предоставить набор данных для обучения, но протокол не токенизирует эти данные — они просто предоставляются офчейн для использования решателем. Cuckoo аналогично не токенизирует пользовательские данные; он в основном обрабатывает данные (например, пользовательские промпты или выходы) временным образом для задач вывода. В блоге Cuckoo прямо говорится, что «децентрализованные данные остаются сложными для токенизации», несмотря на то, что это критически важный ресурс. Данные чувствительны (проблемы конфиденциальности и владения) и трудно обрабатываются с помощью текущих блокчейн-технологий. Таким образом, хотя вычисления становятся товаром, а модели начинают им быть, данные в основном остаются офчейн, за исключением особых случаев (некоторые проекты за пределами этих трех экспериментируют с объединениями данных и токен-вознаграждениями за вклад данных, но это выходит за рамки нашей текущей области). В итоге, вычислительная мощность теперь является ончейн-товаром в этих сетях, модели оцениваются через токены, но еще не токенизированы индивидуально как активы, а токенизация данных все еще остается открытой проблемой (помимо признания ее важности).

Управление и стимулы​

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

• Управление Bittensor: На ранних этапах разработка Bittensor и параметры подсетей в значительной степени контролировались основной командой и набором из 64 «корневых» валидаторов в основной подсети. Это было точкой централизации — несколько влиятельных валидаторов имели чрезмерное влияние на распределение вознаграждений, что привело к тому, что некоторые называли «олигархической системой голосования». Для решения этой проблемы Bittensor в 2025 году ввел управление dTAO (децентрализованный TAO). Система dTAO перевела распределение ресурсов на рыночное и контролируемое сообществом. Конкретно, держатели TAO могут стейкать свои токены в пулы ликвидности для конкретных подсетей (по сути, они «голосуют» за то, какие подсети должны получать больше эмиссии сети) и получать альфа-токены, которые представляют собой право собственности в этих пулах подсетей. Подсети, которые привлекают больше стейка, будут иметь более высокую цену альфа-токена и получать большую долю ежедневной эмиссии TAO, тогда как непопулярные или плохо работающие подсети будут терять капитал (и, следовательно, эмиссию). Это создает петлю обратной связи: если подсеть производит ценные ИИ-сервисы, больше людей стейкают в нее TAO (в поисках вознаграждений), что дает этой подсети больше TAO для вознаграждения своих участников, способствуя росту. Если подсеть стагнирует, стейкеры выводят средства в более прибыльные подсети. По сути, держатели TAO коллективно управляют фокусом сети, финансово сигнализируя, какие ИИ-области заслуживают больше ресурсов. Это форма ончейн-управления по весу токенов, согласованная с экономическими результатами. Помимо распределения ресурсов, основные обновления протокола или изменения параметров, вероятно, по-прежнему проходят через предложения по управлению, за которые голосуют держатели TAO (Bittensor имеет механизм для ончейн-предложений и референдумов, управляемых Фондом Bittensor и избранным советом, аналогично управлению Polkadot). Со временем можно ожидать, что управление Bittensor будет становиться все более децентрализованным, при этом фонд будет отходить на второй план, поскольку сообщество (через стейк TAO) будет управлять такими вещами, как уровень инфляции, утверждение новых подсетей и т. д. Переход на dTAO является большим шагом в этом направлении, заменяя централизованных лиц, принимающих решения, рынком заинтересованных сторон токенов, согласованным по стимулам.

• Стимулы Bittensor: Структура стимулов Bittensor тесно вплетена в его консенсус. Каждый блок (12 секунд) ровно 1 TAO выпускается и делится между участниками каждой подсети на основе производительности. Разделение вознаграждения за блок по умолчанию для каждой подсети составляет 41% майнерам, 41% валидаторам и 18% владельцу подсети. Это гарантирует, что все роли вознаграждаются: майнеры зарабатывают за выполнение работы по выводу, валидаторы зарабатывают за свои усилия по оценке, а владельцы подсетей (которые, возможно, загрузили данные/задачу для этой подсети) получают остаток за предоставление «маркетплейса» или дизайн задачи. Эти проценты фиксированы в протоколе и направлены на согласование стимулов всех участников для получения высококачественного ИИ-вывода. Механизм консенсуса Yuma дополнительно уточняет стимулы, взвешивая вознаграждения в соответствии с оценками качества — майнер, который предоставляет лучшие ответы (согласно консенсусу валидаторов), получает большую часть этих 41%, а валидатор, который точно следует честному консенсусу, получает больше из доли валидатора. Плохие исполнители экономически отсеиваются. Кроме того, делегаторы (стейкеры), которые поддерживают майнера или валидатора, обычно получают долю от заработка этого узла (узлы часто устанавливают комиссию и отдают остальное своим делегаторам, аналогично стейкингу в сетях PoS). Это позволяет пассивным держателям TAO поддерживать лучших участников и получать доход, что еще больше укрепляет меритократию. Токен Bittensor (TAO) таким образом является утилитарным токеном: он требуется для регистрации новых майнеров (майнеры должны потратить небольшое количество TAO, чтобы присоединиться, что борется со спамом Сивиллы) и может быть застейкан для увеличения влияния или заработка через делегирование. Он также рассматривается как платежный токен, если внешние пользователи хотят потреблять услуги из сети Bittensor (например, платить TAO за запрос языковой модели в Bittensor), хотя внутренний механизм вознаграждения до сих пор был основной «экономикой». Общая философия стимулирования заключается в вознаграждении «ценного интеллекта» — то есть моделей, которые помогают производить хорошие ИИ-результаты — и в создании конкуренции, которая постоянно улучшает качество моделей в сети.

• Управление Gensyn: Модель управления Gensyn структурирована таким образом, чтобы развиваться от контроля основной команды к контролю сообщества по мере созревания сети. Первоначально Gensyn будет иметь Фонд Gensyn и избранный совет, который будет контролировать обновления протокола и решения по казначейству. Ожидается, что этот совет будет состоять из членов основной команды и ранних лидеров сообщества. Gensyn планирует Событие генерации токенов (TGE) для своего нативного токена (часто называемого GENS), после чего власть управления будет все больше переходить в руки держателей токенов через ончейн-голосование. Роль фонда заключается в представлении интересов протокола и обеспечении плавного перехода к полной децентрализации. На практике Gensyn, вероятно, будет иметь ончейн-механизмы предложений, где изменения параметров (например, длительность игры верификации, ставки комиссий) или обновления будут голосоваться сообществом. Поскольку Gensyn реализуется как роллап Ethereum, управление также может быть связано с безопасностью Ethereum (например, использование ключей обновления для контракта роллапа, которые в конечном итоге передаются DAO держателей токенов). Раздел децентрализации и управления в лайтпейпере Gensyn подчеркивает, что протокол в конечном итоге должен принадлежать всему миру, что соответствует этике, согласно которой «сеть для машинного интеллекта» должна принадлежать ее пользователям и участникам. В итоге, управление Gensyn начинается полуцентрализованным, но спроектировано так, чтобы стать DAO, где держатели токенов GENS (потенциально взвешенные по стейку или участию) принимают решения коллективно.

• Стимулы Gensyn: Экономические стимулы в Gensyn представляют собой прямую рыночную динамику, дополненную криптоэкономической безопасностью. Разработчики (клиенты) платят за ML-задачи в токене Gensyn, а Решатели зарабатывают токены, правильно выполняя эти задачи. Цена за вычислительные циклы определяется открытым рынком — предположительно, разработчики могут выставлять задачи с вознаграждением, а решатели могут делать ставки или просто брать задачу, если цена соответствует их ожиданиям. Это гарантирует, что пока есть предложение свободных GPU, конкуренция будет снижать стоимость до справедливой ставки (команда Gensyn прогнозирует снижение затрат до 80% по сравнению с облачными ценами, поскольку сеть находит самое дешевое доступное оборудование по всему миру). С другой стороны, решатели заинтересованы в заработке токенов за работу; их оборудование, которое иначе простаивало бы, теперь приносит доход. Для обеспечения качества Gensyn требует от решателей стейкать залог при выполнении задания — если они обманывают или производят неверный результат и их ловят, они теряют этот стейк (он может быть сокращен и передан честному верификатору). Верификаторы стимулируются возможностью получить «джекпот» в случае поимки мошеннического решателя, аналогично дизайну Truebit, который периодически вознаграждает верификаторов, успешно выявляющих неверные вычисления. Это поддерживает честность решателей и мотивирует некоторые узлы действовать как наблюдатели. В оптимальном сценарии (без мошенничества) решатели просто получают плату за задачу, а роль верификатора в основном простаивает (или один из участвующих решателей может выступать в качестве верификатора для других). Токен Gensyn, таким образом, служит как валютой для оплаты газа для покупки вычислений, так и залоговым стейком, который обеспечивает безопасность протокола. В лайтпейпере упоминается тестовая сеть с неперманентными токенами и то, что ранние участники тестовой сети будут вознаграждены на TGE реальными токенами. Это указывает на то, что Gensyn выделил часть предложения токенов для бустрапинга — вознаграждения ранних пользователей, тестовых решателей и членов сообщества. В долгосрочной перспективе плата за реальные задания должна поддерживать сеть. Также может быть небольшая протокольная комиссия (процент от каждого платежа за задачу), которая поступает в казну или сжигается; эта деталь пока не подтверждена, но многие протоколы маркетплейсов включают комиссию для финансирования разработки или выкупа и сжигания токенов. В итоге, стимулы Gensyn согласованы вокруг честного выполнения ML-заданий: выполняй работу, получай оплату; пытайся обмануть, теряй стейк; проверяй других, зарабатывай, если поймаешь мошенников. Это создает саморегулирующуюся экономическую систему, направленную на достижение надежных распределенных вычислений.

• Управление Cuckoo: Cuckoo Network с самого начала встроила управление в свою экосистему, хотя оно все еще находится на стадии развития. Токен $CAI явно является токеном управления в дополнение к его утилитарным ролям. Философия Cuckoo заключается в том, что операторы узлов GPU, разработчики приложений и даже конечные пользователи должны иметь право голоса в развитии сети — это отражает ее видение, ориентированное на сообщество. На практике важные решения (например, обновления протокола или экономические изменения) будут приниматься путем голосования, взвешенного по токенам, предположительно через механизм DAO. Например, Cuckoo может проводить ончейн-голосования за изменение распределения вознаграждений или внедрение новой функции, и держатели$CAI (включая майнеров, разработчиков и пользователей) будут голосовать. Уже сейчас ончейн-голосование используется как система репутации: Cuckoo требует, чтобы каждая роль стейкала токены, а затем члены сообщества могут голосовать (возможно, делегируя стейк или через модули управления) за то, какие координаторы или майнеры заслуживают доверия. Это влияет на оценки репутации и может влиять на планирование задач (например, координатор с большим количеством голосов может привлекать больше пользователей, или майнер с большим количеством голосов может получать больше задач). Это сочетание управления и стимулов — использование токенов управления для установления доверия. Фонд Cuckoo или основная команда до сих пор руководили направлением проекта (например, приняли недавнее решение о прекращении поддержки цепи L1), но их блог указывает на приверженность переходу к децентрализованному владению. Они определили, что запуск собственной цепи повлек за собой высокие накладные расходы, и что переход на роллап позволит более открытую разработку и интеграцию с существующими экосистемами. Вероятно, что после перехода на общий уровень (например, Ethereum) Cuckoo реализует более традиционный DAO для обновлений, при этом сообщество будет голосовать с использованием CAI.

• Стимулы Cuckoo: Дизайн стимулов для Cuckoo имеет две фазы: начальная фаза бустрапинга с фиксированными распределениями токенов и будущее состояние с распределением доходов, зависящим от использования. При запуске Cuckoo провела «честный запуск» распределения 1 миллиарда токенов CAI. 51% предложения было выделено для сообщества, распределено следующим образом:

  • Вознаграждения за майнинг: 30% от общего предложения зарезервировано для оплаты GPU-майнерам за выполнение ИИ-задач.
  • Вознаграждения за стейкинг: 11% предложения для тех, кто стейкает и помогает обеспечивать безопасность сети.
  • Аирдропы: 5% для ранних пользователей и членов сообщества в качестве стимула к принятию.
  • (Еще 5% было выделено на гранты для разработчиков для поощрения создания на Cuckoo.)

  Это большое распределение означало, что на ранних этапах сети майнеры и стейкеры вознаграждались из пула эмиссии, даже если фактический пользовательский спрос был низким. Действительно, на начальном этапе Cuckoo предлагала высокую APY-доходность за стейкинг и майнинг, что успешно привлекало участников, но также и «фармеров доходности», которые были там только ради токенов. Команда отметила, что многие пользователи ушли, как только ставки вознаграждения упали, что указывает на то, что эти стимулы не были связаны с реальным использованием. Учитывая это, Cuckoo переходит к модели, где вознаграждения напрямую коррелируют с реальной ИИ-нагрузкой. В будущем (и частично уже сейчас), когда конечный пользователь платит за ИИ-вывод, этот платеж (в CAI или, возможно, другом принятом токене, конвертированном в CAI) будет разделен между участниками:

  • GPU-майнеры получат большую часть за предоставленные вычисления.
  • Координатор (разработчик приложения) получит часть как поставщик услуг, который предоставил модель и обработал запрос.
  • Стейкеры, которые делегировали этим майнерам или координаторам, могут получить небольшую долю или инфляционное вознаграждение, чтобы продолжать стимулировать поддержку надежных узлов.
  • Сеть/Казначейство может удерживать комиссию за текущую разработку или для финансирования будущих стимулов (или комиссия может быть нулевой/номинальной для максимизации доступности для пользователей).

  По сути, Cuckoo переходит к модели распределения доходов: если ИИ-приложение на Cuckoo приносит доход, этот доход распределяется между всеми участниками этого сервиса справедливым образом. Это согласовывает стимулы таким образом, что участники получают выгоду от фактического использования, а не только от инфляции. Уже сейчас сеть требовала от всех сторон стейкать CAI — это означает, что майнеры и координаторы зарабатывают не только фиксированное вознаграждение, но и, возможно, вознаграждения на основе стейка (например, координатор может зарабатывать больше, если многие пользователи стейкают на него или если он сам стейкает больше, аналогично тому, как зарабатывают валидаторы Proof-of-Stake). Что касается стимулов для пользователей, Cuckoo также представила такие вещи, как портал аирдропов и краны (которые некоторые пользователи обманывали) для стимулирования начальной активности. В будущем пользователи могут быть стимулированы через токен-ребейты за использование услуг или через вознаграждения за управление за участие в курировании (например, возможно, зарабатывая небольшие токены за оценку выходов или предоставление данных). Суть в том, что токен Cuckoo ($CAI) является многоцелевым: это токен газа/комиссии в цепи (все транзакции и платежи используют его), он используется для стейкинга и голосования, и это единица вознаграждения за выполненную работу. Cuckoo явно упоминает, что хочет привязать токен-вознаграждения к KPI на уровне сервиса (ключевым показателям производительности) — например, времени безотказной работы, пропускной способности запросов, удовлетворенности пользователей — чтобы избежать чисто спекулятивных стимулов. Это отражает созревание токеномики от простого майнинга ликвидности к более устойчивой, ориентированной на полезность модели.

Владение моделями и атрибуция ИС​

Обработка интеллектуальной собственности (ИС) и прав собственности на ИИ-модели является сложным аспектом децентрализованных ИИ-сетей. Каждая платформа заняла несколько иную позицию, и в целом это развивающаяся область, пока не имеющая полного решения:

• Bittensor: Модели в Bittensor предоставляются узлами-майнерами, и эти майнеры сохраняют полный контроль над весами своих моделей (которые никогда не публикуются в ончейне). Bittensor явно не отслеживает, кто «владеет» моделью, помимо того факта, что она работает по определенному адресу кошелька. Если майнер уходит, его модель уходит вместе с ним. Таким образом, атрибуция ИС в Bittensor происходит офчейн: если майнер использует проприетарную модель, в ончейне нет ничего, что бы это обеспечивало или даже знало. Философия Bittensor поощряет открытые вклады (многие майнеры могут использовать модели с открытым исходным кодом, такие как GPT-J или другие), и сеть вознаграждает производительность этих моделей. Можно сказать, что Bittensor создает репутационную оценку для моделей (через рейтинги валидаторов), и это является формой признания ценности модели, но права на саму модель не токенизируются и не распределяются. Примечательно, что владельцы подсетей в Bittensor могут рассматриваться как владельцы части ИС: они определяют задачу (которая может включать набор данных или метод). Владелец подсети выпускает NFT (называемый UID подсети) при создании подсети, и этот NFT дает ему право на 18% вознаграждений в этой подсети. Это фактически токенизирует создание маркетплейса моделей (подсети), если не экземпляров моделей. Если определение подсети (скажем, задача распознавания речи с определенным набором данных) рассматривать как ИС, то это по крайней мере записывается и вознаграждается. Но индивидуальные веса моделей, которые обучают майнеры — записи о владении ими в ончейне нет. Атрибуция происходит в виде вознаграждений, выплачиваемых на адрес этого майнера. Bittensor в настоящее время не реализует систему, где, например, несколько человек могли бы совместно владеть моделью и получать автоматическую долю дохода — человек, запускающий модель (майнер), получает вознаграждение, и от него зависит, соблюдать ли офчейн любые лицензии ИС на используемую им модель.

• Gensyn: В Gensyn владение моделями прямолинейно: отправитель (тот, кто хочет обучить модель) предоставляет архитектуру модели и данные, и после обучения получает результирующий артефакт модели. Решатели, выполняющие работу, не имеют прав на модель; они подобны подрядчикам, получающим оплату за услугу. Протокол Gensyn, таким образом, предполагает традиционную модель ИС: если у вас были законные права на модель и данные, которые вы предоставили, они остаются у вас после обучения — вычислительная сеть не претендует на какое-либо владение. Gensyn упоминает, что маркетплейс также может торговать алгоритмами и данными, как и любым другим ресурсом. Это намекает на сценарий, когда кто-то может предложить модель или алгоритм для использования в сети, возможно, за плату, тем самым токенизируя доступ к этой модели. Например, создатель модели может разместить свою предварительно обученную модель на Gensyn и позволить другим дообучать ее через сеть за плату (это фактически монетизировало бы ИС модели). Хотя протокол не обеспечивает соблюдение условий лицензии, можно закодировать требования к оплате: смарт-контракт может требовать плату для разблокировки весов модели для решателя. Однако это спекулятивные варианты использования — основной дизайн Gensyn заключается в обеспечении выполнения задач обучения. Что касается атрибуции, если несколько сторон вносят вклад в модель (скажем, одна предоставляет данные, другая — вычисления), это, вероятно, будет регулироваться любым контрактом или соглашением, которое они заключили до использования Gensyn (например, смарт-контракт может разделить платеж между поставщиком данных и поставщиком вычислений). Сам Gensyn не отслеживает в ончейне «эта модель была создана X, Y, Z» помимо записи о том, какие адреса были оплачены за работу. В итоге, ИС модели в Gensyn остается у отправителя, и любая атрибуция или лицензирование должны обрабатываться через юридические соглашения вне протокола или через пользовательские смарт-контракты, построенные поверх него.

• Cuckoo: В экосистеме Cuckoo создатели моделей (разработчики ИИ-приложений) являются первоклассными участниками — они развертывают ИИ-сервис. Если разработчик приложения дообучает языковую модель или разрабатывает пользовательскую модель и размещает ее на Cuckoo, эта модель по сути является его собственностью, и он выступает в качестве владельца сервиса. Cuckoo не захватывает никакого владения; вместо этого она предоставляет инфраструктуру для монетизации использования. Например, если разработчик развертывает чат-бота с ИИ, пользователи могут взаимодействовать с ним, и разработчик (плюс майнеры) зарабатывают CAI от каждого взаимодействия. Таким образом, платформа приписывает доход от использования создателю модели, но не публикует явно веса модели и не превращает их в NFT. Фактически, для запуска модели на GPU майнеров узел-координатор, вероятно, должен отправить модель (или среду выполнения) майнеру в какой-либо форме. Это вызывает вопросы ИС: может ли злонамеренный майнер скопировать веса модели и распространить их? В децентрализованной сети такой риск существует, если используются проприетарные модели. Текущий фокус Cuckoo был на достаточно открытых моделях (Stable Diffusion, модели, производные от LLaMA и т. д.) и на создании сообщества, поэтому мы еще не видели обеспечения прав ИС через смарт-контракты. Платформа потенциально может интегрировать такие инструменты, как зашифрованное выполнение моделей или защищенные анклавы в будущем для защиты ИС, но в документации ничего конкретного не упоминается. Что она действительно отслеживает, так это кто предоставил сервис модели для каждой задачи — поскольку координатор является ончейн-идентичностью, все использование его модели учитывается ему, и он автоматически получает свою долю вознаграждений. Если бы кто-то передал или продал модель кому-то другому, он фактически передал бы контроль над узлом-координатором (возможно, даже просто передал бы ему приватный ключ или NFT, если роль координатора была токенизирована). В настоящее время общественное владение моделями (через доли токенов) не реализовано, но видение Cuckoo намекает на децентрализованный ИИ, управляемый сообществом, поэтому они могут изучить возможность позволить людям коллективно финансировать или управлять ИИ-моделью. Токенизация моделей за пределами индивидуального владения все еще является открытой областью в этих сетях — это признается целью (позволить сообществам владеть ИИ-моделями, а не корпорациям), но на практике это требует решений для вышеупомянутых проблем ИС и верификации.

В итоге, владение моделями в Bittensor, Gensyn и Cuckoo обрабатывается офчейн традиционными способами: лицо или сущность, запускающая или отправляющая модель, фактически является владельцем. Сети обеспечивают атрибуцию в виде экономических вознаграждений (оплачивая вкладчику модели его ИС или усилия). Ни одна из трех платформ пока не имеет встроенной лицензии или механизма принудительного взимания роялти за использование модели на уровне смарт-контракта. Атрибуция происходит через репутацию и вознаграждение: например, лучшие модели Bittensor получают высокие оценки репутации (что является публичной записью) и больше TAO, что является неявным кредитом их создателям. Со временем мы можем увидеть такие функции, как веса моделей, привязанные к NFT, или децентрализованные лицензии для лучшего отслеживания ИС, но в настоящее время приоритетом является обеспечение функционирования сетей и стимулирование вкладов. Все согласны с тем, что проверка происхождения и выходов моделей является ключом к созданию настоящих рынков активов моделей, и исследования в этом направлении продолжаются.

Структуры распределения доходов​

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

• Bittensor: Как упоминалось в разделе о стимулах, распределение доходов Bittensor определяется протоколом на уровне блоков: 41% майнерам, 41% валидаторам, 18% владельцу подсети за каждый выпуск TAO в блоке. Это фактически встроенное распределение доходов для ценности, генерируемой в каждой подсети. Доля владельца подсети (18%) действует как роялти за «дизайн модели/задачи» или за бустрапинг экосистемы этой подсети. Майнеры и валидаторы, получающие равные доли, гарантируют, что без валидации майнеры не получают вознаграждения (и наоборот) — они симбиотичны, и каждый получает равную часть выпущенных вознаграждений. Если мы рассмотрим внешнего пользователя, платящего TAO за запрос модели, в вайтпейпере Bittensor предполагается, что этот платеж также будет аналогично разделен между майнером, который отвечает, и валидаторами, которые помогли проверить ответ (точное разделение может быть определено протоколом или рыночными силами). Кроме того, делегаторы, которые стейкают на майнеров/валидаторов, фактически являются партнерами — как правило, майнер/валидатор делится процентом своего заработанного TAO со своими делегаторами (это настраивается, но часто большая часть достается делегаторам). Таким образом, если майнер заработал 1 TAO за блок, это может быть разделено, например, 80/20 между его делегаторами и им самим, в зависимости от стейка. Это означает, что даже не-операторы получают долю дохода сети пропорционально своей поддержке. С введением dTAO был добавлен еще один уровень распределения: те, кто стейкает в пул подсети, получают альфа-токены, которые дают им право на часть эмиссии этой подсети (подобно фармингу доходности). По сути, любой может сделать ставку на успех конкретной подсети и получать долю вознаграждений майнеров/валидаторов, владея альфа-токенами (альфа-токены дорожают по мере того, как подсеть привлекает больше использования и эмиссии). В итоге, распределение доходов Bittensor фиксировано кодом для основных ролей и далее распределяется по социальным/стейкинговым соглашениям. Это относительно прозрачное, основанное на правилах разделение — каждый блок участники точно знают, как распределяется 1 TAO, и, таким образом, знают свой «заработок» за вклад. Эта ясность является одной из причин, по которой Bittensor иногда сравнивают с Биткойном для ИИ — детерминированная денежная эмиссия, где вознаграждение участников математически установлено.

• Gensyn: Распределение доходов в Gensyn более динамично и ориентировано на рынок, поскольку задачи оцениваются индивидуально. Когда отправитель создает задание, он прикрепляет вознаграждение (скажем, X токенов), которое он готов заплатить. Решатель, который выполняет задание, получает эти X (за вычетом любой сетевой комиссии). Если задействован верификатор, обычно действует правило: если мошенничество не обнаружено, решатель сохраняет полную оплату; если мошенничество обнаружено, решатель подвергается слэшингу — теряя часть или весь свой стейк — и эта сокращенная сумма передается верификатору в качестве вознаграждения. Таким образом, верификаторы не зарабатывают на каждой задаче, только когда они ловят плохой результат (плюс, возможно, небольшая базовая комиссия за участие, в зависимости от реализации). Здесь нет встроенной концепции оплаты владельцу модели, потому что предполагается, что отправитель либо является владельцем модели, либо имеет права на ее использование. Можно представить сценарий, когда отправитель дообучает чью-то предварительно обученную модель, и часть платежа идет первоначальному создателю модели — но это должно быть обработано вне протокола (например, по соглашению или отдельному смарт-контракту, который соответствующим образом делит платеж в токенах). Распределение на уровне протокола Gensyn, по сути, происходит по схеме клиент -> решатель (-> верификатор). Модель токена, вероятно, включает некоторое распределение для казначейства протокола или фонда; например, небольшой процент от платежа за каждую задачу может идти в казну, которая может использоваться для финансирования разработки или страховых пулов (это не указано явно в доступных документах, но многие протоколы так делают). Кроме того, на ранних этапах Gensyn может субсидировать решателей через инфляцию: пользователям тестовой сети обещаны вознаграждения при TGE, что фактически является долей дохода от первоначального распределения токенов (ранние решатели и сторонники получают часть токенов за помощь в бустрапинге, сродни аирдропу или вознаграждению за майнинг). Со временем, по мере того как реальные задания будут доминировать, инфляционные вознаграждения будут сокращаться, а доход решателей будет в основном поступать от пользовательских платежей. Подход Gensyn можно резюмировать как модель дохода «плата за услугу»: сеть облегчает прямую оплату от тех, кому нужна работа, тем, кто ее выполняет, при этом верификаторы и, возможно, стейкеры токенов получают доли только тогда, когда они играют роль в обеспечении этой услуги.

• Cuckoo: Распределение доходов Cuckoo развивалось. Изначально, поскольку не было много платящих конечных пользователей, распределение доходов по сути было распределением инфляции: 30% на майнинг и 11% на стейкинг из предложения токенов означали, что майнеры и стейкеры делили токены, выпущенные пулом честного запуска сети. На практике Cuckoo осуществляла такие вещи, как ежедневные выплаты CAI майнерам пропорционально выполненным задачам. Эти выплаты в основном поступали из выделения вознаграждений за майнинг (которое является частью зарезервированного фиксированного предложения). Это похоже на то, как многие блокчейны уровня 1 распределяют вознаграждения за блоки майнерам/валидаторам — это не было привязано к фактическому использованию внешними пользователями, это было скорее для стимулирования участия и роста. Однако, как подчеркивается в их блоге от июля 2025 года, это привело к использованию, которое стимулировалось фармингом токенов, а не реальным спросом. Следующий этап для Cuckoo — это настоящая модель распределения доходов, основанная на платах за услуги. В этой модели, когда конечный пользователь использует, скажем, сервис генерации изображений и платит $1 (в криптовалютном выражении), эти токены на$1 будут разделены, возможно, следующим образом: 0,70 майнеру, который выполнил работу на GPU, 0,20 разработчику приложения (координатору), который предоставил модель и интерфейс, и 0,10 стейкерам или казначейству сети. (Примечание: точные соотношения гипотетические; Cuckoo еще не опубликовала их, но это иллюстрирует концепцию.) Таким образом, все участники предоставления услуги получают долю дохода. Это аналогично, например, экономике совместных поездок, но для ИИ: транспортное средство (GPU-майнер) получает большую часть, водитель или платформа (координатор, создавший сервис модели) получает долю, и, возможно, управление/стейкеры платформы получают небольшую комиссию. Упоминание Cuckoo о «моделях распределения доходов и токен-вознаграждениях, напрямую привязанных к метрикам использования» предполагает, что если конкретный сервис или узел обрабатывает большой объем, его операторы и сторонники будут зарабатывать больше. Они отходят от фиксированной доходности за простое блокирование токенов (что было в случае с их начальной APY за стейкинг). В конкретных терминах: если вы стейкаете на координатора, который в итоге обеспечивает работу очень популярного ИИ-приложения, вы можете заработать часть комиссий этого приложения — сценарий стейкинга как инвестирования в полезность, а не стейкинга просто ради инфляции. Это согласовывает стимулы всех участников на привлечение реальных пользователей, которые платят за ИИ-сервисы, что, в свою очередь, возвращает ценность держателям токенов. Стоит отметить, что цепочка Cuckoo также имела комиссии за транзакции (газ), поэтому майнеры, которые производили блоки (изначально GPU-майнеры также способствовали производству блоков в цепочке Cuckoo), также получали комиссии за газ. С закрытием цепочки и миграцией на роллап комиссии за газ, вероятно, будут минимальными (или на Ethereum), поэтому основным доходом станут сами комиссии за ИИ-сервисы. В итоге, Cuckoo переходит от модели, основанной на субсидиях (сеть платит участникам из своего пула токенов), к модели, основанной на спросе (участники зарабатывают на фактических платежах пользователей). Токен по-прежнему будет играть роль в стейкинге и управлении, но ежедневный заработок майнеров и разработчиков приложений должен все больше поступать от пользователей, покупающих ИИ-сервисы. Эта модель более устойчива в долгосрочной перспективе и тесно отражает распределение доходов SaaS в Web2, но реализована через смарт-контракты и токены для прозрачности.

Поверхности атаки и уязвимости​

Децентрализация ИИ вводит несколько проблем со стимулами и безопасностью. Теперь мы проанализируем ключевые векторы атак — атаки Сивиллы, сговор, фрирайдерство и отравление данных/моделей — и то, как каждая платформа смягчает их или остается уязвимой к ним:

• Атаки Сивиллы (фальшивые личности): В открытой сети злоумышленник может создать множество личностей (узлов), чтобы получить непропорциональные вознаграждения или влияние.

  • Bittensor: Устойчивость к атакам Сивиллы обеспечивается в основном стоимостью входа. Для регистрации нового майнера или валидатора в Bittensor необходимо потратить или застейкать TAO — это может быть сжигание или требование залога. Это означает, что создание N фальшивых узлов влечет за собой N-кратные затраты, что делает крупные рои Сивиллы дорогостоящими. Кроме того, консенсус Bittensor связывает влияние со стейком и производительностью; Сивилла без стейка или с плохой производительностью мало зарабатывает. Злоумышленнику придется вложить значительные средства, а также заставить свои узлы Сивиллы фактически вносить полезную работу, чтобы получить какое-либо значительное вознаграждение (что не является типичной стратегией Сивиллы). Тем не менее, если у злоумышленника действительно много капитала, он может приобрести большинство TAO и зарегистрировать много валидаторов или майнеров — фактически, Сивилла за счет богатства. Это пересекается со сценарием атаки 51%: если одна сущность контролирует >50% застейканных TAO в подсети, она может сильно повлиять на консенсус. Введение dTAO в Bittensor немного помогает здесь: оно распределяет влияние по подсетям и требует поддержки сообщества для процветания подсетей, что затрудняет контроль над всем одной сущности. Тем не менее, атаки Сивиллы со стороны хорошо финансируемого противника остаются проблемой — анализ Arxiv явно отмечает, что стейк сейчас довольно сконцентрирован, поэтому барьер для атаки большинства не так высок, как хотелось бы. Для смягчения этой проблемы были предложены такие меры, как ограничения на стейк для каждого кошелька (например, ограничение эффективного стейка 88-м процентилем для предотвращения доминирования одного кошелька). В итоге, Bittensor полагается на идентичность, взвешенную по стейку (вы не можете дешево создавать личности без пропорционального стейка) для борьбы с Сивиллами; это достаточно эффективно, за исключением очень ресурсного злоумышленника.
  • Gensyn: Атаки Сивиллы в Gensyn проявились бы в том, что злоумышленник запускает множество узлов-решателей или верификаторов, чтобы обмануть систему. Защита Gensyn является чисто экономической и криптографической — сами по себе личности не имеют значения, но выполнение работы или внесение залога имеют. Если злоумышленник создает 100 фальшивых узлов-решателей, но у них нет заданий или стейка, они ничего не добьются. Чтобы выиграть задачи, узел Сивиллы должен будет конкурировать в ставках и иметь оборудование для выполнения работы. Если они занижают ставки без достаточной мощности, они потерпят неудачу и потеряют стейк. Аналогично, злоумышленник может создать множество верификаторов, надеясь быть выбранным для проверки (если протокол случайным образом выбирает верификаторов). Но если их слишком много, сеть или отправитель задания могут ограничить количество активных верификаторов. Кроме того, верификаторам, возможно, придется выполнять вычисления для проверки, что дорого; наличие множества фальшивых верификаторов не поможет, если вы не можете фактически проверять результаты. Более актуальный аспект атаки Сивиллы в Gensyn заключается в том, что злоумышленник пытается заполнить сеть поддельными заданиями или ответами, чтобы потратить время других. Это смягчается требованием депозита и от отправителей (злонамеренный отправитель, размещающий фальшивые задания, теряет свою оплату или депозит). В целом, использование Gensyn обязательных стейков/залогов и случайного выбора для верификации означает, что злоумышленник мало что получает от наличия нескольких личностей, если он также не приносит пропорциональные ресурсы. Это становится более дорогостоящей атакой, а не дешевой. Оптимистическая модель безопасности предполагает наличие хотя бы одного честного верификатора — Сивиллы должны будут подавить и быть всеми верификаторами, чтобы постоянно обманывать, что снова сводится к владению большинством стейка или вычислительной мощности. Устойчивость Gensyn к атакам Сивиллы, таким образом, сравнима с устойчивостью оптимистического роллапа: пока есть хотя бы один честный актор, Сивиллы не могут легко причинить системный вред.
  • Cuckoo: Предотвращение атак Сивиллы в Cuckoo основано на стейкинге и проверке сообществом. Каждая роль в Cuckoo (майнер, координатор, даже пользователь в некоторых случаях) требует стейкинга $CAI. Это немедленно увеличивает стоимость личностей Сивиллы — злоумышленнику, создающему 100 фиктивных майнеров, потребуется приобрести и заблокировать стейк для каждого. Более того, дизайн Cuckoo имеет человеческий/общественный элемент: новые узлы должны зарабатывать репутацию через ончейн-голосование. Армия Сивиллы из новых узлов без репутации вряд ли получит много задач или доверия пользователей. Координаторы, в частности, должны привлекать пользователей; фальшивый координатор без послужного списка не получит использования. Для майнеров координаторы могут видеть их статистику производительности (успешные задачи и т. д.) на Cuckoo Scan и будут предпочитать надежных майнеров. Cuckoo также имела относительно небольшое количество майнеров (40 GPU в один момент в бета-версии), поэтому любой странный приток множества узлов был бы заметен. Потенциально слабым местом является то, что злоумышленник также использует систему репутации — например, он стейкает много CAI на своих узлах Сивиллы, чтобы они выглядели респектабельными, или создает фальшивые «пользовательские» учетные записи, чтобы голосовать за себя. Это теоретически возможно, но поскольку все это курируется токенами, это стоит токенов (вы, по сути, будете голосовать своим собственным стейком за свои собственные узлы). Команда Cuckoo также может корректировать параметры стейкинга и вознаграждений, если наблюдается поведение Сивиллы (особенно сейчас, когда она становится более централизованным сервисом роллапа; они могут приостанавливать или сокращать плохих акторов). В целом, Сивиллы сдерживаются требованием «шкурного интереса» (стейка) и необходимостью одобрения сообщества. Никто не может просто так прийти с сотнями фальшивых GPU и получать вознаграждения без значительных инвестиций, которые честные участники могли бы лучше потратить на реальное оборудование и стейк.

• Сговор: Здесь мы рассматриваем сговор нескольких участников для обмана системы — например, сговор валидаторов и майнеров в Bittensor, или решателей и верификаторов в Gensyn и т. д.

  • Bittensor: Сговор был признан реальной проблемой. В первоначальном дизайне несколько валидаторов могли сговориться, чтобы всегда одобрять определенных майнеров или самих себя, несправедливо искажая распределение вознаграждений (это наблюдалось как концентрация власти в корневой подсети). Консенсус Yuma обеспечивает некоторую защиту: принимая медиану оценок валидаторов и наказывая тех, кто отклоняется, он предотвращает драматическое повышение целевого объекта небольшой сговорившейся группой, если только они не составляют большинство. Другими словами, если 3 из 10 валидаторов сговариваются, чтобы дать майнеру очень высокую оценку, но остальные 7 этого не делают, оценки сговорщиков-выбросов отсекаются, и вознаграждение майнера основывается на медианной оценке (таким образом, сговор не помогает значительно). Однако, если сговорщики составляют >50% валидаторов (или >50% стейка среди валидаторов), они фактически являются консенсусом — они могут договориться о ложных высоких оценках, и медиана будет отражать их точку зрения. Это классический сценарий атаки 51%. К сожалению, исследование Arxiv показало, что в некоторых подсетях Bittensor коалиция всего 1–2% участников (по количеству) контролировала большинство стейка из-за высокой концентрации токенов. Это означает, что сговор нескольких крупных держателей был реальной угрозой. Смягчение, которое Bittensor преследует через dTAO, заключается в демократизации влияния: позволяя любому держателю TAO направлять стейк в подсети, это разбавляет власть закрытых групп валидаторов. Также предложения, такие как вогнутый стейкинг (уменьшающаяся отдача от чрезмерного стейка) и ограничения на стейк, направлены на то, чтобы лишить одну сговорившуюся сущность возможности собрать слишком много голосующей силы. Предположение безопасности Bittensor теперь аналогично Proof-of-Stake: ни одна сущность (или картель) не контролирует >50% активного стейка. Пока это сохраняется, сговор ограничен, потому что честные валидаторы будут отменять плохие оценки, а сговорившиеся владельцы подсетей не могут произвольно увеличивать свои собственные вознаграждения. Наконец, что касается сговора между владельцами подсетей и валидаторами (например, владелец подсети подкупает валидаторов, чтобы они высоко оценивали майнеров его подсети), dTAO устраняет прямой контроль валидаторов, заменяя его решениями держателей токенов. Сговориться с «рынком» сложнее, если только вы не выкупите все предложение токенов — в этом случае это не совсем сговор, это поглощение. Таким образом, основной метод борьбы со сговором в Bittensor — это алгоритмический консенсус (отсечение медианы) и широкое распределение токенов.
  • Gensyn: Сговор в Gensyn, вероятно, будет включать сговор решателя и верификатора (или нескольких верификаторов) для обмана системы. Например, решатель может произвести поддельный результат, а сговорившийся верификатор может намеренно не оспаривать его (или даже подтвердить, что он правильный, если протокол просил верификаторов подписать). Для смягчения этого, модель безопасности Gensyn требует наличия хотя бы одного честного верификатора. Если все верификаторы сговариваются с решателем, то плохой результат остается неоспоренным. Gensyn решает эту проблему, поощряя множество независимых верификаторов (любой может верифицировать) и используя теорию игр, согласно которой верификатор может получить большое вознаграждение, выйдя из сговора и оспорив (потому что он получит стейк решателя). По сути, даже если есть группа, согласившаяся на сговор, у каждого члена есть стимул дезертировать и забрать награду себе — это классическая дилемма заключенного. Надежда состоит в том, что это сохраняет группы сговорщиков небольшими или неэффективными. Другой потенциальный сговор — между несколькими решателями для повышения цен или монополизации задач. Однако, поскольку разработчики могут выбирать, куда размещать задачи (и задачи не являются идентичными единицами, которые можно легко монополизировать), сговор решателей по ценам было бы трудно координировать глобально — любой не сговорившийся решатель мог бы предложить более низкую цену, чтобы выиграть работу. Динамика открытого рынка противодействует ценовому сговору, предполагая наличие хотя бы нескольких конкурентоспособных участников. Еще один аспект: сговор верификаторов для «гриферства» решателей — например, верификаторы ложно обвиняют честных решателей, чтобы украсть их стейк. Доказательство мошенничества Gensyn является бинарным и ончейн; ложное обвинение потерпит неудачу, когда ончейн-пересчет не обнаружит ошибки, и предположительно злонамеренный верификатор тогда что-то потеряет (возможно, депозит или репутацию). Таким образом, сговор верификаторов, пытающихся саботировать решателей, будет пойман процессом верификации протокола. В итоге, архитектура Gensyn надежна, пока хотя бы одна сторона в любом сговорившемся наборе имеет стимул быть честной — свойство оптимистической верификации, аналогичное требованию наличия одного честного майнера в Биткойне, чтобы в конечном итоге разоблачить мошенничество. Сговор теоретически возможен, если злоумышленник сможет контролировать всех верификаторов и решателей в задаче (как большинство сети), но тогда они могли бы просто обманывать без необходимости сговора как такового. Криптоэкономические стимулы устроены так, чтобы поддержание сговора было иррациональным.
  • Cuckoo: Сговор в Cuckoo может произойти несколькими способами:
    1. Координатор в сговоре с майнерами — например, координатор может всегда назначать задачи группе дружественных майнеров и делить вознаграждения, игнорируя других честных майнеров. Поскольку координаторы имеют право по своему усмотрению планировать задачи, это может произойти. Однако, если дружественные майнеры работают некачественно, конечные пользователи могут заметить медленное или плохое обслуживание и уйти, поэтому координатор не заинтересован в чистом фаворитизме, который вредит качеству. Если сговор направлен на манипулирование вознаграждениями (скажем, отправку фальшивых задач для выдачи токенов майнерам), это будет обнаружено в ончейне (много задач с, возможно, идентичными входными данными или без фактического пользователя) и может быть наказано. Ончейн-прозрачность Cuckoo означает, что любые необычные паттерны могут быть отмечены сообществом или основной командой. Кроме того, поскольку все участники стейкают, сговорившееся кольцо координатор-майнер рискует потерять свой стейк, если будет поймано на злоупотреблении системой (например, если управление решит сократить их за мошенничество).
    2. Майнеры сговариваются между собой — они могут обмениваться информацией или формировать картель, чтобы, скажем, голосовать друг за друга в репутационной системе или все отказываться обслуживать определенного координатора, чтобы получить более высокие комиссии. Эти сценарии менее вероятны: голосование за репутацию осуществляется стейкерами (включая пользователей), а не самими майнерами, голосующими друг за друга. А отказ от обслуживания только заставит координаторов искать других майнеров или поднимет тревогу. Учитывая относительно небольшой текущий масштаб, любой сговор будет трудно скрыть.
    3. Сговор с целью манипулирования управлением — крупные держатели CAI могут сговориться, чтобы принять предложения в свою пользу (например, установить непомерную комиссию или перенаправить казну). Это риск в любом токен-управлении. Лучшее смягчение — это широкое распределение токена (честный запуск Cuckoo отдал 51% сообществу) и активный надзор со стороны сообщества. Кроме того, поскольку Cuckoo отказалась от L1, непосредственное ончейн-управление может быть ограничено, пока они не перейдут на новую цепь; команда, вероятно, сохраняет мультисиг-контроль в промежутке, что, по иронии судьбы, предотвращает сговор злонамеренных посторонних за счет временной централизации. В целом, Cuckoo опирается на прозрачность и стейкинг для борьбы со сговором. Существует элемент доверия к координаторам, чтобы они вели себя хорошо, потому что они хотят привлекать пользователей в конкурентной среде. Если сговор приводит к ухудшению обслуживания или очевидной игре с вознаграждениями, заинтересованные стороны могут проголосовать против или прекратить стейкинг на плохих акторов, а сеть может сократить или заблокировать их. Достаточно открытый характер (любой может стать координатором или майнером, если он стейкает) означает, что сговор потребует больших скоординированных усилий, которые будут очевидны. Это не так математически предотвращено, как в Bittensor или Gensyn, но сочетание экономического стейка и управления сообществом обеспечивает проверку.

• Фрирайдерство (проблемы безбилетника): Это относится к участникам, пытающимся получить вознаграждение, не внося эквивалентной ценности — например, валидатор, который фактически не оценивает, но все равно зарабатывает, или майнер, который копирует ответы других вместо вычислений, или пользователи, фармящие вознаграждения без предоставления полезного вклада.

  • Bittensor: Известной проблемой фрирайдерства в Bittensor является «копирование весов» ленивыми валидаторами. Валидатор может просто скопировать мнение большинства (или оценки другого валидатора) вместо независимой оценки майнеров. При этом они избегают затрат на выполнение ИИ-запросов, но все равно получают вознаграждение, если их представленные оценки соответствуют консенсусу. Bittensor борется с этим, измеряя согласованность консенсуса и информационный вклад каждого валидатора. Если валидатор всегда просто копирует других, он может хорошо согласовываться (поэтому его не сильно наказывают), но он не добавляет уникальной ценности. Разработчики протокола обсуждали предоставление более высоких вознаграждений валидаторам, которые предоставляют точные, но не чисто избыточные оценки. Такие методы, как «введение шума» (намеренное предоставление валидаторам немного разных запросов), могут заставить их фактически работать, а не копировать — хотя неясно, реализовано ли это. Arxiv предлагает методы взвешенной по производительности эмиссии и композитного скоринга для лучшей связи усилий валидатора с вознаграждением. Что касается майнеров, одним из возможных видов фрирайдерства было бы, если майнер запрашивает других майнеров и передает ответ (форма плагиата). Дизайн Bittensor (с децентрализованными запросами) может позволить модели майнера вызывать другие через свой собственный дендрит. Если майнер просто передает ответ другого, хороший валидатор может это заметить, потому что ответ может не соответствовать заявленным возможностям модели майнера. Это сложно обнаружить алгоритмически, но майнер, который никогда не вычисляет оригинальные результаты, в конечном итоге должен получить низкие оценки по некоторым запросам и потерять репутацию. Другой сценарий фрирайдерства — делегаторы, зарабатывающие вознаграждения без выполнения ИИ-работы. Это намеренно (для вовлечения держателей токенов), поэтому это не атака — но это означает, что часть эмиссии токенов идет людям, которые только стейкали. Bittensor оправдывает это как согласование стимулов, а не растраченные вознаграждения. Короче говоря, Bittensor признает проблему фрирайдерства валидаторов и настраивает стимулы (например, дает «оценки доверия валидаторов», которые повышают тех, кто не отклоняется и не копирует). Их решение, по сути, заключается в более явном вознаграждении за усилия и правильность, так что бездействие или слепое копирование со временем приносит меньше TAO.
  • Gensyn: В Gensyn фрирайдерам было бы трудно зарабатывать, потому что нужно либо предоставлять вычисления, либо ловить кого-то на мошенничестве, чтобы получить токены. Решатель не может «подделать» работу — он должен предоставить либо действительное доказательство, либо рискнуть быть сокращенным. Нет механизма получения оплаты без выполнения задачи. Верификатор теоретически может сидеть без дела и надеяться, что другие поймают мошенников — но тогда он ничего не заработает (потому что только тот, кто поднимает доказательство мошенничества, получает вознаграждение). Если слишком много верификаторов пытаются быть фрирайдерами (фактически не пересчитывают задачи), то мошеннический решатель может проскользнуть, потому что никто не проверяет. Дизайн стимулов Gensyn решает эту проблему с помощью джекпот-вознаграждения: достаточно одного активного верификатора, чтобы поймать мошенника и получить большую выплату, поэтому рационально, чтобы хотя бы один всегда выполнял работу. Другие, не выполняющие работу, не вредят сети, кроме как бесполезностью; они также не получают вознаграждения. Таким образом, система естественным образом отсеивает фрирайдеров: только те верификаторы, которые фактически верифицируют, будут получать прибыль в долгосрочной перспективе (другие тратят ресурсы на узлы впустую или очень редко случайно получают вознаграждение). Протокол также может рандомизировать, какой верификатор получает возможность оспорить, чтобы отговорить всех верификаторов от предположения «кто-то другой это сделает». Поскольку задачи оплачиваются индивидуально, нет аналога «вознаграждений за стейкинг без работы», кроме временных стимулов тестовой сети. Одна область, на которую стоит обратить внимание, — это оптимизация нескольких задач: решатель может попытаться повторно использовать работу между задачами или тайно передать ее кому-то более дешевому (например, использовать централизованное облако) — но это не совсем вредное фрирайдерство; если они предоставляют правильные результаты вовремя, неважно, как они это сделали. Это скорее арбитраж, чем атака. В итоге, дизайн механизма Gensyn оставляет мало места для фрирайдеров, потому что каждый распределенный токен соответствует выполненной работе или наказанному мошенничеству.
  • Cuckoo: Начальная фаза Cuckoo непреднамеренно создала проблему фрирайдерства: аирдроп и высокодоходный стейкинг привлекли пользователей, которые были там только для фарминга токенов. Эти пользователи циклически пропускали токены через краны или обманывали задачи аирдропа (например, постоянно используя бесплатные тестовые промпты или создавая множество учетных записей для получения вознаграждений), не внося вклад в долгосрочную ценность сети. Cuckoo признала это проблемой — по сути, люди «использовали» сеть не для ИИ-вывода, а для спекулятивной выгоды. Решение о прекращении поддержки цепочки L1 и переориентации было частично направлено на устранение этих несоответствий стимулов. Привязывая будущие токен-вознаграждения к фактическому использованию (т. е. вы зарабатываете, потому что сервис фактически используется платящими клиентами), привлекательность фрирайдерства уменьшается. Существует также сценарий фрирайдерства со стороны майнеров: майнер может присоединиться, получить назначенные задачи и каким-то образом не выполнить их, но все равно требовать вознаграждение. Однако координатор проверяет результаты — если майнер возвращает нулевой или плохой результат, координатор не будет считать это выполненной задачей, поэтому майнер не получит оплату. Майнеры также могут пытаться выбирать легкие задачи и отказываться от сложных (например, если некоторые промпты медленнее, майнер может отключиться, чтобы избежать их). Это может быть проблемой, но координаторы могут отмечать надежность майнера. Если майнер часто отключается, координатор может прекратить назначать ему задачи или сократить его стейк (если такой механизм существует или просто не вознаграждать его). Фрирайдерство пользователей — поскольку многие ИИ-сервисы имеют бесплатные пробные версии, пользователь может спамить запросы, чтобы получить выводы без оплаты (если есть субсидируемая модель). Это не столько проблема на уровне протокола, сколько на уровне сервиса; каждый координатор может решить, как обрабатывать бесплатное использование (например, требовать небольшую оплату или дросселировать). Поскольку Cuckoo изначально раздавала бесплатные услуги (например, бесплатную генерацию ИИ-изображений для привлечения пользователей), некоторые воспользовались этим, но это было частью ожидаемого маркетинга роста. По мере окончания этих акций пользователям придется платить, таким образом, не будет бесплатного обеда для эксплуатации. В целом, новая стратегия Cuckoo по привязке распределения токенов к реальной полезности явно направлена на устранение проблемы фрирайдерства «майнинга токенов за бессмысленные циклы».

• Отравление данных или моделей: Это относится к злонамеренному введению плохих данных или поведений, в результате чего ИИ-модели деградируют или выходы манипулируются, а также к проблемам вредоносного или предвзятого контента.

  • Bittensor: Отравление данных в Bittensor означало бы, что майнер намеренно дает неверные или вредоносные ответы, или валидаторы целенаправленно неправильно оценивают хорошие ответы как плохие. Если майнер постоянно выдает мусор или вредоносный контент, валидаторы будут давать низкие оценки, и этот майнер будет мало зарабатывать и в конечном итоге отсеется — экономический стимул заключается в предоставлении качества, поэтому «отравление» других не приносит пользы злоумышленнику (если только его цель не чисто саботаж за свой счет). Может ли злонамеренный майнер отравить других? В Bittensor майнеры не обучают друг друга напрямую (по крайней мере, не по замыслу — нет глобальной модели, которая обновляется и может быть отравлена). Модель каждого майнера отдельна. Они учатся в том смысле, что майнер может брать интересные образцы у других для дообучения себя, но это полностью необязательно и зависит от каждого. Если злонамеренный актор спамит бессмысленные ответы, честные валидаторы отфильтруют это (они оценят это низко), поэтому это не окажет значительного влияния на процесс обучения любого честного майнера (плюс, майнер, вероятно, будет использовать знания высокооцененных коллег, а не низкооцененных). Таким образом, классическое отравление данных (введение плохих обучающих данных для повреждения модели) минимально в текущей настройке Bittensor. Более актуальным риском является манипуляция ответами модели: например, майнер, который выдает тонко предвзятый или опасный контент, который не очевиден для валидаторов. Однако, поскольку валидаторы также являются агентами, разработанными человеком или, по крайней мере, алгоритмическими, явная токсичность или ошибка, вероятно, будет поймана (некоторые подсети могут даже иметь ИИ-валидаторов, проверяющих на небезопасный контент). Худший сценарий — если злоумышленник каким-то образом имеет большинство валидаторов и майнеров, сговаривающихся, чтобы продвигать определенный неверный вывод как «правильный» — они могли бы тогда исказить консенсус сети по ответам (например, все сговаривающиеся валидаторы одобряют вредоносный ответ). Но чтобы внешний пользователь пострадал от этого, он должен фактически запросить сеть и доверять выводу. Bittensor все еще находится на стадии, когда он наращивает возможности, а не широко используется для критических запросов конечными пользователями. К тому времени, когда это произойдет, можно надеяться, что он будет иметь фильтрацию контента и разнообразие валидаторов для смягчения таких рисков. Со стороны валидаторов злонамеренный валидатор может подавать отравленные оценки — например, постоянно занижать оценки определенному честному майнеру, чтобы устранить конкуренцию. При достаточном стейке они могут преуспеть в вытеснении этого майнера (если вознаграждения майнера упадут так низко, что он уйдет). Это атака на механизм стимулирования. Опять же, если они не составляют большинство, отсечение медианы помешает валидатору-выбросу. Если они составляют большинство, это сливается со сценарием сговора/51% — любое большинство может переписывать правила. Решение возвращается к децентрализации: не допускать доминирования одной сущности. В итоге, дизайн Bittensor по своей сути наказывает отравленные данные/вклады моделей через свою систему оценки — плохие вклады получают низкий вес и, следовательно, низкое вознаграждение. Нет постоянного репозитория моделей для отравления; все динамично и постоянно оценивается. Это обеспечивает устойчивость: сеть может постепенно «забывать» или игнорировать плохих акторов, поскольку их вклады отфильтровываются валидаторами.
  • Gensyn: Если решатель захочет отравить обучаемую модель (например, внедрить бэкдор или предвзятость во время обучения), он может попытаться сделать это скрытно. Протокол Gensyn проверит, что обучение проходило в соответствии с указанным алгоритмом (шаги стохастического градиентного спуска и т. д.), но он не обязательно обнаружит, если решатель внедрил тонкий триггер бэкдора, который не проявляется в обычных метриках валидации. Это более коварная проблема — это не сбой вычислений, это манипуляция в рамках допустимых степеней свободы обучения (например, корректировка весов в сторону триггерной фразы). Обнаружение этого является активной исследовательской проблемой в области безопасности ML. Gensyn не имеет специального механизма для отравления моделей, помимо того факта, что отправитель может оценить конечную модель на выбранном им тестовом наборе. Опытный отправитель всегда должен тестировать возвращенную модель; если он обнаружит, что она не работает на некоторых входных данных или имеет странное поведение, он может оспорить результат или отказаться от оплаты. Возможно, протокол мог бы позволить отправителю указать определенные критерии приемлемости (например, «модель должна достичь как минимум X точности на этом секретном тестовом наборе»), и если результат решателя не соответствует, решатель не получает полную оплату. Это предотвратило бы отравление, потому что злоумышленник не соответствовал бы критериям оценки. Однако, если отравление не влияет на точность при обычных тестах, оно может проскользнуть. Верификаторы в Gensyn проверяют только целостность вычислений, а не качество модели, поэтому они не поймают преднамеренное переобучение или трояны, пока журналы обучения выглядят действительными. Таким образом, это остается проблемой доверия на уровне задачи: отправитель должен доверять либо тому, что решатель не отравит модель, либо использовать методы, такие как ансамблирование нескольких результатов обучения от разных решателей, чтобы ослабить влияние любого отдельного решателя. Другой аспект — отравление данных: если отправитель предоставляет обучающие данные, злонамеренный решатель может игнорировать эти данные и обучать на чем-то другом или добавлять мусорные данные. Но это, вероятно, снизит точность, что отправитель заметит в производительности выходной модели. Тогда решатель не получит полную оплату (поскольку предположительно он хочет достичь целевого показателя производительности). Таким образом, отравление, которое ухудшает производительность, само по себе является проигрышным для вознаграждения решателя. Только отравление, которое нейтрально по производительности, но злонамеренно (бэкдор), представляет реальную опасность, и это выходит за рамки типичной блокчейн-верификации — это проблема безопасности машинного обучения. Лучшее смягчение Gensyn, вероятно, социальное: использовать известные авторитетные модели, проводить несколько циклов обучения, использовать инструменты с открытым исходным кодом. Что касается задач вывода (если Gensyn также используется для задач вывода), сговорившийся решатель может возвращать неверные выходы, которые искажают определенный ответ. Но верификаторы поймают неверные выходы, если они запускают ту же модель, так что это меньше отравление и больше просто мошенничество, которое решается доказательствами мошенничества. В итоге, Gensyn обеспечивает безопасность процесса, а не намерения. Он гарантирует, что обучение/вывод были выполнены правильно, но не то, что результат хороший или свободен от скрытых неприятностей. Это остается открытой проблемой, и вайтпейпер Gensyn, вероятно, еще не полностью решает ее (немногие это делают).
  • Cuckoo: Поскольку Cuckoo в настоящее время фокусируется на выводе (обслуживании существующих моделей), риск отравления данных/моделей относительно ограничен манипуляцией выводами или отравлением контента. Злонамеренный майнер может попытаться подделать модель, которую ему дали для запуска — например, если ему предоставили контрольную точку Stable Diffusion, он мог бы заменить ее другой моделью, которая, возможно, вставляет какой-то тонкий водяной знак или рекламу в каждое изображение. Однако координатор (который является владельцем модели) обычно отправляет задачи с ожиданием формата вывода; если майнер постоянно возвращает нестандартные выводы, координатор пометит и заблокирует этого майнера. Кроме того, майнеры не могут легко модифицировать модель, не влияя заметно на ее выводы. Другой сценарий — если Cuckoo введет модели, обученные сообществом: тогда майнеры или поставщики данных могут попытаться отравить обучающие данные (например, ввести много неправильных меток или предвзятого текста). Cuckoo потребуется реализовать валидацию краудсорсинговых данных или взвешивание вкладчиков. Это пока не является функцией, но интерес команды к персонализированному ИИ (например, их упоминание об ИИ-коуче или обучающих приложениях) означает, что они могут в конечном итоге обрабатывать пользовательские обучающие данные, что потребует тщательных проверок. Что касается безопасности контента, поскольку майнеры Cuckoo выполняют вывод, можно беспокоиться о том, что они выдают вредоносный контент, даже если модель обычно этого не делает. Но майнеры не заинтересованы в произвольном изменении выходов — им платят за правильные вычисления, а не за творчество. Во всяком случае, злонамеренный майнер может пропустить полное вычисление, чтобы сэкономить время (например, вернуть размытое изображение или общий ответ). Координатор или пользователь увидят это и понизят рейтинг этого майнера (и, вероятно, не заплатят за эту задачу). Конфиденциальность — еще один аспект: злонамеренный майнер может утечь или записать пользовательские данные (например, если пользователь ввел конфиденциальный текст или изображения). Это не отравление, но это атака на конфиденциальность. Позиция Cuckoo в отношении конфиденциальности заключается в том, что она исследует методы сохранения конфиденциальности (упоминание VPN, сохраняющего конфиденциальность в экосистеме, предполагает будущий фокус). Они могли бы включить такие методы, как защищенные анклавы или разделенный вывод, чтобы сохранить данные конфиденциальными от майнеров. Пока не реализовано, но является известным соображением. Наконец, блог Cuckoo подчеркивает эффективную проверку выходов моделей и обеспечение безопасной децентрализованной работы моделей как ключ к жизнеспособности токенизации моделей. Это указывает на то, что они осознают, что для истинной децентрализации ИИ необходимо защищаться от таких вещей, как отравленные выходы или неисправные модели. Возможно, они намерены использовать комбинацию криптоэкономических стимулов (сокращение стейка для плохих акторов) и систем пользовательских рейтингов (пользователи могут помечать плохие выходы, и эти майнеры теряют репутацию). Система репутации может помочь здесь: если майнер возвращает даже один очевидно вредоносный или неверный результат, пользователи/координаторы могут понизить его рейтинг, что сильно повлияет на его будущую способность зарабатывать. Зная это, майнеры заинтересованы в том, чтобы быть последовательно правильными и не допускать никакого отравления. По сути, Cuckoo полагается на «доверяй, но проверяй»: это более традиционно в том смысле, что если кто-то ведет себя неправильно, вы его идентифицируете и удаляете (с потерей стейка в качестве наказания). У него пока нет специализированных защит от тонкого отравления моделей, но структура, предусматривающая конкретных владельцев приложений (координаторов), добавляет уровень надзора — эти владельцы будут мотивированы обеспечить, чтобы ничто не скомпрометировало целостность их модели, поскольку их собственный доход и репутация зависят от этого.

В заключение, хотя децентрализованные ИИ-сети вводят новые поверхности атаки, они также развертывают комбинацию криптографических, игровых и общественно-управленческих защит: Устойчивость к атакам Сивиллы в основном обеспечивается требованием экономического стейка для участия. Устойчивость к сговору достигается за счет согласования стимулов (честное поведение более выгодно) и механизмов консенсуса, которые ограничивают влияние небольших сговорившихся групп. Предотвращение фрирайдерства достигается путем тесной привязки вознаграждений к фактической полезной работе и наказания или устранения тех, кто ничего не вносит. Отравление и связанные с ним атаки остаются сложными, но системы смягчают явные случаи посредством непрерывной оценки и возможности сокращения или исключения злонамеренных акторов. Эти платформы активно исследуют и совершенствуют эти дизайны — о чем свидетельствуют постоянные доработки Yuma и dTAO в Bittensor, а также изменение токеномики в Cuckoo — для обеспечения безопасной, самоподдерживающейся децентрализованной ИИ-экосистемы.

Сравнительная оценка​

Чтобы выделить различия и сходства Bittensor, Gensyn и Cuckoo AI, следующая таблица предоставляет параллельное сравнение по ключевым параметрам:

Максимально извлекаемая ценность (MEV) относится к прибыли, которую «инсайдер» блокчейна (майнер/валидатор или другой привилегированный участник) может получить, произвольно переупорядочивая, включая или исключая транзакции в блоке. Неконтролируемое извлечение MEV может привести к несправедливому порядку транзакций, высоким комиссиям (из-за аукционов приоритетного газа) и централизации власти в производстве блоков. Появился ряд протоколов для подавления вредоносного MEV или обеспечения справедливого порядка транзакций. В этом отчете сравниваются четыре выдающихся подхода: Flashbots v2 (система Flashbots MEV-Boost после слияния для Ethereum), SUAVE (предстоящий Single Unifying Auction for Value Expression от Flashbots), Anoma (интент-ориентированная архитектура, переосмысливающая сопоставление и упорядочивание транзакций) и Skip Protocol (инструментарий на базе Cosmos для суверенного внутрипротокольного управления MEV). Мы рассмотрим каждый из них с точки зрения их алгоритмов очереди/упорядочивания транзакций, механизмов смягчения или извлечения MEV, моделей стимулирования, функций соответствия и нейтральности, технической архитектуры (консенсус и криптография) и прогресса разработки. Предоставлены структурированные сводки и сравнительная таблица, чтобы выделить их сильные стороны и компромиссы в достижении справедливости и уменьшении негативных внешних эффектов MEV.

Flashbots v2 (MEV-Boost и BuilderNet на Ethereum)​

Flashbots v2 обозначает текущую экосистему Flashbots на Ethereum после перехода на Proof-of-Stake, сосредоточенную вокруг MEV-Boost и недавних инициатив, таких как BuilderNet. Flashbots v2 основывается на парадигме разделения предлагающего/билдера (PBS), чтобы открыть создание блоков для конкурентного рынка билдеров, одновременно защищая пользователей Ethereum от атак MEV в публичном мемпуле.

• Порядок транзакций (очередь и алгоритм): Flashbots MEV-Boost представляет офчейн-рынок для создания блоков. Валидаторы (пропозеры) передают создание блоков специализированным билдерам через ретранслятор, вместо того чтобы упорядочивать транзакции локально. Множество билдеров соревнуются за предоставление самого высокооплачиваемого блока, и валидатор вслепую подписывает заголовок блока с наивысшей ставкой (подход PBS). Этот дизайн эффективно заменяет порядок «первым пришел — первым обслужен» публичного мемпула на аукцион с закрытыми ставками для целых блоков. Билдеры определяют порядок транзакций внутри, чтобы максимизировать общие выплаты (включая возможности MEV), обычно предпочитая бандлы с прибыльными арбитражами или ликвидациями в начале блока. Используя MEV-Boost, Ethereum избежал хаотичных аукционов приоритетного газа (PGA), которые ранее определяли порядок; вместо того чтобы пользователи и боты делали ставки через комиссии за газ в реальном времени (увеличивая перегрузку), MEV-Boost централизует упорядочивание для каждого блока наиболее конкурентоспособному билдеру. Таким образом, очереди транзакций приватно управляются билдерами, которые могут видеть входящие бандлы или транзакции и располагать их для оптимальной прибыли. Одним из недостатков является то, что этот ориентированный на прибыль порядок не обеспечивает «справедливости» для пользователей — например, билдеры все еще могут включать токсичные потоки ордеров, такие как сэндвич-атаки, если это прибыльно — но он оптимизирует эффективность, извлекая MEV через контролируемый аукцион, а не через специальные газовые войны. Недавние разработки были направлены на то, чтобы сделать упорядочивание более нейтральным: например, новый BuilderNet от Flashbots (запущенный в конце 2024 года) позволяет нескольким сотрудничающим билдерам совместно использовать поток ордеров и совместно строить блоки в доверенной среде выполнения (Trusted Execution Environment), вводя проверяемые правила упорядочивания для повышения справедливости. Это перемещает упорядочивание блоков от одного централизованного билдера к децентрализованной сети создания блоков с правилами, которые могут быть проверены на нейтральность.

• Механизмы подавления против извлечения MEV: Flashbots v2 в основном способствует извлечению MEV в более мягкой форме, а не его устранению. Оригинальная система Flashbots (v1) в 2021 году позволяла поисковикам отправлять бандлы (предпочтительные наборы транзакций) непосредственно майнерам, что подавляло вредные внешние эффекты (отсутствие публичного фронтраннинга, отсутствие неудачных транзакций из-за гонки), при этом извлекая MEV. В эпоху MEV-Boost MEV извлекается билдерами, объединяющими прибыльные транзакции, но конкуренция с нулевой суммой уменьшается: поисковики больше не спамят мемпул конкурирующими транзакциями и непомерными комиссиями за газ, что смягчает перегрузку сети и чрезмерные комиссии для пользователей. Flashbots v2 также предоставляет инструменты смягчения MEV для пользователей: например, Flashbots Protect RPC позволяет пользователям отправлять транзакции приватно на ретранслятор, предотвращая публичный мемпул-фронтраннинг (никто не может видеть или переупорядочивать транзакцию до включения). Другая инициатива, MEV-Share, позволяет пользователям делиться лишь достаточной информацией о своих транзакциях, чтобы привлечь ставки MEV, при этом захватывая часть ценности для себя. Однако Flashbots v2 не «предотвращает» MEV, такие как сэндвичи или арбитраж — он направляет эти действия через эффективный аукцион, который, возможно, демократизирует, кто может извлекать MEV. Недавно дизайн BuilderNet имел явную цель «нейтрализации игр с потоком ордеров с отрицательной суммой» и возврата MEV сообществу через ончейн правила возврата. BuilderNet рассчитывает возмещения, выплачиваемые поставщикам потока ордеров транзакций (таким как кошельки или DApp), пропорционально MEV, который сгенерировали их транзакции, перераспределяя ценность, которая в противном случае была бы чистой прибылью для билдеров. В итоге, Flashbots v2 максимизирует эффективность извлечения MEV (обеспечивая захват почти всей извлекаемой ценности в блоке), одновременно вводя меры по пресечению наихудших внешних эффектов и возврату части ценности пользователям. Он не доходит до обеспечения справедливого порядка (транзакции по-прежнему упорядочиваются по прибыли билдера), но через приватную отправку, многостороннее создание и возмещения он подавляет негативный вред для пользователей (такой как проскальзывание от фронтраннинга и эффекты цензуры) насколько это возможно в рамках аукционной модели.

• Экономическая структура стимулирования: Flashbots v2 выравнивает стимулы между валидаторами, билдерами и поисковиками через аукцион PBS. Валидаторы выигрывают, передавая производство блоков на аутсорсинг — они просто принимают самую высокую ставку и получают сумму ставки (в дополнение к консенсусным вознаграждениям), что резко увеличило долю MEV, идущую валидаторам, по сравнению с эпохой, когда майнеры не имели таких аукционов. Билдеры стимулируются к конкуренции друг с другом, находя наиболее прибыльный порядок транзакций (часто включая стратегии поисковиков), и они сохраняют любую прибыль от MEV, оставшуюся после оплаты ставки валидатора. На практике конкуренция вынуждает билдеров платить большую часть MEV валидаторам (часто >90% прибыли), оставляя себе лишь небольшую маржу. Поисковики (теперь взаимодействующие с билдерами через бандлы или прямые транзакции) по-прежнему зарабатывают, находя возможности MEV (арбитраж, ликвидация и т. д.), но они должны отдать большую часть своей прибыли, чтобы выиграть включение — фактически, прибыль поисковиков передается валидаторам через ставки билдеров. Это конкурентное равновесие максимизирует общий доход сети (выгодно валидаторам/стейкерам), но сжимает индивидуальные маржи поисковиков. Таким образом, Flashbots v2 препятствует эксклюзивным сделкам: любой поисковик или билдер с частной стратегией MEV стимулируется к тому, чтобы выставить ее через открытый ретранслятор, чтобы избежать подрыва, что приводит к более открытому рынку. Введение BuilderNet добавляет стимул для источников потока ордеров (таких как DEX или кошельки) — предоставляя им возмещения за MEV, создаваемый их транзакциями, это побуждает пользователей и приложения отправлять поток ордеров в экосистему BuilderNet. Этот механизм выравнивает пользователей с системой: вместо того чтобы быть противниками (пользователи против извлекателей MEV), пользователи делятся MEV, поэтому они более охотно участвуют в аукционе справедливо. В целом, экономика Flashbots v2 способствует сотрудничеству, а не конкуренции в создании блоков: валидаторы получают максимальный доход без риска, билдеры конкурируют по качеству исполнения, а поисковики внедряют инновации для поиска MEV, но отказываются от большей части прибыли, чтобы выиграть ставки, в то время как пользователи получают защиту и, возможно, скидки.

• Соответствие и устойчивость к цензуре: Регуляторное соответствие стало спорным вопросом для Flashbots после слияния Ethereum. Ретранслятор Flashbots по умолчанию изначально реализовал соответствие санкциям OFAC (цензурируя определенные транзакции, такие как Tornado Cash) — что привело к тому, что примерно 80% блоков Ethereum в конце 2022 года были «OFAC-совместимыми» и вызвало опасения сообщества по поводу централизации/цензуры. Flashbots v2 решил эту проблему, создав экосистему с несколькими ретрансляторами, где валидаторы могут выбирать нецензурирующие ретрансляторы (например, UltraSound, Agnostic) или даже запускать свои собственные. Flashbots открыл исходный код своего ретранслятора в середине 2022 года, чтобы стимулировать глобальную конкуренцию и прозрачность ретрансляторов. Кроме того, MEV-Boost v1.4 представил такие функции, как установка минимальной ставки, чтобы пропозеры могли отклонять низкие ставки от цензурирующих билдеров и возвращаться к локальным блокам, обменивая часть прибыли на включение всех транзакций. Эта функция явно дала валидаторам способ улучшить устойчивость Ethereum к цензуре с небольшими затратами. К концу 2024 года Flashbots сделал еще один шаг, отказавшись от своего централизованного билдера в пользу BuilderNet — совместной сети, призванной быть «нецензурируемой и нейтральной». BuilderNet использует TEE (Intel SGX) для сохранения зашифрованного потока ордеров транзакций и проверяемо фиксирует правило упорядочивания, что может помочь предотвратить цензуру отдельных транзакций отдельными билдерами. При совместном создании блоков несколькими участниками внутри безопасных анклавов ни одна сторона не может легко исключить транзакцию без обнаружения. Короче говоря, Flashbots v2 эволюционировал от одного (и изначально цензурирующего) ретранслятора к более децентрализованной инфраструктуре с открытым участием и явными целями нейтральности. Соответствие оставлено на усмотрение отдельных ретрансляторов/билдеров (и валидаторы могут выбирать), а не навязывается протоколом. Траектория направлена на достоверную нейтральность: устранение любых контролируемых Flashbots узких мест, которые могли бы подвергаться давлению со стороны регуляторов. Flashbots публично заявили о своем намерении отказаться от роли центрального оператора и децентрализовать все аспекты цепочки поставок MEV в долгосрочной перспективе.

• Техническая архитектура и криптография: Flashbots v2 работает гибридно: офчейн и внутрипротокольно. Основной аукцион (MEV-Boost) происходит офчейн через сеть билдеров и ретрансляторов, но он напрямую подключается к консенсусу Ethereum: валидаторы запускают сайдкар-клиент (mev-boost), который взаимодействует с ретрансляторами с использованием стандартизированного Builder API. С точки зрения консенсуса, Ethereum по-прежнему использует стандартный PoS (Casper/Hotstuff) — MEV-Boost не изменяет правила консенсуса L1; он только меняет того, кто собирает блок. Изначально аукцион Flashbots требовал доверия к ретранслятору и билдеру, чтобы они не крали транзакции и не цензурировали — не было криптографических гарантий (система полагалась на экономический стимул, что билдеры должны предоставить действительную полезную нагрузку, соответствующую их ставке, иначе они теряют слот). Со временем Flashbots v2 интегрировал больше технологий безопасности. Введение Доверенных сред выполнения (TEE) через BuilderNet является заметным архитектурным сдвигом: билдеры работают внутри анклавов SGX, так что даже оператор билдера не может видеть необработанный поток ордеров транзакций (предотвращая их утечку или фронтраннинг). Эти анклавы совместно следуют протоколу для производства блоков, что может обеспечить проверяемую справедливость (например, доказывая, что транзакции были упорядочены по установленному правилу или что никакая несанкционированная сущность не видела их до включения). Хотя используется SGX (аппаратный подход), исследования Flashbots также изучают чистые криптографические примитивы — например, пороговое шифрование для конфиденциальности мемпула и безопасные многосторонние вычисления — чтобы в конечном итоге заменить или дополнить TEE и еще больше снизить доверие. Программный стек Flashbots v2 включает пользовательские клиенты, такие как MEV-geth (теперь устаревший) и билдеры на Rust (например, rbuilder), и он соответствует спецификациям билдеров Ethereum для обеспечения совместимости. В итоге, архитектура модульная: сеть ретрансляторов, билдеров, а теперь и анклавов, расположенная между пользователями и пропозерами Ethereum. Она приоритезирует производительность (быстрые ставки, доставка блоков) и постепенно добавляет криптографические гарантии конфиденциальности и справедливого порядка. Новый алгоритм консенсуса не вводится; вместо этого Flashbots v2 работает наряду с консенсусом Ethereum, развивая конвейер производства блоков, а не правила консенсуса.

• Дорожная карта разработки и вехи: Flashbots прошел через итерационные фазы. Flashbots v1 (2020–2021) включал запуск MEV-geth и первые офчейн-аукционы бандлов с майнерами. К середине 2021 года более 80% хешрейта Ethereum работало на MEV-geth от Flashbots, что подтвердило принятие подхода. Flashbots v2 (2022) был задуман до слияния: в ноябре 2021 года Flashbots опубликовал архитектуру MEV-Boost для PoS Ethereum. После перехода Ethereum на PoS (15 сентября 2022 года) MEV-Boost был активирован в течение нескольких дней и быстро достиг большинства валидаторов. Последующие вехи включали открытие исходного кода ретранслятора (август 2022 года) и внутреннего билдера блоков Flashbots (ноябрь 2022 года) для стимулирования конкуренции. В конце 2022 года Flashbots также добавил функции, ориентированные на устойчивость к цензуре и отказоустойчивость (например, min-bid для пропозеров) и написал о «Стоимости устойчивости», чтобы побудить валидаторов иногда предпочитать включение прибыли. В течение 2023 года улучшение децентрализации билдеров стало ключевым направлением: Flashbots выпустил «rbuilder» (высокопроизводительный билдер на Rust) в июле 2024 года в качестве эталонной реализации, чтобы снизить барьер для новых билдеров. Наконец, в конце 2024 года Flashbots запустил BuilderNet (альфа-версия) в сотрудничестве с партнерами (Beaverbuild, Nethermind). К декабрю 2024 года Flashbots закрыл свой централизованный билдер и перевел весь поток ордеров на BuilderNet — значительный шаг к децентрализации. В начале 2025 года BuilderNet v1.2 был выпущен с улучшениями безопасности и онбординга (включая воспроизводимые сборки анклавов). Эти вехи знаменуют переход Flashbots от целесообразного централизованного решения к более открытому, управляемому сообществом протоколу. В будущем Flashbots сближается со своим видением следующего поколения (SUAVE), чтобы полностью децентрализовать уровень создания блоков и включить передовые технологии конфиденциальности. Многие уроки из Flashbots v2 (например, необходимость нейтральности, многоцепочечный охват и включение пользователей в вознаграждения MEV) напрямую влияют на дорожную карту SUAVE.

SUAVE (Single Unifying Auction for Value Expression от Flashbots)​

SUAVE — это амбициозный протокол следующего шага от Flashbots, разработанный как децентрализованный, кросс-доменный рынок MEV и уровень справедливой последовательности транзакций. Он нацелен на отделение мемпулов и создания блоков от отдельных блокчейнов и предоставление унифицированной платформы, где пользователи выражают предпочтения, децентрализованная сеть оптимально выполняет транзакции, а билдеры блоков производят блоки по многим цепочкам достоверно нейтральным образом. Короче говоря, SUAVE стремится максимизировать общее извлечение ценности, одновременно возвращая ценность пользователям и сохраняя децентрализацию блокчейна. Flashbots представил SUAVE в конце 2022 года как «будущее MEV» и с тех пор разрабатывает его открыто.

• Очередь и порядок транзакций: На высоком уровне SUAVE функционирует как независимая блокчейн-сеть, которую другие цепочки могут использовать в качестве готового мемпула и билдера блоков. Вместо того чтобы транзакции ставились в очередь в мемпуле каждой цепочки и упорядочивались локальными майнерами или валидаторами, пользователи могут отправлять свои транзакции (или, в более общем смысле, предпочтения) в мемпул сети SUAVE. Мемпул SUAVE затем служит глобальным аукционным пулом предпочтений от всех участвующих цепочек. Порядок транзакций определяется через этот аукцион и последующую оптимизацию выполнения. В частности, SUAVE вводит концепцию предпочтений: отправка пользователя — это не просто необработанная транзакция для одной цепочки, но может кодировать цель или условную сделку (возможно, охватывающую несколько цепочек) и связанную ставку, которую пользователь готов заплатить за выполнение. Алгоритм упорядочивания/очереди в SUAVE имеет несколько этапов: Во-первых, пользователи публикуют свои предпочтения в мемпуле SUAVE («Универсальная среда предпочтений»), который агрегирует все ордера приватно и глобально. Далее, специализированные узлы, называемые исполнителями (аналогично поисковикам/решателям), отслеживают этот мемпул и конкурируют на Рынке оптимального выполнения, чтобы выполнить эти предпочтения. Они эффективно «ставят в очередь» транзакции, находя совпадения или оптимальный порядок выполнения для них. Наконец, SUAVE производит выходы блоков для каждой подключенной цепочки через уровень Децентрализованного создания блоков: многие билдеры (или исполнители SUAVE, действующие как билдеры) сотрудничают для создания блоков, используя (теперь оптимизированный) порядок транзакций, полученный из предпочтений пользователя. На практике порядок SUAVE гибкий и ориентированный на пользователя: пользователь может указать условия, такие как «выполнить мою сделку только если цена < X» или даже выразить абстрактное намерение («обменять токен A на B по лучшей ставке в течение 1 минуты») вместо строгой транзакции. Система ставит эти намерения в очередь, пока исполнитель не найдет оптимальный порядок или совпадение (возможно, объединяя их с другими). Поскольку SUAVE не зависит от блокчейна, он может координировать упорядочивание между цепочками (предотвращая сценарии, когда кросс-цепочечные арбитражи упускаются из-за нескоординированных отдельных мемпулов). По сути, SUAVE реализует глобальный аукцион MEV: все участники используют один уровень секвенирования, который упорядочивает транзакции на основе агрегированных предпочтений и ставок, а не просто времени или цены на газ. Это выравнивает игровое поле — весь поток ордеров проходит через одну прозрачную очередь (хотя и зашифрованную для конфиденциальности, как обсуждается ниже) вместо эксклюзивных сделок или частных мемпулов. Алгоритм упорядочивания SUAVE все еще дорабатывается, но он, вероятно, будет включать аукционы с сохранением конфиденциальности и алгоритмы сопоставления, чтобы можно было достичь «справедливых» результатов (таких как максимальный общий излишек или оптимальные для пользователя цены), а не чистого «первым пришел — первым обслужен». Примечательно, что SUAVE намерен предотвратить манипулирование порядком любым отдельным участником: он является нативным для Ethereum и осведомлен о MEV, с мемпулом, ориентированным на конфиденциальность и зашифрованным, который защищает от любых центральных точек контроля. В итоге, очередь SUAVE — это единый пул потока ордеров, где порядок определяется комбинацией ставок пользователей, стратегии исполнителя и (в конечном итоге) криптографических ограничений справедливости, а не пропозерами блоков, соревнующимися за приоритет.

• Механизмы подавления/извлечения MEV: Философия SUAVE заключается в том, что MEV может быть использован на благо пользователей и для безопасности сети, если это делается совместным, децентрализованным образом. Вместо того чтобы игнорировать MEV или позволять ему концентрироваться в нескольких руках, SUAVE явно выявляет возможности MEV и возвращает ценность тем, кто ее создает (пользователям), насколько это возможно. Основной механизм — это аукцион потока ордеров: всякий раз, когда транзакция пользователя (предпочтение) имеет MEV — например, она может быть бэктраннута для получения прибыли — SUAVE проведет аукцион среди исполнителей (поисковиков) за право выполнить эту возможность MEV. Поисковики (исполнители) делают ставки, обещая вернуть часть прибыли пользователю в качестве платежа (это поле «ставка» пользователя в его предпочтении, которое достается тому, кто его выполнит). Результатом является конкурентное извлечение MEV, которое направляет доход пользователю, а не извлекателю. Например, если крупная DEX-сделка пользователя создает арбитражную возможность на 100 долларов, поисковики на SUAVE могут снизить прибыль, предложив, скажем, 90 долларов обратно пользователю в качестве скидки, оставив себе только 10 долларов. Это подавляет негативные аспекты MEV, такие как извлечение ценности у пользователя, и превращает MEV в пользу для пользователя (пользователи фактически получают улучшение цены или скидки). Дизайн SUAVE также подавляет фронтраннинг и другие вредоносные MEV: транзакции в мемпуле SUAVE могут оставаться зашифрованными до момента создания блока (изначально с использованием анклавов SGX, с переходом к пороговой криптографии). Это означает, что никакой внешний участник не может видеть ожидающие транзакции, чтобы фронтраннить их; только когда достаточно транзакций собрано и блок финализирован, они расшифровываются и выполняются, что по духу похоже на пакетные аукционы или зашифрованные мемпулы, которые устраняют преимущество ботов по времени. Кроме того, поскольку исполнители оптимизируют выполнение по многим предпочтениям, SUAVE может устранить неэффективную конкуренцию (например, двух ботов, борющихся за один и тот же арбитраж путем спама). Вместо этого SUAVE выбирает лучшего исполнителя через аукцион, и этот исполнитель выполняет сделку один раз, при этом результат приносит пользу пользователю и сети. Таким образом, SUAVE действует как агрегатор MEV и «добрая фея»: он не устраняет MEV (прибыльные возможности по-прежнему используются), но эти возможности реализуются в соответствии с прозрачными правилами, а доходы в основном распределяются между пользователями и валидаторами (и не тратятся на комиссии за газ или войны за задержку). Объединяя мемпулы, SUAVE также решает проблему кросс-доменного MEV удобным для пользователя способом — например, арбитраж между Uniswap на Ethereum и DEX на Arbitrum может быть захвачен исполнителем SUAVE, а часть выплачена пользователям с обеих сторон, вместо того чтобы быть упущенным или требовать централизованного арбитражера. Важно отметить, что SUAVE подавляет централизующие силы MEV: эксклюзивные сделки с потоком ордеров (где частные лица захватывают MEV) становятся ненужными, если все используют общий аукцион. Конечная цель SUAVE — уменьшить вредоносное извлечение MEV (такое как сэндвич-атаки, вызывающие проскальзывание), либо сделав их невыгодными, либо возместив проскальзывание, и использовать «хороший MEV» (арбитраж, ликвидации) для укрепления сетей (через распределение доходов и оптимальное выполнение). По словам Flashbots, цель SUAVE — обеспечить «пользователям наилучшее выполнение транзакций с минимальными комиссиями», а «валидаторам — максимальный доход» — то есть, любой присутствующий MEV извлекается наиболее выгодным для пользователя способом.

• Экономическая структура стимулирования: SUAVE вводит новые роли и потоки стимулов в цепочке поставок MEV. Основными участниками являются пользователи, исполнители, билдеры/валидаторы блоков и операторы сети SUAVE (валидаторы цепочки SUAVE). Пользователи устанавливают ставку (платеж) в своем предпочтении, которая будет выплачена, если их условия будут выполнены. Эта ставка является приманкой для исполнителей: исполнитель, который выполняет намерение пользователя (например, бэктраннит его сделку, чтобы получить лучшую цену), может заявить ставку в качестве вознаграждения. Таким образом, пользователи напрямую платят за качество выполнения, подобно объявлению награды. Исполнители (поисковики) мотивированы брать предпочтения пользователей из мемпула SUAVE и оптимизировать их, потому что они зарабатывают ставку пользователя плюс любую дополнительную арбитражную прибыль, присущую транзакции. Исполнители будут конкурировать, чтобы предложить пользователю лучший результат, потому что пользователь может установить свою ставку таким образом, что он платит только в том случае, если исполнитель действительно достигает желаемого результата (ставка может быть условной в зависимости от ончейн-результатов через оракулы). Например, пользователь может сказать: «Я заплачу 0,5 ETH тому, кто выполнит эту транзакцию так, чтобы я получил как минимум X выход; если нет, то без оплаты». Это выравнивает стимулы исполнителя с успехом пользователя. Валидаторы/билдеры SUAVE: Сама цепочка SUAVE, вероятно, будет сетью Proof-of-Stake (дизайн еще не определен), поэтому валидаторы (которые производят блоки на SUAVE) зарабатывают комиссии за транзакции на SUAVE (которые поступают от пользователей, размещающих ставки, и других операций). Поскольку SUAVE является EVM-совместимой цепочкой, может также существовать нативный токен или система комиссий за газ для этих транзакций. Эти валидаторы также играют роль в секвенировании кросс-доменных блоков; однако окончательное включение блока в каждый L1 по-прежнему осуществляется валидатором этого L1. Во многих случаях SUAVE будет производить частичный или полный шаблон блока, который может принять пропозер Ethereum или другой цепочки. Этот билдер может заплатить SUAVE (или исполнителям SUAVE) некоторую часть MEV. Flashbots упомянул, что валидаторы SUAVE стимулируются обычными сетевыми комиссиями, в то время как исполнители стимулируются ставками. Распределение ценности: Подход SUAVE имеет тенденцию передавать ценность на периферию: пользователи получают ценность (через лучшие цены или прямые возмещения), а валидаторы получают ценность (через увеличенные комиссии/ставки). Теоретически, если SUAVE выполнит свою миссию, большая часть MEV будет либо возвращена пользователям, либо использована для компенсации валидаторам за обеспечение безопасности сети, а не сконцентрирована у поисковиков. Сам Flashbots указал, что не планирует заниматься рентоискательством от SUAVE и не будет брать долю сверх того, что необходимо для запуска — они хотят разработать рынок, а не монополизировать его. Еще одно соображение по стимулированию — это кросс-цепочечные билдеры: SUAVE позволяет билдерам блоков получать доступ к кросс-доменному MEV, что означает, что билдер в одной цепочке может зарабатывать дополнительные комиссии, включая транзакции, которые завершают арбитраж с другой цепочкой. Это побуждает билдеров/валидаторов разных цепочек участвовать в SUAVE, потому что отказ означает упущенный доход. По сути, экономический дизайн SUAVE пытается выровнять всех участников для присоединения к общему аукциону: пользователей, потому что они получают лучшее выполнение (и, возможно, скидки MEV), валидаторов, потому что они получают максимальный доход, и поисковиков, потому что там агрегируется поток ордеров. Концентрируя поток ордеров, SUAVE также получает информационное преимущество над любым изолированным участником (все предпочтения в одном месте), что экономически вынуждает всех сотрудничать в рамках SUAVE, а не отделяться. В итоге, стимулы SUAVE способствуют добродетельному циклу: больше потока ордеров → лучшие комбинированные возможности MEV → более высокие ставки для пользователей/валидаторов → больше потока ордеров. Это контрастирует с конкуренцией с нулевой суммой и эксклюзивными сделками прошлого, стремясь вместо этого к «кооперации», где MEV является общей ценностью для роста и распределения.

• Соответствие и регуляторные соображения: SUAVE строится с учетом достоверной нейтральности и устойчивости к цензуре как основных принципов. По своей конструкции SUAVE устраняет центральных посредников — нет единого мемпула или единого билдера для атаки или регулирования. Транзакции (предпочтения) в SUAVE могут быть полностью зашифрованы и приватны до их выполнения, используя безопасные анклавы и, в конечном итоге, криптографические методы. Это означает, что цензура на уровне содержимого транзакций непрактична, поскольку валидаторы/билдеры даже не могут прочитать детали транзакции до финализации ордера. SUAVE по сути навязывает подход «не доверяй, проверяй»: участникам не нужно доверять одной сущности, что она не будет цензурировать, потому что сама архитектура системы (децентрализованная сеть + шифрование) обеспечивает справедливое включение предпочтений каждого. Более того, SUAVE предназначен быть открытой, безразрешительной сетью — Flashbots явно приглашает все стороны (пользователей, поисковиков, кошельки, другие блокчейны) к участию. В его дизайне нет KYC или разрешительного доступа. Это может вызвать вопросы у регуляторов (например, протокол может способствовать извлечению MEV из санкционированных транзакций), но поскольку SUAVE — это просто децентрализованная платформа, правоприменение будет затруднено и аналогично попытке регулировать мемпул блокчейна. Ориентация SUAVE на конфиденциальность (через SGX, а затем криптографию) также защищает пользовательские данные и поток ордеров от нежелательного мониторинга, что положительно для безопасности пользователей, но может конфликтовать с регуляторными требованиями к прозрачности. С другой стороны, подход SUAVE можно рассматривать как более справедливый и соответствующий духу открытых рынков: создавая равные условия и возвращая ценность пользователям, он уменьшает эксплуатационные аспекты MEV, которые могут вызвать гнев регуляторов (например, бэктраннинг пользователей без их согласия). SUAVE также может помочь устранить нерегулируемые темные пулы — одна из причин, по которой регуляторы могут беспокоиться о MEV, — это эксклюзивные продажи потока ордеров (которые напоминают инсайдерскую торговлю). SUAVE заменяет их прозрачным публичным аукционом, что, возможно, является более соответствующей рыночной структурой. Что касается явных функций соответствия, SUAVE может допускать множество политик упорядочивания: например, сообщества или юрисдикции могут развертывать своих собственных исполнителей с определенными фильтрами или предпочтениями. Однако базовый принцип заключается в том, что SUAVE будет стремиться быть максимально нейтральным: «устранить любые центральные точки контроля, включая Flashbots» и избегать встраивания каких-либо политических решений на уровне протокола. Flashbots подчеркнул, что он сам не будет контролировать рынок SUAVE по мере его созревания — это означает отсутствие центрального выключателя или переключателя цензуры. Управление (если таковое будет) SUAVE еще не определено публично, но можно ожидать, что оно будет включать более широкое сообщество и, возможно, токен, а не фиатную валюту компании. В итоге, SUAVE разработан в соответствии с децентрализованными принципами, что по своей природе сопротивляется определенному регуляторному контролю (цензуре), при этом потенциально снимая некоторые регуляторные опасения, делая извлечение MEV более справедливым и прозрачным.

• Техническая архитектура (консенсус и криптография): SUAVE будет работать в своей собственной блокчейн-среде — по крайней мере, на начальном этапе. Он описывается как EVM-совместимая цепочка, специализированная для предпочтений и MEV. Архитектура имеет три основных компонента: (1) Универсальная среда предпочтений (цепочка SUAVE + мемпул, где публикуются и агрегируются предпочтения), (2) Рынок выполнения (офчейн или ончейн-исполнители, которые решают/оптимизируют предпочтения, подобно децентрализованному «движку сопоставления ордеров») и (3) Децентрализованное создание блоков (сеть участников SUAVE, которые собирают блоки для различных доменов). По своей сути, консенсус SUAVE, вероятно, будет консенсусом Proof-of-Stake BFT (подобно Ethereum или Cosmos) для работы самой цепочки SUAVE — хотя еще решается, станет ли SUAVE L1, L2 Ethereum или набором контрактов «рестейкинга». Одна из возможностей заключается в том, что SUAVE может начать как уровень 2 или сайдчейн, который использует Ethereum для финализации, или использовать существующие наборы валидаторов. Модель безопасности еще не определена, но обсуждения включали превращение ее в Ethereum L3 или цепочку Cosmos. Криптографически SUAVE сильно опирается на доверенное оборудование и шифрование в своей ранней дорожной карте. Фаза SUAVE Centauri реализует «аукцион потока ордеров с учетом конфиденциальности», в котором Flashbots (централизованно) управляет анклавами SGX для сохранения конфиденциальности потока ордеров поисковиков и пользователей. В SUAVE Andromeda они планируют использовать аукционы и создание блоков на основе SGX без доверия к Flashbots (анклавы обеспечивают конфиденциальность, так что даже Flashbots не может заглянуть). К SUAVE Helios цель состоит в создании децентрализованной сети билдеров на основе SGX — что означает, что многие независимые стороны запускают анклавы, которые совместно строят блоки, достигая как конфиденциальности, так и децентрализации. В долгосрочной перспективе Flashbots исследует пользовательские безопасные анклавы и криптографические замены, такие как пороговое дешифрование и многосторонние вычисления, чтобы уменьшить зависимость от Intel SGX. Например, они могут использовать схему порогового шифрования, где валидаторы SUAVE совместно владеют ключом для дешифрования транзакций только после принятия решения об упорядочивании (обеспечивая, чтобы никто не мог фронтраннить). Эта концепция аналогична Ferveo от Anoma или другим идеям «справедливого упорядочивания через пороговое шифрование». Кроме того, SUAVE рассматривает предпочтения пользователей как смарт-контракты в своей цепочке. Предпочтение пользователя может содержать предикат валидности и условие оплаты — это, по сути, часть кода, которая говорит: «если на цепочке Y достигнут результат X, то заплатить исполнителю Z эту сумму». Цепочке SUAVE необходимо обрабатывать оракулы и кросс-цепочечную верификацию, чтобы знать, когда предпочтение было выполнено (например, считывать состояние Ethereum, чтобы увидеть, произошел ли обмен). Это подразумевает, что архитектура SUAVE будет включать ончейн-легкие клиенты или оракульные системы для подключенных цепочек, а также потенциально атомарное кросс-цепочечное урегулирование (чтобы гарантировать, например, что исполнитель может выполнить на Ethereum и Arbitrum и атомарно заявить ставку). SUAVE планирует быть очень расширяемым: поскольку он совместим с EVM, на нем могут работать произвольные контракты (SUAVE-нативные «предпочтения» или даже обычные DApp), хотя намерение состоит в том, чтобы сосредоточиться на координации потока ордеров. С точки зрения консенсуса, SUAVE может внедрять инновации, будучи интент-ориентированной цепочкой, а не транзакционно-ориентированной, но в конечном итоге он должен упорядочивать сообщения (предпочтения) и производить блоки, как любая цепочка. Можно представить, что SUAVE примет алгоритм консенсуса, оптимизированный для пропускной способности и низкой задержки финализации, поскольку он будет находиться на критическом пути транзакций для многих цепочек. Возможно, может быть использован консенсус в стиле Tendermint с мгновенной финализацией или даже консенсус на основе DAG для быстрого подтверждения предпочтений. В любом случае, отличительные особенности SUAVE находятся на уровне транзакций, а не на уровне консенсуса: использование технологий конфиденциальности (SGX, пороговое шифрование) для упорядочивания, кросс-доменной связи и логики интеллектуальной маршрутизации ордеров, встроенной в протокол. Это делает его своего рода «мета-уровнем» поверх существующих блокчейнов. Технически, каждая участвующая цепочка должна будет в некоторой степени доверять выходам SUAVE (например, пропозер Ethereum должен будет принять блок, построенный SUAVE, или включить предложения SUAVE). Flashbots указал, что SUAVE будет вводиться постепенно и по выбору — домены могут выбрать использование секвенирования SUAVE для своих блоков. В случае широкого распространения SUAVE может стать де-факто сетью маршрутизации транзакций с учетом MEV для Web3. Подводя итог, архитектура SUAVE — это сочетание блокчейна и офчейн-аукциона: специализированная цепочка для координации, объединенная с офчейн-безопасными вычислениями среди исполнителей, все это закреплено криптографическими гарантиями справедливости и конфиденциальности.

• Дорожная карта разработки и вехи: Flashbots изложил дорожную карту SUAVE в трех основных этапах, названных в честь звездных систем: Centauri, Andromeda и Helios. Centauri (первая фаза, разрабатываемая в 2023 году) сосредоточена на создании централизованного, но сохраняющего конфиденциальность аукциона потока ордеров. На этом этапе Flashbots запускает аукционный сервис (вероятно, в SGX), который позволяет поисковикам делать ставки на бэктраннинг пользовательских транзакций, приватно возвращая MEV пользователям. Он также включает запуск devnet SUAVE для раннего тестирования. Действительно, в августе 2023 года Flashbots открыл исходный код раннего клиента SUAVE (suave-geth) и запустил Toliman, первый публичный тестнет SUAVE. Этот тестнет использовался для экспериментов с выражением предпочтений и базовой логикой аукциона. Andromeda (следующая фаза) запустит первый основной блокчейн SUAVE. Здесь пользователи смогут выражать предпочтения в живой сети, и будет работать Рынок выполнения (исполнители, выполняющие намерения). Andromeda также вводит аукционы и создание блоков на основе SGX в более распределенном виде — устраняя необходимость доверять Flashbots как оператору и делая систему по-настоящему безразрешительной для поисковиков и билдеров. Одним из результатов на этом этапе является использование SGX для шифрования потока ордеров таким образом, что даже билдеры блоков не могут заглянуть, но все же могут строить блоки (то есть «открытый, но приватный» поток ордеров). Helios — это амбициозная третья фаза, когда SUAVE достигает полной децентрализации и кросс-цепочечной функциональности. В Helios децентрализованная сеть билдеров в SGX совместно производит блоки (без доминирования одного билдера). Также SUAVE «подключит второй домен» помимо Ethereum — это означает, что он будет обрабатывать MEV как минимум для двух цепочек, демонстрируя кросс-цепочечные аукционы MEV. Кроме того, будет включено выражение и выполнение кросс-доменного MEV (пользователи смогут публиковать по-настоящему многоцепочечные намерения и выполнять их атомарно). После Helios Flashbots предполагает исследование пользовательского оборудования и передовой криптографии (такой как zk-доказательства или MPC) для дальнейшего усиления гарантий доверия. Ключевые обновления и вехи на данный момент: Ноябрь 2022 года — анонс SUAVE; Август 2023 года — первый выпуск кода SUAVE и тестнет (Toliman); продолжается 2024 год — работает аукцион потока ордеров фазы Centauri (Flashbots намекнул, что это тестируется с пользовательскими транзакциями в закрытой среде). Заметной вехой будет запуск основного блокчейна SUAVE (Andromeda), который, по состоянию на середину 2025 года, находится на горизонте. Flashbots обязался строить SUAVE открыто и приглашать к сотрудничеству всю экосистему. Это отражено в исследованиях и обсуждениях на форумах, таких как серия постов «Stargazing», которые обновляют информацию об эволюции дизайна SUAVE. Конечная цель SUAVE заключается в том, чтобы он стал общедоступной инфраструктурой — «децентрализованным уровнем секвенирования» для всей криптоиндустрии. Достижение этого станет важной вехой в борьбе за справедливое упорядочивание: если SUAVE преуспеет, MEV перестанет быть темным лесом, а станет прозрачным, общим источником ценности, и ни одна цепочка не будет страдать от централизующих эффектов MEV в одиночку.

Anoma (Интент-ориентированная архитектура для справедливого поиска контрагентов)​

Anoma — это радикально иной подход к обеспечению справедливого порядка и смягчению MEV — это целая архитектура для интент-ориентированной блокчейн-инфраструктуры. Вместо того чтобы прикреплять аукцион к существующим цепочкам, Anoma переосмысливает парадигму транзакций с нуля. В Anoma пользователи не транслируют конкретные транзакции; они транслируют интенты — декларации желаемого конечного состояния — и сама сеть находит контрагентов и формирует транзакции, которые выполняют эти интенты. Интегрируя поиск контрагентов, справедливый порядок и конфиденциальность на уровне протокола, Anoma стремится практически исключить определенные формы MEV (например, фронтраннинг) и обеспечить «безфронтраннинговый» децентрализованный обмен и расчет. Anoma — это скорее фреймворк, чем одна цепочка: любой блокчейн может быть «фрактальным экземпляром» Anoma, приняв его архитектуру обмена интентами и сопоставления. В этом обсуждении мы сосредоточимся на первой реализации Anoma (иногда называемой Anoma L1) и ее основных протокольных функциях, поскольку они связаны со справедливостью и MEV.

• Очередь и порядок транзакций: Anoma отказывается от обычного мемпула транзакций; вместо этого у нее есть сплетниковая сеть интентов. Пользователи транслируют интент, например, «Я хочу обменять 100 DAI на как минимум 1 ETH» или «Я хочу занять под залог по лучшей ставке». Эти интенты являются частичными ордерами — они не указывают точные пути выполнения, только желаемый результат и ограничения. Все интенты распространяются по сети и собираются. Теперь упорядочивание в Anoma работает в два этапа: (1) Поиск/сопоставление контрагентов и (2) Выполнение транзакций со справедливым порядком. На этапе 1 специализированные узлы, называемые сольверами, постоянно отслеживают пул интентов и пытаются найти наборы интентов, которые дополняют друг друга для формирования действительной транзакции. Например, если Алиса намеревается обменять DAI на ETH, а Боб намеревается обменять ETH на DAI, сольвер может сопоставить их. Если несколько интентов совместимы (как книга ордеров с заявками на покупку и продажу), сольверы могут найти оптимальное сопоставление или клиринговую цену. Важно отметить, что это происходит офчейн в сети сольверов — фактически алгоритмическое сопоставление. Как только сольвер (или группа сольверов) сформировал полную транзакцию (или набор транзакций), которые выполняют некоторые интенты, они отправляют ее в цепочку для выполнения. Здесь начинается этап 2: консенсус Anoma затем упорядочит эти транзакции, отправленные сольверами, в блоки. Однако консенсус Anoma разработан для обеспечения справедливого порядка: он использует криптографические методы (пороговое шифрование), чтобы гарантировать, что транзакции упорядочиваются без влияния их содержимого или точного времени отправки. В частности, Anoma планирует использовать Ferveo, схему порогового шифрования, на уровне мемпула. Это работает следующим образом: сольверы шифруют транзакции, которые они хотят предложить, используя коллективный публичный ключ валидаторов. Валидаторы включают эти зашифрованные транзакции в блоки, не зная их деталей. Только после финализации транзакции в блоке валидаторы совместно дешифруют ее (каждый внося свою долю ключа дешифрования). Это гарантирует, что ни один валидатор не может выборочно фронтраннить или переупорядочивать на основе содержимого транзакции — они фиксируют порядок вслепую. Алгоритм консенсуса эффективно упорядочивает транзакции (на самом деле, интенты) в режиме, более близком к первому увиденному или пакетному, поскольку все транзакции в данном «пакете» (блоке) шифруются и раскрываются одновременно. На практике Anoma может реализовать пакетные аукционы для определенных приложений: например, интент на торговлю может быть собран за N блоков (хранится зашифрованным), затем все дешифруются вместе после N блоков и сопоставляются сольверами в одном пакете. Это предотвращает быстрых участников от просмотра ордеров других и реагирования в рамках этого пакета — огромное преимущество для справедливости (эта техника вдохновлена частыми пакетными аукционами и была предложена для устранения преимуществ высокочастотной торговли). Кроме того, предикаты валидности Anoma (смарт-контракты на уровне приложения) могут обеспечивать ограничения справедливости на результат упорядочивания. Например, приложение Anoma DEX может иметь правило: «все сделки в пакете получают одинаковую клиринговую цену, и сольверы не могут вставлять дополнительные транзакции для эксплуатации пользователей». Поскольку эти правила являются частью валидности состояния, любой блок, содержащий несправедливое сопоставление (скажем, сольвер попытался незаметно вставить самосделку по лучшей цене), будет недействительным и отклонен валидаторами. В итоге, упорядочивание в Anoma происходит как сопоставление, затем шифрование+упорядочивание: интенты концептуально ставятся в очередь, пока сольвер не сформирует транзакцию, а затем эта транзакция упорядочивается консенсусом справедливого порядка (предотвращая типичный MEV). Фактически нет гонки в мемпуле, поскольку интенты пользователей не конкурируют напрямую по цене газа или приоритету времени. Вместо этого конкуренция заключается в том, чтобы сольверы находили совпадения, а затем эти совпадения выполняются таким образом, что никто не может изменить порядок или перехватить их во время выполнения. Эта архитектура обещает нейтрализовать многие векторы MEV — нет концепции фронтраннинга интента, потому что интенты не являются действительными, пока сольвер не соберет их, а к тому времени они зашифрованы в блок. Это принципиально иная модель очереди, направленная на устранение эксплойтов, основанных на приоритете времени.

• Механизмы подавления/извлечения MEV: Anoma разработана для минимизации «плохого MEV» по своей конструкции. Благодаря тому, что сделки разрешаются с помощью пакетного решения и порогового шифрования, типичные атаки MEV, такие как сэндвич-атаки, становятся невозможными — никто не видит интент и не может вставить свой собственный до него, потому что интенты не являются транзакциями, которые находятся в прозрачном мемпуле. Сольверы выводят окончательные сопоставленные транзакции только после того, как возможность для вставки прошла (из-за шифрования и пакетирования). В DEX на базе Anoma пользователи не будут подвергаться фронтраннингу или бэктраннингу в традиционном смысле, потому что все сделки в пакете выполняются вместе по единой цене (предотвращая эксплуатацию изменения цены между ними злоумышленником). Это по сути подавляет хищнический MEV, такой как арбитраж DEX или сэндвич-атаки; ценность, которая была бы взята ботом, вместо этого сохраняется пользователями (они получают справедливую цену). Подход Anoma к арбитражу также заслуживает внимания: во многих случаях, если несколько интентов создают арбитражную возможность, сольвер, который их сопоставляет, включит эту прибыль в сопоставление (например, сопоставит разные цены и получит чистую прибыль). Но поскольку несколько сольверов могут конкурировать за предоставление лучшего сопоставления, конкуренция может вынудить сольверов вернуть большую часть этого преимущества пользователям в виде лучших условий исполнения. Например, если один пользователь хочет продать по цене A, а другой хочет купить по цене B (B > A подразумевает разрыв), сольвер может выполнить оба по промежуточной цене и получить разницу в качестве прибыли — но если другой сольвер предложит пользователям еще более близкую цену друг к другу (оставляя меньше прибыли), он выиграет интент. Таким образом, сольверы конкурируют за маржу MEV в пользу пользователей, подобно тому, как поисковики в Flashbots конкурируют через комиссии. Разница в том, что это происходит алгоритмически через сопоставление интентов, а не через ставки на газ. В Anoma все еще может быть «извлеченный MEV», но он, вероятно, ограничивается получением сольверами скромных комиссий за свои услуги. Примечательно, что Anoma ожидает, что большая часть потока ордеров будет интернализована протоколом или логикой приложения. В некоторых случаях это означает, что то, что было бы возможностью MEV, становится просто обычной протокольной комиссией. Например, первый фрактальный экземпляр Anoma (Namada) реализует ончейн-AMM с кривой связывания; арбитраж на этом AMM захватывается механизмом AMM (например, встроенным ребалансировщиком), а не внешними арбитражерами. Другой пример: интент на кредитование, предлагающий высокий процент, может быть сопоставлен с интентом на заимствование; сторонний ликвидатор не нужен, если залог падает, потому что сами интенты могут обрабатывать ребалансировку или протокол может автоматически ликвидировать по справедливой цене. Устраняя сторонних извлекателей, Anoma уменьшает распространенность офчейн-извлечения MEV. Кроме того, Anoma делает акцент на конфиденциальности (через подсистему ZK-схем Taiga). Пользователи могут выбрать частичное или полное экранирование своих интентов (например, скрытие сумм или типов активов). Это еще больше подавляет MEV: если детали крупного ордера скрыты, никто не может нацелиться на него для извлечения ценности. Только после сопоставления и выполнения детали могут появиться, к тому времени будет слишком поздно для эксплуатации. В итоге, механизм Anoma в значительной степени направлен на предотвращение MEV, а не на его извлечение: путем пакетирования транзакций, шифрования мемпула и встраивания экономического выравнивания в сопоставление он пытается обеспечить минимальные возможности для злонамеренного арбитража или фронтраннинга. Необходимый MEV (например, арбитраж для выравнивания цен на рынках) обрабатывается сольверами или протокольной логикой с минимальным доверием. Можно сказать, что Anoma стремится к «минимизации MEV», добиваясь результатов, как если бы каждый пользователь имел мгновенный доступ к идеальному контрагенту без утечек. Любая ценность, извлеченная при содействии этому (вознаграждение сольвера), сродни небольшой плате за услугу, а не непредвиденной прибыли от эксплуатации асимметрии.

• Экономическая структура стимулирования: В Anoma сольверы берут на себя роль, аналогичную как посредникам, так и билдерам блоков. Они несут расходы (вычисления, возможно, размещение залога) для поиска совпадений интентов, и они вознаграждаются, когда успешно предлагают транзакции, которые включаются в блок. Сольверы могут зарабатывать несколькими способами: они могут взимать комиссию или спред в рамках транзакции, которую они строят (например, предоставляя пользователям немного менее выгодные условия и сохраняя разницу, подобно тому, как агрегатор DEX может брать небольшую долю). Или же определенные интенты могут явно включать вознаграждение для сольвера (например, «Я готов заплатить до 0,01 ETH, чтобы это было сделано»). Точная модель компенсации гибкая, но главное, что сольверы конкурируют. Если один сольвер пытается взять слишком высокую комиссию, другой может предложить решение с лучшим результатом для пользователя и выиграть включение. Эта конкурентная динамика призвана контролировать прибыль сольверов и согласовывать ее с предоставлением ценности. Валидаторы (производители блоков): Валидаторы Anoma запускают консенсус, который упорядочивает и выполняет транзакции. Они стимулируются вознаграждениями за блоки и комиссиями, как и в любом блокчейне. Примечательно, что если интенты сопоставляются между несколькими пользователями, результирующая транзакция может иметь несколько источников комиссий (каждый пользователь может внести комиссию или часть активов). Возможно, модель комиссий Anoma может допускать разделение комиссий, но обычно валидаторы получают стандартные комиссии за газ за обработку транзакций. В будущих фазах Anoma планирует «консенсус по требованию» и нативный токен. Идея заключается в том, что может существовать множество экземпляров Anoma (или шардов), и некоторые из них могут временно запускаться для конкретных задач («специальный консенсус» для конкретных потребностей приложения). Токен, вероятно, будет использоваться для стейкинга и обеспечения безопасности этих экземпляров. Стимулы здесь гарантируют, что сеть имеет достаточно валидаторов для надежной обработки всех сопоставленных транзакций и что они ведут себя честно в процессе порогового дешифрования (возможно, условия слэшинга, если они пытаются дешифровать раньше или цензурировать). Пользователи: Пользователи в Anoma потенциально экономят деньги и получают лучшие результаты, а не платят MEV неявно. Например, они могут постоянно получать лучшие торговые цены, чем в традиционной цепочке, что означает, что ценность остается у них. В некоторых случаях пользователи могут также платить явные комиссии для стимулирования сольверов, особенно для сложных интентов или когда они желают более быстрого сопоставления. Но поскольку пользователи могут выражать интенты, не указывая, как их выполнять, они перекладывают тяжелую работу на сольверов и платят только в том случае, если это того стоит. Существует также понятие «владельцы интентов могут определять свои собственные компромиссы в безопасности/производительности» — например, пользователь может сказать: «Я подожду дольше для лучшей цены» или «Я заплачу больше за немедленное выполнение». Эта гибкость позволяет самим пользователям решать, сколько предлагать сольверам или валидаторам, согласовывая экономические стимулы с их потребностями. Перераспределение MEV: Если какой-либо MEV все же возникает (например, кросс-цепочечный ARB и т. д.), архитектура Anoma может позволить захватывать его в систему. Например, несколько шардов или экземпляров Anoma могут координироваться для атомарного многоцепочечного арбитража, и прибыль может быть разделена или сожжена (в зависимости от дизайна), вместо того чтобы внешний арбитражер сохранял ее всю. В целом, поскольку Anoma дает приложениям контроль над потоком транзакций, возможно реализовать MEV, принадлежащий протоколу (аналогично философии Skip) на уровне приложения. Например, DeFi-приложение на Anoma может автоматически маршрутизировать все пользовательские сделки через внутрипротокольный сольвер, который гарантирует лучшее выполнение и делится любой дополнительной прибылью с пользователями или поставщиками ликвидности. Чистый эффект заключается в том, что сторонние извлекатели MEV дезинтермедируются. Экономически это положительная сумма для честных участников (пользователей, поставщиков ликвидности и т. д.), но это может уменьшить возможности для классических поисковиков. Однако появятся новые роли, такие как специализированные сольверы (возможно, один специализируется на сопоставлении NFT, другой на валютных свопах и т. д.). Эти сольверы аналогичны сегодняшним поисковикам MEV, но они работают в рамках правил системы и, вероятно, имеют менее безумные маржи прибыли из-за конкуренции и протокольных ограничений. Наконец, видение Anoma Foundation намекает на то, что Anoma является инфраструктурой общественного блага. Будет нативный токен, предположительно ANOMA, который может захватывать ценность через комиссии или требоваться для стейкинга. Можно предвидеть токеновые стимулы (инфляционные вознаграждения и т. д.) для валидаторов и, возможно, даже для сольверов для запуска активности. На момент написания детали токеномики не окончательны, но дорожная карта подтверждает, что токен Anoma и нативный консенсус по требованию запланированы в будущих фазах. Подводя итог, модель стимулирования Anoma поощряет кооперативное поведение: сольверы зарабатывают, помогая пользователям получить то, что они хотят, а не эксплуатируя их; валидаторы зарабатывают, обеспечивая безопасность сети и упорядочивая справедливо; а пользователи «платят» в основном, отдавая часть MEV сольверам или в виде комиссий, но в идеале гораздо меньше, чем неявный MEV, который они потеряли бы в других системах.

• Соответствие и нейтральность: Anoma, будучи фреймворком, а не единой сетью, может быть реализована различными способами — некоторые могут быть с разрешениями, но флагманский Anoma L1 и аналогичные экземпляры предназначены быть безразрешительными и с повышенной конфиденциальностью. Включая мощные функции конфиденциальности (такие как экранированные интенты с использованием доказательств с нулевым разглашением в Taiga), Anoma соответствует точке зрения, что финансовая конфиденциальность является правом. Это может привести к конфликту с некоторыми регуляторными режимами, которые требуют открытой видимости транзакций. Однако дизайн Anoma также может избежать определенных регуляторных ловушек. Например, если фронтраннинг и несправедливый выбор ордеров исключены, опасения по поводу манипулирования рынком смягчаются — регулятор может оценить, что пользователи не подвергаются систематической эксплуатации инсайдерами. Кроме того, концепция «пользовательских моделей безопасности» подразумевает, что пользователи или сообщества могут выбирать различные предположения о доверии. Потенциально, регулируемое приложение может быть построено на Anoma, где, скажем, сольвер или некоторое подмножество валидаторов являются KYC-проверенными сущностями, обеспечивающими соответствие для этого конкретного домена интентов. Anoma как базовый уровень не будет навязывать KYC всем, но можно реализовать предикаты валидности, требующие (например) доказательства соответствия для определенных транзакций (например, доказательство отсутствия в санкционном списке или проверка учетных данных), если это необходимо приложению. Архитектура достаточно гибка, чтобы поддерживать соответствие на уровне приложения без ущерба для нейтральности базового уровня. Что касается цензуры: пороговое шифрование Anoma означает, что даже если валидаторы захотят цензурировать, они не могут нацеливаться на конкретные интенты, потому что они не видят их в открытом виде. Единственное, что они могли бы сделать, это отказаться включать зашифрованные транзакции от определенных сольверов или пользователей, но это было бы очевидно (и противоречило бы правилам протокола, если бы делалось произвольно). Ожидается, что правила консенсуса будут препятствовать цензуре — например, если блок не включает все доступные дешифрованные интенты из последней партии, он может быть признан недействительным или менее предпочтительным. В любом случае, децентрализация валидаторов и зашифрованный характер полезных нагрузок вместе обеспечивают высокую степень устойчивости к цензуре. Что касается нейтральности: Anoma стремится быть общей платформой, не контролируемой какой-либо одной сущностью. Исследования и разработки возглавляются Heliax (командой, стоящей за Anoma и Namada), но после запуска сеть Anoma будет управляться сообществом. Вероятно, будет ончейн-управление для обновлений и т. д., что может вызвать вопросы соответствия (например, может ли правительство подорвать управление, чтобы изменить правила?), но это общая проблема блокчейна. Одна интересная функция, связанная с соответствием, заключается в том, что Anoma поддерживает несколько параллельных экземпляров — это означает, что можно иметь изолированный пул интентов или шард для определенных типов активов или юрисдикций. Это не явно для регулирования, но это может позволить, например, пул интентов CBDC, где только авторизованные банки запускают сольверы, сосуществуя со свободным пулом DeFi. Модульность архитектуры обеспечивает гибкость для разделения при необходимости, при этом позволяя взаимодействие через мосты интентов. Наконец, с точки зрения юридической совместимости, вся концепция интентов Anoma может избежать некоторых классификаций, которые преследуют традиционную криптографию: поскольку интент не является обязывающей транзакцией до сопоставления, можно утверждать, что пользователи сохраняют больший контроль (это как размещение ордера на бирже, что имеет более четкий юридический прецедент, по сравнению с прямым выполнением сделки). Это может помочь с такими вещами, как налоговый режим (система потенциально может предоставить единую квитанцию о многоэтапной сделке, а не о многих транзакциях) — хотя это спекулятивно. В целом, Anoma приоритезирует децентрализацию, конфиденциальность и автономию пользователей, что исторически может конфликтовать с регуляторными ожиданиями, но выгоды от справедливости и прозрачности могут завоевать расположение. По сути, она переносит сложность традиционных финансовых механизмов сопоставления на блокчейн, но без централизованных операторов. Если регуляторы поймут эту модель, они могут увидеть в ней более упорядоченную и справедливую рыночную структуру, чем хаос мемпулов.

• Техническая архитектура (консенсус и криптография): Архитектура Anoma сложна и состоит из нескольких компонентов: Typhon (сеть, мемпул, консенсус, выполнение) и Taiga (уровень конфиденциальности с нулевым разглашением). Ядро Typhon — это уровень обмена интентами и новый подход к комбинированному консенсусу + сопоставлению. Протокол консенсуса Anoma расширяет типичный консенсус BFT концепцией «предикатов валидности» и «доказательства сопоставления ордеров». По сути, каждое приложение в Anoma может определить предикат валидности, который должен быть удовлетворен для транзакций (представьте это как условия смарт-контракта, которые применяются на уровне блока, а не только на уровне транзакции). Это позволяет обеспечивать такие свойства, как клиринговые цены пакетных аукционов и т. д., как описано. Сам алгоритм консенсуса, вероятно, основан на BFT в стиле Tendermint или HotStuff (поскольку Anoma находится в экосистеме Cosmos и поддерживает IBC). Действительно, первоначальный тестнет Anoma (Feigenbaum в 2021 году) и Namada используют консенсус в стиле Tendermint с модификациями. Одной из основных модификаций является интеграция порогового шифрования (Ferveo) в конвейер мемпула. Обычно Tendermint выбирает пропозера, который упорядочивает транзакции. В Anoma пропозер будет упорядочивать зашифрованные интенты/транзакции. Ferveo, вероятно, работает следующим образом: валидаторы периодически договариваются о пороговом публичном ключе, и каждый интент, отправленный сольверами, шифруется этим ключом. Во время предложения блока все зашифрованные транзакции включаются; после предложения валидаторы запускают протокол для их дешифрования (возможно, следующий блок содержит дешифрованные выходы или какую-то подобную схему). Это добавляет фазу к консенсусу, но обеспечивает справедливость порядка. Криптографически это использует распределенную генерацию ключей и пороговое дешифрование (поэтому оно опирается на предположения, такие как честность не менее 2/3 валидаторов, чтобы не допустить утечки или раннего дешифрования данных). Что касается конфиденциальности, Taiga предоставляет zkSNARK или zk-STARK доказательства, которые позволяют интентам оставаться частично или полностью экранированными. Например, пользователь может отправить интент на обмен, не раскрывая тип актива или сумму; он предоставляет ZK-доказательство того, что у него достаточно средств и что транзакция будет действительной, если сопоставлена, не раскрывая подробностей. Это аналогично тому, как работают экранированные транзакции в Zcash, но расширено до интентов. Упоминается использование рекурсивных доказательств, что означает, что несколько шагов транзакции (или несколько интентов) могут быть доказаны в одном кратком доказательстве для эффективности. Взаимодействие Taiga и Typhon означает, что некоторые сольверы и валидаторы могут работать с шифротекстом или обязательствами, а не с открытыми значениями. Например, сольвер может сопоставлять интенты, выраженные конфиденциальным образом, решая уравнение обязательств. Это передовая криптография, выходящая за рамки того, что делают большинство современных блокчейнов. Еще одна ключевая часть — это интеграция IBC: экземпляры Anoma могут общаться с другими цепочками (особенно цепочками Cosmos) через протокол Inter-Blockchain Communication. Это означает, что интент в Anoma потенциально может вызвать действие в другой цепочке (через сообщение IBC) или использовать данные из состояния другой цепочки. Фаза 1 основной сети в дорожной карте Anoma специально упоминает «адаптер» на Ethereum и роллапах, чтобы позволить интентам Anoma использовать ликвидность EVM. Вероятно, сольвер Anoma может составить транзакцию, которая, скажем, использует Uniswap на Ethereum, создав интент, который при сопоставлении отправляет сообщение в Ethereum для выполнения свопа (возможно, через ретранслятор или через что-то вроде моста IBC). Консенсус должен обеспечивать атомарность: предположительно, вывод Anoma может быть похож на одну транзакцию, охватывающую несколько цепочек (что-то вроде инициирования транзакции в цепочке A и ожидания результата в цепочке B). Достижение атомарного кросс-цепочечного расчета сложно; возможно, Anoma начнет с расчета по одной цепочке за раз (Фаза 1 сосредоточена на экосистеме Ethereum, вероятно, это означает, что интенты Anoma будут рассчитываться на Ethereum L1 или L2 за один раз). Позже «цепочки Химеры» и консенсус по требованию могут позволить настраиваемым сайдчейнам запускаться для обработки конкретных кросс-цепочечных совпадений. С точки зрения производительности, подход Anoma может быть более вычислительно интенсивным (сольверы решают NP-сложные задачи сопоставления, валидаторы выполняют тяжелую криптографию). Но компромисс — значительно улучшенный пользовательский опыт (нет неудачных транзакций, лучшие цены и т. д.). Разработка Anoma требует создания этих новых компонентов практически с нуля: Heliax создает Juvix, новый язык для написания предикатов валидности и интентов, а также много исследований (некоторые ссылки с сайта Anoma подробно описывают эти концепции). Основные вехи: первый публичный тестнет Anoma Feigenbaum запущен в ноябре 2021 года как демонстрация базового обмена интентами. Впоследствии Heliax переключил внимание на запуск Namada (L1, ориентированный на конфиденциальность, который можно рассматривать как экземпляр Anoma, сосредоточенный на передаче активов) — Namada запущен в 2023 году и включает такие функции, как экранированные переводы и пороговое шифрование Ferveo для своего мемпула. Это демонстрирует технологию в действии для более узкого случая использования. Тем временем, полномасштабные тестнеты Anoma развертываются поэтапно (также упоминался «тестнет лета 2023 года» в сообществе). Дорожная карта указывает, что основная сеть Фазы 1 будет интегрировать Ethereum, Фаза 2 добавит больше цепочек и передовую криптографию, и в конечном итоге появятся нативный консенсус и токен. Разделение «консенсуса и токена в будущей фазе» предполагает, что первоначальная основная сеть Anoma может полагаться на Ethereum (например, используя безопасность Ethereum или существующие токены, а не имея свой собственный с первого дня). Возможно, они запустят L2 или сайдчейн, который будет публиковать данные в Ethereum. А затем запустят свою собственную PoS-сеть с токеном. Этот поэтапный подход интересен — он может снизить барьер для принятия (использовать существующий капитал на Ethereum, а не запускать новую монету изначально). В заключение, архитектура Anoma новаторская и всеобъемлющая: она сочетает криптографическую справедливость (пороговое шифрование, ZK-доказательства) с новой парадигмой транзакций (интент-ориентированное сопоставление) и кросс-цепочечными возможностями. Это, возможно, самая агрессивная попытка искоренить традиционный MEV на уровне протокола, делая то, чего не делает ни одна устаревшая цепочка: встроенные механизмы справедливого сопоставления. Сложность высока, но в случае успеха цепочка Anoma может предоставить пользователям почти гарантии исполнения, как на CEX, в децентрализованной среде, что является святым Граалем в UX и справедливости блокчейна.

Skip Protocol (Инструментарий для суверенного контроля MEV и справедливого порядка в Cosmos)​

Skip Protocol — это ведущее решение для MEV в экосистеме Cosmos, ориентированное на предоставление каждому блокчейну («аппчейну») инструментов для управления порядком транзакций и захватом MEV на своих условиях. В отличие от Flashbots или Anoma, которые предлагают сетевые системы, Skip соответствует философии суверенитета Cosmos: каждая цепочка может интегрировать модули Skip для применения пользовательских правил справедливого порядка, запуска внутрипротокольных аукционов за блочное пространство и захвата MEV для заинтересованных сторон или пользователей цепочки. Skip можно рассматривать как набор модулей Cosmos SDK и инфраструктуры, которые вместе обеспечивают Protocol-Owned Blockbuilding (POB) и гибкое секвенирование транзакций. Он был принят в таких цепочках, как Osmosis, Juno, Terra и других в Cosmos, а также сотрудничает с проектами, такими как предстоящая цепочка dYdX, для смягчения MEV. Ключевые элементы включают механизм ончейн-аукциона для приоритетных транзакций, логику упорядочивания транзакций на уровне консенсуса и внутриприложенческие механизмы для переработки MEV («хорошего MEV») в пользу протокола.

• Алгоритмы очереди и порядка транзакций: В типичной цепочке Cosmos (использующей консенсус Tendermint/BFT) мемпул упорядочивает транзакции примерно по комиссии и времени поступления, а пропозер блока может выбрать любой порядок при создании блока (без алгоритмических ограничений, кроме включения действительных транзакций). Skip изменяет это, вводя правила упорядочивания, обеспечиваемые консенсусом, и многополосные мемпулы. Используя новый интерфейс ABCI++ Cosmos (который позволяет настраивать предложение и обработку блоков), модуль Protocol-Owned Builder (POB) Skip может разделять блок на отдельные полосы с различными политиками упорядочивания. Например, одна полоса может быть полосой аукциона в начале блока, где транзакции с наивысшими ставками (возможно, от арбитражных ботов или срочных сделок) помещаются первыми в блок в фиксированном порядке, другая полоса может быть свободной полосой для обычных пользовательских транзакций без комиссий, и полосой по умолчанию для обычных транзакций с комиссиями. Компонент BlockBuster модуля Skip позволяет разработчикам модульно определять эти полосы и их логику упорядочивания. Важно отметить, что эти правила обеспечиваются всеми валидаторами: когда пропозер строит блок, другие валидаторы будут проверять, что транзакции блока соответствуют согласованным правилам упорядочивания (через проверки ProcessProposal ABCI). В противном случае они могут отклонить блок. Это означает, что даже злонамеренный или стремящийся к прибыли пропозер не может отклониться (например, не может незаметно вставить свою собственную фронтраннинговую транзакцию перед победителем аукциона, потому что это нарушило бы правило упорядочивания). Некоторые примеры правил упорядочивания, которые позволяет Skip: (а) Упорядочивать транзакции по убыванию цены газа (комиссии) — гарантируя, что транзакции с самой высокой комиссией всегда получают приоритет. Это формализует справедливую схему «плати за приоритет» вместо случайной или основанной на времени. (б) Должна включать по крайней мере одну транзакцию обновления цены оракула перед любыми сделками — обеспечивая обновление потоков данных, что предотвращает сценарии, когда пропозер мог бы игнорировать обновления оракула для эксплуатации устаревших цен. (в) Ограничить количество специальных транзакций в начале блока — например, только один выигрышный бандл аукциона может занимать самое верхнее место, чтобы предотвратить спам множеством мелких захватов MEV. (г) Нет транзакций, нарушающих свойство состояния — Skip позволяет правила упорядочивания, зависящие от состояния, такие как «после построения блока убедитесь, что ни одна DEX-сделка не была выполнена по цене хуже, чем если бы она была последней в блоке» (способ обеспечить отсутствие сэндвич-атаки). Одно конкретное описанное правило — это «условие нулевого фронтраннинга по всем DEX», что может означать, что если какая-либо транзакция была бы затронута последующими таким образом, что это указывает на фронтраннинг, блок недействителен. Это мощно: по сути, это делает справедливость частью валидности блока. Цепочки Cosmos могут реализовать такие правила, потому что они контролируют весь свой стек. Фреймворк Skip предоставляет структурированный способ сделать это через AuctionDecorator в SDK, который может проверять каждую транзакцию на соответствие настроенным правилам. Кроме того, Skip предоставляет улучшения мемпула: мемпул узла может заранее симулировать блоки, отфильтровывать неудачные транзакции и т. д., чтобы помочь пропозерам эффективно следовать правилам. Например, если полоса аукциона блока должна иметь самые высокие ставки, мемпул может быть отсортирован по ставкам для этой полосы. Если блок должен включать только транзакции, которые приводят к определенному состоянию, узел пропозера может симулировать транзакции по мере их выбора, чтобы убедиться, что условие выполняется. В итоге, Skip обеспечивает детерминированное, определяемое цепочкой упорядочивание, а не оставляет его полностью на усмотрение пропозера или простого приоритета цены газа. Цепочки принимают модуль билдера Skip, чтобы эффективно кодифицировать свою политику упорядочивания транзакций в протокол. Это способствует справедливости, потому что все валидаторы обеспечивают одни и те же правила, устраняя возможность для одного пропозера произвольно переупорядочивать для MEV, если это не в рамках разрешенного механизма (например, аукциона, где это прозрачно и конкурентно). Очередь транзакций в модели Skip может включать отдельные очереди для каждой полосы. Например, полоса аукциона может ставить в очередь специальные транзакции ставок (Skip использует специальный тип MsgAuctionBid для ставок на включение в начало блока). Эти ставки собираются в каждом блоке, и выбирается самая высокая. Тем временем обычные транзакции ставятся в очередь в мемпуле по умолчанию. По сути, Skip вводит структурированную очередь: одну для приоритетных ставок, одну для бесплатных или других, и т. д., каждая со своими критериями упорядочивания. Этот модульный подход означает, что каждая цепочка может настраивать, как она балансирует справедливость и доход — например, Osmosis может сказать: «мы вообще не хотим аукциона MEV, но мы обеспечиваем справедливость порядка через пороговое шифрование» (они реализовали пороговое шифрование с помощью Skip и других), тогда как другая цепочка может сказать: «мы разрешаем аукционы для MEV, но требуем, чтобы часть доходов была сожжена». Skip поддерживает оба варианта. Эта конфигурируемость упорядочивания является отличительной чертой Skip.

• Механизмы смягчения и извлечения MEV: Подход Skip к MEV часто описывается как «MEV, принадлежащий протоколу» и «множественность». MEV, принадлежащий протоколу, означает, что сам блокчейн-протокол, через свой код и управление, захватывает или перераспределяет MEV, а не оставляет его отдельным валидаторам или посторонним. Множественность относится к обеспечению включения «правильных» (множественных) транзакций — по сути, не исключая легитимные пользовательские транзакции в пользу только MEV-транзакций, и, возможно, включая несколько возможностей MEV в одном блоке, если это возможно (чтобы ни один поисковик не монополизировал). Конкретно, Skip предоставляет инструменты для захвата MEV способами, которые приносят пользу сети: один из них — Skip Select, система аукциона за блочное пространство для включения в начало блока. В Skip Select поисковики (например, арбитражные боты) отправляют бандлы с чаевыми валидаторам, аналогично бандлам Flashbots, за исключением того, что это делается нативно ончейн через модули Skip. Бандл (или бандлы) с самой высокой оплатой затем автоматически вставляются в начало блока в указанном порядке. Это гарантирует, что эти транзакции будут выполнены, как задумано, и валидатор (или цепочка) собирает чаевые. Этот механизм превращает то, что было офчейн-OTC-процессом (в Ethereum), в открытый, ончейн-аукцион — улучшая прозрачность и доступ. Другой механизм — ProtoRev (модуль Prototype Revenue), который Skip разработал для Osmosis. ProtoRev — это ончейн-арбитражный модуль, который автоматически обнаруживает и выполняет циклические арбитражи (например, те, которые включают несколько пулов) внутри выполнения блока и накапливает прибыль в казну цепочки или пул сообщества. По сути, Osmosis решил, что определенный «хороший MEV» (например, арбитраж, который поддерживает выравнивание цен) должен по-прежнему происходить (для эффективности рынка), но сам протокол выполняет арбитраж и захватывает прибыль, а затем распределяет ее (например, стейкерам или в качестве стимулов для майнинга ликвидности). Это устраняет необходимость во внешних арбитражных ботах для этих возможностей и гарантирует, что ценность остается в экосистеме. ProtoRev был первым в своем роде в крупной цепочке и демонстрирует, как глубокая интеграция может смягчить внешние эффекты MEV: пользователи, торгующие на Osmosis, сталкиваются с меньшим проскальзыванием, потому что если после их сделки существует арбитраж, протокол закроет его и по сути вернет ценность Osmosis (что может косвенно принести пользу пользователям через более низкие комиссии или выкуп токенов и т. д.). Более того, Skip дает цепочкам возможность реализовать меры против MEV, такие как пороговое шифрование для мемпула. Например, Osmosis, в сотрудничестве со Skip и другими, реализует шифрование мемпула, где транзакции отправляются зашифрованными и раскрываются только через фиксированное время (аналогично идее Anoma, но на уровне цепочки). Хотя это не продукт Skip как таковой, архитектура Skip совместима — аукцион Skip может работать с зашифрованными транзакциями, проводя аукцион на основе объявленных ставок, а не считывая содержимое транзакции. Что касается подавления вредоносного MEV: правила консенсуса Skip, такие как «фронтраннинг запрещен» (обеспечиваемые проверками состояния), являются прямой мерой для пресечения злонамеренного поведения. Если валидатор пытается включить сэндвич-атаку, другие валидаторы обнаружат, что результат состояния нарушает правило запрета фронтраннинга (например, они могут проверить, что ни одна сделка не была непосредственно предшествована и не сопровождалась другой с того же адреса таким образом, чтобы это было использовано). Этот блок будет отклонен. Зная это, валидаторы даже не будут пытаться включать такие паттерны, таким образом пользователи защищены законом протокола. Skip также поощряет сжигание или перераспределение доходов от MEV, чтобы избежать извращенных стимулов. Например, цепочка может выбрать сжигание всех доходов от аукциона или поместить их в общественный фонд, а не отдавать все пропозеру блока. Это снижает стимул для валидаторов самостоятельно переупорядочивать транзакции, поскольку они могут лично не получать от этого прибыли (в зависимости от выбора цепочки). В итоге, инструментарий Skip позволяет каждой цепочке хирургически извлекать MEV там, где это выгодно (например, арбитраж для поддержания эффективности рынка, ликвидации для поддержания здоровья рынков кредитования) и гарантировать, что эта ценность захватывается протоколом или пользователями, при этом строго запрещая и предотвращая злонамеренный MEV (например, недружественный для пользователей фронтраннинг). Это прагматичное сочетание извлечения и подавления, адаптированное управлением: вместо универсального решения Skip дает сообществам возможность решать, какой MEV является «хорошим» (и автоматизировать его захват) и какой является «плохим» (и запрещать его с помощью правил консенсуса). Результатом является более справедливая торговая среда в цепочках, поддерживающих Skip, и дополнительный источник дохода, который может финансировать общественные блага или снижать затраты (один из постов в блоге Skip отмечает, что справедливый захват MEV может быть использован для «справедливого распределения доходов среди всех участников сети»).

• Экономическая структура стимулирования: Введение Skip принципиально меняет стимулы, особенно для валидаторов и сообществ цепочек в Cosmos. Традиционно валидатор в Cosmos мог извлекать MEV, приватно переупорядочивая транзакции в своем блоке (поскольку Cosmos по умолчанию не имеет аукциона MEV). Со Skip валидаторы вместо этого соглашаются на протокол, где MEV захватывается через аукционы или модули и часто распределяется. Валидаторы по-прежнему получают выгоду: они могут получать долю от доходов аукциона или дополнительные комиссии от механизмов Skip, но важно, что все валидаторы (а не только пропозер) могут получать выгоду, если это так задумано. Например, некоторые аукционы Skip могут быть настроены так, чтобы доход делился между всеми стейкерами или в соответствии с решениями управления, а не по принципу «победитель получает все» для пропозера. Это коллективно побуждает валидаторов запускать программное обеспечение Skip, потому что даже не-пропозеры получают безопасность (зная, что если кто-то попытается создать недействительный блок, это не окупится) и, возможно, доход. Некоторые цепочки могут по-прежнему отдавать пропозеру большую часть комиссии аукциона MEV (чтобы максимизировать немедленный стимул для его включения), но даже тогда это прозрачно и конкурентно, что, возможно, уменьшает вероятность закулисных сделок. Цепочка/Сообщество: Концепция MEV, принадлежащего протоколу, означает, что блокчейн и его заинтересованные стороны захватывают MEV. Например, Osmosis направляет прибыль ProtoRev в свой общественный пул, фактически превращая MEV в дополнительный доход протокола, который может финансировать разработку или распределяться между стейкерами OSMO. Это делает сообщество в целом «владельцем» этого MEV, выравнивая интересы всех в извлечении MEV здоровыми способами. Если пользователи знают, что MEV возвращается на улучшение цепочки или токеномики, они могут быть более лояльны к нему, чем если бы он доставался случайному боту. Поисковики: В модели Skip независимые поисковики/боты могут иметь меньше работы ончейн, потому что некоторые возможности захватываются логикой протокола (например, ProtoRev), а другие направляются через аукционы. Однако Skip не устраняет поисковиков — скорее, он направляет их на участие в торгах по правильным маршрутам. Поисковик все еще может попытаться использовать сложную стратегию, но чтобы гарантировать включение в определенное место, он должен участвовать в аукционе Skip (Skip Select), отправляя свой бандл со ставкой. В противном случае он рискует, что валидатор проигнорирует его в пользу того, кто сделал ставку, или что собственным механизмом цепочки будет использована возможность. Таким образом, поисковики в Cosmos развиваются, чтобы работать со Skip: например, многие арбитражеры на Osmosis теперь отправляют свои арбитражи через систему Skip. Они платят часть цепочке, сохраняя меньшую прибыль, но это цена игры. Со временем некоторые роли «поисковиков» могут быть полностью поглощены (например, бэктраннинг арбитража — ProtoRev обрабатывает его, поэтому внешний поисковик не может конкурировать). Это может уменьшить спам и напрасные усилия в сети (больше нет гонки нескольких ботов; только одно выполнение протокола). Пользователи: Конечные пользователи выигрывают благодаря более справедливой среде (без неожиданных атак MEV). Кроме того, некоторые конфигурации Skip явно вознаграждают пользователей: возможно перераспределение MEV пользователям. Например, цепочка может решить вернуть часть дохода от аукциона MEV пользователям, чьи сделки создали этот MEV (аналогично идее возмещения Flashbots). Astroport, DEX на Terra, интегрировал Skip для распределения дохода от MEV со своперами — это означает, что если сделка пользователя имела MEV, часть этой ценности по умолчанию возвращается ему. Это соответствует этике, что MEV должен доставаться пользователям. Хотя не все цепочки делают это, возможность существует через инфраструктуру Skip для реализации таких схем. Сам Skip Protocol (компания/команда) имеет бизнес-модель, при которой они часто предоставляют эти инструменты валидаторам бесплатно (для поощрения принятия), и монетизируют, сотрудничая с цепочками (B2B). Например, Skip может брать небольшую комиссию от захваченного MEV или взимать плату с цепочек за расширенные функции/поддержку. Упоминается, что Skip бесплатен для валидаторов, но использует модель B2B с цепочками. Это означает, что Skip заинтересован в максимизации MEV, захваченного цепочкой и сообществом (чтобы цепочка была довольна и, возможно, делилась частью в соответствии с соглашением). Но поскольку управление участвует, любая комиссия, которую берет Skip, обычно согласовывается сообществом. Экономический эффект интересен: он профессионализирует извлечение MEV как услугу, предоставляемую цепочкам. При этом он препятствует мошенническому поведению — валидаторам не нужно индивидуально заключать сомнительные сделки, они могут просто использовать Skip и получать надежный поток дополнительного дохода, который социально приемлем. Честное поведение (следование правилам протокола) приносит почти столько же или больше прибыли, чем попытка обмануть, потому что если вы обманываете, ваш блок может быть недействительным или вы можете быть социально наказаны и т. д. Управление играет значительную роль: принятие модуля Skip или установка параметров (таких как доля аукциона, распределение доходов) осуществляется через ончейн-предложения. Это означает, что экономические результаты (кто получает MEV) в конечном итоге определяются голосованием сообщества. Например, Cosmos Hub обсуждает принятие SDK билдера Skip, чтобы, возможно, перенаправить MEV в казну Hub или стейкерам. Это выравнивание через управление гарантирует, что использование MEV рассматривается сообществом как легитимное. Оно превращает MEV из токсичного побочного продукта в общественный ресурс, который может быть распределен (на безопасность, пользователей, разработчиков и т. д.). В итоге, Skip перестраивает стимулы таким образом, что валидаторы коллективно и пользователи/сообщество получают выгоду, в то время как оппортунистические извлекатели MEV либо кооптируются в систему (в качестве участников торгов), либо исключаются из нее. Теоретически все выигрывают: пользователи теряют меньше ценности из-за MEV, валидаторы по-прежнему получают компенсацию (возможно, даже больше в сумме, благодаря аукционам), и сеть в целом может использовать MEV для своего укрепления (финансово или через более справедливый опыт). Единственные проигравшие — те, кто процветал на извлечении с нулевой суммой, не возвращая ценности.

• Соответствие и регуляторная совместимость: Фреймворк Skip, предоставляя управление цепочкой, фактически облегчает цепочкам обеспечение соответствия или конкретных политик, если они того желают. Поскольку Skip работает на уровне протокола, цепочка может выбрать применение определенных правил фильтрации или упорядочивания транзакций для соблюдения регуляций. Например, если цепочка хотела бы блокировать адреса, находящиеся под санкциями, она могла бы интегрировать правило AnteHandler или AuctionDecorator в модуль Skip, которое делает недействительными блоки, содержащие заблокированные адреса. Это, возможно, проще, чем в Ethereum, где цензура является офчейн-выбором отдельных валидаторов; в Cosmos со Skip это может быть общецепочечное правило (хотя это было бы спорно и противоречило бы идеалам децентрализации для многих). Альтернативно, цепочка могла бы обеспечить что-то вроде «транзакции пополнения FIAT должны появляться раньше других», если это предписано каким-либо законом. Инструментарий Skip не поставляется с предустановленными правилами соответствия, но он достаточно гибок, чтобы реализовать их, если сообщество вынуждено это сделать (через управление). С другой стороны, Skip может усилить устойчивость к цензуре: распределяя доход от MEV и предоставляя равный доступ, он уменьшает преимущество любого отдельного валидатора, который мог бы цензурировать ради прибыли. Кроме того, если мемпулы с пороговым шифрованием (подобные тому, который добавляет Osmosis) станут стандартом со Skip, это скроет содержимое транзакций, что затруднит цензуру (как в Anoma). Skip — это нейтральная инфраструктура — ее можно использовать как для соблюдения, так и для сопротивления, в зависимости от управления. Поскольку цепочки Cosmos часто специфичны для юрисдикции (сообщество Terra может беспокоиться о корейских законах, Kava может беспокоиться о законах США и т. д.), наличие опции для настройки соответствия ценно. Например, цепочка Cosmos с разрешениями (например, институциональная цепочка) все еще могла бы использовать модуль билдера Skip, но, возможно, требовать, чтобы только адреса из белого списка могли делать ставки на аукционах и т. д., соответствуя их регуляциям. Регуляторная совместимость также связана с прозрачностью: ончейн-аукционы Skip создают публичную запись транзакций MEV и того, кто сколько заплатил. Это фактически может удовлетворить некоторые регуляторные опасения по поводу справедливости (у каждого была возможность сделать ставку, и это поддается аудиту). Это более прозрачно, чем закулисные платежи валидаторам. Кроме того, захватывая MEV ончейн, Skip уменьшает вероятность офчейн-картелей или темных пулов, которых регуляторы опасаются из-за непрозрачности. Например, без Skip валидаторы могли бы заключать частные сделки с поисковиками (как это было замечено с проблемами цензуры ретрансляторов). Со Skip ожидается, что вы используете официальный аукцион — который открыт и регистрируется — для получения приоритета. Это способствует открытому рынку, доступному всем ботам в равной степени, что, возможно, более справедливо и менее подвержено сговору (сговор возможен, но существует надзор со стороны управления). Еще один аспект соответствия: поскольку Skip занимается захватом ценности, если доход от MEV поступает в общественный пул или казну, это может вызвать вопросы (является ли это комиссией, облагается ли налогом и т. д.?). Но это аналогично тому, как обрабатываются комиссии за транзакции, поэтому ничего принципиально нового с юридической точки зрения нет. В Cosmos сообщества цепочек также могут решать, как использовать этот фонд (сжигать, распределять и т. д.), что они могут согласовать с любыми юридическими рекомендациями, если это необходимо (например, они могут избегать отправки его в фонд, если это вызывает налоговые проблемы, и вместо этого сжигать его). Что касается устойчивости к цензуре, одно интересное замечание: обеспечивая правила валидности блока, Skip предотвращает цензуру валидаторами определенных транзакций, если это нарушит правила. Например, если цепочка имела правило «всегда включать хотя бы одно обновление оракула», цензурирующий валидатор не мог бы просто опустить все транзакции оракула (которые могут поступать из определенных источников), потому что его блок был бы недействительным. Таким образом, по иронии судьбы, правила Skip могут принуждать к включению критических транзакций (антицензура) так же, как они могут быть использованы для принудительного исключения запрещенных. Все зависит от того, что установит сообщество. Нейтральность: Позиция Skip по умолчанию — это предоставление цепочкам возможности «защищать пользователей от негативного MEV и улучшать пользовательский опыт», что подразумевает нейтральность и удобство для пользователя. Нет центральной сети Skip, принимающей решения — каждая цепочка суверенна. Skip как компания может консультировать или предоставлять настройки по умолчанию (например, рекомендуемый формат аукциона), но в конечном итоге держатели токенов цепочки решают. Эта децентрализация политики MEV для управления каждой цепочкой может рассматриваться как более совместимая с регуляторным разнообразием: например, цепочка, базирующаяся в США, могла бы реализовать соответствие OFAC, если на нее оказывается юридическое давление, не затрагивая другие цепочки. Это не один ретранслятор, цензурирующий множество цепочек; это выбор каждой цепочки. С точки зрения регулятора, Skip не вводит никакой дополнительной незаконной деятельности — он просто реорганизует порядок транзакций. Если что, он может уменьшить волатильность (меньше газовых войн) и создать более предсказуемое выполнение, что может быть плюсом. Подводя итог, архитектура Skip очень адаптивна к потребностям соответствия, сохраняя при этом возможность максимальной устойчивости к цензуре, если сообщества это приоритезируют. Она держит MEV на виду и под коллективным контролем, что, вероятно, делает блокчейн-экосистемы более устойчивыми как к злонамеренным акторам, так и к регуляторным репрессиям, поскольку самоуправление может проактивно бороться с наихудшими злоупотреблениями.

• Техническая архитектура и реализация: Skip Protocol тесно встроен в стек Cosmos SDK. Основная поставка — это набор модулей (например, x/builder) и модификации, такие как реализация мемпула BlockBuster. Цепочки Cosmos запускают консенсус (Tendermint/CometBFT), который предлагает хуки ABCI для подготовки и обработки предложений. Skip использует расширения ABCI++, которые позволяют выполнять код между предложением блока и финализацией. Именно так он обеспечивает упорядочивание: PrepareProposal может переупорядочить транзакции блока в соответствии с правилами полос перед трансляцией предложения, а ProcessProposal на принимающих валидаторах может проверять упорядочивание и валидность состояния на соответствие ожиданиям. Это современная функция (Cosmos SDK v0.47+), и POB Skip совместим с последними версиями SDK. Под капотом модули Skip поддерживают структуры данных для аукционов (например, ончейн-книгу ордеров ставок для начала блока). Они также, вероятно, используют приоритетные типы транзакций. README показывает специальный MsgAuctionBid и пользовательскую логику для его обработки. Таким образом, поисковики взаимодействуют, отправляя эти сообщения через обычные транзакции Cosmos, которые затем модуль перехватывает и размещает соответствующим образом. AnteHandler модуля билдера (AuctionDecorator) может потреблять ставки аукциона и определять победителей на этапе сборки блока. Криптографически Skip по умолчанию не добавляет новых криптографических требований (помимо того, что выбирает цепочка, например, пороговая криптография для мемпула, которая отдельна). Он полагается на честность >2/3 валидаторов для обеспечения правил и не сговора для их нарушения. Если большинство сговорится, они могли бы технически изменить правила через управление или игнорировать их, сделав это новым де-факто правилом. Но это относится к любой логике цепочки. Дизайн Skip пытается сделать механически невозможным для одного валидатора обманывать в малом масштабе. Например, любая попытка отклониться от порядка будет замечена другими, потому что это объективно. Таким образом, это снижает доверие к отдельным пропозерам. С точки зрения производительности, проведение аукционов и дополнительных проверок добавляет накладные расходы. Однако блоки Cosmos относительно малы, а время между блоками часто составляет пару секунд, чего в большинстве случаев достаточно для этих операций. Симуляция (предварительное выполнение транзакций для обеспечения отсутствия сбоев и ограничений порядка) может быть самой тяжелой частью, но валидаторы уже обычно выполняют блоки, так что это аналогично. Наличие нескольких полос означает разделение мемпула: например, транзакция может потребовать указания, какую полосу она нацеливает (аукционную, свободную или по умолчанию). Дизайн Skip BlockBuster действительно имел отдельные полосы, такие как lanes/auction, lanes/free и т. д., вероятно, отдельные очереди мемпула. Это гарантирует, например, что свободные транзакции не задерживают и не мешают аукционным. Это немного похоже на наличие нескольких классов приоритета в планировании. Еще один аспект — это безопасность и неправомерное поведение: если пропозер пытается обмануть аукцион (например, включить свою собственную транзакцию, но утверждать, что она следовала правилам), другие валидаторы отклонят блок. Консенсус Cosmos затем, вероятно, переходит к следующему пропозеру, наказывая предыдущего за двойную подпись или просто пропуск (в зависимости от сценария). Таким образом, модель безопасности цепочки справляется с этим — никаких специальных наказаний от Skip не требуется, помимо существующего консенсуса. Можно было бы расширить Skip, чтобы наказывать за злонамеренное упорядочивание, но, вероятно, это излишне, если блок просто не проходит. Разработка и инструментарий: Код Skip был открыт (изначально в skip-mev/pob, а теперь, вероятно, перенесен в новый репозиторий после стабильных релизов). Они прошли через тестнеты и итерации с партнерскими цепочками. В дорожной карте мы видели: Предложение Osmosis 341 (принято осенью 2022 года) по интеграции ProtoRev и аукционов со Skip — реализовано в начале 2023 года. Astroport от Terra интегрировал распределение MEV со Skip в 2023 году. Cosmos Hub оценивает «Block SDK» Skip, который принесет аналогичные функции в Hub. Еще один интересный рубеж — это кросс-цепочечный MEV через Interchain Scheduler — сообщество Cosmos Hub исследует межцепочечный аукцион MEV, где MEV из многих цепочек может торговаться на Hub, и Skip участвует в этих обсуждениях (исследование Zerocap отметило запланированный межцепочечный планировщик IBC). Технология Skip могла бы служить основой для таких кросс-цепочечных аукционов, потому что она уже проводит аукционы в отдельных цепочках. Это было бы аналогично кросс-доменной цели SUAVE, но в рамках Cosmos. Что касается ключевых обновлений: Skip запущен примерно в середине 2022 года. К середине 2023 года у них был стабильный релиз POB для SDK v0.47+ (на который многие цепочки переходят). Они также привлекли начальное финансирование, что указывает на активную разработку. Другой конкурент в Cosmos, Mekatek, предлагает аналогичную функциональность. Это, возможно, ускорило дорожную карту Skip, чтобы оставаться впереди. Skip продолжает совершенствовать функции, такие как приватные полосы транзакций (возможно, для скрытия транзакций до их включения) и более сложные правила валидности по мере появления вариантов использования. Поскольку он модульный, цепочка, такая как dYdX (которая будет иметь книгу ордеров), может использовать Skip для обеспечения справедливости в сопоставлении ордеров ончейн и т. д., поэтому инструменты Skip могут адаптироваться к различной логике приложений. Технически решение Skip проще, чем создание совершенно новой цепочки: оно обновляет возможности существующих цепочек. Этот инкрементальный, опциональный подход позволил довольно быстрое внедрение — например, включение аукционов на Osmosis не требовало нового алгоритма консенсуса, а только добавления модуля и координации валидаторов для запуска обновленного программного обеспечения (что они и сделали, поскольку это было выгодно и одобрено управлением). В итоге, архитектура Skip встроена в программное обеспечение узла каждой цепочки, настраивая мемпул и конвейер предложения блоков. Это прагматичный инженерный подход к справедливому упорядочиванию: использовать то, что уже есть (Tendermint BFT), добавить логику для его управления. Тяжелая работа (например, поиск арбитражей) может даже выполняться собственным модулем цепочки (ProtoRev использует встроенный код Wasm и Rust Osmosis для сканирования пулов). Таким образом, большая часть обработки MEV перемещается ончейн. Этот ончейн-подход должен быть тщательно закодирован для эффективности и безопасности, но он находится под контролем сообщества. Если какое-либо правило проблематично (слишком строгое и т. д.), управление может его изменить. Таким образом, технически и социально Skip превращает MEV просто в еще один параметр цепочки, который нужно оптимизировать и управлять, а не в дикий запад. Это уникальная позиция, обеспечиваемая гибкостью Cosmos.

Сравнительный анализ SUAVE, Anoma, Skip и Flashbots v2​

Эти четыре протокола подходят к проблеме MEV и справедливого порядка с разных сторон, адаптированных к их соответствующим экосистемам и философиям дизайна. Flashbots v2 — это инкрементальное, прагматичное решение для текущей архитектуры Ethereum: оно принимает аукционы MEV, но пытается демократизировать и смягчить их воздействие (через офчейн-координацию, конфиденциальность SGX и механизмы совместного использования). SUAVE — это дальновидный план Flashbots по созданию межцепочечной платформы MEV, которая максимизирует общую ценность и выгоды для пользователей — по сути, масштабируя аукционную модель до децентрализованной, сохраняющей конфиденциальность глобальной сети. Anoma — это фундаментальное переосмысление того, как транзакции формулируются и выполняются, с целью устранения первопричин несправедливого порядка путем использования интентов, сопоставления через сольверы и криптографической справедливости в консенсусе. Skip — это подход суверенной цепочки, интегрирующий справедливость и захват MEV на уровне протокола для каждой цепочки, особенно в Cosmos, через настраиваемые правила и аукционы.

Каждый из них имеет свои сильные стороны и компромиссы:

• Гарантии справедливости и порядка: Anoma предлагает самые сильные теоретические гарантии справедливости (отсутствие фронтраннинга по замыслу, зашифрованные пакеты), но требует новой парадигмы и сложной технологии, которая все еще доказывается. Skip может применять конкретные правила справедливости к существующим цепочкам (предотвращая фронтраннинг или обеспечивая порядок «первым пришел — первым обслужен» в пределах полос), но ограничен тем, что каждое сообщество выбирает для обеспечения. SUAVE и Flashbots v2 улучшают справедливость с точки зрения доступа (открытые аукционы, а не секретные сделки, защита от публичного снайпинга в мемпуле), но они не предотвращают по своей сути выполнение определенной стратегии MEV — они просто гарантируют, что она платит пользователям или выполняется нейтрально.
• Перераспределение MEV: SUAVE и Flashbots явно стремятся вернуть MEV «обратно» пользователям/валидаторам: SUAVE через ставки/возмещения пользователей, Flashbots через конкуренцию билдеров и возмещения. Skip может направлять MEV пользователям (как настроено, например, в случае Astroport) или в общественные фонды. Anoma избегает явного перераспределения, потому что цель состоит в том, чтобы избежать извлечения в первую очередь — в идеале пользователи просто получают справедливые цены, что эквивалентно отсутствию потери ценности из-за MEV.
• Область применения (одно- или многодоменная): Flashbots v2 и Skip сосредоточены на своих собственных доменах (Ethereum и отдельные цепочки Cosmos соответственно). SUAVE по своей сути многодоменный — он рассматривает кросс-цепочечный MEV как основную мотивацию. Anoma также в конечном итоге рассматривает многоцепочечные интенты, но на начальных этапах это может быть в рамках одного фрактального экземпляра за раз, затем мостовое соединение через адаптеры. Кросс-цепочечный аукцион SUAVE может разблокировать арбитраж и координацию, которые другие не могут сделать так легко (за исключением, возможно, Interchain Scheduler с помощью Skip в Cosmos).
• Сложность и принятие: Flashbots v2 был относительно прост в принятии (сайдкар-клиент) и быстро захватил большинство блоков Ethereum. Skip также использует существующие технологии и наблюдает принятие в Cosmos с помощью простых предложений по управлению. SUAVE и Anoma более революционны — они требуют новых сетей или серьезных изменений. Задача SUAVE будет заключаться в том, чтобы многие цепочки и пользователи согласились на новый уровень; задача Anoma — создать новую экосистему и убедить разработчиков строить в интент-ориентированной модели.
• Соответствие и нейтральность: Все четыре предлагают улучшения в прозрачности. Flashbots v2/SUAVE устраняют элементы «темного леса», но им приходилось управлять проблемами цензуры — SUAVE явно строится, чтобы избежать этих центральных точек. Anoma, с конфиденциальностью по умолчанию, максимально защищает пользователей (но может беспокоить регуляторов из-за зашифрованной активности). Модель Skip дает каждой цепочке автономию для достижения компромисса в соответствии. Если регулятор потребует «без аукционов MEV» или «без конфиденциальности», Ethereum, использующий Flashbots, может столкнуться с конфликтом, тогда как цепочка Cosmos, использующая Skip, могла бы просто не реализовывать эти функции или корректировать их. С точки зрения нейтральности: SUAVE и Anoma стремятся к достоверной нейтральности (каждый получает доступ к одной системе на равных условиях; обе по сути являются сетями общественного блага). Flashbots v2 нейтрален в предоставлении открытого доступа, но некоторая централизация существует на рынке билдеров (хотя и смягчается усилиями BuilderNet). Нейтральность Skip зависит от управления — в идеале она делает MEV невыгодным для любого инсайдера, но ее можно плохо настроить и нанести ущерб нейтральности (хотя это маловероятно, так как для этого потребуется консенсус управления).
• Различия в технической архитектуре: Flashbots v2 и SUAVE — это офчейн-рынки, наложенные на цепочку: они вводят специализированные роли (билдеры, ретрансляторы, исполнители) и используют аппаратное обеспечение или криптографию для их защиты. Anoma и Skip интегрируются непосредственно в консенсус или конечный автомат. Anoma изменяет жизненный цикл транзакций и сам консенсус (с пороговым шифрованием и унифицированными интентами). Skip подключается к консенсусу Tendermint через ABCI++, но не меняет фундаментальный алгоритм — это настройка на уровне приложения. Это различие означает, что SUAVE/Flashbots теоретически могут обслуживать многие цепочки без обновления каждой цепочки (они работают параллельно с ними), тогда как Anoma/Skip требуют, чтобы каждая цепочка или экземпляр использовали новое программное обеспечение. SUAVE находится где-то посередине: это отдельная цепочка, но для эффективного использования другие цепочки нуждаются в небольших корректировках (чтобы принимать блоки, построенные SUAVE, или выводить данные в SUAVE). Криптографическая сложность самая высокая в Anoma (ZK, MPC, пороговая криптография все в одном), умеренная в SUAVE (пороговая криптография и SGX, плюс обычная криптография для мостового соединения) и относительно низкая в Flashbots v2 (SGX, стандартные подписи) и Skip (в основном стандартные подписи, плюс то, что использует цепочка, например, пороговое дешифрование, если выбрано).
• Стадия разработки: Flashbots v2 в производстве на Ethereum (с сентября 2022 года). Skip в производстве на нескольких цепочках Cosmos (с 2022–2023 годов). SUAVE находится на стадии тестнета/девнета с поэтапным развертыванием частей (некоторые функции аукциона тестируются, тестнет Toliman запущен). Anoma также находится на стадии тестнета (визионерский документ, частичные реализации, такие как основная сеть Namada, и, вероятно, тестнет Anoma, требующий кодов приглашения в 2023 году). Таким образом, с точки зрения реальных данных: Flashbots v2 и Skip продемонстрировали результаты (например, Flashbots v2 принес миллионы валидаторам и снизил средние цены на газ в периоды высокого MEV; ProtoRev Skip принес значительные средства сообществу Osmosis и предотвратил многие сэндвич-атаки по мере внедрения порогового шифрования). SUAVE и Anoma многообещающи, но им еще предстоит доказать свою работоспособность и экономическую эффективность.

Чтобы кристаллизовать эти сравнения, таблица ниже суммирует ключевые аспекты каждого протокола бок о бок:

Каждое решение нацелено на проблему MEV с разных уровней — Flashbots v2 работает вокруг консенсуса L1, SUAVE предлагает новый уровень L1.5, Anoma перепроектирует сам L1, а Skip использует модульную настройку L1. На практике эти подходы не являются взаимоисключающими и даже могут дополнять друг друга (например, цепочка Cosmos может использовать Skip внутри и также отправлять интенты в SUAVE для кросс-цепочечного MEV, или Ethereum может реализовать некоторую справедливость порядка, подобную Anoma, в будущем, продолжая использовать Flashbots для рынков билдеров). Таблица иллюстрирует их сравнительные свойства: Flashbots v2 уже приносит улучшения в Ethereum, но все еще извлекает MEV (просто более справедливо и эффективно); SUAVE стремится к максимальному синергетическому результату, где все сотрудничают через одну сеть — его успех будет зависеть от широкого принятия и технической реализации обещанной конфиденциальности и децентрализации; Anoma предлагает, возможно, самое мощное подавление MEV, полностью изменяя способ работы транзакций, но сталкивается с серьезной проблемой создания новой экосистемы и доказательства своего сложного протокола; Skip находит прагматичный баланс для Cosmos, позволяя сообществам активно управлять MEV и справедливостью на своих условиях — он менее радикален, чем Anoma, но более встроен, чем Flashbots, и уже показывает ощутимые результаты в Cosmos.

Заключение и перспективы​

Подавление MEV и справедливый порядок остаются одной из «проблем тысячелетия криптоиндустрии». Четыре проанализированных протокола — Flashbots v2, SUAVE, Anoma и Skip — представляют собой спектр решений: от немедленных смягчений в существующих фреймворках до полных сдвигов парадигмы в обработке транзакций. Flashbots v2 продемонстрировал силу открытых рынков MEV в снижении хаоса и перераспределении ценности, хотя и с учетом компромиссов, таких как цензура, которые решаются путем децентрализации. Он показывает, что инкрементальные изменения (такие как аукционы PBS и приватные мемпулы) могут значительно уменьшить боль от MEV в краткосрочной перспективе. SUAVE, следующий шаг Flashbots, развивает эту этику на единой кросс-цепочечной арене — если он преуспеет, мы можем увидеть будущее, где пользователи регулярно получают плату за MEV, создаваемый их сделками, и где производство блоков во многих сетях является совместным и зашифрованным для обеспечения справедливости. Anoma указывает на более фундаментальную эволюцию: устраняя концепцию приоритетных транзакций и заменяя ее системой сопоставления интентов, она может исключить целые классы MEV и разблокировать более выразительные финансовые DApp. Ее справедливый порядок на уровне консенсуса (через пороговое шифрование и пакетные аукционы) — это взгляд на то, как сами блокчейны могут предоставлять гарантии справедливости, а не только офчейн-дополнения. Skip Protocol, тем временем, представляет собой золотую середину в многоцепочечном контексте — он дает отдельным цепочкам возможность решать, как балансировать доход от MEV и защиту пользователей. Его раннее принятие в Cosmos показывает, что многие негативные последствия MEV могут быть решены сегодня с помощью продуманной инженерии протокола и согласия сообщества.

В дальнейшем мы можем ожидать взаимопроникновения идей: исследователи Ethereum изучают консенсус, обеспечивающий справедливый порядок, и пороговое шифрование (вдохновленные такими проектами, как Anoma и зашифрованный мемпул Osmo) для потенциального включения в решения L1 или L2. SUAVE от Flashbots может взаимодействовать с цепочками Cosmos (возможно, даже через Skip), поскольку он стремится быть агностическим к цепочкам. Концепция интентов Anoma может повлиять на дизайн приложений даже на традиционных платформах (например, CoW Swap на Ethereum уже использует модель сольверов; его можно рассматривать как DApp, «подобный Anoma»). Успех Skip может побудить другие экосистемы (Polkadot, Solana и т. д.) принять аналогичные внутрипротокольные механизмы контроля MEV. Ключевая тема — экономическое выравнивание — все эти протоколы стремятся выровнять стимулы тех, кто обеспечивает безопасность сети, с благосостоянием пользователей, чтобы эксплуатация пользователей не была прибыльной или невозможной. Это имеет решающее значение для долгосрочного здоровья блокчейн-экосистем и предотвращения централизации.

В итоге, SUAVE, Anoma, Skip и Flashbots v2 каждый вносят свой вклад в решение головоломки справедливого порядка и смягчения MEV. Flashbots v2 установил шаблон для аукционов MEV, который другие имитируют, Skip доказал, что ончейн-принуждение жизнеспособно, Anoma расширила представление о том, что возможно, перестроив модель транзакций, а SUAVE стремится унифицировать и децентрализовать достижения прошлых лет. Окончательное решение может включать элементы всех: глобальные аукционы с сохранением конфиденциальности, интент-ориентированные пользовательские интерфейсы, правила справедливости на уровне цепочки и совместное создание блоков. По состоянию на 2025 год борьба с несправедливостью, вызванной MEV, идет полным ходом — эти протоколы превращают MEV из темной неизбежности в управляемую, даже продуктивную часть криптоэкономики, приближаясь к идеалу «лучшего выполнения для пользователей с максимально децентрализованной инфраструктурой».

Представляем сводное резюме отчета об инновациях в области опыта разработчиков Web3 (DevEx).

Краткое изложение​

Опыт разработчиков Web3 значительно улучшился в 2024-2025 годах благодаря инновациям в языках программирования, наборах инструментов и инфраструктуре развертывания. Разработчики сообщают о повышении производительности и удовлетворенности благодаря более быстрым инструментам, более безопасным языкам и оптимизированным рабочим процессам. В этом резюме объединены результаты по пяти ключевым наборам инструментов (Solidity, Move, Sway, Foundry и Cairo 1.0) и двум основным тенденциям: развертыванию роллапов «в один клик» и горячей перезагрузке смарт-контрактов.

Сравнение наборов инструментов для разработчиков Web3​

Каждый набор инструментов предлагает свои уникальные преимущества, ориентированные на различные экосистемы и философии разработки.

• Solidity (EVM): Остается самым доминирующим языком благодаря своей огромной экосистеме, обширным библиотекам (например, OpenZeppelin) и зрелым фреймворкам, таким как Hardhat и Foundry. Хотя ему не хватает нативных функций, таких как макросы, его широкое распространение и сильная поддержка сообщества делают его выбором по умолчанию для Ethereum и большинства EVM-совместимых L2.
• Move (Aptos/Sui): Приоритизирует безопасность и формальную верификацию. Его ресурсно-ориентированная модель и инструмент Move Prover помогают предотвращать распространенные ошибки, такие как повторный вход, по своей конструкции. Это делает его идеальным для высокозащищенных финансовых приложений, хотя его экосистема меньше и сосредоточена на блокчейнах Aptos и Sui.
• Sway (FuelVM): Разработан для максимальной производительности разработчиков, позволяя им писать контракты, скрипты и тесты на одном языке, похожем на Rust. Он использует высокопроизводительную архитектуру Fuel Virtual Machine на основе UTXO, что делает его мощным выбором для ресурсоемких приложений в сети Fuel.
• Foundry (EVM Toolkit): Трансформационный набор инструментов для Solidity, который произвел революцию в разработке EVM. Он предлагает чрезвычайно быструю компиляцию и тестирование, позволяя разработчикам писать тесты непосредственно на Solidity. Такие функции, как фаззинг-тестирование, форкинг основной сети и "чит-коды", сделали его основным выбором для более чем половины разработчиков Ethereum.
• Cairo 1.0 (Starknet): Представляет собой значительное улучшение DevEx для экосистемы Starknet. Переход к высокоуровневому синтаксису, вдохновленному Rust, и современным инструментам (таким как менеджер пакетов Scarb и Starknet Foundry) значительно ускорил и упростил разработку для ZK-роллапов. Хотя некоторые инструменты, такие как отладчики, все еще находятся в стадии доработки, удовлетворенность разработчиков резко возросла.

Ключевые инновации DevEx​

Две основные тенденции меняют подход разработчиков к созданию и развертыванию децентрализованных приложений.

Развертывание роллапов "в один клик"​

Запуск кастомного блокчейна (L2/appchain) стал радикально проще.

• Основа: Фреймворки, такие как OP Stack от Optimism, предоставляют модульный, открытый исходный код для создания роллапов.
• Платформы: Сервисы, такие как Caldera и Conduit, создали платформы Rollup-as-a-Service (RaaS). Они предлагают веб-панели управления, которые позволяют разработчикам развернуть кастомизированный роллап основной или тестовой сети за считанные минуты, с минимальным опытом в блокчейн-инженерии.
• Влияние: Это обеспечивает быструю экспериментировку, снижает барьер для создания цепочек, специфичных для приложений, и упрощает DevOps, позволяя командам сосредоточиться на своем приложении, а не на инфраструктуре.

Горячая перезагрузка для смарт-контрактов​

Эта инновация переносит цикл мгновенной обратной связи современного веб-разработки в пространство блокчейна.

• Концепция: Инструменты, такие как Scaffold-ETH 2, автоматизируют цикл разработки. Когда разработчик сохраняет изменение в смарт-контракте, инструмент автоматически перекомпилирует, повторно развертывает его в локальной сети и обновляет фронтенд, чтобы отразить новую логику.
• Влияние: Горячая перезагрузка устраняет повторяющиеся ручные шаги и значительно сокращает цикл итераций. Это делает процесс разработки более увлекательным, снижает порог вхождения для новых разработчиков и поощряет частое тестирование, что приводит к созданию более качественного кода.

Заключение​

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

Источники:

• Solidity Developer Survey 2024 – Soliditylang (2025)
• Moncayo Labs on Aptos Move vs Solidity (2024)
• Aptos Move Prover intro – Monethic (2025)
• Fuel Labs – Fuel & Sway Documentation (2024); Fuel Book (2024)
• Spearmanrigoberto – Foundry vs Hardhat (2023)
• Medium (Rosario Borgesi) – Building Dapps with Scaffold-ETH 2 (2024)
• Starknet/Cairo developer survey – Cairo-lang.org (2024)
• Starknet Dev Updates – Starknet.io (2024–2025)
• Solidity forum – Macro preprocessor discussion (2023)
• Optimism OP Stack overview – CoinDesk (2025)
• Caldera rollup platform overview – Medium (2024)
• Conduit platform recap – Conduit Blog (2025)
• Blockchain DevEx literature review – arXiv (2025)

Введение​

Быстрый рост блокчейнов Уровня 1 и Уровня 2 привел к фрагментации пользовательского опыта Web3. Сегодня пользователям приходится жонглировать множеством кошельков, сетей и мостов токенов, чтобы выполнить сложные задачи, охватывающие несколько цепей. Абстракция цепи и интент-ориентированная архитектура стали ключевыми парадигмами для упрощения этого ландшафта. Абстрагируясь от специфических для цепи деталей и позволяя пользователям действовать на основе интентов (желаемых результатов), а не создавать явные транзакции для каждой цепи, эти подходы обещают унифицированный, бесшовный межцепочечный опыт. Этот отчет углубляется в основные принципы абстракции цепи, проектирование интент-ориентированных моделей исполнения, реальные реализации (такие как Wormhole и Etherspot), технические основы (релееры, смарт-кошельки и т. д.) и преимущества UX для разработчиков и конечных пользователей. Мы также суммируем выводы с EthCC 2025 – где абстракция цепи и интенты были горячими темами – и приводим сравнительную таблицу различных подходов протоколов.

Принципы абстракции цепи​

Абстракция цепи относится к любой технологии или фреймворку, который представляет пользователям и разработчикам несколько блокчейнов так, как если бы они были единой унифицированной средой. Мотивация состоит в устранении трения, вызванного гетерогенностью цепей. На практике абстракция цепи означает:

• Унифицированные интерфейсы: Вместо управления отдельными кошельками и конечными точками RPC для каждого блокчейна, пользователи взаимодействуют через один интерфейс, который скрывает детали сети. Разработчики могут создавать dApps без развертывания отдельных контрактов в каждой цепи или написания пользовательской логики моста для каждой сети.
• Отсутствие ручного бриджинга: Перемещение активов или данных между цепями происходит за кулисами. Пользователи не выполняют вручную транзакции блокировки/минта моста или обмена для токенов моста; уровень абстракции обрабатывает это автоматически. Например, пользователь может предоставить ликвидность протоколу независимо от того, в какой цепи находится ликвидность, и система соответствующим образом маршрутизирует средства.
• Абстракция платы за газ: Пользователям больше не нужно держать нативный токен каждой цепи для оплаты газа в этой цепи. Уровень абстракции может спонсировать плату за газ или позволять оплачивать газ в активе по выбору пользователя. Это снижает барьер для входа, поскольку не нужно отдельно приобретать ETH, MATIC, SOL и т. д.
• Сетевая агностическая логика: Логика приложения становится цепе-независимой. Смарт-контракты или внецепочечные сервисы координируют выполнение действий пользователя в любых необходимых цепях, не требуя от пользователя вручную переключать сети или подписывать несколько транзакций. По сути, пользовательский опыт представляет собой одну «мета-цепь» или блокчейн-агностический уровень приложения.

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

Мотивация: Стремление к абстракции цепи проистекает из болевых точек в текущих межцепочечных рабочих процессах. Управление отдельными кошельками для каждой цепи и выполнение многоэтапных межцепочечных операций (обмен в Цепи A, бридж в Цепь B, снова обмен в Цепи B и т. д.) утомительно и подвержено ошибкам. Фрагментированная ликвидность и несовместимые кошельки также ограничивают рост dApp в экосистемах. Абстракция цепи решает эти проблемы путем связного объединения экосистем. Важно отметить, что она рассматривает Ethereum и его многочисленные L2 и сайдчейны как часть единого пользовательского опыта. EthCC 2025 подчеркнул, что это критически важно для массового внедрения — докладчики утверждали, что по-настоящему ориентированное на пользователя будущее Web3 «должно абстрагироваться от блокчейнов», делая мир мультичейн таким же простым, как одна сеть.

Интент-ориентированная архитектура: от транзакций к интентам​

Традиционные взаимодействия с блокчейном транзакционно-ориентированы: пользователь явно создает и подписывает транзакцию, которая выполняет определенные операции (вызывает функцию контракта, передает токен и т. д.) в выбранной цепи. В контексте мультичейн достижение сложной цели может потребовать множества таких транзакций в разных сетях, каждая из которых вручную инициируется пользователем в правильной последовательности. Интент-ориентированная архитектура переворачивает эту модель. Вместо микроуправления транзакциями пользователь объявляет интент — высокоуровневую цель или желаемый результат — и позволяет автоматизированной системе выяснить, какие транзакции необходимы для его выполнения.

При интент-ориентированном дизайне пользователь может сказать: «Обменять 100 USDC на Base на 100 USDT на Arbitrum». Этот интент инкапсулирует что (обмен одного актива на другой в целевой цепи), не предписывая как. Затем специализированный агент (часто называемый решателем) берет на себя задачу его выполнения. Решатель определит, как лучше всего выполнить обмен между цепями — например, он может перевести USDC с Base на Arbitrum с помощью быстрого моста, а затем выполнить обмен на USDT, или использовать протокол прямого межцепочечного обмена — что бы ни принесло лучший результат. Пользователь подписывает одно разрешение, а решатель обрабатывает сложную последовательность в бэкэнде, включая поиск оптимального маршрута, отправку необходимых транзакций в каждой цепи и даже авансирование любых требуемых комиссий за газ или принятие на себя промежуточного риска.

Как интенты обеспечивают гибкое выполнение: Предоставляя системе свободу решать, как выполнить запрос, интент-ориентированный дизайн позволяет создавать гораздо более интеллектуальные и гибкие уровни выполнения, чем фиксированные пользовательские транзакции. Некоторые преимущества:

• Оптимальная маршрутизация: Решатели могут оптимизировать по стоимости, скорости или надежности. Например, несколько решателей могут конкурировать за выполнение интента пользователя, и ончейн-аукцион может выбрать того, кто предлагает лучшую цену (например, лучший обменный курс или самые низкие комиссии). Эта конкуренция снижает затраты для пользователя. Протокол Mayan Swift от Wormhole является примером, который встраивает ончейн-аукцион английского типа на Solana для каждого интента, смещая конкуренцию с гонки «первым пришел» на ценовое предложение для лучших результатов для пользователя. Решатель, который может выполнить обмен наиболее выгодно для пользователя, выигрывает ставку и выполняет план, гарантируя, что пользователь получит максимальную выгоду. Такой вид динамического определения цены невозможен, когда пользователь заранее указывает один путь в обычной транзакции.
• Устойчивость и гибкость: Если один мост или DEX недоступен или неоптимален в данный момент, решатель может выбрать альтернативный путь. Интент остается тем же, но уровень выполнения может адаптироваться к условиям сети. Таким образом, интенты позволяют использовать программируемые стратегии выполнения — например, разделение ордера или повторную попытку через другой маршрут — все это невидимо для конечного пользователя, которого волнует только достижение его цели.
• Атомарные мультичейн-действия: Интенты могут охватывать то, что традиционно было бы множеством транзакций в разных цепях. Фреймворки выполнения стремятся сделать всю последовательность ощущаемой как атомарная или, по крайней мере, управляемой при сбоях. Например, решатель может считать интент выполненным только тогда, когда все подтранзакции (мост, обмен и т. д.) подтверждены, и откатить или компенсировать, если что-то не удастся. Это гарантирует, что высокоуровневое действие пользователя либо будет выполнено полностью, либо не будет выполнено вообще, что повышает надежность.
• Снятие сложности: Интенты значительно упрощают роль пользователя. Пользователю не нужно понимать, какие мосты или биржи использовать, как распределять ликвидность или как планировать операции — все это перекладывается на инфраструктуру. Как говорится в одном отчете, «пользователи сосредоточены на что, а не на как». Прямым преимуществом является пользовательский опыт: взаимодействие с блокчейн-приложениями становится больше похоже на использование приложения Web2 (где пользователь просто запрашивает результат, а сервис обрабатывает процесс).

По сути, интент-ориентированная архитектура повышает уровень абстракции от низкоуровневых транзакций до высокоуровневых целей. Сообщество Ethereum настолько заинтересовано в этой модели, что Ethereum Foundation представила Открытую структуру интентов (OIF), открытый стандарт и эталонную архитектуру для создания межцепочечных интент-систем. OIF определяет стандартные интерфейсы (например, формат интента ERC-7683) для того, как интенты создаются, передаются и рассчитываются между цепями, чтобы множество различных решений (мосты, релееры, механизмы аукционов) могли модульно подключаться. Это стимулирует целую экосистему решателей и протоколов расчетов, которые могут взаимодействовать. Рост интентов основан на необходимости сделать Ethereum и его роллапы «похожими на одну цепь» с точки зрения UX — достаточно быстрыми и бесшовными, чтобы перемещение между L2 или сайдчейнами происходило за секунды без головной боли для пользователя. Ранние стандарты, такие как ERC-7683 (для стандартизированного формата и жизненного цикла интентов), даже получили поддержку от таких лидеров, как Виталик Бутерин, что подчеркивает динамику интент-ориентированных дизайнов.

Краткое изложение ключевых преимуществ: Подводя итог, интент-ориентированные архитектуры приносят несколько ключевых преимуществ: (1) Упрощенный UX — пользователи заявляют, что они хотят, а система выясняет остальное; (2) Межцепочечная плавность — операции, охватывающие несколько сетей, обрабатываются бесшовно, эффективно рассматривая многие цепи как одну; (3) Масштабируемость для разработчиков — разработчики dApp могут охватывать пользователей и ликвидность во многих цепях, не изобретая велосипед для каждой, потому что уровень интентов предоставляет стандартизированные хуки для межцепочечного выполнения. Разделяя что нужно сделать от как/где это делается, интенты действуют как мост между удобными для пользователя инновациями и сложной интероперабельностью за кулисами.

Технические строительные блоки межцепочечной абстракции​

Реализация абстракции цепи и интент-ориентированного выполнения требует стека технических механизмов, работающих согласованно. Ключевые компоненты включают:

• Релееры межцепочечных сообщений: В основе любой мультичейн-системы лежит уровень обмена сообщениями, который может надежно передавать данные и ценность между блокчейнами. Протоколы, такие как Wormhole, Hyperlane, Axelar, LayerZero и другие, предоставляют эту возможность, ретранслируя сообщения (часто с доказательствами или аттестациями валидаторов) из исходной цепи в одну или несколько целевых цепей. Эти сообщения могут содержать команды, такие как «выполнить этот интент» или «сминтить этот актив» в целевой цепи. Надежная сеть релееров имеет решающее значение для унифицированной маршрутизации транзакций — она служит «почтовой службой» между цепями. Например, сеть Wormhole из 19 узлов Guardian наблюдает за событиями в подключенных цепях и подписывает VAA (подтверждение проверяемого действия), которое может быть отправлено в любую другую цепь для доказательства того, что событие произошло. Это отделяет действие от любой отдельной цепи, обеспечивая цепе-независимое поведение. Современные релееры сосредоточены на том, чтобы быть цепе-независимыми (поддерживать множество типов цепей) и децентрализованными для безопасности. Wormhole, например, выходит за рамки цепей на основе EVM для поддержки Solana, цепей Cosmos и т. д., что делает его универсальным выбором для межцепочечной связи. Уровень обмена сообщениями часто также обрабатывает упорядочивание, повторные попытки и гарантии завершенности для межцепочечных транзакций.

• Смарт-кошельки (абстракция аккаунта): Абстракция аккаунта (например, ERC-4337 Ethereum) заменяет внешние аккаунты аккаунтами смарт-контрактов, которые могут быть запрограммированы с помощью пользовательской логики валидации и многоэтапных транзакционных возможностей. Это основа для абстракции цепи, потому что смарт-кошелек может служить единым мета-аккаунтом пользователя, контролирующим активы во всех цепях. Проекты, такие как Etherspot, используют смарт-кошельки для включения таких функций, как пакетная обработка транзакций и сессионные ключи между цепями. Интент пользователя может быть упакован как одна пользовательская операция (в терминах 4337), которую контракт кошелька затем расширяет до нескольких подтранзакций в разных сетях. Смарт-кошельки также могут интегрировать пеймастеров (спонсоров) для оплаты комиссий за газ от имени пользователя, обеспечивая истинную абстракцию газа (пользователь может платить в стейблкоине или вообще не платить). Механизмы безопасности, такие как сессионные ключи (временные ключи с ограниченными разрешениями), позволяют пользователям одобрять интенты, включающие несколько действий, без множества запросов, при этом ограничивая риск. Короче говоря, абстракция аккаунта предоставляет программируемый контейнер выполнения, который может интерпретировать высокоуровневый интент и оркестровать необходимые шаги как серию транзакций (часто через релееров).

• Оркестрация интентов и решатели: Над уровнем обмена сообщениями и кошельков находится сеть решателей интентов — мозг, который выясняет, как выполнить интенты. В некоторых архитектурах эта логика находится в цепи (например, ончейн-контракт аукциона, который сопоставляет ордера интентов с решателями, как в аукционе Wormhole на Solana для Mayan Swift). В других это внецепочечные агенты, отслеживающие мемпул интентов или книгу ордеров (например, Открытая структура интентов предоставляет эталонный решатель на TypeScript, который прослушивает новые события интентов, а затем отправляет транзакции для их выполнения). Решатели обычно должны обрабатывать: поиск маршрутов ликвидности (через DEX, мосты), определение цены (обеспечение справедливой ставки для пользователя) и иногда покрытие промежуточных затрат (например, размещение залога или принятие на себя риска завершенности — доставка средств пользователю до того, как межцепочечный перевод будет полностью завершен, тем самым ускоряя UX с некоторым риском для решателя). Хорошо спроектированная интент-ориентированная система часто включает конкуренцию между решателями для обеспечения оптимального выполнения интента пользователя. Решатели могут быть экономически стимулированы (например, они получают комиссию или арбитражную прибыль за выполнение интента). Механизмы, такие как аукционы решателей или пакетная обработка, могут использоваться для максимизации эффективности. Например, если несколько пользователей имеют схожие интенты, решатель может объединить их в пакет, чтобы минимизировать комиссии моста для каждого пользователя.

• Единая ликвидность и абстракция токенов: Перемещение активов между цепями создает классическую проблему фрагментированной ликвидности и обернутых токенов. Уровни абстракции цепи часто абстрагируют сами токены — стремясь предоставить пользователю опыт единого актива, который может использоваться во многих цепях. Один из подходов — омничейн-токены (где токен может существовать нативно в нескольких цепях под одним общим предложением, вместо множества несовместимых обернутых версий). Wormhole представил Нативные переводы токенов (NTT) как эволюцию традиционных мостов блокировки и минта: вместо бесконечных «мостовых» токенов IOU, фреймворк NTT рассматривает токены, развернутые в разных цепях, как один актив с общими элементами управления минтом/сжиганием. На практике, бриджинг актива в рамках NTT означает сжигание в исходной цепи и минт в целевой, поддерживая единое циркулирующее предложение. Такая унификация ликвидности имеет решающее значение, чтобы абстракция цепи могла «телепортировать» активы, не сбивая пользователя с толку множеством представлений токенов. Другие проекты используют сети ликвидности или пулы (например, Connext или Axelar), где поставщики ликвидности предоставляют капитал в каждой цепи для обмена активами, так что пользователи могут эффективно обменивать один актив на его эквивалент в другой цепи за один шаг. Пример фонда Securitize SCOPE показателен: токен институционального фонда был сделан мультичейн, так что инвесторы могут подписываться или выкупать на Ethereum или Optimism, а за кулисами протокол Wormhole перемещает токен и даже конвертирует его в доходные формы, устраняя необходимость в ручных мостах или нескольких кошельках для пользователей.

• Программируемые уровни выполнения: Наконец, некоторые ончейн-инновации расширяют возможности более сложных межцепочечных рабочих процессов. Поддержка атомарных мультивызовов и планирование транзакций помогают координировать многоэтапные интенты. Например, Программируемые блоки транзакций (PTB) блокчейна Sui позволяют объединять несколько действий (таких как обмены, переводы, вызовы) в одну атомарную транзакцию. Это может упростить выполнение межцепочечных интентов на Sui, гарантируя, что все шаги либо произойдут, либо ни один из них не произойдет, с одной подписью пользователя. В Ethereum предложения, такие как EIP-7702 (код смарт-контракта для EOA), расширяют возможности пользовательских аккаунтов для поддержки таких вещей, как спонсируемый газ и многоэтапная логика даже на базовом уровне. Более того, могут использоваться специализированные среды выполнения или межцепочечные маршрутизаторы — например, некоторые системы маршрутизируют все интенты через определенный L2 или хаб, который координирует межцепочечные действия (пользователь может просто взаимодействовать с этим хабом). Примеры включают проекты, такие как L1 протокола Push (Push Chain), который разрабатывается как выделенный уровень расчетов для цепе-независимых операций, с универсальными смарт-контрактами и завершенностью менее чем за секунду для ускорения межцепочечных взаимодействий. Хотя эти подходы не получили всеобщего распространения, они иллюстрируют спектр методов, используемых для реализации абстракции цепи: от чисто внецепочечной оркестрации до развертывания новой ончейн-инфраструктуры, специально созданной для выполнения межцепочечных интентов.

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

Пример 1: Wormhole – интент-ориентированная, цепе-независимая маршрутизация​

Wormhole — это ведущий протокол межцепочечной интероперабельности, который эволюционировал из моста токенов в комплексную сеть передачи сообщений с интент-ориентированной функциональностью. Его подход к абстракции цепи заключается в предоставлении единого уровня маршрутизации сообщений, соединяющего более 20 цепей (включая цепи EVM и не-EVM цепи, такие как Solana), и поверх этого — создании цепе-независимых прикладных протоколов. Ключевые элементы архитектуры Wormhole включают:

• Уровень общих сообщений: По своей сути Wormhole — это общий мост publish/subscribe. Валидаторы (Guardians) наблюдают за событиями в каждой подключенной цепи и подписывают VAA (проверяемое действие), которое может быть отправлено в любую другую цепь для воспроизведения события или вызова целевого контракта. Этот общий дизайн означает, что разработчики могут отправлять произвольные инструкции или данные между цепями, а не только переводы токенов. Wormhole обеспечивает последовательную доставку и проверку сообщений, абстрагируясь от того, была ли источником Ethereum, Solana или другая цепь.

• Цепе-независимые переводы токенов: Оригинальный мост токенов Wormhole (Portal) использовал подход блокировки и минта. Недавно Wormhole представил Нативные переводы токенов (NTT), улучшенный фреймворк для мультичейн-токенов. С NTT активы могут выпускаться нативно в каждой цепи (избегая фрагментированных обернутых токенов), в то время как Wormhole обрабатывает учет сжиганий и минтов между цепями для синхронизации предложения. Для пользователей это похоже на «телепортацию» токена между цепями — они депонируют в одной цепи и выводят тот же актив в другой, при этом Wormhole управляет учетом минта/сжигания. Это форма абстракции токенов, которая скрывает сложность различных стандартов токенов и адресов в каждой цепи.

• Интент-ориентированные протоколы xApp: Признавая, что бриджинг токенов — это лишь часть межцепочечного UX, Wormhole разработал протоколы более высокого уровня для выполнения интентов пользователя, таких как обмены или переводы с управлением комиссиями за газ. В 2023–2024 годах Wormhole сотрудничал с межцепочечным агрегатором DEX Mayan для запуска двух интент-ориентированных протоколов, часто называемых xApps (кросс-чейн приложения) в экосистеме Wormhole: Mayan Swift и Mayan MCTP (Мультичейн протокол передачи).

  • Mayan Swift описывается как «гибкий протокол межцепочечных интентов», который по сути позволяет пользователю запросить обмен токенов из Цепи A в Цепь B. Пользователь подписывает одну транзакцию в исходной цепи, блокируя свои средства и указывая желаемый результат (например, «Я хочу получить не менее X количества токена Y в целевой цепи к времени T»). Этот интент (ордер) затем подхватывается решателями. Уникально, что Wormhole Swift использует ончейн-аукцион на Solana для проведения конкурентного определения цены для интента. Решатели отслеживают специальный контракт Solana; когда создается новый ордер интента, они делают ставки, обязуясь, сколько выходного токена они могут доставить. В течение короткого периода аукциона (например, 3 секунды) ставки конкурируют, повышая цену. Победитель аукциона (тот, кто предлагает наиболее выгодный курс для пользователя) выигрывает и получает право выполнить обмен. Затем Wormhole передает сообщение в целевую цепь, авторизуя этого решателя доставить токены пользователю, и еще одно сообщение обратно для высвобождения заблокированных средств пользователя решателю в качестве оплаты. Этот дизайн гарантирует, что интент пользователя будет выполнен по наилучшей возможной цене децентрализованным способом, при этом пользователю нужно было взаимодействовать только со своей исходной цепью. Он также разделяет межцепочечный обмен на два шага (блокировка средств, затем выполнение в целевой цепи) для минимизации риска. Интент-ориентированный дизайн здесь показывает, как абстракция позволяет умное выполнение: вместо того, чтобы пользователь выбирал конкретный мост или DEX, система автоматически находит оптимальный путь и цену.

  • Mayan MCTP фокусируется на межцепочечных переводах активов с управлением газом и комиссиями. Он использует CCTP (Протокол кросс-чейн передачи) Circle — который позволяет сжигать нативный USDC в одной цепи и минтить в другой — в качестве основы для передачи ценности, и использует обмен сообщениями Wormhole для координации. При передаче MCTP интент пользователя может быть просто «переместить мой USDC из Цепи A в Цепь B (и, возможно, обменять на другой токен в B)». Контракт исходной цепи принимает токены и желаемое назначение, затем инициирует сжигание через CCTP и одновременно публикует сообщение Wormhole, содержащее метаданные, такие как адрес назначения пользователя, желаемый токен в назначении и даже газовый дроп (количество переведенных средств для конвертации в нативный газ в назначении). В целевой цепи, как только Circle минтит USDC, релеер Wormhole обеспечивает доставку и проверку метаданных интента. Затем протокол может автоматически, например, обменять часть USDC на нативный токен для оплаты газа и доставить остальное в кошелек пользователя (или в указанный контракт). Это обеспечивает одношаговый мост с включенным газом: пользователю не нужно приобретать газ в новой цепи или выполнять отдельный обмен для газа. Все это закодировано в интенте и обрабатывается сетью. Таким образом, MCTP демонстрирует, как абстракция цепи может обрабатывать абстракцию комиссий и надежные переводы в одном потоке. Роль Wormhole заключается в безопасной передаче интента и доказательства того, что средства были перемещены (через CCTP), чтобы запрос пользователя был выполнен от начала до конца.

Иллюстрация интент-ориентированной архитектуры обмена Wormhole (Mayan Swift). В этом дизайне пользователь блокирует активы в исходной цепи и определяет результат (интент). Решатели делают ставки на ончейн-аукционе за право выполнить этот интент. Выигравший решатель использует сообщения Wormhole для координации разблокировки средств и доставки результата в целевую цепи, при этом гарантируя, что пользователь получит лучшую цену за свой обмен.

• Унифицированный UX и потоки в один клик: Приложения на базе Wormhole все чаще предлагают межцепочечные действия в один клик. Например, Wormhole Connect — это SDK для фронтенда, который dApps и кошельки интегрируют, чтобы пользователи могли переводить активы одним щелчком мыши — за кулисами он вызывает бриджинг токенов Wormhole и (опционально) релееров, которые депонируют газ в целевой цепи. В случае использования фонда Securitize SCOPE инвестор на Optimism может приобрести токены фонда, которые изначально находятся в Ethereum, без ручного бриджинга; уровень ликвидности Wormhole автоматически перемещает токены между цепями и даже конвертирует их в доходную форму, так что пользователь просто видит унифицированный инвестиционный продукт. Такие примеры подчеркивают идею абстракции цепи: пользователь выполняет высокоуровневое действие (инвестировать в фонд, обменять X на Y), а платформа бесшумно обрабатывает межцепочечную механику. Стандартная ретрансляция сообщений Wormhole и автоматическая доставка газа (через такие сервисы, как Automatic Relayer Wormhole или Gas Service Axelar, интегрированные в некоторые потоки) означают, что пользователь часто подписывает только одну транзакцию в своей исходной цепи и получает результат в целевой цепи без дальнейшего вмешательства. С точки зрения разработчика, Wormhole предоставляет унифицированный интерфейс для вызова контрактов между цепями, что упрощает создание межцепочечной логики.

Таким образом, подход Wormhole к абстракции цепи заключается в предоставлении инфраструктуры (децентрализованные релееры + стандартизированные контракты в каждой цепи), на которой другие могут строить цепе-независимые решения. Поддерживая широкий спектр цепей и предлагая протоколы более высокого уровня (такие как аукцион интентов и управляемый газом перевод), Wormhole позволяет приложениям рассматривать экосистему блокчейна как единое целое. Пользователи выигрывают, поскольку им больше не нужно беспокоиться о том, в какой цепи они находятся или как переводить активы — будь то перемещение ликвидности или выполнение мультичейн-обмена, интент-ориентированные xApps Wormhole стремятся сделать это так же просто, как взаимодействие в одной цепи. Соучредитель Wormhole Робинсон Берки отметил, что такого рода инфраструктура достигла «институциональной зрелости», позволяя даже регулируемым эмитентам активов бесшовно работать в сетях и абстрагироваться от специфических для цепи ограничений для своих пользователей.

Пример 2: Etherspot – абстракция аккаунта встречается с интентами​

Etherspot подходит к проблеме межцепочечного UX с точки зрения кошельков и инструментов для разработчиков. Он предоставляет SDK для абстракции аккаунта и стек протоколов интентов, которые разработчики могут интегрировать, чтобы предоставить своим пользователям унифицированный мультичейн-опыт. По сути, Etherspot сочетает смарт-кошельки с логикой абстракции цепи, так что единый смарт-аккаунт пользователя может работать во многих сетях с минимальным трением. Ключевые особенности архитектуры Etherspot включают:

• Модульный смарт-кошелек (абстракция аккаунта): Каждый пользователь Etherspot получает смарт-кошелек (в стиле ERC-4337), который может быть развернут в нескольких цепях. Etherspot внес вклад в стандарты, такие как ERC-7579 (минимальный модульный интерфейс смарт-аккаунтов), чтобы обеспечить интероперабельность и обновляемость этих кошельков. Контракт кошелька действует как агент пользователя и может быть настроен с помощью модулей. Например, один модуль может включать единый просмотр баланса — кошелек может сообщать общую сумму средств пользователя во всех цепях. Другой модуль может включать сессионные ключи, так что пользователь может одобрять серию действий одной подписью. Поскольку кошелек присутствует в каждой цепи, он может напрямую инициировать транзакции локально, когда это необходимо (при этом бэкэнд-бандлеры и релееры Etherspot оркестрируют межцепочечную координацию).

• Бандлер транзакций и пеймастеры: Etherspot запускает службу бандлера (называемую Skandha), которая собирает пользовательские операции из смарт-кошельков, и службу пеймастера (Arka), которая может спонсировать комиссии за газ. Когда пользователь запускает интент через Etherspot, он фактически подписывает сообщение для своего контракта кошелька. Инфраструктура Etherspot (бандлер) затем преобразует это в фактические транзакции в соответствующих цепях. Важно отметить, что она может объединять несколько действий — например, обмен на DEX в одной цепи и перевод через мост в другую цепь — в одну мета-транзакцию, которую контракт кошелька пользователя будет выполнять шаг за шагом. Пеймастер означает, что пользователю может не понадобиться платить какой-либо газ L1; вместо этого dApp или третья сторона могут покрыть его, или комиссия может быть взята в другом токене. Это реализует абстракцию газа на практике (большое преимущество в удобстве использования). Фактически, Etherspot подчеркивает, что с предстоящими функциями Ethereum, такими как EIP-7702, даже внешние аккаунты (EOA) могут получить безгазовые возможности, аналогичные контрактным кошелькам — но смарт-аккаунты Etherspot уже сегодня позволяют безгазовые интенты через пеймастеров.

• API интентов и решатели (Pulse): Поверх уровня аккаунтов Etherspot предоставляет высокоуровневый API интентов, известный как Etherspot Pulse. Pulse — это движок абстракции цепи Etherspot, который разработчики могут использовать для включения межцепочечных интентов в свои dApps. В демонстрации Etherspot Pulse в конце 2024 года они показали, как пользователь может выполнить обмен токенов из Ethereum на актив в Base, используя простой интерфейс React-приложения в один клик. Под капотом Pulse безопасно и эффективно обрабатывал мультичейн-транзакцию. Ключевые особенности Pulse включают Единые балансы (пользователь видит все активы как единый портфель независимо от цепи), Безопасность сессионных ключей (ограниченные привилегии для определенных действий, чтобы избежать постоянных подтверждений), Интент-ориентированные обмены и Интеграцию решателей. Другими словами, разработчик просто вызывает интент, такой как swap(tokenA on Chain1 -> tokenB on Chain2 for user) через SDK Etherspot, и Pulse выясняет, как это сделать — будь то маршрутизация через сеть ликвидности, такую как Socket, или вызов межцепочечного DEX. Etherspot интегрирован с различными мостами и агрегаторами DEX для поиска оптимальных маршрутов (вероятно, он также использует некоторые концепции Открытой структуры интентов, учитывая участие Etherspot в сообществе интентов Ethereum).

• Образование и стандарты: Etherspot был активным сторонником стандартов абстракции цепи. Он выпустил образовательный контент, объясняющий интенты и то, как «пользователи заявляют о своем желаемом результате, в то время как решатели обрабатывают бэкэнд-процесс», подчеркивая упрощенный UX и межцепочечную плавность. Они перечисляют преимущества, такие как отсутствие необходимости для пользователей беспокоиться о бриджинге или газе, и масштабируемость dApps за счет легкого доступа к нескольким цепям. Etherspot также активно сотрудничает с проектами экосистемы: например, он ссылается на Открытую структуру интентов Ethereum Foundation и исследует интеграцию новых стандартов межцепочечных сообщений (ERC-7786, 7787 и т. д.) по мере их появления. Согласовываясь с общими стандартами, Etherspot гарантирует, что его формат интентов или интерфейс кошелька могут работать в тандеме с другими решениями (такими как Hyperlane, Connext, Axelar и т. д.), выбранными разработчиком.

• Варианты использования и UX для разработчиков: Для разработчиков использование Etherspot означает, что они могут добавлять кросс-чейн функции, не изобретая велосипед. DeFi dApp может позволить пользователю депонировать средства в любой цепи, где у него есть активы, и Etherspot абстрагирует различия цепей. Игровое приложение может позволить пользователям подписать одну транзакцию для получения NFT на L2 и автоматически перевести его в Ethereum, если это необходимо для торговли. SDK Etherspot по сути предлагает цепе-независимые вызовы функций — разработчики вызывают высокоуровневые методы (например, унифицированный transfer() или swap()), а SDK обрабатывает поиск средств пользователя, их перемещение при необходимости и обновление состояния между цепями. Это значительно сокращает время разработки для поддержки мультичейн (команда утверждает до 90% сокращения времени разработки при использовании их платформы абстракции цепи). Другим аспектом являются RPC Playground и инструменты отладки, разработанные Etherspot для потоков AA, которые упрощают тестирование сложных пользовательских операций, которые могут включать несколько сетей. Все это направлено на то, чтобы сделать интеграцию абстракции цепи такой же простой, как интеграция API платежей в Web2.

С точки зрения конечного пользователя, приложение на базе Etherspot может предложить гораздо более плавный процесс адаптации и ежедневного использования. Новые пользователи могут войти в систему с помощью социального входа или электронной почты (если dApp использует модуль социальных аккаунтов Etherspot) и автоматически получить смарт-аккаунт — нет необходимости управлять сид-фразами для каждой цепи. Они могут получать токены из любой цепи на свой единый адрес (адрес смарт-кошелька одинаков во всех поддерживаемых цепях) и видеть их в одном списке. Если они хотят выполнить действие (обмен, кредитование и т. д.) в цепи, где у них нет актива или газа, протокол интентов автоматически маршрутизирует их средства и действия, чтобы это произошло. Например, пользователь, держащий USDC на Polygon, который хочет участвовать в пуле DeFi Ethereum, может просто нажать «Инвестировать в пул» — приложение (через Etherspot) обменяет USDC на требуемый актив, переведет его в Ethereum, внесет в контракт пула и даже обработает комиссии за газ, взяв небольшую часть USDC, все в одном потоке. Пользователь никогда не сталкивается с ошибками «пожалуйста, переключитесь на сеть X» или «вам нужен ETH для газа» — они обрабатываются за кулисами. Этот опыт в один клик — именно то, к чему стремится абстракция цепи.

Генеральный директор Etherspot, Майкл Месселе, выступил на EthCC 2025 с докладом о «продвинутой абстракции цепи» и подчеркнул, что превращение Web3 в по-настоящему блокчейн-агностическое решение может расширить возможности как пользователей, так и разработчиков за счет улучшения интероперабельности, масштабируемости и UX. Собственные разработки Etherspot, такие как демонстрация Pulse одноинтентных кросс-чейн обменов, показывают, что технология уже существует для радикального упрощения кросс-чейн взаимодействий. Как позиционирует Etherspot, интенты — это мост между инновационными возможностями мультичейн-экосистемы и удобством использования, которое ожидают конечные пользователи. С такими решениями, как их, dApps могут предоставлять «бесшовный» опыт, где различия цепей исчезают на заднем плане, ускоряя массовое внедрение Web3.

Улучшения пользовательского и разработческого опыта​

Как абстракция цепи, так и интент-ориентированные архитектуры в конечном итоге служат для улучшения пользовательского опыта (UX) и опыта разработчиков (DX) в мультичейн-мире. Некоторые из заметных улучшений включают:

• Бесшовная адаптация: Новые пользователи могут быть адаптированы без беспокойства о том, в каком блокчейне они находятся. Например, пользователю может быть предоставлен единый смарт-аккаунт, который работает везде, возможно, созданный с помощью социального входа. Они могут получать любой токен или NFT на этот аккаунт из любой цепи без путаницы. Новичку больше не нужно изучать переключение сетей в MetaMask или защиту нескольких сид-фраз. Это значительно снижает барьер для входа, поскольку использование dApp становится ближе к регистрации в приложении Web2. Проекты, реализующие абстракцию аккаунта, часто позволяют создавать кошельки на основе электронной почты или OAuth, при этом полученный смарт-аккаунт является цепе-независимым.

• Действия в один клик между цепями: Возможно, наиболее заметным преимуществом UX является сведение того, что раньше было многоэтапными рабочими процессами с несколькими приложениями, к одному или двум кликам. Например, кросс-чейн обмен токенов ранее мог потребовать: обмена Токена A на бриджируемый актив в Цепи 1, перехода к пользовательскому интерфейсу моста для отправки его в Цепь 2, затем обмена на Токен B в Цепи 2 — и управления комиссиями за газ в обеих цепях. С интент-ориентированными системами пользователь просто запрашивает «Обменять A в Цепи1 на B в Цепи2» и подтверждает один раз. Все промежуточные шаги (включая получение газа в Цепи2, если необходимо) автоматизированы. Это не только экономит время, но и снижает вероятность ошибок пользователя (использование неправильного моста, отправка на неправильный адрес и т. д.). Это сродни удобству бронирования многосегментного рейса через один туристический сайт по сравнению с ручной покупкой каждого сегмента по отдельности.

• Отсутствие беспокойства о нативном газе: Пользователям не нужно постоянно обменивать небольшие суммы ETH, MATIC, AVAX и т. д. просто для оплаты транзакций. Абстракция платы за газ означает, что либо dApp покрывает газ (и, возможно, взимает комиссию в транзакционном токене или через модель подписки), либо система автоматически конвертирует часть актива пользователя для оплаты комиссий. Это имеет огромное психологическое воздействие — оно устраняет класс запутанных подсказок (больше никаких ошибок «недостаточно газа») и позволяет пользователям сосредоточиться на действиях, которые им важны. Несколько докладов на EthCC 2025 отметили абстракцию газа как приоритет, например, EIP-7702 Ethereum даже позволит аккаунтам EOA иметь спонсируемый газ в будущем. На практике сегодня многие интент-протоколы выделяют небольшое количество выходного актива в качестве газа в целевой цепи для пользователя или используют пеймастеров, подключенных к пользовательским операциям. Результат: пользователь может, скажем, переместить USDC из Arbitrum в Polygon, ни разу не касаясь ETH с обеих сторон, и при этом его кошелек Polygon сможет немедленно совершать транзакции по прибытии.

• Унифицированное управление активами: Для конечных пользователей единый просмотр активов и действий в разных цепях является значительным улучшением качества жизни. Абстракция цепи может представлять комбинированный портфель — так, ваш 1 ETH в основной сети и 2 ETH в виде бриджированного stETH на Optimism могут просто отображаться как «баланс ETH». Если у вас есть стейблкоины USD в пяти разных цепях, цепе-независимый кошелек может показать вашу общую стоимость USD и позволить тратить их без ручного бриджинга. Это больше похоже на традиционное банковское приложение, которое показывает единый баланс (даже если средства распределены по счетам за кулисами). Пользователи могут устанавливать предпочтения, такие как «использовать самую дешевую сеть по умолчанию» или «максимизировать доходность», и система может автоматически распределять транзакции в соответствующую цепь. Между тем, вся их история транзакций может быть видна в одной временной шкале независимо от цепи. Такая согласованность важна для более широкого внедрения — она скрывает сложность блокчейна под знакомыми метафорами.

• Повышенная производительность разработчиков: Со стороны разработчика платформы абстракции цепи означают отсутствие необходимости писать специфический для цепи код для каждой интеграции. Вместо интеграции пяти различных мостов и шести бирж для обеспечения покрытия активов и сетей разработчик может интегрировать один API интент-протокола, который абстрагирует их. Это не только экономит усилия на разработку, но и снижает затраты на обслуживание — по мере появления новых цепей или мостов, разработчики уровня абстракции обрабатывают интеграцию, а dApp просто получает от этого выгоду. Еженедельный дайджест от Etherspot подчеркнул, что такие решения, как платформа абстракции цепи Okto, заявляют о сокращении времени разработки мультичейн dApp до 90% за счет предоставления готовой поддержки основных цепей и таких функций, как оптимизация ликвидности. По сути, разработчики могут сосредоточиться на логике приложения (например, на продукте кредитования, игре), а не на тонкостях кросс-чейн переводов или управления газом. Это открывает двери для большего числа разработчиков Web2, чтобы войти в Web3, поскольку они могут использовать высокоуровневые SDK вместо того, чтобы нуждаться в глубоких знаниях блокчейна для каждой цепи.

• Новые компонуемые возможности: С интентами и абстракцией цепи разработчики могут создавать возможности, которые ранее были слишком сложны для реализации. Например, кросс-чейн стратегии доходного фермерства могут быть автоматизированы: пользователь может нажать «максимизировать доходность моих активов», и интент-протокол может перемещать активы между цепями к лучшим доходным фермам, даже делая это непрерывно по мере изменения ставок. Игры могут иметь активы и квесты, которые охватывают несколько цепей, не требуя от игроков вручную переводить предметы — бэкэнд игры (использующий фреймворк интентов) обрабатывает телепортацию предметов или синхронизацию состояния. Даже управление может выиграть: DAO может позволить пользователю проголосовать один раз, и этот голос будет применен к контрактам управления всех соответствующих цепей через кросс-чейн сообщения. Общий эффект — компонуемость: так же, как DeFi в одной цепи позволял компоновать протоколы, как из Lego, слои кросс-чейн интентов позволяют компоновать протоколы в разных цепях. Интент пользователя может запускать действия в нескольких dApps в разных цепях (например, развернуть NFT в одной цепи и продать его на торговой площадке в другой), что создает более богатые рабочие процессы, чем изолированные одноцепочечные операции.

• Защитные механизмы и надежность: Часто недооцениваемый аспект UX — это обработка ошибок. В ранних кросс-чейн взаимодействиях, если что-то шло не так (застрявшие средства в мосту, сбой транзакции после отправки средств и т. д.), пользователи сталкивались с кошмаром устранения неполадок на нескольких платформах. Интент-фреймворки могут включать логику повторных попыток, страхование или механизмы защиты пользователей. Например, решатель может взять на себя риск завершенности — немедленно (в течение секунд) доставить средства пользователя в пункт назначения и самостоятельно ждать более медленной завершенности исходной цепи. Это означает, что пользователю не придется ждать минуты или часы для подтверждения. Если интент частично не удается, система может автоматически откатить или вернуть средства. Поскольку весь поток оркестрируется известными шагами, есть больше возможностей компенсировать пользователю, если что-то сломается. Некоторые протоколы исследуют эскроу и страхование для кросс-чейн операций как часть выполнения интента, что было бы невозможно, если бы пользователь вручную преодолевал препятствия — он нес бы этот риск в одиночку. Короче говоря, абстракция может сделать общий опыт не только более плавным, но и более безопасным и надежным для обычного пользователя.

Все эти улучшения указывают на одну тенденцию: снижение когнитивной нагрузки на пользователей и абстрагирование блокчейн-сантехники на задний план. При правильном выполнении пользователи могут даже не осознавать, какие цепи они используют — они просто получают доступ к функциям и услугам. Разработчики, с другой стороны, могут создавать приложения, которые используют ликвидность и пользовательские базы во многих сетях из единой кодовой базы. Это перенос сложности с периферии (пользовательские приложения) в центр (инфраструктурные протоколы), что является естественным прогрессом по мере созревания технологии. Тон EthCC 2025 отразил это настроение, когда «бесшовная, компонуемая инфраструктура» была названа первостепенной целью для сообщества Ethereum.

Выводы с EthCC 2025​

Конференция EthCC 2025 (прошедшая в июле 2025 года в Каннах) подчеркнула, насколько центральными стали абстракция цепи и интент-ориентированный дизайн в экосистеме Ethereum. Специальный блок сессий был посвящен унификации пользовательского опыта в сетях. Ключевые выводы с мероприятия включают:

• Согласование сообщества по абстракции: Множество выступлений лидеров отрасли повторяли одно и то же сообщение — упрощение мультичейн-опыта критически важно для следующей волны внедрения Web3. Майкл Месселе (Etherspot) говорил о движении «к блокчейн-агностическому будущему», Алекс Баш (кошелек Zerion) обсуждал «унификацию UX Ethereum с помощью абстракции и интентов», а другие представили конкретные стандарты, такие как ERC-7811 для абстракции цепи стейблкоинов. Само название одного из докладов, «Нет будущего Web3 без абстракции цепи», отразило настроения сообщества. Другими словами, существует широкое согласие, что без решения проблемы удобства использования кросс-чейн Web3 не достигнет своего полного потенциала. Это представляет собой сдвиг по сравнению с предыдущими годами, когда масштабирование L1 или L2 было основным фокусом — теперь, когда многие L2 запущены, их соединение для пользователей является новым рубежом.

• Роль Ethereum как хаба: Панели EthCC подчеркнули, что Ethereum позиционирует себя не просто как одна из многих цепей, а как основа мультичейн-экосистемы. Безопасность Ethereum и его абстракция аккаунта 4337 в основной сети могут служить общей базой, лежащей в основе активности в различных L2 и сайдчейнах. Вместо того чтобы конкурировать со своими роллапами, Ethereum (и, соответственно, сообщество Ethereum) инвестирует в протоколы, которые делают всю сеть цепей унифицированной. Это подтверждается поддержкой Ethereum Foundation таких проектов, как Открытая структура интентов, которая охватывает множество цепей и роллапов. Атмосфера на EthCC заключалась в том, что зрелость Ethereum проявляется в принятии «экосистемы экосистем», где ориентированный на пользователя дизайн (независимо от цепи) имеет первостепенное значение.

• Стейблкоины и реальные активы как катализаторы: Интересной темой было пересечение абстракции цепи со стейблкоинами и RWA (реальными активами). Стейблкоины неоднократно отмечались как «основополагающая сила» в DeFi, и несколько докладов (например, по абстракции цепи стейблкоинов ERC-7811) рассматривали возможность использования стейблкоинов цепе-независимым образом. Идея состоит в том, что обычному пользователю не должно быть важно, в какой цепи находится его USDC или DAI — он должен иметь ту же ценность и быть пригодным для использования везде бесшовно. Мы видели это на примере фонда Securitize, использующего Wormhole для перехода в мультичейн, эффективно абстрагируя институциональный продукт между цепями. Дискуссии на EthCC предполагали, что решение проблемы кросс-чейн UX для стейблкоинов и RWA является большим шагом к более широкому блокчейн-финансированию, поскольку эти активы требуют плавного пользовательского опыта для принятия учреждениями и массовыми пользователями.

• Волнение разработчиков и инструментарий: Семинары и сопутствующие мероприятия (например, Multichain Day) познакомили разработчиков с новыми доступными инструментами. Проекты хакатонов и демонстрации показали, как API интентов и SDK абстракции цепи (от различных команд) могут быть использованы для быстрого создания кросс-чейн dApps за считанные дни. Было ощутимое волнение, что «Святой Грааль» UX Web3 — использование нескольких сетей, не осознавая этого — находится в пределах досягаемости. Команда Открытой структуры интентов провела семинар для начинающих, объясняющий, как создать приложение с поддержкой интентов, вероятно, используя их эталонный решатель и контракты. Разработчики, которые в прошлом сталкивались с трудностями при бриджинге и развертывании в нескольких цепях, были заинтересованы в этих решениях, о чем свидетельствуют сессии вопросов и ответов (как сообщалось неофициально в социальных сетях во время конференции).

• Анонсы и сотрудничество: EthCC 2025 также послужил площадкой для объявления о сотрудничестве между проектами в этой области. Например, были намеки на партнерство между поставщиком кошельков и протоколом интентов или между проектом моста и проектом абстракции аккаунта. Одним из конкретных объявлений стала интеграция Wormhole с экосистемой Stacks (привнесение ликвидности Bitcoin в кросс-чейн потоки), что не было напрямую абстракцией цепи для Ethereum, но иллюстрировало расширяющуюся связность между традиционно отдельными криптоэкосистемами. Присутствие таких проектов, как Zerion (кошелек), Safe (смарт-аккаунты), Connext, Socket, Axelar и т. д., все обсуждающие интероперабельность, сигнализировало о том, что многие части головоломки собираются воедино.

В целом, EthCC 2025 нарисовал картину сообщества, объединяющегося вокруг ориентированных на пользователя кросс-чейн инноваций. Фраза «компонуемая инфраструктура» использовалась для описания цели: все эти L1, L2 и протоколы должны образовывать связную ткань, на которой приложения могут строиться без необходимости сшивать все вместе ad-hoc. Конференция ясно дала понять, что абстракция цепи и интенты — это не просто модные слова, а активные области развития, привлекающие серьезные таланты и инвестиции. Лидерство Ethereum в этом — через финансирование, установление стандартов и предоставление надежного базового уровня — было подтверждено на мероприятии.

Сравнение подходов к абстракции цепи и интентам​

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

(Легенда таблицы: AA = Абстракция аккаунта, ChA = Абстракция цепи, AMB = Произвольный мост сообщений)

Каждый из вышеуказанных подходов решает проблему кросс-чейн UX с несколько иной точки зрения — некоторые фокусируются на кошельке/аккаунте пользователя, другие на передаче сообщений в сети, а третьи на уровне API разработчика — но все они разделяют цель сделать взаимодействия с блокчейном цепе-независимыми и интент-ориентированными. Примечательно, что эти решения не являются взаимоисключающими; фактически, они часто дополняют друг друга. Например, приложение может использовать смарт-кошелек Etherspot + пеймастеры, со стандартом Открытых интентов для форматирования интента пользователя, а затем использовать Axelar или Connext под капотом в качестве уровня выполнения для фактического бриджинга и выполнения действий. Возникающая тенденция — это компонуемость между самими инструментами абстракции цепи, в конечном итоге строящаяся к Интернету блокчейнов, где пользователи свободно перемещаются.

Заключение​

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

Преимущества в пользовательском опыте уже ощутимы: более плавная адаптация, кросс-чейн обмены в один клик и по-настоящему бесшовные взаимодействия dApp в экосистемах. Разработчики также получают расширенные возможности благодаря высокоуровневым SDK и стандартам, которые значительно упрощают создание приложений для мультичейн-мира. Как было видно на EthCC 2025, существует сильный консенсус сообщества в том, что эти разработки являются не только захватывающими улучшениями, но и фундаментальными требованиями для следующей фазы роста Web3. Проекты, такие как Wormhole и Etherspot, демонстрируют, что можно сохранить децентрализацию и отсутствие доверия, предлагая при этом простоту использования, как в Web2.

Заглядывая вперед, мы можем ожидать дальнейшего сближения этих подходов. Стандарты, такие как интенты ERC-7683 и абстракция аккаунта ERC-4337, вероятно, получат широкое распространение, обеспечивая совместимость между платформами. Больше мостов и сетей будут интегрироваться с открытыми фреймворками интентов, увеличивая ликвидность и возможности для решателей выполнять интенты пользователей. В конечном итоге термин «кросс-чейн» может исчезнуть, поскольку взаимодействия вообще не будут рассматриваться с точки зрения отдельных цепей — подобно тому, как пользователи Интернета не задумываются о том, какой центр обработки данных обработал их запрос. Вместо этого пользователи будут просто вызывать сервисы и управлять активами в унифицированной блокчейн-экосистеме.

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

Источники: Информация в этом отчете была собрана из ряда актуальных ресурсов, включая документацию протоколов, блоги разработчиков и доклады с EthCC 2025. Ключевые ссылки включают официальную документацию Wormhole по их кросс-чейн интент-протоколам, серию технических блогов Etherspot по абстракции аккаунтов и цепей, а также примечания к выпуску Открытой структуры интентов Ethereum Foundation, среди прочего, как цитируется по всему тексту. Каждая цитата обозначается в формате 【источник†строки】 для точного указания исходного материала, подтверждающего сделанные утверждения.

Введение​

Блокчейн Sui, анонсированный к публичному запуску 3 мая 2023 года после обширного трехволнового тестнета, представил инновационную систему ценообразования на газ, разработанную для выгоды как пользователей, так и валидаторов. В её основе лежит Эталонная цена на газ (RGP) — базовая сетевая комиссия за газ, которую валидаторы согласовывают в начале каждой эпохи (примерно 24 часа).

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

Механизм эталонной цены на газ (RGP)​

RGP Sui не является статичным значением, а переустанавливается каждую эпоху посредством динамического процесса, управляемого валидаторами.

• Опрос по цене на газ: В начале каждой эпохи каждый валидатор представляет свою «резервную цену» — минимальную цену на газ, которую он готов принять за обработку транзакций. Затем протокол упорядочивает эти заявки по доле стейка и устанавливает RGP для данной эпохи на уровне 2/3 перцентиля, взвешенного по доле стейка. Такая конструкция гарантирует, что валидаторы, представляющие супербольшинство (не менее двух третей) от общего стейка, готовы обрабатывать транзакции по этой цене, обеспечивая надёжный уровень обслуживания.

• Частота и требования к обновлению: Хотя RGP устанавливается каждую эпоху, валидаторы обязаны активно управлять своими котировками. Согласно официальным рекомендациям, валидаторы должны обновлять свою котировку цены на газ не реже одного раза в неделю. Кроме того, если происходит значительное изменение стоимости токена SUI, например, колебание на 20% или более, валидаторы должны немедленно обновить свою котировку, чтобы гарантировать, что RGP точно отражает текущие рыночные условия.

• Правило подсчёта и распределение вознаграждений: Чтобы гарантировать соблюдение валидаторами согласованной RGP, Sui использует «правило подсчёта». В течение эпохи валидаторы отслеживают производительность друг друга, проверяя, оперативно ли их коллеги обрабатывают транзакции по цене RGP. Этот мониторинг приводит к получению оценки производительности для каждого валидатора. В конце эпохи эти оценки используются для расчёта множителя вознаграждения, который корректирует долю каждого валидатора в вознаграждениях за стейкинг.

  • Валидаторы, показавшие хорошие результаты, получают множитель ≥1, увеличивая свои вознаграждения.
  • Валидаторы, которые задерживали, откладывали или не смогли обработать транзакции по RGP, получают множитель <1, что фактически сокращает часть их заработка.

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

Операции валидатора: Расчёт котировки цены на газ​

С точки зрения валидатора, установка котировки RGP является критически важной операционной задачей, которая напрямую влияет на прибыльность. Она требует создания конвейеров данных и уровней автоматизации для обработки ряда входных данных как из ончейн, так и из офчейн источников. Ключевые входные данные включают:

• Единицы газа, выполненные за эпоху
• Вознаграждения за стейкинг и субсидии за эпоху
• Взносы в фонд хранения
• Рыночная цена токена SUI
• Операционные расходы (оборудование, облачный хостинг, обслуживание)

Цель состоит в том, чтобы рассчитать котировку, которая гарантирует положительные чистые вознаграждения. Процесс включает несколько ключевых формул:

1. Расчёт общих операционных затрат: Это определяет расходы валидатора в фиатной валюте за данную эпоху.

   $$\text{Cost}_{\text{epoch}} = (\text{Total Gas Units Executed}_{\text{epoch}}) \times (\text{Cost in \$ per Gas Unit}_{\text{epoch}})$$

2. Расчёт общих вознаграждений: Это определяет общий доход валидатора в фиатной валюте, полученный как от субсидий протокола, так и от комиссий за транзакции.

   $$\text{\$Rewards}_{\text{epoch}} = (\text{Total Stake Rewards in SUI}_{\text{epoch}}) \times (\text{SUI Token Price})$$

   Где Total Stake Rewards — это сумма любых предоставленных протоколом Stake Subsidies и Gas Fees, собранных с транзакций.

3. Расчёт чистых вознаграждений: Это окончательная мера прибыльности для валидатора.

   $$\text{\$Net Rewards}_{\text{epoch}} = \text{\$Rewards}_{\text{epoch}} - \text{\$Cost}_{\text{epoch}}$$

   Моделируя свои ожидаемые затраты и вознаграждения при различных уровнях RGP, валидаторы могут определить оптимальную котировку для представления в Опросе по цене на газ.

При запуске основной сети Sui установил начальную RGP на фиксированном уровне 1 000 MIST (1 SUI = 10⁹ MIST) на первые одну-две недели. Это обеспечило стабильный период работы для валидаторов, чтобы собрать достаточные данные об активности сети и наладить свои процессы расчёта до того, как динамический механизм опроса вступил в полную силу.

Влияние на экосистему Sui​

Механизм RGP глубоко формирует экономику и пользовательский опыт всей сети.

• Для пользователей: Предсказуемые и стабильные комиссии: RGP служит надёжным ориентиром для пользователей. Комиссия за газ для транзакции следует простой формуле: Цена газа пользователя = RGP + Чаевые. В нормальных условиях чаевые не требуются. Во время перегрузки сети пользователи могут добавить чаевые для получения приоритета, создавая рынок комиссий без изменения стабильной базовой цены в рамках эпохи. Эта модель обеспечивает значительно большую стабильность комиссий, чем системы, где базовая комиссия меняется с каждым блоком.

• Для валидаторов: Гонка за эффективностью: Система способствует здоровой конкуренции. Валидаторы стимулируются снижать свои операционные расходы (за счёт оптимизации аппаратного и программного обеспечения), чтобы иметь возможность прибыльно предлагать более низкую RGP. Эта «гонка за эффективностью» приносит пользу всей сети, снижая транзакционные издержки. Механизм также подталкивает валидаторов к сбалансированной прибыли; слишком высокая котировка рискует быть исключённой из расчёта RGP, в то время как слишком низкая приводит к операционным убыткам и штрафам за производительность.

• Для сети: Децентрализация и устойчивость: Механизм RGP помогает обеспечить долгосрочное здоровье сети. «Угроза входа» новых, более эффективных валидаторов предотвращает сговор существующих валидаторов с целью поддержания высоких цен. Кроме того, корректируя свои котировки на основе рыночной цены токена SUI, валидаторы коллективно обеспечивают устойчивость своих операций в реальном выражении, защищая экономику комиссий сети от волатильности цены токена.

Управление и эволюция системы: SIP-45​

Механизм газа Sui не статичен и развивается посредством управления. Ярким примером является SIP-45 (Приоритетная отправка транзакций), который был предложен для уточнения приоритезации на основе комиссий.

• Решаемая проблема: Анализ показал, что простая оплата высокой цены на газ не всегда гарантировала более быстрое включение транзакции.
• Предлагаемые изменения: Предложение включало увеличение максимально допустимой цены на газ и введение «усиленной трансляции» для транзакций, оплачивающих значительно выше RGP (например, ≥5x RGP), гарантируя их быстрое распространение по сети для приоритетного включения.

Это демонстрирует приверженность итеративному развитию модели газа на основе эмпирических данных для повышения её эффективности.

Сравнение с другими моделями газа в блокчейне​

Модель RGP Sui уникальна, особенно в сравнении с EIP-1559 Ethereum.

Потенциальные критические замечания и вызовы​

Несмотря на свою инновационную конструкцию, механизм RGP сталкивается с потенциальными вызовами:

• Сложность: Система опросов, правил подсчёта и офчейн-расчётов сложна и может представлять собой кривую обучения для новых валидаторов.
• Медленная реакция на пики: RGP фиксируется на эпоху и не может реагировать на внезапные всплески спроса в середине эпохи, что может привести к временной перегрузке, пока пользователи не начнут добавлять чаевые.
• Потенциал сговора: Теоретически, валидаторы могли бы сговориться, чтобы установить высокую RGP. Этот риск в основном снижается конкурентным характером децентрализованного набора валидаторов.
• Отсутствие сжигания комиссий: В отличие от Ethereum, Sui перераспределяет все комиссии за газ валидаторам и в фонд хранения. Это вознаграждает операторов сети, но не создаёт дефляционного давления на токен SUI — функцию, которую ценят некоторые держатели токенов.

Часто задаваемые вопросы (FAQ)​

Зачем стейкать SUI? Стейкинг SUI обеспечивает безопасность сети и приносит вознаграждения. Изначально эти вознаграждения сильно субсидируются Sui Foundation для компенсации низкой сетевой активности. Эти субсидии уменьшаются на 10% каждые 90 дней, с ожиданием, что вознаграждения от транзакционных комиссий станут основным источником дохода. Застейканные SUI также предоставляют право голоса в ончейн-управлении.

Могут ли мои застейканные SUI быть слэшированы? Да. Хотя параметры всё ещё дорабатываются, применяется «слэшинг по правилу подсчёта». Валидатор, получивший нулевую оценку производительности от 2/3 своих коллег (из-за низкой производительности, злонамеренного поведения и т. д.), будет иметь свои вознаграждения слэшированы на определённую сумму. Стейкеры также могут упустить вознаграждения, если выбранный ими валидатор имеет простой или предлагает неоптимальную RGP.

Автоматически ли реинвестируются вознаграждения за стейкинг? Да, вознаграждения за стейкинг в Sui автоматически распределяются и реинвестируются (компаундируются) каждую эпоху. Чтобы получить доступ к вознаграждениям, вы должны явно их разстейкать.

Каков период разблокировки (unbonding period) Sui? Изначально стейкеры могут разблокировать свои токены немедленно. Ожидается, что будет реализован период разблокировки, когда токены будут заблокированы на определённое время после разстейкинга, и это будет предметом управления.

Сохраняю ли я контроль над своими токенами SUI при стейкинге? Да. Когда вы стейкаете SUI, вы делегируете свой стейк, но остаётесь в полном контроле над своими токенами. Вы никогда не передаёте хранение валидатору.

В быстро сближающихся мирах искусственного интеллекта и блокчейна спрос на доверие и прозрачность никогда не был таким высоким. Как мы можем быть уверены, что результат работы модели ИИ точен и не подвергался изменениям? Как мы можем выполнять сложные вычисления на огромных ончейн-наборах данных без ущерба для безопасности или масштабируемости? Lagrange Labs решает эти вопросы напрямую с помощью своего набора инфраструктуры с нулевым разглашением (ZK), стремясь построить будущее "ИИ, который можно доказать". Этот пост представляет объективный обзор их миссии, технологий и недавних прорывов, кульминацией которых стала их последняя статья о динамических zk-SNARKs.

1. Команда и ее миссия​

Lagrange Labs создает базовую инфраструктуру для генерации криптографических доказательств для любого вывода ИИ или ончейн-приложения. Их цель — сделать вычисления проверяемыми, привнося новый уровень доверия в цифровой мир. Их экосистема построена на трех основных продуктовых линейках:

• Сеть ZK-доказателей: Децентрализованная сеть из более чем 85 узлов-доказателей, которая обеспечивает вычислительную мощность, необходимую для широкого спектра задач доказательства, от ИИ и роллапов до децентрализованных приложений (dApps).
• DeepProve (zkML): Специализированная система для генерации ZK-доказательств выводов нейронных сетей. Lagrange утверждает, что она до 158 раз быстрее конкурирующих решений, что делает проверяемый ИИ практической реальностью.
• ZK-сопроцессор 1.0: Первый ZK-сопроцессор на основе SQL, позволяющий разработчикам выполнять пользовательские запросы к массивным ончейн-наборам данных и получать проверяемо точные результаты.

2. Дорожная карта к проверяемому ИИ​

Lagrange методично реализует дорожную карту, разработанную для поэтапного решения проблем проверяемости ИИ.

• 3 квартал 2024 г.: Запуск ZK-сопроцессора 1.0: Этот релиз представил гиперпараллельные рекурсивные схемы, которые обеспечили среднее увеличение скорости примерно в 2 раза. Такие проекты, как Azuki и Gearbox, уже используют сопроцессор для своих потребностей в ончейн-данных.
• 1 квартал 2025 г.: Представление DeepProve: Lagrange анонсировала DeepProve, свое решение для машинного обучения с нулевым разглашением (zkML). Оно поддерживает популярные архитектуры нейронных сетей, такие как многослойные перцептроны (MLP) и сверточные нейронные сети (CNN). Система достигает значительного, на порядок, ускорения на всех трех критических этапах: однократная настройка, генерация доказательства и верификация, при этом ускорение достигает 158x.
• 2 квартал 2025 г.: Статья о динамических zk-SNARKs (Последняя веха): Эта статья представляет новаторский алгоритм "обновления". Вместо повторной генерации доказательства с нуля каждый раз, когда изменяются базовые данные или вычисления, этот метод может "заплатать" старое доказательство (π) в новое доказательство (π'). Это обновление может быть выполнено со сложностью всего O(√n log³n), что является значительным улучшением по сравнению с полной перегенерацией. Это нововведение особенно подходит для динамических систем, таких как постоянно обучающиеся модели ИИ, игровая логика в реальном времени и развивающиеся смарт-контракты.

3. Почему динамические zk-SNARKs важны​

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

• Новая парадигма затрат: Отрасль переходит от модели "полной перегенерации для каждого доказательства" к "инкрементальному доказательству, основанному на размере изменения". Это значительно снижает вычислительные и финансовые затраты для приложений, которые часто подвергаются незначительным обновлениям.

• Последствия для ИИ:

  • Непрерывная донастройка: При донастройке менее 1% параметров модели время генерации доказательства растет почти линейно с количеством измененных параметров (Δ параметров), а не с общим размером модели.
  • Потоковый вывод: Это позволяет генерировать доказательства одновременно с самим процессом вывода. Это значительно сокращает задержку между принятием решения ИИ и его фиксацией и верификацией в блокчейне, открывая такие варианты использования, как ончейн-сервисы ИИ и сжатые доказательства для роллапов.

• Последствия для ончейн-приложений:

  • Динамические zk-SNARKs предлагают огромную оптимизацию газа и времени для приложений, характеризующихся частыми, небольшими изменениями состояния. Это включает книги ордеров децентрализованных бирж (DEX), развивающиеся игровые состояния и обновления реестра, включающие частые добавления или удаления.

4. Взгляд на технологический стек​

Мощная инфраструктура Lagrange построена на сложном и интегрированном технологическом стеке:

• Проектирование схем: Система является гибкой, поддерживая встраивание моделей ONNX (Open Neural Network Exchange), SQL-парсеров и пользовательских операторов непосредственно в свои схемы.
• Рекурсия и параллелизм: Сеть ZK-доказателей облегчает распределенные рекурсивные доказательства, в то время как ZK-сопроцессор использует шардинг "микросхем" для параллельного выполнения задач, максимизируя эффективность.
• Экономические стимулы: Lagrange планирует запустить нативный токен LA, который будет интегрирован в систему двойного аукциона для рекурсивного аукциона (DARA). Это создаст надежный рынок для торгов за вычисления доказателей, дополненный стимулами и штрафами для обеспечения целостности сети.

5. Экосистема и реальное внедрение​

Lagrange не просто строит в вакууме; ее технология уже интегрируется растущим числом проектов в различных секторах:

• ИИ и МО: Такие проекты, как 0G Labs и Story Protocol, используют DeepProve для верификации результатов своих моделей ИИ, обеспечивая происхождение и доверие.
• Роллапы и инфраструктура: Ключевые игроки, такие как EigenLayer, Base и Arbitrum, участвуют в сети ZK-доказателей в качестве узлов валидации или партнеров по интеграции, способствуя ее безопасности и вычислительной мощности.
• Приложения NFT и DeFi: Такие бренды, как Azuki, и протоколы DeFi, такие как Gearbox, используют ZK-сопроцессор для повышения достоверности своих запросов данных и механизмов распределения вознаграждений.

6. Вызовы и путь вперед​

Несмотря на впечатляющий прогресс, Lagrange Labs и более широкая область ZK сталкиваются с рядом препятствий:

• Аппаратные узкие места: Даже при наличии распределенной сети обновляемые SNARKs по-прежнему требуют высокой пропускной способности и полагаются на криптографические кривые, дружественные к GPU, для эффективной работы.
• Отсутствие стандартизации: Процесс сопоставления фреймворков ИИ, таких как ONNX и PyTorch, с ZK-схемами по-прежнему не имеет универсального, стандартизированного интерфейса, что создает трудности для разработчиков.
• Конкурентная среда: Гонка за создание zkVM и обобщенных платформ zkCompute набирает обороты. Конкуренты, такие как Risc-Zero и Succinct, также добиваются значительных успехов. В конечном итоге победителем может стать тот, кто первым сможет коммерциализировать удобный для разработчиков, управляемый сообществом набор инструментов.

7. Заключение​

Lagrange Labs методично меняет пересечение ИИ и блокчейна через призму проверяемости. Их подход предлагает комплексное решение:

• DeepProve решает проблему доверенного вывода.
• ZK-сопроцессор решает проблему доверенных данных.
• Динамические zk-SNARKs напрямую включают потребность реального мира в непрерывных обновлениях в систему доказательства.

Если Lagrange сможет сохранить свое преимущество в производительности, решить критическую проблему стандартизации и продолжить развивать свою надежную сеть, она имеет хорошие шансы стать краеугольным камнем в развивающемся секторе "ИИ + ZK-инфраструктуры".

Когда вы отправляете криптовалюту, какова ваша обычная процедура? Для большинства из нас она включает копирование адреса получателя из истории транзакций. В конце концов, никто не может запомнить строку из 40 символов, такую как 0x1A2b...8f9E. Это удобный ярлык, которым мы все пользуемся.

Но что, если это удобство — тщательно расставленная ловушка?

Разрушительно эффективная афера, называемая отравлением блокчейн-адресов, использует именно эту привычку. Недавнее исследование Университета Карнеги-Меллона выявило шокирующие масштабы этой угрозы. Всего за два года только в сетях Ethereum и Binance Smart Chain (BSC) мошенники совершили более 270 миллионов попыток атак, нацелившись на 17 миллионов жертв и успешно украв не менее 83,8 миллиона долларов.

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

Как работает обман 🤔​

Отравление адресов — это игра визуального обмана. Стратегия злоумышленника проста, но гениальна:

1. Генерация похожего адреса: Злоумышленник определяет адрес, на который вы часто отправляете средства. Затем он использует мощные компьютеры для генерации нового крипто-адреса, который имеет точно такие же начальные и конечные символы. Поскольку большинство кошельков и блокчейн-эксплореров сокращают адреса для отображения (например, 0x1A2b...8f9E), их мошеннический адрес на первый взгляд выглядит идентично настоящему.

2. «Отравление» вашей истории транзакций: Далее злоумышленнику необходимо внедрить свой похожий адрес в историю вашего кошелька. Они делают это, отправляя «отравляющую» транзакцию. Это может быть:

   • Крошечный перевод: Они отправляют вам ничтожную сумму криптовалюты (например, $0.001) со своего похожего адреса. Теперь он появляется в вашем списке недавних транзакций.
   • Перевод с нулевой стоимостью: В более хитром ходе они используют функцию во многих токен-контрактах для создания поддельного перевода на нулевую сумму, который выглядит так, будто он пришел от вас на их похожий адрес. Это делает поддельный адрес еще более легитимным, поскольку создается впечатление, что вы уже отправляли туда средства.
   • Перевод поддельного токена: Они создают бесполезный, поддельный токен (например, «USDTT» вместо USDT) и фальсифицируют транзакцию на свой похожий адрес, часто имитируя сумму предыдущей реальной транзакции, которую вы совершали.

3. Ожидание ошибки: Ловушка расставлена. В следующий раз, когда вы захотите оплатить законному контакту, вы просканируете свою историю транзакций, увидите то, что, по вашему мнению, является правильным адресом, скопируете его и нажмете «отправить». К тому времени, как вы осознаете свою ошибку, средства будут утеряны. И благодаря необратимой природе блокчейна, нет банка, куда можно позвонить, и нет способа вернуть их.

Взгляд на преступное предприятие 🕵️‍♂️​

Это не работа хакеров-одиночек. Исследование показывает, что эти атаки осуществляются крупными, организованными и высокодоходными преступными группами.

Кого они выбирают в качестве цели​

Злоумышленники не тратят время на мелкие аккаунты. Они систематически нацеливаются на пользователей, которые являются:

• Состоятельными: Владеют значительными балансами в стейблкоинах.
• Активными: Совершают частые транзакции.
• Крупными транзакторами: Перемещают большие суммы денег.

Гонка вооружений в сфере оборудования​

Генерация похожего адреса — это вычислительная задача методом перебора. Чем больше символов вы хотите сопоставить, тем экспоненциально сложнее становится. Исследователи обнаружили, что, хотя большинство злоумышленников используют стандартные центральные процессоры (CPU) для создания умеренно убедительных подделок, самая изощренная преступная группа подняла это на новый уровень.

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

Как защитить свои средства 🛡️​

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

1. Для каждого пользователя (это самая важная часть):

   • ПРОВЕРЯЙТЕ ПОЛНЫЙ АДРЕС. Прежде чем нажать «Подтвердить», потратьте пять дополнительных секунд, чтобы вручную проверить весь адрес, символ за символом. Не просто смотрите на первые и последние несколько цифр.
   • ИСПОЛЬЗУЙТЕ АДРЕСНУЮ КНИГУ. Сохраняйте доверенные, проверенные адреса в адресной книге или списке контактов вашего кошелька. При отправке средств всегда выбирайте получателя из этого сохраненного списка, а не из вашей динамической истории транзакций.
   • ОТПРАВЬТЕ ТЕСТОВУЮ ТРАНЗАКЦИЮ. Для крупных или важных платежей сначала отправьте небольшую сумму. Подтвердите с получателем, что он ее получил, прежде чем отправлять полную сумму.

2. Призыв к улучшению кошельков:

   • Разработчики кошельков могут помочь, улучшив пользовательские интерфейсы. Это включает отображение большей части адреса по умолчанию или добавление строгих, явных предупреждений, когда пользователь собирается отправить средства на адрес, с которым он взаимодействовал только через крошечный или нулевой перевод.

3. Долгосрочное решение:

   • Такие системы, как Ethereum Name Service (ENS), которые позволяют сопоставить удобочитаемое имя, например yourname.eth, с вашим адресом, могут полностью устранить эту проблему. Широкое распространение является ключом.

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