Редакція не надає інвестиційних порад, матеріал опубліковано виключно в ознайомчих цілях. Криптовалюта — це волатильний актив, який може призвести до фінансових збитків.

Може здаватися, що блокчейн не здатен виконувати операції паралельно, адже це порушує логіку роботи такої мережі. Однак обмеження може виникнути лише там, де користувачі одночасно намагаються змінити одну й ту саму дію, пише РБК Крипто.

Основна мережа Ethereum наразі виконує транзакції блоку послідовно. Перша змінює стан мережі, друга працює вже з новим станом, потім виконується третя. Повний список адрес та комірок сховища, до яких звернеться довільний контракт, заздалегідь невідомий.

Це має змінитися з оновленням Glamsterdam. EIP-7928 додає Block-Level Access Lists — списки доступу до стану на рівні блоку. Отримавши такий список, клієнт зможе заздалегідь визначити залежності та паралельно читати дані, перевіряти транзакції й розраховувати новий стан. Станом на 10 серпня 2026 року оновлення ще не активовано в Mainnet.

У Solana програма зберігає логіку, а змінний стан знаходиться в окремих акаунтах. Транзакція заздалегідь перелічує акаунти, які її інструкції будуть читати та змінювати.

Sealevel отримує цю інформацію до виконання. Якщо набори даних не конфліктують, операції можна відправити на різні ядра. Кілька транзакцій можуть одночасно читати один акаунт. Але якщо хоча б одна з них збирається його змінити, інші звернення до цих даних доводиться узгоджувати.

Наприклад, два перекази між незалежними парами користувачів не заважають одне одному. Але тисячі операцій, яким потрібен запис в один акаунт, конкурують за нього.

Звідси практична вимога до розробників Solana: стан вигідно розносити по окремих акаунтах. У липні 2026 року розробники торгових додатків на Solana обговорювали дроблення книг заявок саме як спосіб уникнути конкуренції за блокування одного акаунта.

Sui будує мережу навколо об’єктів. Монета, NFT або стан додатку існують як окремі об’єкти зі своїми ідентифікаторами та версіями.

Для об’єктів, що належать одній адресі, можливий швидкий шлях — fastpath. Такі операції оминають консенсус і мають меншу затримку. Спільні об’єкти, якими можуть користуватися кілька учасників, проходять через консенсус і отримують певний порядок змін.

Тому дві операції з незалежними об’єктами не мусять чекати одна одну. Якщо ж користувачі масово звертаються до одного спільного об’єкта — наприклад, стану одного ринку, — виникає конкуренція саме навколо нього.

Сучасна модель Sui стала складнішою за початкову. Зараз мережа підтримує так звані party objects: об’єкт зберігає обмежене володіння, але його операції впорядковуються консенсусом. Документація рекомендує такий варіант замість fastpath, коли одному об’єкту потрібні кілька одночасно оброблюваних транзакцій.

Aptos використовує Block-STM. Тут розробнику не потрібно заздалегідь оголошувати повний набір залежностей.

Транзакції вже мають певний порядок у блоці, але кілька операцій запускаються одночасно. Рушій відстежує читання та записи. Якщо з’ясовується, що одна транзакція використала застаріле значення, її результат скасовується і обчислення повторюється.

Фінальний стан залишається таким самим, яким він був би при послідовному виконанні. Паралельність існує всередині вузла і не змінює порядок операцій, який бачить блокчейн.

Block-STM розробила команда Aptos Labs. У актуальній документації Aptos зазначено, що після публікації цей підхід прийняли або адаптували Polygon, Sei, Starknet та інші проєкти.

У Ethereum Virtual Machine (EVM — віртуальна машина Ethereum) контракт може під час виконання звертатися до іншого контракту та довільних комірок сховища. Залежності часто стають зрозумілими лише після запуску операції.

Monad вирішує завдання оптимістично. Транзакції зберігають звичайний лінійний порядок, але перший прохід виконується паралельно. Потім результати підтверджуються по черзі.

Якщо операція прочитала дані, які змінив попередній транзакція, вона виконується повторно. За документацією Monad, одна транзакція виконується максимум два рази: спочатку і, якщо виявлено залежність, під час повторного проходу.

При цьому конфлікт визначається не за адресою контракту, а за конкретними даними. У документації Monad є приклад: Аліса переказує USDC Бобу, а Чарлі — Девіду. Обидві транзакції викликають один контракт USDC, але працюють з різними комірками балансів і можуть вважатися паралельно.

Якщо ж перша операція переказує USDC Аліси Бобу, а наступна одразу відправляє частину балансу Боба Чарлі, з’являється залежність. Друга спочатку побачить старий баланс Боба, тому її доведеться перерахувати.

Sei використовує оптимістичний контроль конкурентного доступу. До виконання система оцінює, які ключі стану може зачепити транзакція, розподіляє операції між робочими потоками, а потім перевіряє результат на конфлікти. Залежні операції виконуються повторно.

Документація Sei наводить результати внутрішніх випробувань. Прості перекази зросли приблизно з 3 тис. до понад 15 тис. операцій на секунду, перекази ERC-20 — з 2,2 тис. до понад 9,5 тис., обміни на децентралізованій біржі — з 800 до понад 2,8 тис.

Це не заявлена постійна швидкість мережі. Чим більше незалежних операцій, тим краще завантажені ядра. При великій кількості конфліктів частина виграшу з’їдається перевірками та повторним виконанням.

Для підготовлюваного Sei Giga розробникам окремо рекомендують зберігати стан користувачів роздільно. У документації наведено приклад токена, де баланси лежать в окремих елементах mapping. Додавання спільного лічильника переказів, навпаки, змушує всі операції змінювати одну комірку і створює штучну чергу.

Сам по собі популярний контракт не означає послідовне виконання. Важливіше, які саме дані змінюють його користувачі.

Десять тисяч переказів одного ERC-20 можуть зачіпати тисячі незалежних балансів і добре розподілятися між ядрами. Якщо ті ж десять тисяч операцій кожен раз збільшують один глобальний лічильник, всі вони конкурують за одну комірку.

Саме тому архітектура додатку починає впливати на пропускну здатність блокчейну. Solana дозволяє розділяти стан між акаунтами, Sui — між об’єктами, а паралельні EVM знаходять залежності на рівні окремих комірок сховища.

Паралельне виконання не скасовує єдиного результату. Всі валідатори мають отримати один стан після одного набору транзакцій.

Solana намагається визначити конфлікти до виконання. Sui використовує властивості об’єктів та консенсус. Aptos, Monad та Sei допускають оптимістичний запуск і потім перевіряють залежності. Різні архітектури вирішують одне завдання: використовувати кілька ядер, не змінюючи результат обчислень.

Тому показник TPS (transactions per second — транзакцій на секунду) без опису навантаження мало що говорить. Тисяча незалежних переказів і тисяча операцій навколо одного спільного стану висувають до мережі абсолютно різні вимоги.

Не дорівнює паралельність і простому збільшенню блоку. Великий блок дозволяє включити більше обчислень. Паралельне виконання намагається швидше обробити наявну роботу. Після процесора обмеженнями стають пам’ять, база стану, швидкість накопичувачів та передача даних між вузлами.

Ethereum зараз готує власний варіант цієї оптимізації. Block-Level Access Lists у Glamsterdam мають надати клієнтам карту залежностей, якої бракує сьогоднішньому послідовному виконанню. Актуальна дорожня карта очікує активацію Glamsterdam у другій половині 2026 року.

За матеріалами: cryptocurrency.tech