Ще раз про технологічну архітектуру 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 здобула значну частку ринку в індустрії блокчейну завдяки своїй високій пропускній здатності та низьким комісійним витратам, вона також стикається з жорсткою конкуренцією з боку інших нових публічних ланцюгів. Base, як потенційний суперник в екосистемі EVM, швидко зростає кількість активних адрес на його ланцюзі, в той час як загальний обсяг заблокованих активів Solana в секторі DeFi досяг історичного максимуму (TVL), але конкуренти, такі як Base, також швидко займають частку ринку, а обсяг фінансування екосистеми Base вперше перевищив Solana в Q2.

Хоча Solana досягла певних успіхів у технічному та ринковому прийнятті, їй необхідно постійно інновувати та вдосконалюватися, щоб справлятися з викликами з боку конкурентів, таких як Base. Особливо в питаннях підвищення стабільності мережі, зниження рівня невдалих транзакцій, вирішення проблеми 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 hash, то транзакції в цьому блоці будуть підтверджені, будь-яка зміна призведе до зміни hash-значення. Після цього hash блоку буде використовуватися як частина X для наступної функції sha256, і буде додано hash наступного блоку, таким чином, попередній і наступний блоки будуть підтверджені, будь-яка зміна призведе до нового Y.

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

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

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

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

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

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

![Ще раз про технічну архітектуру Solana: чи чекає нас друге весняне пробудження?]###https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.webp(

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

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

) Турбіна

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

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

![Знову розглядаємо технічну архітектуру Solana: Чи зустрінемо друге весняне пробудження?])https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(

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

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

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

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

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

![Знову розгляд архітектури технології Solana: чи чекає її другий весняний період?])https://img-cdn.gateio.im/webp-social/moments-9fd8693259e2864d6978d2b4e8ef2e85.webp(

Вузли з високою часткою прав на участь, при поділі на рівні, будуть на більш високому рівні, отже, зможуть заздалегідь отримати повні 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: чи чекає нас друге весняне відродження?])https://img-cdn.gateio.im/webp-social/moments-636ac72327705b9f93e62e394355436f.webp(

Екосистема