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

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

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

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

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

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

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

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

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

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

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

) Турбіна

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

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

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

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

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

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

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

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

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

Ідея цієї системи подібна до механізму одноядерного вузла Leader. У процесі поширення блоків також існують деякі пріоритетні вузли, які першими отримують шрідси для формування повного блоку з метою досягнення консенсусу голосування. Виведення надмірності на більш глибокий рівень може значно прискорити процес фіналізації, а також максимізувати пропускну здатність і ефективність. Оскільки насправді перші кілька рівнів можуть представляти 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-e9bc35d0c790496c59c20979e5af1491.webp(

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

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