В Neon Labs мы создаем первую EVM на блокчейне Solana. Наша платформа Neon EVM состоит из двух частей:
- Контракт EVM : программа Solana, которая управляет контрактами Ethereum и сохраняет данные в учетных записях Solana.
- Прокси -сервер : прокси-сервер, который преобразует транзакции, подобные Ethereum, в транзакции Solana, а затем отправляет их в программу EVM в Solana для обработки.
В этой статье мы рассмотрим масштабируемость Neon EVM, рассчитав теоретические пределы транзакций в секунду (TPS) Neon EVM и сравнив теоретические пределы TPS с результатами синтетического нагрузочного теста, проведенного командой.
Как Solana управляет потреблением сетевых ресурсов
Прежде чем мы рассчитаем теоретические лимиты транзакций Neon EVM, важно понять, как Solana управляет потреблением сетевых ресурсов.
Пользователи Solana платят небольшую комиссию за каждую транзакцию в зависимости от объема потребляемых ими вычислительных ресурсов (подробнее здесь ). Комиссия поддерживает стабильность сети и всегда будет одинаковой для транзакций, идентичных по операционному принципу. Это не зависит от требований сети. Эта модель отличается от Ethereum, где пользователи должны платить «газовую» плату, определяемую спросом и предложением вычислительной мощности сети.
Количество вычислительных ресурсов, необходимых для транзакции Solana, измеряется в вычислительных единицах (CU). Каждый « слот », созданный Соланой, ограничен потреблением 48 миллионов CU. Поскольку каждый «слот» составляет минимум 400 мс, Solana теоретически может поддерживать использование 120 миллионов CU в секунду.
Теоретические лимиты транзакций на Neon EVM
Транзакция, которая отправляет токены NEON между учетными записями, стоит от 50 000 до 65 000 вычислительных единиц. В этом примере транзакции Neon мы видим, что связанная с ней транзакция Solana требует 52 127 вычислительных единиц.
Из предыдущего раздела мы знаем, что Solana имеет ограничение в 48 миллионов CU на слот, а каждый слот составляет минимум 400 мс. С помощью этих трех точек данных мы можем рассчитать теоретические пределы TPS для простых транзакций, таких как передача токена NEON.
- 48 миллионов CU на слот / в среднем. 60 000 CU на транзакцию = 800 транзакций на слот
- 800 транзакций на слот = 800 транзакций на 400 мс
- 800 транзакций на 400 мс = 2000 транзакций в секунду
Исходя из вышеизложенного, наш теоретический предел составляет ~ 2000 TPS для простых транзакций по передаче токенов. В следующем разделе мы подробно опишем наше синтетическое нагрузочное тестирование и сравним результаты с нашими теоретическими ~2000 TPS.
Синтетическое нагрузочное тестирование
Наши стенды
Сначала мы установили узел Solana на выделенный сервер с рекомендованными Solana конфигурациями . Характеристики следующие: 12-ядерный процессор и 128 ГБ оперативной памяти. Для нагрузочного теста мы установили 6 серверов с 8 процессорами и 32 ГБ ОЗУ в том же центре обработки данных, что и наш узел Solana, для меньшего пинга.
Программное обеспечение
Для создания синтетической нагрузки мы использовали фреймворк https://locust.io на Python. Фреймворк был выбран потому, что он позволяет быстро создавать нагрузочные тесты, а необходимые библиотеки для нашей задачи уже были написаны на Python. Весь код можно найти здесь .
Подготовка
Перед запуском нагрузочного теста мы предприняли следующие действия:
- Мы отключили оператора белого списка в EVM и увеличили количество казначейских счетов.
- Мы создали учетные записи отправителя/получателя Ethereum и Solana через сборщик (аирдроп токенов NEON на учетные записи)
- Подготовили операторские аккаунты (аирдроп Солана и неон на каждый операторский ключ)
Для шагов 2 и 3 выше мы использовали этот скрипт .
Запустить тест
Мы запустили 8 экземпляров саранчи на каждом сервере нагрузочного тестирования, потому что один обработчик саранчи может создавать только 66 транзакций в секунду (он использует только одно ядро на процесс).
Также было создано несколько переменных среды , потому что нам нужно было разделить ключи нашего оператора и учетные записи пользователей между каждым процессом саранчи.
После установки мы запустили наш процесс саранчи, используя следующую команду:
Полученные результаты
Когда мы запустили более 40 процессов борьбы с саранчой, мы наблюдали отличные результаты в официальном исследовании Соланы, соответствующие нашим теоретическим расчетам:
После выполнения нагрузочного теста более 30 минут мы сделали следующий снимок производительности:
В одном слоте мы увидели более 800 транзакций:
По завершении нашего тестирования мы отметили максимальное количество транзакций в секунду, равное 2169 за 30 минут. Результаты немного превышают наши теоретические расчеты и связаны с разным количеством CU, потребляемых на транзакцию.
На приведенном выше снимке видно, что в транзакциях используется от 57 до 60 тыс. CU.