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

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

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

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

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

) Турбина

Лідер вузла розділяє блоки на підблоки, звані shreds, через процес, відомий як Sharding, розмір яких визначається максимальною передавальною одиницею 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.

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

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

) SVM

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

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

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

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

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