Ще раз про технологічну архітектуру Solana: Чи чекає нас друге весняне пробудження?

Solana є високопродуктивною блокчейн-платформою, яка використовує унікальну технологічну архітектуру для досягнення високої пропускної здатності та низької затримки. Її основні технології включають алгоритм Proof of History (POH), який забезпечує порядок транзакцій та глобальний годинник, графік ротації лідерів та механізм консенсусу Tower BFT, що підвищує швидкість створення блоків. Механізм Turbine оптимізує поширення великих блоків через кодування Ріда-Соломона. Solana Virtual Machine (SVM) та паралельний виконавчий двигун Sealevel прискорюють швидкість виконання транзакцій. Усе це є архітектурним дизайном Solana для досягнення високої продуктивності, але також призводить до деяких проблем, таких як збої в мережі, невдалі транзакції, проблеми MEV, занадто швидке зростання стану та централізація, про які ми також детально висвітлюємо в цій статті.

Екосистема Solana розвивається швидкими темпами, всі показники в першій половині року зросли, особливо в сферах DeFi, інфраструктури, GameFi/NFT, DePin/AI та споживчих додатків. Високий TPS Solana та стратегія, орієнтована на споживчі додатки, а також слабкий брендовий ефект екосистеми надають підприємцям і розробникам безліч можливостей для стартапів. У сфері споживчих додатків Solana демонструє своє бачення щодо просування технологій блокчейн у більш широких сферах. Підтримуючи такі ініціативи, як Solana Mobile та створюючи SDK спеціально для споживчих додатків, Solana прагне інтегрувати технології блокчейн у повсякденні додатки, підвищуючи прийнятність і зручність для користувачів. Наприклад, такі програми, як Stepn, поєднують технології блокчейн і мобільні технології, пропонуючи користувачам нові можливості для фітнесу та соціальної взаємодії. Хоча багато споживчих додатків наразі все ще шукають найкращі бізнес-моделі та ринкову позицію, технологічна платформа та екосистема, які пропонує Solana, безсумнівно, забезпечують надійну підтримку для цих інноваційних спроб. З подальшим розвитком технологій і зрілістю ринку Solana має всі шанси досягти нових проривів і успішних кейсів у сфері споживчих додатків.

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

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

Технічна архітектура

Solana відома своїм алгоритмом POH, механізмом консенсусу Tower BFT, а також мережею передачі даних Trubine та віртуальною машиною SVM, які забезпечують високу TPS і швидку фіналізацію. Ми коротко ознайомимося з тим, як працюють її компоненти, як вони реалізують свою мету високої продуктивності в архітектурному дизайні, а також з недоліками та виникаючими проблемами, які виникають внаслідок цього архітектурного дизайну.

алгоритм POH

POH (Proof of History) є технологією, що визначає глобальний час, яка не є механізмом консенсусу, а є алгоритмом, що визначає порядок транзакцій. Технологія POH походить від базової криптографії SHA256. SHA256 зазвичай використовується для обчислення цілісності даних, при заданому вході X завжди буде лише один унікальний вихід Y, тому будь-яка зміна X призведе до абсолютно іншого Y.

У послідовності POH у Solana, застосування алгоритму sha256 може забезпечити цілісність усієї послідовності, а отже, визначити цілісність транзакцій. Наприклад, якщо ми упакуємо транзакції в блок, згенеруємо відповідне значення хешу sha256, то транзакції в цьому блоці будуть підтверджені, будь-які зміни призведуть до зміни значення хешу, після цього хеш цього блоку буде використовуватися як частина X для наступної функції sha256, і ми додамо хеш наступного блоку, таким чином, попередній блок та наступний блок будуть підтверджені, будь-які зміни призведуть до нового Y.

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

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

Щоб уникнути виникнення єдиної точки відмови на вузлі Leader, було введено часові обмеження. У Solana одиниця часу ділиться на епохи, кожна епоха містить 432 000 слотів, кожен слот триває 400 мс. У кожному слоті система ротації призначає вузол Leader, який повинен опублікувати блок протягом заданого часу слота (400 мс), інакше цей слот буде пропущено, і буде повторно обрано вузол Leader для наступного слота.

