Solana Sealevel: Паралельний рушій обробки

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

Показники продуктивності в цій статті потребують контексту. Широко цитована цифра 65 000 TPS є теоретичним або контрольованим тестуванням, а не гарантованою пропускною здатністю основної мережі. Цільовий інтервал приблизно 400 мілісекунд не дорівнює остаточності транзакції, а комісії варіюються залежно від підписів, використання обчислень, налаштувань пріоритету та умов мережі.

Ethereum обробляє приблизно 15 транзакцій на секунду на своєму базовому шарі. Документація Solana історично вказувала до 65 000 TPS за теоретичних або контрольованих умов; фактична пропускна здатність, яка спостерігається користувачами, варіюється. Цей розрив — не випадковість. Рушій, що стоїть за цим, називається Sealevel.

Sealevel — це паралельне середовище виконання смартконтрактів Solana: рушій виконання, який обробляє тисячі незалежних транзакцій одночасно, а не по одній. Його розробив Анатолій Яковенко, колишній інженер Qualcomm, який заснував Solana Labs (компанія, що стоїть за розробкою основного протоколу Solana) і написав фундаментальний Whitepaper Solana у 2017 році.

Уявіть головну автомагістраль у годину пік. Solana (Блокчейн або розподілений цифровий реєстр, стійкий до підробки) використовує Sealevel для будівництва сотень смуг і сортування вхідного трафіку за призначенням. Кожен автомобіль на Ethereum повинен використовувати одну смугу. Автомобілі шикуються один за одним і рухаються вперед по одному. Sealevel сортує автомобілі за призначенням: ті, що прямують до різних адрес, рухаються одночасно, без очікування. Лише автомобілі, що прямують до однієї й тієї ж адреси, повинні чекати в черзі. Цей механізм сортування — архітектурна особливість, що стоїть за швидкістю Solana.

Цей пояснювальний матеріал охоплює, що таке Sealevel, як механічно працює його обліково-орієнтований паралелізм, як він порівнюється із середовищем виконання Ethereum, де він поступається, і що ці можливості означають для розробників та інвесторів, які оцінюють Solana.

Паралельна обробка Solana Sealevel: Короткий огляд

• Sealevel — це паралельне середовище виконання смартконтрактів Solana, яке обробляє тисячі транзакцій одночасно.
• Як це працює: транзакції попередньо оголошують залежності облікових записів; Sealevel виконує несумісні транзакції паралельно.
• Пропускна здатність: теоретичний максимум ~65 000 TPS; реальні транзакції, що не є голосуванням, зазвичай досягають 2000–4000 TPS.
• Порівняно з Ethereum: Віртуальна машина Ethereum (EVM) обробляє транзакції по одній; Sealevel одночасно обробляє незалежні.
• Чесне обмеження: Solana зазнала збоїв мережі у 2021 та 2022 роках через збої прийому вище за Sealevel.

Послідовне проти паралельного виконання: Основна проблема, яку вирішує Sealevel

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

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

Обмеження пропускної здатності, яке це створює, є реальним. Віртуальна машина Ethereum (EVM) Ethereum обробляє приблизно 15–30 транзакцій на секунду на своєму базовому шарі (L1) без ролапів рівня 2 (L2), згідно з документацією Ethereum Foundation. Цей показник залишався приблизно постійним роками, оскільки вузьким місцем є архітектура.

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

Паралельна обробка пропонує іншу відповідь. Замість одного касира для всіх покупців уявіть супермаркет із 500 касами. Покупці, які купують абсолютно різні товари (без спільних платіжних терміналів, без спільних бонусних програм), можуть одночасно обслуговуватися на всіх касах. Лише покупці, яким справді потрібен спільний термінал, повинні чекати в черзі. Загальна пропускна здатність магазину зростає на порядки, не тому, що будь-який окремий касир став швидшим, а тому, що незалежні транзакції перестали блокувати одна одну.

Середовище виконання смартконтрактів — це програмне середовище, яке виконує код смартконтрактів на Блокчейні. Це шар, який бере програмний код і фактично виконує його. У Solana смартконтракти називаються «програмами» (канонічний термін у документації Solana, хоча «смартконтракт» залишається широко зрозумілим і використовується тут як синонім). Sealevel — це середовище виконання Solana: створене з нуля для одночасного виконання тисяч таких програм, а не послідовно.

