У Neon Labs ми будуємо перший EVM на блокчейні Solana. Наша платформа, Neon EVM, складається з двох частин:
Договір EVM: Програма Solana, яка керує контрактами Ethereum та зберігає дані на рахунки Солані.
Проксі-сервер: проксі, який перетворює транзакції, подібні до Ethereum, у транзакції Solana, а потім надсилає їх у програму EVM в межах Solana для обробки.
У цій статті ми вивчимо масштабованість Neon EVM, обчислюючи теоретичні транзакції в секунду (TPS) Neon EVM та порівнюючи теоретичні межі TPS проти результатів синтетичного навантаження, проведеного командою.
Перш ніж обчислити теоретичні обмеження транзакцій Neon EVM, важливо зрозуміти, як Solana управляє споживанням мережевих ресурсів.
Користувачі Solana сплачують невелику плату за кожну транзакцію на основі суми обчислювальних ресурсів, які вони споживають (детальніше тут). Плата підтримує стабільність мережі і завжди буде однаковою для операцій, які є оперативно однаковими. Це не залежить від попиту на мережу. Ця модель відрізняється від Ethereum, коли користувачі повинні сплачувати "газову" плату, визначену попитом та пропозицією потужності обчислення мережі.
Кількість обчислювальних ресурсів, необхідних для транзакції Солана, вимірюється в обчислювальних одиницях (CUS). Кожен «слот», створений Соланою, обмежується споживанням 48 мільйонів куб. Оскільки кожен «слот» мінімум 400 мс, Солана теоретично може підтримувати використання 120 мільйонів CUS в секунду.
Угода, яка надсилає неонові жетони між рахунками, коштує від 50 000 до 65 000 обчислювальних одиниць. У цьому прикладі неонової транзакції ми можемо побачити, що її пов'язана транзакція Solana вимагала 52,127 обчислювальних одиниць.
З попереднього розділу ми знаємо, що Солана має обмеження 48 мільйонів кублів на слот, і кожен слот - мінімум 400 мс. За допомогою цих трьох точок даних ми можемо обчислити теоретичні межі TPS для простих транзакцій, як передача неонових маркерів.
48 мільйонів кублів на слот / серп. 60 000 куб на TXN = 800 TXN на слот
800 TXNS на слот = 800 TXN на 400 мс
800 TXNS на 400 мс = 2000 TXN в секунду
З вищезазначеного, наша теоретична межа становить ~ 2000 TPS для простих транзакцій передачі токенів. У наступному розділі ми деталізуємо наше тестування синтетичного навантаження та порівняємо результати з нашим теоретичним ~ 2000 TPS.
Наші трибуни
По-перше, ми встановили вузол Solana на спеціалізований сервер із конфігураціями, рекомендованими Solana. Характеристики такі: 12 ядер CPU та 128 ГБ оперативної пам’яті. Для тестового працівника навантаження ми встановили 6 серверів з 8 процесорами та 32 ГБ оперативної пам’яті в тому ж центрі обробки даних, що і наш вузол Solana для меншої пінг.
Для створення синтетичного навантаження ми використовували рамку https://locust.io в Python. Рамка була обрана, оскільки вона дозволяє швидко створювати тести на навантаження, і ми вже мали необхідні бібліотеки для нашого завдання, написаного в Python. Весь код можна знайти тут.
Перш ніж запустити тест навантаження, ми вжили наступних дій:
Ми відключили оператора білих в EVM та збільшили кількість казначейських рахунків
Ми створили облікові записи Ethereum та Solana Sender/Recitient через кран (Neon -маркери Airdrop до рахунків)
Ми підготували облікові записи оператора (Airdrop Solana та Neon до кожного ключа оператора)
Для кроків 2 і 3 вище ми використовували цей сценарій.
Ми запустили 8 екземплярів сарани на кожному тестовому сервері навантаження, оскільки один працівник сарани може створювати лише 66 транзакцій в секунду (він використовує лише один ядровий на процес.)
Також було створено кілька змінних середовищ, оскільки нам потрібно було розділити ключі нашого оператора та облікові записи користувачів між кожним процесом сарани.
Після налаштування ми запустили наш процес Locust, використовуючи таку команду:
Коли ми розпочали процеси 40+ саранки, ми спостерігали чудові результати в офіційній дослідженні Solana вбудовано за допомогою нашого теоретичного розрахунку:
Після запуску тесту на навантаження більше 30 хвилин ми взяли наступний знімок продуктивності:
В одному слоті ми побачили понад 800 транзакцій:
Після закінчення нашого тестування ми відзначили максимальний TPS 2169 протягом 30 хвилин. Результати трохи вищі, ніж наш теоретичний розрахунок, і пояснюються різною кількістю споживаних CUS за транзакцію.
На наведеному вище знімку ви можете побачити, що в транзакціях використовується десь від 57 к до 60 к.с.
Статтю переклав :
Discord - Sivic007#6940
Twitter - VaceslavPenov