В цілому, вузли-лідери, що використовують механізм POH, можуть підтвердити всі історичні транзакції. Основною одиницею часу в Solana є слот, і вузол-лідер повинен транслювати блок протягом одного слоту. Користувачі передають транзакції вузлу RPC, вузол-лідер упаковує транзакції, сортує їх, а потім виконує їх, генеруючи блок, який розсилається іншим валідаторам. Валідатори повинні досягти консенсусу через певний механізм, щоб погодитися з транзакціями в блоці та їх порядком; для цього використовується механізм консенсусу Tower BFT.

Механізм консенсусу Tower BFT

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

У алгоритмі Tower BFT визначено, що якщо всі валідатори голосують за цей блок, і більше 2/3 валідаторів проголосували за затвердження, то цей блок може бути підтверджений. Перевагою цього механізму є те, що він економить велику кількість пам'яті, оскільки для підтвердження блоку потрібно лише голосувати за хеш-послідовність. Але в традиційних механізмах консенсусу зазвичай використовують метод розподілу блоків: один валідатор отримує блок, а потім надсилає його сусіднім валідаторам, що призводить до значного надмірності в мережі, оскільки один валідатор отримує той самий блок неодноразово.

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

Турбіна

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

Розділяючи блоки на чотири Data Shreds, а потім, щоб запобігти втраті пакетів і пошкодженням під час передачі даних, використовують кодування Ріда-Соломона, щоб закодувати чотири пакети в eight пакунків. Ця схема може витримати до 50% втрати пакетів. У реальних тестах, втрата пакетів у Solana становила приблизно 15%, тому ця схема добре сумісна з поточною архітектурою Solana.

У передачі даних на нижньому рівні зазвичай розглядається використання протоколів UDP/TCP. Оскільки Solana має високу терпимість до втрати пакетів, для передачі використовується протокол UDP. Його недолік полягає в тому, що при втраті пакетів повторна передача не відбувається, але перевага полягає в швидшій швидкості передачі. Навпаки, протокол TCP повторно передає пакети при їх втраті кілька разів, що значно знижує швидкість передачі та пропускну здатність. Завдяки Reed-Solomon ця система може суттєво збільшити пропускну здатність Solana. У реальних умовах пропускна здатність може зрости в 9 разів.

Turbine після розподілу даних використовує багаторівневий механізм розповсюдження. Лідер-вузол передає блок будь-якому з валідаційних вузлів перед закінченням кожного слота, після чого цей валідаційний вузол розділяє блок на Shreds і генерує код відновлення. Потім цей валідаційний вузол запускає розповсюдження Turbine. Спочатку потрібно поширити на кореневий вузол, після чого цей кореневий вузол визначить, які валідаційні вузли знаходяться на якому рівні. Процес виглядає наступним чином:

1. Створення списку вузлів: кореневий вузол збирає всіх активних валідаторів у список, а потім сортує їх за часткою кожного валідатора в мережі (тобто кількістю залікованих SOL), де валідатори з вищою вагою розташовуються на першому рівні, і так далі.

2. Групування вузлів: потім кожен валідатор, який знаходиться на першому рівні, також створить власний список вузлів, щоб побудувати свій перший рівень.

3. Формування шарів: від верхньої частини списку вузли діляться на шари, шляхом визначення двох значень - глибини і ширини, можна визначити загальну форму дерева, цей параметр вплине на швидкість поширення shreds.

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

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

SVM

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

У SVM команди складаються з 4 частин: ідентифікатор програми, програма команд та список облікових записів для читання/запису даних. Визначивши, чи знаходиться поточний рахунок у стані читання чи запису, а також чи є конфлікти в операціях, необхідних для зміни стану, можна дозволити паралелізацію команд рахунку, які не конфліктують зі станом, причому кожна команда представляється за допомогою ідентифікатора програми. І це одна з причин, чому вимоги до валідаторів Solana дуже високі, оскільки від валідаторів вимагається, щоб їх GPU/CPU підтримували SIMD (одна команда - багато даних) і AVX.