Розуміння того, як Sealevel досягає цього безпечно, без станів гонитви чи пошкодженого стану, вимагає розуміння архітектурного механізму, який робить паралелізм безпечним. Цим механізмом є модель облікових записів Solana.

Як працює Sealevel: Облікова модель та попереднє оголошення стану

Sealevel безпечно досягає паралельного виконання завдяки двом архітектурним особливостям, що працюють разом: модель облікових записів Solana та попереднє впорядкування транзакцій, що забезпечується Proof of History (PoH) — криптографічним механізмом годинника, який створює перевірений часовий штамп для кожної події в мережі Solana. Цей розділ пояснює обидва.

Модель облікових записів Solana: Відокремлення коду від стану

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

У Solana програми містять лише виконуваний код і самі не зберігають дані. Це безстатеві програми: вони містять інструкції, але не мають власного стану. Дані зберігаються в окремих об'єктах облікових записів, які програми можуть читати або записувати. Ця конструкція відокремлює код від стану на архітектурному рівні. Вона відрізняється від моделі Ethereum, де смартконтракт зберігає як свій виконуваний код, так і свій стан за однією адресою контракту.

Кожна транзакція Solana повинна попередньо оголосити, які облікові записи вона буде читати, а які — записувати, до початку виконання. Sealevel читає ці оголошення для планування виконання. Транзакція, яка пропускає цей крок, буде відхилена середовищем виконання. Це не необов'язкове ведення обліку: це структурна передумова, яка робить безпечний паралелізм можливим.

Уявіть двох кухарів, які працюють на кухні з шістьма конфорками. Кухар А готує пасту і потребує конфорок один і два. Кухар Б готує стир-фрай і потребує конфорок чотири і п'ять. Вони можуть працювати одночасно без будь-якої координації, оскільки їхні робочі поверхні не перетинаються. Нікому не потрібно чекати іншого. Лише якщо обом кухарям потрібна конфорка три одночасно, одному доведеться чекати. Sealevel застосовує цю точну логіку до транзакцій: ті, що використовують різні облікові записи, виконуються паралельно; ті, що спільно використовують обліковий запис для запису, виконуються послідовно.

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

Як Sealevel планує паралельне виконання

Коли транзакція досягає Sealevel, процес планування проходить чотири окремі етапи.

1. Транзакція надходить із маніфестом: повний список облікових записів, які вона буде читати, та облікових записів, які вона буде записувати.
2. Sealevel будує граф залежностей (карту транзакцій, які спільно використовують облікові записи), одночасно порівнюючи маніфести всіх очікуючих транзакцій.
3. Транзакції, які не спільно використовують облікові записи для запису, є незалежними. Sealevel одночасно розподіляє їх до окремих ядер процесора, запускаючи їх паралельно на всіх доступних ядрах CPU та GPU.
4. Транзакції, які заявляють залежність запису до одного й того ж облікового запису, перебувають у конфлікті. Sealevel серіалізує ці конкретні транзакції, виконуючи їх одну за одною в порядку, встановленому PoH, тоді як усі інші, що не конфліктують, продовжують виконуватися паралельно.

Цей підхід є детермінованим паралелізмом: Sealevel ідентифікує конфлікти перед початком виконання, а не вирішує їх після факту. Він не виконує транзакції спекулятивно та не відкочує невдачі. Це відрізняє його від підходів оптимістичної паралельності, як-от Aptos Block-STM, де транзакції спочатку виконуються спекулятивно, а потім повторно запускаються у разі конфлікту.

Sealevel також може маршрутизувати завдання перевірки підписів до ядер GPU, подібно до того, як GPU виконує тисячі обчислень шейдерів одночасно в ігрових або AI-навантаженнях. Блокчейн Solana Transaction Processing Unit (TPU) використовує конвеєризацію для одночасного виконання етапів валідації транзакцій на апаратних блоках, при цьому Sealevel обробляє етап виконання цього конвеєра.

Sealevel проти Ethereum EVM: Пряме архітектурне порівняння

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

Порівняння Sealevel та EVM

EVM обробляє транзакції по одній, оскільки його статусна архітектура смартконтрактів робить архітектурно складним визначити заздалегідь, які транзакції безпечно паралелізувати. Смартконтракти на Ethereum зберігають власний стан. Будь-які два смартконтракти теоретично можуть спільно використовувати стан, і без попереднього знання, які транзакції є незалежними, їх паралелізація ризикує пошкодити стан. Це не недолік дизайну Ethereum; це наслідок його архітектури.

