Аналіз технологічної архітектури та екологічного розвитку Solana
Solana є високопродуктивною блокчейн-платформою, яка використовує унікальну технічну архітектуру для досягнення високої пропускної здатності та низької затримки. Її основні технології включають алгоритм Proof of History (POH), що забезпечує порядок транзакцій та глобальний годинник, графік ротації лідерів та механізм консенсусу Tower BFT, які підвищують швидкість створення блоків. Механізм Turbine оптимізує поширення великих блоків за допомогою кодування Ріда-Соломона. Віртуальна машина Solana (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.
Незважаючи на те, що Solana досягла певних успіхів у технологічному та ринковому прийнятті, їй потрібно постійно інновувати та вдосконалюватися, щоб справлятися з викликами з боку конкурентів, таких як Base. Особливо у підвищенні стабільності мережі, зниженні рівня невдалих транзакцій, вирішенні проблеми MEV та уповільненні зростання стану, Solana потрібно постійно оптимізувати свою технічну архітектуру та мережеві протоколи, щоб зберегти свою провідну позицію в індустрії блокчейнів.
Технічна архітектура
Solana відома своєю алгоритмом POH, консенсусом Tower BFT, а також високим TPS і швидкою фіналізацією, які забезпечуються мережею передачі даних Trubine та віртуальною машиною SVM. Як працюють різні компоненти, як вони реалізують свою мету високої продуктивності для архітектурного дизайну, а також недоліки та пов'язані з ними проблеми, що виникають в рамках цього архітектурного дизайну.
алгоритм 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. Під час голосування за блок, якщо голосування валідаторів само по собі є торговою транзакцією, тоді хеш блоку, що формується транзакціями користувача та транзакціями валідаторів, також може слугувати історичним доказом, деталі транзакцій користувача та деталі голосування валідатора можуть бути унікально підтверджені.
![Знову розглядаємо технічну архітектуру Solana: чи чекає її другий весняний період?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.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 разів.
![Ще раз про архітектуру технологій Solana: чи чекає нас друге весняне пробудження?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Turbine, поділивши дані на частини, використовує багаторівневий механізм поширення. Лідер-нод передає блок будь-якому валідатору блоків до закінчення кожного слота, а потім цей валідатор розділяє блок на Shreds і генерує код виправлення. Після цього валідатор запускає поширення Turbine. Спочатку дані повинні бути передані до кореневої ноди, а потім ця коренева нода визначає, які валідатори знаходяться на якому рівні. Процес виглядає наступним чином:
Створення списку вузлів: кореневий вузол збирає всіх активних валідаторів у один список, а потім сортує їх відповідно до частки кожного валідатора в мережі ), а саме кількості зворотного SOL (, вага яких є вищою, розташована на першому рівні, і так далі.
Групування вузлів: потім кожен валідатор, що знаходиться на першому рівні, також створить власний список вузлів, щоб побудувати свій перший рівень.
Формування шарів: від верхньої частини списку вузли поділяються на шари, визначивши два значення - глибину і ширину, можна визначити приблизну форму всього дерева, цей параметр вплине на швидкість поширення 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-46a028270f3c2da92e7056c17c1d9e16.webp(
У SVM інструкція складається з 4-х частин, які містять ID програми, інструкцію програми та список облікових записів для читання/запису даних. Визначивши, чи поточний обліковий запис знаходиться у стані читання або запису, а також чи є конфлікти у операціях, що змінюють стан, можна дозволити паралелізацію інструкцій транзакцій облікового запису, де немає конфліктів. Кожна інструкція представлена за допомогою ID програми. І це одна з причин, чому вимоги до валідаторів Solana є такими високими, оскільки потрібно, щоб GPU/CPU валідаторів підтримували SIMD) одноінструкційні множинні дані( і можливості AVX розширеного векторного оброблення.
Екологічний розвиток
У процесі розвитку екосистеми Solana все більше акцентується на практичній корисності, наприклад, Blink, Actions та навіть Solana Mobile, тоді як офіційно підтримувані напрямки розвитку застосунків більше спрямовані на споживчі програми, а не на безкінечну внутрішню конкуренцію в інфраструктурі. У ситуації, коли продуктивність Solana достатня, видів застосунків стає більше. Що стосується Ethereum, то через низький TPS екосистема Ethereum все ще залишається зосередженою на інфраструктурі та технологіях масштабування; коли інфраструктура не може витримати застосунки, неможливо створити споживчі програми, що призводить до нерівноваги, коли інвестиції в інфраструктуру є надмірними, а інвестиції в застосунки — недостатніми.
) DeFi
У DeFi-протоколах на Solana є багато проектів, що не випустили токени, серед яких Kamino### перший Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora тощо. Завдяки єдності екосистеми Solana, зазвичай один проект на час випуску токенів намагається уникати інших проектів, щоб залучити достатню увагу ринку.
Зараз на всьому DEX спостерігається жорстка конкуренція, і його лідер також зазнав кількох переміщень, від Raydium, Orca до теперішнього домінування певного DEX.
Варто зазначити, що близько 50% торгівлі на DEX здійснюється за допомогою MEV bot.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
19 лайків
Нагородити
19
6
Поділіться
Прокоментувати
0/400
staking_gramps
· 07-16 11:08
перформанс sol дійсно класний
Переглянути оригіналвідповісти на0
0xSunnyDay
· 07-15 15:18
Чи дійсно цей король простоїв ще й хвалиться продуктивністю?
Переглянути оригіналвідповісти на0
CoconutWaterBoy
· 07-14 03:35
Знову дмуть у sol?
Переглянути оригіналвідповісти на0
SandwichTrader
· 07-14 03:21
Замість того, щоб блокувати, краще знайти шлях, подумай про це, це призведе до збоїв.
Аналіз технологічної архітектури Solana та поточний стан екосистеми
Аналіз технологічної архітектури та екологічного розвитку Solana
Solana є високопродуктивною блокчейн-платформою, яка використовує унікальну технічну архітектуру для досягнення високої пропускної здатності та низької затримки. Її основні технології включають алгоритм Proof of History (POH), що забезпечує порядок транзакцій та глобальний годинник, графік ротації лідерів та механізм консенсусу Tower BFT, які підвищують швидкість створення блоків. Механізм Turbine оптимізує поширення великих блоків за допомогою кодування Ріда-Соломона. Віртуальна машина Solana (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.
Незважаючи на те, що Solana досягла певних успіхів у технологічному та ринковому прийнятті, їй потрібно постійно інновувати та вдосконалюватися, щоб справлятися з викликами з боку конкурентів, таких як Base. Особливо у підвищенні стабільності мережі, зниженні рівня невдалих транзакцій, вирішенні проблеми MEV та уповільненні зростання стану, Solana потрібно постійно оптимізувати свою технічну архітектуру та мережеві протоколи, щоб зберегти свою провідну позицію в індустрії блокчейнів.
Технічна архітектура
Solana відома своєю алгоритмом POH, консенсусом Tower BFT, а також високим TPS і швидкою фіналізацією, які забезпечуються мережею передачі даних Trubine та віртуальною машиною SVM. Як працюють різні компоненти, як вони реалізують свою мету високої продуктивності для архітектурного дизайну, а також недоліки та пов'язані з ними проблеми, що виникають в рамках цього архітектурного дизайну.
алгоритм 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. Під час голосування за блок, якщо голосування валідаторів само по собі є торговою транзакцією, тоді хеш блоку, що формується транзакціями користувача та транзакціями валідаторів, також може слугувати історичним доказом, деталі транзакцій користувача та деталі голосування валідатора можуть бути унікально підтверджені.
![Знову розглядаємо технічну архітектуру Solana: чи чекає її другий весняний період?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.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 разів.
![Ще раз про архітектуру технологій Solana: чи чекає нас друге весняне пробудження?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
Turbine, поділивши дані на частини, використовує багаторівневий механізм поширення. Лідер-нод передає блок будь-якому валідатору блоків до закінчення кожного слота, а потім цей валідатор розділяє блок на Shreds і генерує код виправлення. Після цього валідатор запускає поширення Turbine. Спочатку дані повинні бути передані до кореневої ноди, а потім ця коренева нода визначає, які валідатори знаходяться на якому рівні. Процес виглядає наступним чином:
Створення списку вузлів: кореневий вузол збирає всіх активних валідаторів у один список, а потім сортує їх відповідно до частки кожного валідатора в мережі ), а саме кількості зворотного SOL (, вага яких є вищою, розташована на першому рівні, і так далі.
Групування вузлів: потім кожен валідатор, що знаходиться на першому рівні, також створить власний список вузлів, щоб побудувати свій перший рівень.
Формування шарів: від верхньої частини списку вузли поділяються на шари, визначивши два значення - глибину і ширину, можна визначити приблизну форму всього дерева, цей параметр вплине на швидкість поширення 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-46a028270f3c2da92e7056c17c1d9e16.webp(
У SVM інструкція складається з 4-х частин, які містять ID програми, інструкцію програми та список облікових записів для читання/запису даних. Визначивши, чи поточний обліковий запис знаходиться у стані читання або запису, а також чи є конфлікти у операціях, що змінюють стан, можна дозволити паралелізацію інструкцій транзакцій облікового запису, де немає конфліктів. Кожна інструкція представлена за допомогою ID програми. І це одна з причин, чому вимоги до валідаторів Solana є такими високими, оскільки потрібно, щоб GPU/CPU валідаторів підтримували SIMD) одноінструкційні множинні дані( і можливості AVX розширеного векторного оброблення.
Екологічний розвиток
У процесі розвитку екосистеми Solana все більше акцентується на практичній корисності, наприклад, Blink, Actions та навіть Solana Mobile, тоді як офіційно підтримувані напрямки розвитку застосунків більше спрямовані на споживчі програми, а не на безкінечну внутрішню конкуренцію в інфраструктурі. У ситуації, коли продуктивність Solana достатня, видів застосунків стає більше. Що стосується Ethereum, то через низький TPS екосистема Ethereum все ще залишається зосередженою на інфраструктурі та технологіях масштабування; коли інфраструктура не може витримати застосунки, неможливо створити споживчі програми, що призводить до нерівноваги, коли інвестиції в інфраструктуру є надмірними, а інвестиції в застосунки — недостатніми.
) DeFi
У DeFi-протоколах на Solana є багато проектів, що не випустили токени, серед яких Kamino### перший Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora тощо. Завдяки єдності екосистеми Solana, зазвичай один проект на час випуску токенів намагається уникати інших проектів, щоб залучити достатню увагу ринку.
Зараз на всьому DEX спостерігається жорстка конкуренція, і його лідер також зазнав кількох переміщень, від Raydium, Orca до теперішнього домінування певного DEX.
Варто зазначити, що близько 50% торгівлі на DEX здійснюється за допомогою MEV bot.