Neon EVM.
Что будет, если взять блокчейн с наибольшим количеством приложений и максимальным откликом среди разработчиков и комьюнити, и скрестить его с блокчейном, который позволяет наиболее эффективно масштабировать приложения, при этом обладая высочайшей скоростью транзакций?
Neon EVM:
Инструмент, который позволяет обрабатывать ETH-подобные транзакции на блокчейне Solana, используя все преимущества функционала, имеющегося на Cолане:
- Cкорость развития самого блокчейна.
- Внедрение нового функционала.
То, что некоторые блокчейны изобретают и вводят в обиход, занимает порой пару лет, а на Солане аналогичная процедура протекает в течение пары месяцев.
C Neon EVM появляется возможность выполнения параллельных транзакций.
Смарт-контракты, расположенные на базе Ethereum, – по своему устройству должны выполняться последовательно. Что сильно ограничивает скорость обработки.
Даже если учитывать блокчейны с оптимизированным EVM, то максимальная скорость обработки 1.500 TPS.
В то время когда Солана была разработана с упором на массовое масштабирование DApps – максимальная пропускная способность составляет 50.000 TPS.
Разница в 33 раза, звучит неплохо, правда же?
Neon EVM построен как смарт-контракт на Cолане.
Для чего?
Гибкость в плане обновлений, а также легчайшее обновление при появлении нового функционала на Ethereum.
Neon EVM – промежуточный прокси-сервер, который сворачивает (WRAP) ETH-подобные транзакции и преобразует их в транзакции на Cолане, после чего отправляет в сам Neon EVM для параллельной обработки.
Подобное решение позволяет запускать на Солане любой Ethereum DApps без изменений в коде проекта.
С помощью Neon EVM – все ключевые инструменты для DApps, которые базируются на Ethereum, можно будет использовать на Cолане. К примеру Metamask, Solidity, Remix, Truffle и тд.
Как можно было догадаться – Neon EVM отлично подходит для уже существующих протоколов и разработчиков в целом.
Немного технических аспектов:
У блокчейна Солана есть виртуальная машина BPF. Она также используется в ядре Linux. И сам байткод BPF изначально строился для выполнения задач с максимальной скоростью.
А также и сама Солана поддерживает компиляцию “just in time” для байткода BPF, что еще более увеличивает скорость исполнения BPF-контрактов.
Neon EVM же написан на языке Rust, как и сама Солана, и скомпилирован в BPF-байткод.
Это означает, что Neon EVM впитывает в себя весь функционал, который есть у Соланы, и дополняет параллельным выполнением транзакций.
Neon EVM также легкообновляем даже если Солана проведет какой-либо мощнейший форк в будущем.
Архитектура:
Neon EVM - это виртуальная машина Ethereum, скомпилированная в байткод Berkeley Packet Filter виртуальной машины, работающей на Solana.
Пользователь Neon EVM - это любой пользователь, имеющий аккаунт в Neon EVM с балансом в токенах ETH, ERC20 и ERC721.
Клиент Neon EVM - это любое приложение, которое имеет контракт байткода EVM (Solidity/Vyper/etc.), загруженный в Neon EVM на Solana.
Оператор Neon EVM - это любой аккаунт Solana (кошелек), который оплачивает выполнение транзакции Neon в токенах SOL и получает оплату за эту работу от пользователя Neon EVM в произвольном токене, указанном пользователем.
Neon EVM Governance - это децентрализованное управление Neon EVM, которое управляет работой Neon EVM, устанавливая параметры Neon EVM и обновляя программное обеспечение Neon EVM, оно же получает комиссию за свои услуги.
Neon Web3 Proxy - это инструмент, который может быть использован оператором Neon EVM для упаковки транзакции Neon в транзакцию Solana.
Neon Transaction - это транзакция, сформированная в соответствии с правилами Ethereum, с подписью, созданной по правилам Ethereum.
Bridge - это стороннее решение EVM (независимое от Neon) с собственными операторами.
Neon EVM содержит следующий функционал:
Загрузка контрактов EVM (созданных компиляторами Solidity/Vyper) в отдельные учетные записи Solana.
Проверка подписей в соответствии с правилами Ethereum на Solana.
Выполнение транзакций Neon, в том числе, при необходимости, в итеративном режиме, с учетом ресурсных ограничений Solana с финансовыми гарантиями завершения транзакций.
Расчет потребления газа в соответствии с правилами Ethereum.
Получение платежа пользователя оператором Neon EVM за потребленный газ и комиссионные в любом ETH или любом токене ERC-20, указанном пользователем.
Расчет и снятие платы в токенах SOL в пул управления Neon EVM со счета оператора Neon EVM за выполнение транзакций Neon.
Хранение данных EVM-контрактов в виде хэш-таблицы с использованием алгоритма Hash Array Mapped Trie (HAMT).
Neon Web3 Proxy
Neon Web3 Proxy - это сервис, предоставляющий Web3 API для доступа к блокчейну Solana. Он является посредником для связи между пользователями Neon EVM и самим Neon EVM, и может запускаться операторами Neon EVM.
Neon Web3 Proxy необязателен для пользователей Neon EVM. Его основная функциональность заключается в том, чтобы помочь пользователям Neon EVM начать использовать Neon EVM без каких-либо изменений в source-коде.
Для каждого токена блокчейна Solana может быть развернут контракт ERC-20 SPL-Wrapper.
Задача ERC-20 SPL-Wrapper - обеспечить взаимодействие приложений Solana с контрактами на байткоде EVM (Solidity/Vyper/и тд).
ERC-20 SPL-Wrapper также может использоваться для перевода средств в токенах Solana с помощью кошельков Ethereum таких, как Metamask.
Этот контракт предназначен для контрактов ERC-20.
При его вызове генерируется токен Solana, который представляет соответствующий токен ERC-20 в контракте SPL-token.
Токены Solana, зарегистрированные в контракте SPL-token, могут быть переданы в контракты Solana.
Независимость операций внутри Neon EVM.
Neon EVM обеспечивает независимость своей деятельности, предоставляя открытый доступ к своей инфраструктуре любому, кто хочет и может запустить Neon Web3 Proxy.
Более того, Neon Web 3 Proxy может быть заменен на пользовательскую библиотеку любым пользователем Neon EVM.
Транзакции, получаемые Neon EVM, не могут быть дискриминированы, поскольку они не имеют никаких атрибутов, определяющих их приоритет.
Что такое ценовая дискриминация? Ценовая дискриминация - это стратегия продажи, которая взимает с клиентов разные цены за один и тот же продукт или услугу в зависимости от того, считает ли продавец, что может заставить клиента согласиться. При чистой ценовой дискриминации продавец взимает с каждого клиента максимальную цену, которую тот заплатит. В более распространенных формах ценовой дискриминации продавец размещает клиентов в группах на основе определенных атрибутов и взимает с каждой группы разные цены.
Неизменные поля и подписи пользователя, проверяемые Neon EVM, гарантируют последовательность выполнения транзакций Neon и защищают от повторного выполнения.
Параллельное выполнение транзакций Neon на Solana.
Большинство блокчейнов обрабатывают транзакции в одном потоке.
Это означает, что один контракт за раз изменяет состояние блокчейна. В отличие от этого, Solana может обрабатывать десятки тысяч контрактов параллельно, используя столько ядер, сколько доступно ее валидатору.
Эта функциональность известна как Sealevel, и она значительно увеличивает пропускную способность. Параллельная обработка возможна благодаря тому, что транзакции Solana описывают все состояния, которые транзакция будет читать или записывать во время выполнения.
Это предотвращает наложение транзакций друг на друга, позволяя параллельно выполнять независимые транзакции и транзакции, читающие одно и то же состояние.
Транзакции Neon выполняются Solana как собственные транзакции:
параллельно, ограничивая при этом доступ к общим данным из состояния Solana.
Однако в некоторых случаях транзакция Neon требует больше ресурсов, чем Solana выделяет для одной транзакции.
В этом случае Neon EVM выполняет транзакцию итеративно, при этом используется расширенный режим ограничения доступа к общим данным в состоянии Solana.
Чтобы обеспечить параллельное выполнение транзакций Solana, она требует список всех счетов Sol., участвующих в транзакции.
Если происходит обращение к счету Solana, который не указан в заголовке транзакции Solana, алгоритм прерывает выполнение с ошибкой.
Параллельное выполнение транзакций Neon с помощью Neon EVM осуществляется следующим образом:
1. Каждый контракт байткода EVM (Solidity/Vyper/etc.), выполняемый на Solana, имеет независимое состояние.
2. Neon Web3 Proxy имеет встроенный EVM аналогичный Neon EVM.
3. Когда Neon Web3 Proxy получает транзакцию Neon:
- Он выполняет тестовый запуск транзакции Neon, вызывая узел Solana для получения текущего состояния.
- В результате проведенного теста Neon Web3 Proxy получает полный список контрактов и счетов, участвующих в транзакции Neon.
- Он формирует транзакцию Solana, используя список контрактов Neon и счетов Neon, внутри которых упакована транзакция Neon.
4. Solana получает всю необходимую информацию для выполнения контрактов Solidity с помощью своих инструментов, включая параллельное выполнение.
Ускорение выполнения транзакций Neon.
Как отмечалось выше, Neon Web3 Proxy выполняет тестовый прогон для получения полного списка учетных записей Neon, которые используются для выполнения транзакций Neon.
Тестовый прогон занимает время, и это время может быть критичным, когда транзакция должна быть выполнена быстро.
Любая транзакция Neon может быть выполнена без тестового запуска следующим образом:
1. Транзакция Solana создается на стороне клиента (веб/мобильный) с упакованной в нее транзакцией Neon.
Транзакция Solana отправляется непосредственно на узел Solana без Neon Web3 Proxy.
Важно понимать, что при использовании этого метода, отправитель должен убедиться в том, что:
- В случаях, когда транзакция Neon слишком велика, ее приходится выполнять итеративно.
- На стороне клиента должен быть определен список всех счетов и контрактов Neon, соответствующих транзакции Neon.
2. Можно использовать дополнительные методы в Neon Web3 Proxy с передачей списка задействованных счетов Neon.
Важно понимать, что - при использовании этого метода - отправитель должен убедиться, что на стороне клиента должен быть определен список всех счетов Neon и контрактов, соответствующих транзакции Neon.
Итеративное выполнение транзакций Neon.
Блокчейн Solana ограничивает ресурсы, выделяемые на выполнение одной транзакции, чтобы обеспечить оптимальное использование аппаратного обеспечения.
Чтобы обеспечить максимально эффективное обслуживание (с учетом существующих ограничений Solana), Neon EVM вводит итеративное выполнение транзакций Neon.
Основные этапы итеративного выполнения следующие:
1. Neon EVM переводит депозит в токенах SOL со счета оператора на отдельный счет.
2. Размер депозита определяется настройками Neon EVM, установленными руководством Neon EVM.
- Вознаграждения валидаторам Solana за выполнение транзакций Solana.
- Платы за управление Neon EVM, которая идет в пул управления (Governance = DAO).
- Платы за итеративное выполнение транзакции Neon, которая заблокирована.
3. Neon EVM блокирует счета Solana, используемые в транзакциях Neon.
4. Если какие-либо счета Solana уже заблокированы другой транзакцией Neon, то новая транзакция ставится в очередь на выполнение Neon Web3 Proxy.
Настройки Neon EVM - параметры устанавливает Neon EVM Governance:
Максимальное количество итераций для одной транзакции Neon. В настоящее время Solana взимает плату за проверку подписей, указанных в транзакции Solana.
Таким образом, в транзакции Solana указывается только подпись Solana оператора Neon EVM, отвечающего за транзакцию.
Все подписи Neon проверяются Neon EVM во время выполнения транзакций Neon.
Количество итераций для каждой транзакции Neon заранее неизвестно. Необходимо ограничить время выполнения транзакции, поскольку все счета и контракты, задействованные в этой транзакции, будут заблокированы для использования в других транзакциях Neon.
Поэтому управление Neon EVM устанавливает максимальное количество итераций и максимальное количество блоков ожидания (Mn).
Размер депозита напрямую зависит от максимального количества итераций.
Взнос в пул управления Neon EVM
1. Депозит для итеративного выполнения транзакции Neon:
- Зависит от количества счетов (аккаунтов/кошельков), участвующих в транзакции, поскольку это влияет на параллельное выполнение транзакций в Solana. Выплачивается оператору, который выполняет последний шаг транзакции Neon и завершает ее.
2. Максимальное количество блоков ожидания (Mn) определяется управлением Neon EVM.
Оператору предоставляется максимальное количество блоков (Mn) между двумя итерациями, когда он может выполнить следующую итерацию.
По истечении Mn блоков любой другой оператор может продолжить выполнение и получить депозит.
Mn: максимальное количество блоков ожидания между двумя итерациями для одного оператора после которого транзакция может быть продолжена другим оператором.
Mi: максимальное количество итераций на одну транзакцию Neon.
Li: количество SOL для проверки одной подписи Солана.
Na: количество счетов, используемых в транзакции Solana.
Fa: депозит в SOL для итеративного исполнения, который будет выплачен на каждый счет Solana, указанный в транзакции.
Fg: плата в SOL в пул управления Neon EVM.
Основные этапы итеративного выполнения транзакции Neon следующие:
1. Если это не первая итерация, то:
- Если прошло более Mn блоков, выполнение передается другому оператору.
- Восстановите состояние Neon EVM.
2. Выполните максимальное количество шагов EVM, указанных в транзакции Solana.
3. Если это не конец исполнения:
- Запись оператора, который завершил шаг в итеративном выполнении.
- Увеличьте количество завершенных итераций.
- Сохраните состояние Neon EVM до состояния Solana.
Условия для завершения итеративного выполнения транзакции Neon:
2. Мi: итерации транзакций Neon были достигнуты.
3. Транзакция Neon была отменена, в этом случае неизрасходованный депозит сгорает.
Транзакции Neon могут быть отменены:
- Любым оператором Neon EVM, если с момента последней итерации не прошло Mn блоков.
- Иначе, оператором Neon EVM из последнего итерационного выполнения.
В конце итеративного выполнения транзакции Neon:
1. Результат транзакции Neon сохраняется в чеке Solana.
2. Оператору Neon EVM выплачивается оставшийся депозит.
Формула для расчета оставшегося депозита:
Mi: максимальное количество итераций на одну транзакцию Neon. Md: количество итераций, используемых для выполнения транзакции Neon.
Li: количество SOL для проверки одной подписи Солана. Na: количество счетов в транзакции Солана.
Fa: сумма депозита в SOL для итеративного исполнения для одного счета в транзакции Solana.
Rd: итоговые остатки вклада в SOL.
Оплата за транзакции произведенные с помощью Neon.
Расчет стоимости выполнения транзакции в Neon EVM осуществляется в соответствии с правилами Ethereum. Для этого используется инструмент для расчета газа, доступный в Ethereum.
Об инструменте по расчету газа мы писали здесь.
Стоимость газа в Neon EVM значительно ниже, чем в Ethereum, поскольку она основана на цене газа Solana.
Стоимости выполнения транзакции Solana, которая зависит от количества подписей, указанных в транзакции - как упоминалось ранее, в транзакциях Solana указывается только одна подпись (подпись оператора Neon EVM), поскольку подписи Neon проверяются в Neon EVM (см. выше пункт об итеративном выполнении транзакций).
Платы, выплачиваемой руководству Neon EVM, которое поддерживает работу Neon EVM.
Платы оператору Neon EVM, выполняющему транзакцию.
Платежное средство (токен для оплаты) устанавливается самим пользователем Neon EVM:
По умолчанию пользователь Neon EVM платит оператору Neon EVM в токенах ETH.
Однако Neon EVM предоставляет пользователям возможность выбрать любой другой токен ERC-20 для оплаты транзакций Neon.
Платежные предпочтения хранятся в состоянии Solana.
Существует независимый рынок операторов Neon EVM, и пользователь может выбрать оператора с приемлемыми ценами на транзакции.
Клиенты Neon EVM могут устанавливать собственные цены в зависимости от своих требований.
Любой пользователь Neon EVM может самостоятельно развернуть Neon Web3 Proxy и выполнить транзакцию Neon с помощью Neon EVM без помощи операторов Neon EVM.
В этом случае пользователь должен покрыть выполнение транзакции на Solana токенами SOL.
Чтобы стать оператором Neon EVM, нужно поднять Ноду. Как поднять ноду, о токеномике проекта, DAO и как поучаствовать в тестнете мы расскажем в следующей части отчета.
Публикация подготовлена командой @True_Market_Vision.