Solana компілює програми до модифікованого байт-коду Solana eBPF (extended Berkeley Packet Filter): компактного набору інструкцій, адаптованого з добре встановленого формату, рідного для Linux. Sealevel виконує цей байт-код зі швидкістю, близькою до нативної. Байт-код EVM, навпаки, виконується на спеціальній програмно-емульованій віртуальній машині. Підхід BPF надає шляхи оптимізації на рівні обладнання, яких немає у власному форматі EVM, що сприяє перевазі Sealevel у пропускній здатності на рівні виконання інструкцій.

Що робить Solana архітектурно відмінною від Ethereum:

• Модель виконання: паралельна детермінована (Sealevel) проти послідовної (EVM)
• Архітектура стану: безстатусні програми та окремі облікові записи проти статусних смартконтрактів
• Підхід до масштабування: паралельне виконання L1 проти ролапів L2 та шардингу
• Мова розробки: Rust проти Solidity

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

Sealevel проти Aptos Block-STM та Monad: Як відрізняються підходи до паралельного виконання

Sealevel не є єдиною архітектурою паралельного виконання, що використовується. Порівняння його підходу з Aptos Block-STM та Monad, а також Sui, виявляє різні компроміси, на які йде кожен дизайн.

Aptos використовує Block-STM (Software Transactional Memory), підхід оптимістичної паралельності. Він спекулятивно виконує транзакції паралельно, не вимагаючи попереднього оголошення облікових записів, потім перевіряє результати та повторно виконує будь-які транзакції, що спричинили конфлікти. Перевага для розробників: не потрібно оголошувати залежності облікових записів під час створення. Компроміс: навантаження зі значною кількістю конфліктів викликають повторне виконання, що коштує часу. Sealevel повністю уникає повторного виконання, оскільки ідентифікує конфлікти до запуску.

Monad націлений на паралельне виконання EVM із сумісністю з Ethereum Solidity. Він конвеєризує етапи виконання та застосовує оптимістичний паралелізм поверх моделі EVM. Ставка Monad полягає в тому, що сумісність з EVM варта архітектурних накладних витрат. Sealevel зробив протилежний вибір: чиста модель облікових записів з вищим сирим паралелізмом, але вимагає від розробників прийняття нової парадигми програмування.

