Цель Neon Labs — обеспечить масштабируемость и низкую стоимость Solana для экосистемы Ethereum dApps, разработчиков и конечных пользователей. Наше решение, Neon EVM, представляет собой встроенный в Solana инструмент совместимости с EVM, который позволяет смарт-контрактам Solidity, запущенным на платформе, взаимодействовать с традиционными токенами SPL и токенами ERC20, обернутыми в SPL. Один из наших основных принципов — предоставлять возможности Neon EVM таким образом, чтобы не нарушать работу разработчиков или конечных пользователей. Короче говоря, мы хотим обеспечить как можно более естественный опыт работы с EVM при работе на Solana.

Чтобы сделать Neon EVM более «удобным» как для разработчиков, так и для конечных пользователей, мы создали Neon Web3 Proxy — дополнительный компонент инфраструктуры для экосистемы Neon. Прокси упаковывает транзакции, подобные Ethereum, называемые транзакциями Neon, в транзакции Solana, снимая с разработчиков бремя реализации логики преобразования. Это позволяет проектным группам сосредоточиться на создании своих продуктов/услуг, а не беспокоиться о совместимости между своими смарт-контрактами Solidity и Solana. Это также позволяет проектным группам без каких-либо изменений перемещать существующий исходный код смарт-контракта Solidity в Neon EVM. Для конечных пользователей прокси-сервер избавляет их от необходимости вручную структурировать транзакции для правильного выполнения на Neon EVM. Они могут продолжать использовать децентрализованные приложения Solidity в обычном режиме без каких-либо дополнительных действий.

Чтобы преодолеть проблемы совместимости между транзакциями Ethereum и Solana, при проектировании решения Neon Web3 Proxy необходимо учитывать три ключевых момента:

Вычислительный бюджет Solana составляет 200 000 инструкций BPF на транзакцию. Бюджет вычислений применяется, чтобы «предотвратить злоупотребление вычислительными ресурсами программы».
Ограничение размера транзакции Solana составляет 1232 байта. Ограничение размера транзакции применяется для «обеспечения быстрой и надежной сетевой передачи информации о кластере по протоколу UDP».
Большие размеры транзакций Ethereum. Транзакции Ethereum не ограничены двумя указанными выше ограничениями Solana и могут стать большими по размеру и количеству инструкций.

Когда Neon Web3 Proxy принимает транзакцию Neon, он попытается упаковать транзакцию Neon в одну транзакцию Solana (мы будем называть их неитеративными транзакциями на протяжении всей статьи) для выполнения Neon EVM. Неитеративные транзакции содержат следующую информацию:

Neon EVM в качестве целевого смарт-контракта, выполняющего транзакцию
Сериализованные данные транзакции, содержащие, но не ограничиваясь:
- Флаг функции Neon EVM. Это сообщает Neon EVM, как выполнить транзакцию.
- Отправитель транзакции.
- Имя смарт-контракта.
- Данные транзакции из запрошенной транзакции Neon.
- Подпись конечного пользователя dApp для транзакции Neon.
Список учетных записей, затронутых транзакцией в емкости чтения/записи.

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

Как структурированы итерационные транзакции и почему они важны

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

Итеративные транзакции необходимы, если выполняется любой из следующих сценариев:

Неитерационная транзакция, созданная из запрошенной транзакции Neon, превышает 1232 байта.
Однократная транзакция, созданная из запрошенной транзакции Neon, содержит более 200 000 инструкций BPF.

Существует два способа структурирования итерационных транзакций:

Фпервый. Предположим, исходная неитеративная транзакция, созданная из запрошенной транзакции Neon, имеет размер менее 1232 байт, но содержит более 200 000 инструкций BPF . В этом случае Neon Web3 Proxy будет генерировать несколько итерационных транзакций Solana, которые содержат почти ту же информацию, что и исходная неитеративная транзакция. Весь набор инструкций будет выполняться для каждой отдельной итерационной транзакции. Каждая итерационная транзакция будет содержать следующие данные:

