Переосмислення технічної архітектури Solana: чи чекає нас друге весняне пробудження?
Solana є високопродуктивною платформою блокчейн, яка використовує унікальну технічну архітектуру для забезпечення високої пропускної спроможності та низької затримки. Її основні технології включають алгоритм Proof of History (POH), який забезпечує порядок транзакцій та глобальний годинник, графік ротації лідерів та механізм консенсусу Tower BFT для підвищення швидкості створення блоків. Механізм Turbine оптимізує поширення великих блоків за допомогою кодування Reed-solomon. Solana Virtual Machine (SVM) та паралельний виконавчий двигун Sealevel прискорюють швидкість виконання транзакцій. Усе це є архітектурним дизайном Solana для досягнення високої продуктивності, але одночасно також призвело до деяких проблем, таких як збої мережі, невдачі транзакцій, проблеми MEV, надмірне зростання стану та проблеми централізації, про які ми також детально розглядаємо в цій статті.
Екосистема Solana швидко розвивається, різні показники в першій половині року демонструють стрімке зростання, особливо в сферах DeFi, інфраструктури, GameFi/NFT, DePin/AI та споживчих додатків. Високий TPS Solana та стратегія, орієнтована на споживчі додатки, разом із слабким брендовим ефектом екосистеми створюють багатий вибір можливостей для підприємців і розробників. У сфері споживчих додатків Solana демонструє своє бачення щодо просування технології блокчейн у більш широких сферах. Підтримуючи такі проекти, як Solana Mobile та SDK, створений спеціально для споживчих додатків, Solana прагне інтегрувати технологію блокчейн у повсякденні застосування, тим самим підвищуючи прийнятність і зручність для користувачів. Наприклад, один з фітнес-додатків поєднує блокчейн і мобільні технології, щоб запропонувати користувачам новий досвід тренувань і соціальної взаємодії. Хоча багато споживчих додатків наразі ще експериментують із найкращими бізнес-моделями та ринковими позиціями, технологічна платформа та екосистема, які пропонує Solana, безсумнівно, забезпечують потужну підтримку для цих інноваційних спроб. З подальшим розвитком технологій та зрілістю ринку, Solana має перспективи досягти ще більших проривів та успішних випадків у сфері споживчих додатків.
Хоча Solana здобула значну частку ринку в індустрії блокчейнів завдяки своїй високій пропускній здатності та низьким витратам на транзакції, вона також стикається з жорсткою конкуренцією з боку інших нових публічних блокчейнів. Base, як потенційний суперник в екосистемі EVM, швидко нарощує кількість активних адрес на своїй ланцюзі. Тим часом загальний заблокований обсяг (TVL) в DeFi-сфері Solana, що становить (, хоча і встановив історичний максимум, але конкуренти, такі як Base, також швидко завойовують частки ринку. Обсяги фінансування екосистеми Base вперше перевищили Solana в другому кварталі.
Незважаючи на те, що Solana досягла певних успіхів у технологіях та прийнятті на ринку, їй потрібно постійно інноваційно розвиватися та вдосконалюватися, щоб протистояти викликам від конкурентів, таких як Base. Особливо в питаннях підвищення стабільності мережі, зниження рівня невдач транзакцій, вирішення проблеми MEV та уповільнення зростання стану, Solana потрібно продовжувати оптимізувати свою технологічну архітектуру та мережеві протоколи, щоб зберегти свою лідируючу позицію в індустрії блокчейн.
Технічна архітектура
Solana відома своїм алгоритмом POH, механізмом консенсусу Tower BFT, а також мережею передачі даних Trubine і віртуальною машиною SVM, які забезпечують високу TPS і швидку фіналізацію. Ми коротко представимо, як працюють усі ці компоненти, як вони сприяють досягненню високої продуктивності для архітектурного дизайну, а також недоліки та виникаючі проблеми, пов'язані з цим архітектурним дизайном.
![Ще раз про технічну архітектуру Solana: чи чекає нас друге весняне пробудження?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
) алгоритм 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: чи чекає нас друга весна?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
У схемі потоку транзакцій 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 валідаторів проголосують за approve, тоді цей блок може бути підтверджений. Перевагою цього механізму є те, що він економить велику кількість пам'яті, оскільки для підтвердження блоку потрібно лише голосувати за хеш-послідовність. Однак у традиційних механізмах консенсусу зазвичай використовується затоплення блоків, коли валідатор отримує блок і відправляє його сусіднім валідаторам, що призводить до великої надмірності в мережі, оскільки один валідатор отримує один і той же блок більше одного разу.
У Solana, через велику кількість голосувань валідаторів і високу ефективність, яка виникає внаслідок централізації вузлів-лідерів та часу слотів у 400 мс, загальний розмір блоку та частота створення блоків є особливо високими. Великі блоки під час розповсюдження також створюють значний тиск на мережу. Solana використовує механізм Turbine для вирішення проблеми розповсюдження великих блоків.
) Турбина
Лідер-нод через процес, відомий як Sharding, розділяє блоки на субблоки типу shred, розмір яких відповідає максимальному розміру передачі MTU###, максимально можливій кількості даних, що може бути передана з одного вузла на наступний без необхідності їх розподілу на менші одиниці, становить ###. Потім для забезпечення цілісності та доступності даних використовується схема кодування з виправленням помилок Ріда-Соломона.
Розділивши блоки на чотири Data Shreds, потім для запобігання втратам і пошкодженням даних під час передачі, використовується кодування Ріда-Соломона, щоб закодувати чотири пакети в вісім пакетів. Ця схема може витримувати до 50% втрат пакетів. У реальних тестах, втрати пакетів у Solana становлять приблизно 15%, тому ця схема добре сумісна з поточною архітектурою Solana.
У передачі даних на нижньому рівні зазвичай розглядається використання протоколів UDP/TCP. Оскільки Solana має високу толерантність до втрат пакетів, тому використовується протокол UDP для передачі, його недолік полягає в тому, що при втраті пакета він не буде повторно передаватися, але перевагою є більш висока швидкість передачі. Навпаки, протокол TCP повторно передаватиме пакети кілька разів при їх втраті, що значно знижує швидкість передачі та пропускну здатність. Завдяки Reed-solomon ця система може значно підвищити пропускну здатність Solana, у реальних умовах пропускна здатність може зрости в 9 разів.
Після розбиття даних за допомогою Turbine, використовується багаторазовий механізм поширення. Вузол-лідер передає блок будь-якому з блокчейн-верифікаторів перед завершенням кожного слоту, після чого цей верифікатор розбиває блок на Shreds і генерує код виправлення. Потім цей верифікатор розпочне поширення Turbine. Спочатку потрібно поширити до кореневого вузла, після чого цей кореневий вузол визначить, які верифікатори знаходяться на якому рівні. Процес виглядає наступним чином:
Створення списку вузлів: кореневий вузол збирає всіх активних валідаторів в один список, а потім сортує їх відповідно до частки кожного валідатора в мережі (, тобто кількості заморожених SOL ), причому вузли з вищою вагою знаходяться на першому рівні, і так далі.
Групування вузлів: Потім кожен валідатор, який знаходиться на першому рівні, також створить власний список вузлів для побудови власного першого рівня.
Формування шарів: з верхньої частини списку вузли поділяються на шари, шляхом визначення двох значень: глибини та ширини, можна визначити загальну форму всього дерева, цей параметр вплине на швидкість розповсюдження shreds.
Вузли з високою часткою прав власності, під час поділу на рівні, знаходяться на більш високому рівні, тому можуть заздалегідь отримувати повні шреди. У цей момент вони можуть відновити повний блок, тоді як вузли з нижчих рівнів, через втрати під час передачі, мають знижену ймовірність отримання повних шредів. Якщо цих шредів недостатньо для побудови повних фрагментів, лідер вимагатиме повторної передачі. Тоді передача даних відбуватиметься всередині дерева, а вузли першого рівня вже давно підтвердили повний блок. Час, який потрібен для голосування після завершення побудови блоку перевірювачами на нижчих рівнях, буде зростати.
Ця система має концепцію, схожу на механізм одиничного вузла лідера. У процесі розповсюдження блоків також існують деякі пріоритетні вузли, які першими отримують шматки shreds для формування повного блоку з метою досягнення консенсусу голосування. Перенесення надмірності на глибший рівень може значно прискорити процес фіналізації та максимізувати пропускну здатність і ефективність. Оскільки насправді перші кілька рівнів можуть представляти 2/3 вузлів, то голосування наступних вузлів стає неважливим.
( SVM
Solana може обробляти тисячі транзакцій на секунду, головною причиною чого є її механізм POH, консенсус Tower BFT та механізм розповсюдження даних Turbine. Однак SVM як віртуальна машина для переходу станів, якщо лідер-нод під час виконання транзакцій, швидкість обробки SVM повільна, то це знижує загальну пропускну спроможність системи, тому для SVM Solana запропонувала паралельний виконавчий двигун Sealevel для прискорення виконання транзакцій.
У SVM інструкція складається з 4-х частин, що містять ID програми, інструкцію програми та список облікових записів для читання/запису даних. Визначивши, чи поточний обліковий запис знаходиться в стані читання або запису, а також чи є конфлікти з операцією, яка має бути змінена, можна дозволити паралелізацію торгових інструкцій облікових записів, де немає конфліктів зі станом, при цьому кожна інструкція представляється через Program ID. Саме це є однією з причин високих вимог до валідаторів Solana, оскільки вимагається, щоб GPU/CPU валідаторів підтримували SIMD) одноінструкційні багатодані### та можливості розширення AVX.
Екологічний розвиток
У процесі розвитку екосистеми Solana все більше уваги приділяється реальній корисності, наприклад, певному проекту смартфона, певному магазину додатків або навіть певному мобільному пристрою. Напрямок розвитку офіційно підтримуваних додатків також більше орієнтований на споживчі програми, а не на безкінечну внутрішню конкуренцію в інфраструктурі. На даний момент продуктивності Solana достатньо.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
5
Поділіться
Прокоментувати
0/400
OnchainArchaeologist
· 07-08 02:05
Коли ж ці старі проблеми будуть вирішені?
Переглянути оригіналвідповісти на0
WalletDoomsDay
· 07-05 08:55
sol завжди До місяця не рухається, гай
Переглянути оригіналвідповісти на0
MetaNomad
· 07-05 08:50
Хто ще ставить на sol? Продовжуйте все вкласти, вперед!
Аналіз технологічної архітектури Solana: висока продуктивність та виклики співіснують, екосистема бурхливо розвивається та зустрічає нові можливості
Переосмислення технічної архітектури Solana: чи чекає нас друге весняне пробудження?
Solana є високопродуктивною платформою блокчейн, яка використовує унікальну технічну архітектуру для забезпечення високої пропускної спроможності та низької затримки. Її основні технології включають алгоритм Proof of History (POH), який забезпечує порядок транзакцій та глобальний годинник, графік ротації лідерів та механізм консенсусу Tower BFT для підвищення швидкості створення блоків. Механізм Turbine оптимізує поширення великих блоків за допомогою кодування Reed-solomon. Solana Virtual Machine (SVM) та паралельний виконавчий двигун Sealevel прискорюють швидкість виконання транзакцій. Усе це є архітектурним дизайном Solana для досягнення високої продуктивності, але одночасно також призвело до деяких проблем, таких як збої мережі, невдачі транзакцій, проблеми MEV, надмірне зростання стану та проблеми централізації, про які ми також детально розглядаємо в цій статті.
Екосистема Solana швидко розвивається, різні показники в першій половині року демонструють стрімке зростання, особливо в сферах DeFi, інфраструктури, GameFi/NFT, DePin/AI та споживчих додатків. Високий TPS Solana та стратегія, орієнтована на споживчі додатки, разом із слабким брендовим ефектом екосистеми створюють багатий вибір можливостей для підприємців і розробників. У сфері споживчих додатків Solana демонструє своє бачення щодо просування технології блокчейн у більш широких сферах. Підтримуючи такі проекти, як Solana Mobile та SDK, створений спеціально для споживчих додатків, Solana прагне інтегрувати технологію блокчейн у повсякденні застосування, тим самим підвищуючи прийнятність і зручність для користувачів. Наприклад, один з фітнес-додатків поєднує блокчейн і мобільні технології, щоб запропонувати користувачам новий досвід тренувань і соціальної взаємодії. Хоча багато споживчих додатків наразі ще експериментують із найкращими бізнес-моделями та ринковими позиціями, технологічна платформа та екосистема, які пропонує Solana, безсумнівно, забезпечують потужну підтримку для цих інноваційних спроб. З подальшим розвитком технологій та зрілістю ринку, Solana має перспективи досягти ще більших проривів та успішних випадків у сфері споживчих додатків.
Хоча Solana здобула значну частку ринку в індустрії блокчейнів завдяки своїй високій пропускній здатності та низьким витратам на транзакції, вона також стикається з жорсткою конкуренцією з боку інших нових публічних блокчейнів. Base, як потенційний суперник в екосистемі EVM, швидко нарощує кількість активних адрес на своїй ланцюзі. Тим часом загальний заблокований обсяг (TVL) в DeFi-сфері Solana, що становить (, хоча і встановив історичний максимум, але конкуренти, такі як Base, також швидко завойовують частки ринку. Обсяги фінансування екосистеми Base вперше перевищили Solana в другому кварталі.
Незважаючи на те, що Solana досягла певних успіхів у технологіях та прийнятті на ринку, їй потрібно постійно інноваційно розвиватися та вдосконалюватися, щоб протистояти викликам від конкурентів, таких як Base. Особливо в питаннях підвищення стабільності мережі, зниження рівня невдач транзакцій, вирішення проблеми MEV та уповільнення зростання стану, Solana потрібно продовжувати оптимізувати свою технологічну архітектуру та мережеві протоколи, щоб зберегти свою лідируючу позицію в індустрії блокчейн.
Технічна архітектура
Solana відома своїм алгоритмом POH, механізмом консенсусу Tower BFT, а також мережею передачі даних Trubine і віртуальною машиною SVM, які забезпечують високу TPS і швидку фіналізацію. Ми коротко представимо, як працюють усі ці компоненти, як вони сприяють досягненню високої продуктивності для архітектурного дизайну, а також недоліки та виникаючі проблеми, пов'язані з цим архітектурним дизайном.
![Ще раз про технічну архітектуру Solana: чи чекає нас друге весняне пробудження?])https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
) алгоритм 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: чи чекає нас друга весна?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
У схемі потоку транзакцій 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 валідаторів проголосують за approve, тоді цей блок може бути підтверджений. Перевагою цього механізму є те, що він економить велику кількість пам'яті, оскільки для підтвердження блоку потрібно лише голосувати за хеш-послідовність. Однак у традиційних механізмах консенсусу зазвичай використовується затоплення блоків, коли валідатор отримує блок і відправляє його сусіднім валідаторам, що призводить до великої надмірності в мережі, оскільки один валідатор отримує один і той же блок більше одного разу.
У Solana, через велику кількість голосувань валідаторів і високу ефективність, яка виникає внаслідок централізації вузлів-лідерів та часу слотів у 400 мс, загальний розмір блоку та частота створення блоків є особливо високими. Великі блоки під час розповсюдження також створюють значний тиск на мережу. Solana використовує механізм Turbine для вирішення проблеми розповсюдження великих блоків.
) Турбина
Лідер-нод через процес, відомий як Sharding, розділяє блоки на субблоки типу shred, розмір яких відповідає максимальному розміру передачі MTU###, максимально можливій кількості даних, що може бути передана з одного вузла на наступний без необхідності їх розподілу на менші одиниці, становить ###. Потім для забезпечення цілісності та доступності даних використовується схема кодування з виправленням помилок Ріда-Соломона.
Розділивши блоки на чотири Data Shreds, потім для запобігання втратам і пошкодженням даних під час передачі, використовується кодування Ріда-Соломона, щоб закодувати чотири пакети в вісім пакетів. Ця схема може витримувати до 50% втрат пакетів. У реальних тестах, втрати пакетів у Solana становлять приблизно 15%, тому ця схема добре сумісна з поточною архітектурою Solana.
У передачі даних на нижньому рівні зазвичай розглядається використання протоколів UDP/TCP. Оскільки Solana має високу толерантність до втрат пакетів, тому використовується протокол UDP для передачі, його недолік полягає в тому, що при втраті пакета він не буде повторно передаватися, але перевагою є більш висока швидкість передачі. Навпаки, протокол TCP повторно передаватиме пакети кілька разів при їх втраті, що значно знижує швидкість передачі та пропускну здатність. Завдяки Reed-solomon ця система може значно підвищити пропускну здатність Solana, у реальних умовах пропускна здатність може зрости в 9 разів.
Після розбиття даних за допомогою Turbine, використовується багаторазовий механізм поширення. Вузол-лідер передає блок будь-якому з блокчейн-верифікаторів перед завершенням кожного слоту, після чого цей верифікатор розбиває блок на Shreds і генерує код виправлення. Потім цей верифікатор розпочне поширення Turbine. Спочатку потрібно поширити до кореневого вузла, після чого цей кореневий вузол визначить, які верифікатори знаходяться на якому рівні. Процес виглядає наступним чином:
Створення списку вузлів: кореневий вузол збирає всіх активних валідаторів в один список, а потім сортує їх відповідно до частки кожного валідатора в мережі (, тобто кількості заморожених SOL ), причому вузли з вищою вагою знаходяться на першому рівні, і так далі.
Групування вузлів: Потім кожен валідатор, який знаходиться на першому рівні, також створить власний список вузлів для побудови власного першого рівня.
Формування шарів: з верхньої частини списку вузли поділяються на шари, шляхом визначення двох значень: глибини та ширини, можна визначити загальну форму всього дерева, цей параметр вплине на швидкість розповсюдження shreds.
Вузли з високою часткою прав власності, під час поділу на рівні, знаходяться на більш високому рівні, тому можуть заздалегідь отримувати повні шреди. У цей момент вони можуть відновити повний блок, тоді як вузли з нижчих рівнів, через втрати під час передачі, мають знижену ймовірність отримання повних шредів. Якщо цих шредів недостатньо для побудови повних фрагментів, лідер вимагатиме повторної передачі. Тоді передача даних відбуватиметься всередині дерева, а вузли першого рівня вже давно підтвердили повний блок. Час, який потрібен для голосування після завершення побудови блоку перевірювачами на нижчих рівнях, буде зростати.
Ця система має концепцію, схожу на механізм одиничного вузла лідера. У процесі розповсюдження блоків також існують деякі пріоритетні вузли, які першими отримують шматки shreds для формування повного блоку з метою досягнення консенсусу голосування. Перенесення надмірності на глибший рівень може значно прискорити процес фіналізації та максимізувати пропускну здатність і ефективність. Оскільки насправді перші кілька рівнів можуть представляти 2/3 вузлів, то голосування наступних вузлів стає неважливим.
( SVM
Solana може обробляти тисячі транзакцій на секунду, головною причиною чого є її механізм POH, консенсус Tower BFT та механізм розповсюдження даних Turbine. Однак SVM як віртуальна машина для переходу станів, якщо лідер-нод під час виконання транзакцій, швидкість обробки SVM повільна, то це знижує загальну пропускну спроможність системи, тому для SVM Solana запропонувала паралельний виконавчий двигун Sealevel для прискорення виконання транзакцій.
У SVM інструкція складається з 4-х частин, що містять ID програми, інструкцію програми та список облікових записів для читання/запису даних. Визначивши, чи поточний обліковий запис знаходиться в стані читання або запису, а також чи є конфлікти з операцією, яка має бути змінена, можна дозволити паралелізацію торгових інструкцій облікових записів, де немає конфліктів зі станом, при цьому кожна інструкція представляється через Program ID. Саме це є однією з причин високих вимог до валідаторів Solana, оскільки вимагається, щоб GPU/CPU валідаторів підтримували SIMD) одноінструкційні багатодані### та можливості розширення AVX.
Екологічний розвиток
У процесі розвитку екосистеми Solana все більше уваги приділяється реальній корисності, наприклад, певному проекту смартфона, певному магазину додатків або навіть певному мобільному пристрою. Напрямок розвитку офіційно підтримуваних додатків також більше орієнтований на споживчі програми, а не на безкінечну внутрішню конкуренцію в інфраструктурі. На даний момент продуктивності Solana достатньо.