Sui використовує володіння об'єктами як одиницю паралелізму. Транзакції, що зачіпають незалежні об'єкти, виконуються паралельно за визначенням, без необхідності явного оголошення. Згідно з поточною документацією, кожен підхід (детермінована модель Sealevel, оптимістична модель Block-STM, модель володіння об'єктами Sui) представляє собою різну відповідь на одне й те саме запитання: як досягти безпечного паралелізму в масштабі.

Жоден підхід не є універсально кращим. Попереднє оголошення Sealevel створює додаткове навантаження для розробників. Оптимістична модель Block-STM несе витрати на повторне виконання при навантаженнях з великою кількістю конфліктів. Monad жертвує сирою продуктивністю заради сумісності з Solidity. Правильний вибір залежить від вимог використання та екосистеми розробників, у якій команда вже працює.

Роль Sealevel в архітектурі з восьми інновацій Solana

Паралелізм Sealevel безпечний лише тому, що Proof of History (PoH) вже встановив довірений порядок транзакцій перед початком виконання. Розуміння цієї залежності виявляє, як Sealevel вписується в ширшу архітектуру з восьми інновацій Solana і чому компоненти не можуть оцінюватися ізольовано.

Архітектура Solana базується на восьми спільно розроблених інноваціях: PoH, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak, Archivers. Кожен обробляє окремий етап життєвого циклу транзакції. Sealevel є рівнем виконання: двигуном, що запускає програми.

PoH — це криптографічний механізм годинника, який створює перевірений часовий штамп для кожної події в мережі Solana. Кожен валідатор погоджується з цією послідовністю часових штампів. До того часу, як транзакції досягають Sealevel, питання їхнього порядку вже вирішено. Sealevel не координує. Він планує.

Уявіть це як конвеєрну стрічку. PoH — це конвеєрна стрічка, яка доставляє попередньо відсортовані робочі елементи у перевіреній послідовності. Sealevel — це команда працівників на лінії, які одночасно беруть та обробляють елементи, що не конфліктують. Працівникам не потрібно домовлятися, який елемент обробляти наступним, тому що стрічка вже визначила порядок. Без стрічки працівники постійно зупинялися б і координувалися, повністю усуваючи перевагу паралелізму.

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

Інші інновації відіграють допоміжну роль. Tower BFT (Механізм консенсусу Solana, оптимізований під PoH варіант Practical Byzantine Fault Tolerance) валідує блоки, які генерує Sealevel. Gulf Stream (протокол пересилання транзакцій без мемпулу) надсилає транзакції валідаторам до підтвердження блоку, тому Sealevel може почати обробку наступної партії, поки поточний блок завершується. Cloudbreak (база даних облікових записів) розроблена спільно з Sealevel для підтримки одночасного читання та запису в тисячах паралельних потоків виконання.

Реальна продуктивність: Що Sealevel насправді надає (і де зазнає невдач)

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

Показники пропускної здатності Solana вимагають уважного читання, оскільки загальновживане число, приблизно 65 000 Транзакцій на Секунду (TPS), описує теоретичну стелю архітектури, а не типову продуктивність основної мережі.

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

Показник ~65 000 TPS є реальним як архітектурна стеля проєктування. Він описує, що Sealevel може обробити за ідеальних умов з оптимальними профілями транзакцій. Реальний показник нижчий з кількох задокументованих причин: складність транзакцій, конкуренція за облікові записи в популярних програмах та мережеві обмеження, що передують самому Sealevel. Навіть з урахуванням цього, пропускна здатність основної мережі Solana значно випереджає базовий шар Ethereum (приблизно 15–30 TPS) (документація Ethereum Foundation).

Можливість паралельного виконання Sealevel є задокументованою архітектурною реальністю, а не маркетинговим твердженням. Теоретичний показник TPS відображає дизайн середовища виконання; реальний показник відображає операційне середовище навколо нього.

Збої мережі та перевантаження: Чесна оцінка

Solana пережила кілька великих збоїв мережі у 2021 та 2022 роках, і будь-яке чесне висвітлення Sealevel повинно пояснити, чому ці збої сталися, незважаючи на можливості паралельної обробки середовища виконання.

Інцидент у вересні 2021 року тривав приблизно 17 годин. Ботнет, який намагався отримати перевагу під час запуску токена, затопив шар прийому транзакцій мережі спамом, перевантаживши його. Додаткові значні збої сталися в січні 2022 року та в кілька моментів протягом 2022 року. Це задокументовані історичні події з опублікованими звітами після аналізу.

Збої не були наслідком логіки паралельного виконання Sealevel. Вони були збоями інфраструктури прийому транзакцій, що передували Sealevel. Потужність Sealevel ~65 000 TPS описує, скільки валідних транзакцій він може обробити; це не робить мережу несприйнятливою до потоків транзакцій. Шосе зі 100 смугами все одно потрапляє в затор, коли мільярд машин намагається одночасно в'їхати на смугу поповнення. Стелі обробки та стійкість до спаму — це окремі інженерні проблеми.

Події карбування (mint) Незмінних Токенів (Non-Fungible Token) (NFT), коли тисячі користувачів намагаються карбувати одночасно, створювали найінтенсивніші сплески навантаження, з якими стикалася мережа, і виявили той самий вузький прохід шару прийому.

Відтоді Solana впровадила кілька інженерних рішень: протокол QUIC замінив UDP для прийому транзакцій (забезпечуючи кращий контроль перевантаження), локальні ринки комісій дозволяють додаткам встановлювати пріоритетні комісії під навантаженням, а клієнт валідатора Firedancer, розроблений Jump Crypto, очікується, покращить пропускну здатність та стійкість. Ці рішення демонструють ітеративне вдосконалення, але жодне оновлення не усуває фундаментальної напруженості між відкритим доступом до подання транзакцій та обмеженою пропускною здатністю.

Багатоядерне паралельне виконання Sealevel також вимагає від валідаторів використання високопродуктивного обладнання: швидких багатоядерних процесорів, великих обсягів оперативної пам'яті та високошвидкісних мережевих з'єднань. Це створює значні бар'єри для участі валідаторів і являє собою компроміс у децентралізації, який правильно відзначають критики архітектури Solana.

Чи є Sealevel міцним конкурентним ровом для Solana (SOL)?

Sealevel надає Solana реальну перевагу в пропускній здатності на базовому рівні. Чи становить ця перевага міцний конкурентний рів, вимагає відділення архітектурних фактів від екосистемних змінних.

Аргумент на користь довговічності починається з глибини інтеграції. Архітектура Sealevel тісно пов'язана з іншими спільно розробленими компонентами Solana. PoH попередньо замовляє транзакції перед їх надходженням до Sealevel. Cloudbreak обробляє паралельне читання сховища, яке потребують паралельні потоки Sealevel. Gulf Stream зменшує чергу транзакцій, яку повинен обробити Sealevel. Відтворення продуктивності Sealevel в ізоляції, без цього повного стеку, не відтворює переваги. Така інтеграція є справжнім бар'єром для відтворення: не абсолютним, але нетривіальним.

Модель облікових записів також створює реальні витрати на перехід для розробників, які створили виробничі додатки навколо парадигми Sealevel. Архітектури програм, розроблені навколо попереднього оголошення облікових записів, шаблонів PDA та фреймворку розробки Anchor, не портуються на EVM-ланцюжки без значної реархітектури. Зростаюча бібліотека інструментів Rust, ресурсів Anchor, послуг аудиту та еталонних реалізацій додає подальшої інерції.

Аргумент проти постійної довговічності є таким самим реальним. Aptos і Monad демонструють, що архітектури паралельного виконання можуть бути побудовані на різних технічних основах. Екосистема L2 Ethereum (Arbitrum, Optimism, Base) досягає високої пропускної здатності через офчейн виконання з ончейн розрахунком, інший шлях до масштабованості, який повністю обходить обмеження Sealevel. Для багатьох випадків використання Децентралізованих Фінансів (Decentralized Finance) (DeFi) (включаючи автоматизовані маркет-мейкери, або AMM, та децентралізовані біржі, або DEX, такі як Orca та Raydium), пропускної здатності L2-ролапів достатньо без необхідності зміни парадигми Sealevel.

Там, де перевага Sealevel є структурно найбільш захищеною, це у випадках використання, які вимагають високочастотних, одночасних оновлень стану ончейн: книги ордерів ончейн, двигуни ліквідації та великі події карбування NFT, де тисячі незалежних транзакцій повинні бути врегульовані одночасно. Ці випадки використання залишаються архітектурно складними на EVM-ланцюжках навіть із рішеннями L2, оскільки розрахунок L2 все ще вимагає координації з L1-рівнем для фінальності.

Sealevel представляє справжній та задокументований архітектурний диференціатор на базовому рівні. Його конкурентний рів є реальним, але не постійним. Він відчуває тиск з боку нових паралельних ланцюжків та розширюваної екосистеми L2 Ethereum. Довговічність позиції Solana залежить так само від мережевих ефектів (прийняття розробниками, DeFi загальна заблокована вартість, інституційна інфраструктура), як і від сирої технічної архітектури середовища виконання.

Для контексту щодо конкурентного позиціонування Layer-1 у блокчейн-мережах та того, як архітектурні компроміси розгортаються в різних дизайнах L1, паралелі з вибором дизайну Sealevel є повчальними.

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

Пов'язані ресурси про архітектуру Solana

Sealevel залежить від моделі акаунтів Solana і є однією з частин ширшої швидкісної архітектури Solana. Читачі ринку можуть звернутися до сторінки ціни SOL.). Безстроковий контракт SOLUSDT) є похідним інструментом з кредитним плечем і несе ризик ліквідації; він не є показником технічної продуктивності Sealevel.