Neon EVM в качестве целевого смарт-контракта, выполняющего транзакцию.
Сериализованные данные транзакции, содержащие, но не ограничиваясь:
- Флаг функции Neon EVM. Это сообщает Neon EVM, как выполнить транзакцию. В этом случае флаг сообщит Neon EVM, что транзакция должна выполняться итеративно.
- Отправитель транзакции.
- Имя смарт-контракта.
- Данные транзакции из запрошенной транзакции Neon.
- Подпись для транзакции Neon.
- Максимальное количество кодов операций (кодов операций) , которые должны быть выполнены до тех пор, пока транзакция не будет остановлена и состояние Neon EVM не будет сохранено в указанной учетной записи состояния. Это позволяет выполнять транзакцию на Solana, несмотря на наличие более 200 000 инструкций BPF.
Список учетных записей, на которые повлияла транзакция с возможностью чтения/записи. Этот список учетных записей будет содержать дополнительную специальную учетную запись (State Account), используемую для сохранения состояния Neon EVM между выполнением итерационных транзакций.

Свторой Предположим, исходная неитеративная транзакция, созданная из запрошенной транзакции Neon, имеет размер более 1232 байт . В этом случае, независимо от количества инструкций BPF, прокси-сервер запросит создание новой учетной записи Solana, называемой учетной записью держателя. Затем прокси-сервер разбивает исходные данные транзакции на более мелкие части размером менее 1232 байт. Эти данные сохраняются в недавно созданной учетной записи владельца. Параллельно прокси будет создавать идентичные итерационные транзакции со следующими данными:

Neon EVM в качестве целевого смарт-контракта, выполняющего транзакцию
Сериализованные данные транзакции, содержащие, но не ограничиваясь:
- Флаг функции Neon EVM. В этом случае флаг укажет Neon EVM выполнить транзакцию итеративно, используя данные в учетной записи держателя.
- Максимальное количество кодов операций (кодов операций) , которые должны быть выполнены до тех пор, пока транзакция не будет остановлена и состояние Neon EVM не будет сохранено в указанной учетной записи состояния.
Список учетных записей, затронутых транзакцией в емкости чтения/записи. В этот список включены (1) специальная учетная запись (государственная учетная запись), используемая для сохранения состояния Neon EVM между выполнением итерационных транзакций, и (2) учетная запись владельца с данными транзакции, которые должны быть выполнены.

В дополнение к приведенной выше информации, как однократные, так и итеративные транзакции Solana также будут содержать следующие логистические данные платежей (операторы Neon будут подробно описаны в следующем разделе):

Учетная запись оператора Neon EVM, которая будет оплачивать и подписывать транзакцию Solana.
Учетная запись оператора Neon EVM, на которую будет отправлен платеж конечного пользователя для оплаты услуг Оператора
Счет Neon EVM, на который будут депонированы средства для повторного выполнения транзакции.

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

Модель итеративных транзакций является неотъемлемой частью создания транзакций, подобных Ethereum, в Solana, не требуя от проектных групп переписывать какие-либо смарт-контракты. Эта функция позволяет прокси-серверу Neon Web3 упростить транзакции в Neon EVM.

Под капотом прокси-сервера Neon Web3

Как упоминалось ранее, Neon Web3 Proxy является дополнительным компонентом для использования Neon EVM. У разработчиков есть возможность реализовать логику прокси непосредственно в своих dApps. Этот инструмент задуман как готовое решение, которое делает транзакции с Neon EVM dApps максимально похожими на Ethereum.

Функции прокси выполняются с помощью Неоновых Операторов. Операторы являются участниками экосистемы Neon, которые поддерживают выполнение транзакций Solana, генерируемых Neon Web3 Proxy. Когда транзакция Neon подписывается и отправляется на прокси-сервер конечным пользователем dApp, она упаковывается в одну неитеративную транзакцию Solana или несколько итерационных транзакций Solana в зависимости от размера и количества инструкций. Чтобы определить размер и количество инструкций, прокси будет запускать транзакции через внутренний эмулятор EVM. Наряду с размером транзакции и количеством инструкций эмулятор также помогает определить затраты и доступ к учетным записям Solana. Количество созданных итеративных транзакций примерно равно общему количеству кодов операций, возвращенных внутренним эмулятором, деленному на количество кодов операций, указанных для каждой итерационной транзакции.

Чтобы подтвердить успешное выполнение всей транзакции Neon, прокси-сервер Web3 просматривает квитанции о транзакциях, отправленные Neon EVM после выполнения всех итерационных транзакций. Прокси проверяет две вещи:

Была ли выполнена и подтверждена ли каждая отдельная итерационная транзакция в блокчейне Solana.
Если какая-либо из квитанций о транзакции включает флаг «завершения». Флаг «завершение» устанавливается Neon EVM только после выполнения исходной транзакции Neon.

