Блокчейн, що здавалося, не може виконувати операції паралельно, адже це порушує логіку роботи такої мережі. Однак обмеження може виникнути лише там, де користувачі одночасно намагаються змінити одне й те саме, пише РБК Крипто.
Основна мережа Ethereum поки виконує транзакції блоку послідовно. Перша змінює стан мережі, друга працює вже з новим станом, потім виконується третя. Повний список адрес і комірок сховища, до яких звернеться довільний контракт, заздалегідь невідомий.
Це має змінитися з оновленням Glamsterdam. EIP-7928 додає Block-Level Access Lists — списки звернень до стану на рівні блоку. Отримавши такий список, клієнт зможе заздалегідь визначити залежності та паралельно читати дані, перевіряти транзакції й розраховувати новий стан. На 10 серпня 2026 року оновлення ще не активовано в Mainnet.
Solana: список даних відомий до запуску
У Solana програма зберігає логіку, а змінний стан перебуває в окремих акаунтах. Транзакція заздалегідь перераховує акаунти, які її інструкції будуть читати та змінювати.
Sealevel отримує цю інформацію до виконання. Якщо набори даних не конфліктують, операції можна відправити на різні ядра. Кілька транзакцій можуть одночасно читати один акаунт. Але якщо хоча б одна з них збирається його змінити, решту звернень до цих даних доводиться узгоджувати.
Наприклад, два перекази між незалежними парами користувачів не заважають один одному. Але тисячі операцій, яким потрібен запис в один акаунт, конкурують за нього.
Звідси практична вимога до розробників Solana: стан вигідно розносити по окремих акаунтах. У липні 2026 року розробники торговельних додатків на Solana обговорювали дроблення книг заявок саме як спосіб уникнути конкуренції за блокування одного акаунта.
Sui: замість єдиного стану — об’єкти
Sui будує мережу навколо об’єктів. Монета, NFT або стан додатка існують як окремі об’єкти зі своїми ідентифікаторами та версіями.
Для об’єктів, що належать одній адресі, можливий швидкий шлях — fastpath. Такі операції оминають консенсус і отримують меншу затримку. Спільні об’єкти, якими можуть користуватися кілька учасників, проходять через консенсус і отримують певний порядок змін.
Тому дві операції з незалежними об’єктами не зобов’язані чекати одна одну. Якщо ж користувачі масово звертаються до одного спільного об’єкта — наприклад, стану одного ринку — виникає конкуренція саме навколо нього.
Сучасна модель Sui стала складнішою за початкову. Зараз мережа підтримує так звані party objects: об’єкт зберігає обмежене володіння, але його операції впорядковуються консенсусом. Документація рекомендує такий варіант замість fastpath, коли одному об’єкту потрібні кілька одночасно оброблюваних транзакцій.
Aptos: спочатку виконати, потім перевірити
Aptos використовує Block-STM. Тут розробнику не потрібно заздалегідь оголошувати повний набір залежностей.
Транзакції вже мають певний порядок у блоці, але кілька операцій запускаються одночасно. Рушій відстежує читання та записи. Якщо з’ясовується, що одна транзакція використала застаріле значення, її результат скасовується і обчислення повторюється.
Кінцевий стан залишається таким самим, яким він був би при послідовному виконанні. Паралельність існує всередині вузла і не змінює порядок операцій, який бачить блокчейн.
Block-STM розробила команда Aptos Labs. В актуальній документації Aptos зазначено, що після публікації цей підхід прийняли або адаптували Polygon, Sei, Starknet та інші проєкти.
Як паралельність працює з EVM
У Ethereum Virtual Machine (EVM — віртуальна машина Ethereum) контракт може під час виконання звертатися до іншого контракту та довільних комірок сховища. Залежності часто стають зрозумілими лише після запуску операції.
Monad вирішує завдання оптимістично. Транзакції зберігають звичайний лінійний порядок, але перший прохід виконується паралельно. Потім результати підтверджуються в порядку.
Якщо операція прочитала дані, які змінила більш рання транзакція, вона виконується повторно. За документацією Monad, одна транзакція виконується максимум два рази: спочатку і, якщо виявилася залежність, під час повторного проходу.
При цьому конфлікт визначається не за адресою контракту, а за конкретними даними. У документації Monad є приклад: Аліса переказує USDC Бобу, а Чарлі — Девіду. Обидві транзакції викликають один контракт USDC, але працюють з різними комірками балансів і можуть виконуватися паралельно.
Якщо ж перша операція переказує USDC Аліси Бобу, а наступна одразу відправляє частину балансу Боба Чарлі, з’являється залежність. Друга спочатку побачить старий баланс Боба, тому її доведеться перерахувати.
Що показує Sei
Sei використовує оптимістичний контроль конкурентного доступу. До виконання система оцінює, які ключі стану може зачепити транзакція, розподіляє операції між робочими потоками, а потім перевіряє результат на конфлікти. Залежні операції виконуються повторно.
Документація Sei наводить результати внутрішніх випробувань. Прості перекази зросли приблизно з 3 тис. до понад 15 тис. операцій на секунду, перекази ERC-20 — з 2,2 тис. до понад 9,5 тис., обміни на децентралізованій біржі — з 800 до понад 2,8 тис.
Це не заявлена стала швидкість мережі. Чим більше незалежних операцій, тим краще завантажені ядра. При великій кількості конфліктів частина виграшу «з’їдається» перевірками та повторним виконанням.
Для майбутнього Sei Giga розробникам окремо рекомендують зберігати стан користувачів роздільно. У документації наведено приклад токена, де баланси лежать в окремих елементах mapping. Додавання загального лічильника переказів, навпаки, змушує всі операції змінювати одну комірку і створює штучну чергу.
Вузьке місце — дані, а не контракт
Сам по собі популярний контракт не означає послідовне виконання. Важливіше, які саме дані змінюють його користувачі.
Десять тисяч переказів одного ERC-20 можуть зачіпати тисячі незалежних балансів і добре розподілятися між ядрами. Якщо ті ж десять тисяч операцій щоразу збільшують один глобальний лічильник, усі вони конкурують за одну комірку.
Саме тому архітектура додатка починає впливати на пропускну здатність блокчейну. Solana дозволяє розділяти стан між акаунтами, Sui — між об’єктами, а паралельні EVM знаходять залежності на рівні окремих комірок сховища.
Чому більше ядер не означає більше TPS
Паралельне виконання не скасовує єдиного результату. Усі валідатори мають отримати однаковий стан після одного набору транзакцій.
Solana намагається визначити конфлікти до виконання. Sui використовує властивості об’єктів і консенсус. Aptos, Monad та Sei допускають оптимістичний запуск і потім перевіряють залежності. Різні архітектури вирішують одне завдання: використовувати кілька ядер, не змінюючи результат обчислень.
Тому показник TPS (transactions per second — транзакцій на секунду) без опису навантаження мало що говорить. Тисяча незалежних переказів і тисяча операцій навколо одного спільного стану висувають до мережі абсолютно різні вимоги.
Не дорівнює паралельність і простому збільшенню блоку. Великий блок дозволяє включити більше обчислень. Паралельне виконання намагається швидше обробити наявну роботу. Після процесора обмеженнями стають пам’ять, база стану, швидкість накопичувачів і передача даних між вузлами.
Ethereum зараз готує власний варіант цієї оптимізації. Block-Level Access Lists у Glamsterdam мають надати клієнтам карту залежностей, якої бракує сьогоднішньому послідовному виконанню. Актуальна дорожня карта очікує активацію Glamsterdam у другій половині 2026 року.