FAQ: Паралельна обробка Solana Sealevel

Ці поширені запитання розглядають найбільш типові моменти плутанини щодо моделі паралельного виконання Sealevel, показників пропускної здатності та зв'язку з іншими архітектурами блокчейнів.

Що таке Sealevel у Solana?

Sealevel — це середовище виконання паралельних смартконтрактів Solana: механізм виконання, який обробляє тисячі незалежних транзакцій одночасно, а не одну за одною. Визначаючи, які транзакції не мають спільних залежностей даних через модель акаунтів Solana, Sealevel розподіляє їх на окремі ядра процесора одночасно, забезпечуючи пропускну здатність, яку не може забезпечити послідовне виконання.

Як Sealevel забезпечує паралельну обробку транзакцій?

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

Чим Solana Sealevel відрізняється від Ethereum EVM?

Віртуальна машина Ethereum (EVM) обробляє транзакції послідовно, по одній за раз, тому що архітектура контрактів Ethereum із відстеженням стану робить архітектурно складним попереднє визначення того, які транзакції безпечно паралелізувати. Sealevel обробляє транзакції без конфліктів одночасно, оскільки модель акаунтів Solana вимагає від транзакцій декларувати свої залежності стану заздалегідь, надаючи Sealevel інформацію, необхідну для безпечної паралелізації перед початком виконання.

