Аналіз технічної архітектури та екосистемного розвитку 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 прагне інтегрувати технології блокчейн у повсякденні застосунки, тим самим підвищуючи прийнятність та зручність для користувачів.

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

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

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

алгоритм POH

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

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

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

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

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

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

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

![Ще раз про технічну архітектуру Solana: чи чекати на друге весняння?]###panews/images/90Jj8P8FH5.webp(

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

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

) Турбіна

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

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

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

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

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

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

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

![Знову розглядаємо технічну архітектуру Solana: чи чекає нас друге весняне пробудження?])panews/images/iQ41c4b6DM.webp(

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

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

) SVM

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

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

![Ще раз про технічну архітектуру Solana: чи чекає нас друге весняне пробудження?])panews/images/Czi5MR4h94.webp(

Екологічний розвиток

У процесі розвитку екосистеми Solana все більше уваги приділяється реальній утиліті, такій як Blinks, Actions та навіть Solana Mobile. Офіційна підтримка також більше орієнтується на споживчі застосунки, а не на безмежну конкуренцію в інфраструктурі. У сучасних умовах, коли продуктивність Solana достатня, різноманітність застосунків зростає. Що стосується Ethereum, то через низький TPS екосистема Ethereum все ще зосереджена на інфраструктурі та технологіях розширення. Якщо інфраструктура не може витримати навантаження від застосунків, неможливо створити споживчі застосунки. Це призводить до дисбалансу, коли інвестиції в інфраструктуру надмірні, а в інвестиції в застосунки - занадто малі.

) DeFi

У протоколах DeFi на Solana є велика кількість проектів, які ще не випустили токени, включаючи Kamino### перший Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora тощо. Завдяки згуртованій екосистемі Solana, зазвичай, коли один проект випускає токени, інші проекти намагаються уникати цього періоду, щоб залучити достатню увагу ринку.

В даний час у всьому секторі DEX спостерігається жорстка конкуренція, а лідер також пережив кілька перенесень, від Raydium, Orca до теперішнього часу, коли домінує Jupiter.

Варто зазначити, що близько 50% угод на DEX ініційовані MEV-ботами, головним чином через їх низькі витрати та активність торгівлі мемами, що сприяє прибутковості MEV. Це також є однією з основних причин частих невдач у пікових угодах користувачів та збоїв.

Протоколи DeFi на Solana, разом із зростанням ціни SOL, також зазнали вибухоподібного зростання свого номінального TVL у доларах США. Тенденція зростання їхнього TVL досі не зупинилася, формується нова хвиля зростання.

![Знову розглядаємо технічну архітектуру Solana: чи чекає нас друга весна?])