Прокси-сервер Web3 подсчитывает количество транзакций, не подтвержденных Solana, если таковые имеются. Затем он отправляет вторую волну итерационных транзакций в Neon EVM, чтобы завершить выполнение всей транзакции Neon. Количество транзакций во второй волне равно количеству транзакций, не подтвержденных Соланой с первой попытки. Каждая из дополнительных итерационных транзакций содержит данные, идентичные итерационным транзакциям, отправленным в первой попытке.

Основные функции прокси включают в себя :

Получение запросов по протоколу Web3 API (когда пользователь dApp запрашивает транзакцию через клиентский интерфейс, сгенерированная транзакция отправляется на прокси-сервер по протоколу Web3 API).
Формирование ответов с использованием протокола Web3 API.
Упаковка транзакций Neon в транзакцию Solana.
Выполнение методов контрактов Solidity только для чтения.
Предоставление метода доступа к контрактам токенов SPL через транзакции Neon.
Эмулятор EVM, используемый для «тестового запуска» транзакций Solana, сгенерированных из транзакций Neon. «Тестовый запуск» определяет учетные записи Solana, к которым будет осуществляться транзакция Neon, и расчетную стоимость транзакции Neon.
Предоставление пользователям способа выполнить транзакцию Neon без «тестового запуска».

Как работает прокси с Neon EVM

Давайте подробно рассмотрим, как прокси-сервер облегчает транзакции, в сквозном пошаговом руководстве.

Процесс инициируется конечным пользователем, запрашивающим транзакцию при взаимодействии с Neon EVM dApp через своего клиента. Клиент dApp генерирует транзакцию, подобную Ethereum (транзакция Neon), запрашивает подпись пользователя (через MetaMask) и отправляет транзакцию в Neon Web3 Proxy. Транзакция Neon, отправленная на прокси, содержит тот же тип информации, что и стандартная транзакция Ethereum.

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

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

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

После «тестового прогона» прокси сгенерирует неитеративную транзакцию Solana и отправит ее в Neon EVM для попытки выполнения. Транзакция создается с использованием информации из исходной транзакции Neon вместе со списком учетных записей, составленным во время «тестового прогона». Если транзакция завершится неудачно из-за ограничения размера или бюджета вычислений, будет создано несколько итерационных транзакций Solana. Количество созданных итерационных транзакций равно общему количеству необходимых кодов операций, деленному на количество кодов операций, указанных для каждой итерационной транзакции.

Все итерационные транзакции одновременно отправляются в Neon EVM для выполнения. Neon EVM выполнит итеративную транзакцию для заданного количества инструкций и сохранит свое состояние в учетной записи состояния при остановке. Затем он переходит к следующей итерационной транзакции. Используя информацию из учетной записи состояния, EVM определяет, в какой точке списка инструкций начать выполнение. EVM начнет выполнять инструкции, пока не достигнет предела инструкций, указанного в данных итерационной транзакции.

После обработки всех отправленных итерационных транзакций прокси-сервер запрашивает квитанции о транзакциях у Neon EVM. Прокси просматривает все квитанции, чтобы проверить, не были ли подтверждены какие-либо повторяющиеся транзакции в блокчейне Solana. Если были какие-либо неподтвержденные итерационные транзакции, прокси-сервер отправит вторую волну итерационных транзакций для завершения общей транзакции Neon. Количество повторяющихся транзакций во второй волне равно количеству неподтвержденных транзакций из первого отправленного пакета.

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

Когда прокси-сервер наконец находит «флаг завершения» в одном из итерационных квитанций транзакции, он отмечает, что вся транзакция Neon завершена. Конечный пользователь, инициировавший транзакцию Neon, платит оператору Neon за его услуги и комиссию за транзакцию Solana. С точки зрения пользователя оплата аналогична оплате децентрализованных приложений через MetaMask. Вся логистика комиссий за транзакции Neon обрабатывается прокси-сервером Web3.

Следующие шаги

Если у вас остались вопросы или вы хотите получить более подробную информацию о Neon Web3 Proxy или итеративных транзакциях, ознакомьтесь с нашими документами для разработчиков, ссылка на которые приведена ниже:

Если эта статья или документы, указанные выше, оставят у вас дополнительные вопросы, свяжитесь с нашей командой через Discord. Мы будем более чем рады помочь вам понять, как прокси-сервер Web3 и итерационные транзакции обеспечивают бесшовные транзакции в Neon EVM. Наконец, если вы хотите стать неоновым оператором или узнать больше об экономике неоновых операторов, ознакомьтесь с нашим кратким руководством оператора .