Скільки транзакцій на секунду може обробляти Solana за допомогою Sealevel?

Згідно з документацією Solana Labs, у ідеальних умовах Solana теоретично може обробляти до ~65 000 TPS. На практиці реальна пропускна здатність в основній мережі для транзакцій без голосування зазвичай становить 2 000–4 000 TPS, залежно від складності транзакцій, конкуренції за акаунти та мережевих умов. Це все одно залишається значно вищим за пропускну здатність базового рівня Ethereum, яка становить приблизно 15–30 TPS.

Яку мову програмування використовують для створення на Sealevel?

Програми Solana переважно пишуться мовою програмування Rust, хоча також підтримуються C та C++. Всі програми компілюються в модифікований формат байт-коду eBPF (extended Berkeley Packet Filter) Solana перед розгортанням ончейн. Фреймворк Anchor є широко використовуваним інструментом розробки на базі Rust, який абстрагує управління акаунтами та зменшує кількість шаблонного коду для розробки програм Solana.

Чому в Solana траплялися збої в мережі, якщо Sealevel така швидка?

Збої в мережі Solana у 2021 та 2022 роках не були спричинені помилками в логіці паралельного виконання Sealevel. Вони стали результатом напливу спаму та некоректних транзакцій, що перевантажили рівень прийому транзакцій мережі — окрему систему перед Sealevel. Показник TPS Sealevel описує, скільки валідних транзакцій вона може обробити; він не робить мережу імунною до атак із переповненням транзакціями на рівні прийому.

Який зв'язок між Proof of History та Sealevel?

Proof of History (PoH) уможливлює роботу Sealevel, встановлюючи довірений порядок транзакцій до початку виконання. PoH — це механізм криптографічного годинника, який створює послідовність часових міток, що піддаються перевірці та з якими погоджується кожен валідатор. Оскільки порядок транзакцій визначається до того, як Sealevel отримує транзакції, Sealevel не потрібно робити паузи та координуватися з валідаторами. Вона може негайно розподіляти транзакції без конфліктів між паралельними потоками обробки.

Висновок: Що Sealevel означає для майбутнього Solana

Sealevel — це найчіткіша відповідь Solana на питання, з яким стикається кожен блокчейн: як обробляти більше транзакцій без шкоди для безпеки чи децентралізації?

Паралельне виконання Sealevel — це архітектурно реальна та задокументована можливість, яка відрізняє модель виконання Solana від кожного блокчейну з послідовним виконанням на Layer-1. Її реальна пропускна здатність є значущою, значно вищою за базовий рівень Ethereum, але залишається нижчою за теоретичні максимуми та піддається обмеженням рівня прийому, які спричиняли збої в мережі. Її тривалість як конкурентної переваги залежить від розвитку екосистеми та темпів впровадження конкуруючих архітектур паралельного виконання так само, як і від власного дизайну середовища виконання.

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

Рекомендована література

• Виконання смартконтрактів Ethereum: 5-етапна торгова стратегія
• Як працюють моделі акаунтів у різних архітектурах блокчейнів
• Порівняння архітектур блокчейнів Layer-1: Near Protocol проти FetchAI

Джерела

1. Анатолій Яковенко, «Solana: A new architecture for a high performance blockchain v0.8.13», 2017. https://solana.com/solana-whitepaper.pdf
2. Документація для розробників Solana: Модель програмування та модель акаунтів. https://docs.solana.com/developing/programming-model/accounts
3. Документація програм Solana ончейн. https://docs.solana.com/developing/on-chain-programs/overview
4. Ethereum Foundation: Документація Віртуальної машини Ethereum (EVM). https://ethereum.org/en/developers/docs/evm/
5. Звіти про збої в мережі та продуктивність Solana. https://solana.com/news/
6. Документація паралельного виконання Aptos Block-STM. https://aptoslabs.com/developer