Перепроектування технічної архітектури 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 отримала значну частку ринку в індустрії блокчейн завдяки своїй високій пропускній спроможності та низьким витратам на транзакції, вона також стикається з жорсткою конкуренцією з боку інших нових публічних блокчейнів. Один з торгових майданчиків, як потенційний суперник в екосистемі EVM, швидко нарощує кількість активних адрес на своїй ланцюжку, в той час як загальний обсяг заблокованих активів у сфері DeFi Solana досяг історичного максимуму (TVL), але конкуренти, такі як цей торговий майданчик, також швидко завойовують частку ринку, а обсяги фінансування екосистеми цього торгового майданчика вперше в другому кварталі перевищили Solana.
Хоча Solana досягла певних успіхів у технологічному та ринковому прийнятті, їй необхідно постійно інноваційно розвиватися та вдосконалюватися, щоб протистояти викликам з боку конкурентів, таких як деякі торгові платформи. Особливо в питаннях підвищення стабільності мережі, зниження рівня невдалих угод, вирішення проблеми 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, тоді транзакції в цьому блоці будуть зафіксовані, будь-які зміни призведуть до зміни значення хешу, після чого цей хеш блоку буде частиною наступної функції sha256 як X, далі додаємо хеш наступного блоку, тоді попередній блок та наступний блок будуть зафіксовані, будь-які зміни призведуть до нової Y.
Це є центральне значення його технології Proof of History, попередній хеш блоку буде частиною наступної функції sha256, подібно до ланцюга, найновіший Y завжди містить історичне підтвердження.
У схемі торгового потоку Solana описується процес торгівлі в рамках механізму POH. У рамках ротаційного механізму, який називається Leader Rotation Schedule, серед усіх валідаторів у ланцюгу створюється лідер-нод. Цей лідер-нод збирає транзакції та виконує їх у порядку, формуючи послідовність POH, після чого створюється блок, який розповсюджується на інші вузли.
Щоб уникнути виникнення єдиної точки відмови на вузлі Leader, було введено часові обмеження. У Solana одиниці часу розділені на епохи, кожна епоха містить 432 000 слотів (, кожен слот триває 400 мс. У кожному слоті ротаційна система призначає вузол Leader, який повинен опублікувати блок протягом заданого часу слоту )400 мс (, інакше цей слот буде пропущено, і буде повторно обрано вузол Leader для наступного слоту.
В цілому, вузли-лідери, що використовують механізм POH, можуть повністю підтвердити історичні транзакції. Основна одиниця часу в Solana - це Slot, вузол-лідер повинен транслювати блок протягом одного слоту. Користувачі передають транзакції через 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 для вирішення проблеми розповсюдження великих блоків.
) Турбіна
Лідер вузла розділяє блоки на підблоки, звані шредами, за допомогою процесу, відомого як шардінг, розмір яких відповідає максимальному обсягу передачі 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. Спочатку потрібно поширити дані до кореневого вузла, а потім цей кореневий вузол визначає, які валідатори знаходяться на якому рівні. Процес виглядає наступним чином:
Створення списку вузлів: кореневий вузол зібирає всіх активних валідаторів в один список, а потім сортує їх відповідно до частки кожного валідатора в мережі ), тобто кількості залікованих SOL (, де більша вага займає перший рівень, і так далі.
Групування вузлів: тоді кожен валідатор, що знаходиться на першому рівні, також створить свій список вузлів, щоб побудувати свій перший рівень.
Формування шарів: поділити вузли на шари з верхньої частини списку, визначивши два значення - глибину і ширину, можна визначити загальну форму всього дерева, цей параметр вплине на швидкість поширення 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, а також офіційно підтримувані напрямки розвитку застосунків.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
25 лайків
Нагородити
25
7
Репост
Поділіться
Прокоментувати
0/400
FlyingLeek
· 16год тому
sol знову хоче великий памп?
Переглянути оригіналвідповісти на0
NervousFingers
· 08-15 01:45
Бігти так швидко - це просто продаж.
Переглянути оригіналвідповісти на0
MemeTokenGenius
· 08-13 22:07
Знову прийшов з ритмом, не вірю, що sol зможе піднятися.
Глибина аналізу технічної архітектури Solana: Виклики та можливості за високим TPS
Перепроектування технічної архітектури 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 отримала значну частку ринку в індустрії блокчейн завдяки своїй високій пропускній спроможності та низьким витратам на транзакції, вона також стикається з жорсткою конкуренцією з боку інших нових публічних блокчейнів. Один з торгових майданчиків, як потенційний суперник в екосистемі EVM, швидко нарощує кількість активних адрес на своїй ланцюжку, в той час як загальний обсяг заблокованих активів у сфері DeFi Solana досяг історичного максимуму (TVL), але конкуренти, такі як цей торговий майданчик, також швидко завойовують частку ринку, а обсяги фінансування екосистеми цього торгового майданчика вперше в другому кварталі перевищили Solana.
Хоча Solana досягла певних успіхів у технологічному та ринковому прийнятті, їй необхідно постійно інноваційно розвиватися та вдосконалюватися, щоб протистояти викликам з боку конкурентів, таких як деякі торгові платформи. Особливо в питаннях підвищення стабільності мережі, зниження рівня невдалих угод, вирішення проблеми 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, тоді транзакції в цьому блоці будуть зафіксовані, будь-які зміни призведуть до зміни значення хешу, після чого цей хеш блоку буде частиною наступної функції sha256 як X, далі додаємо хеш наступного блоку, тоді попередній блок та наступний блок будуть зафіксовані, будь-які зміни призведуть до нової Y.
Це є центральне значення його технології Proof of History, попередній хеш блоку буде частиною наступної функції sha256, подібно до ланцюга, найновіший Y завжди містить історичне підтвердження.
У схемі торгового потоку Solana описується процес торгівлі в рамках механізму POH. У рамках ротаційного механізму, який називається Leader Rotation Schedule, серед усіх валідаторів у ланцюгу створюється лідер-нод. Цей лідер-нод збирає транзакції та виконує їх у порядку, формуючи послідовність POH, після чого створюється блок, який розповсюджується на інші вузли.
Щоб уникнути виникнення єдиної точки відмови на вузлі Leader, було введено часові обмеження. У Solana одиниці часу розділені на епохи, кожна епоха містить 432 000 слотів (, кожен слот триває 400 мс. У кожному слоті ротаційна система призначає вузол Leader, який повинен опублікувати блок протягом заданого часу слоту )400 мс (, інакше цей слот буде пропущено, і буде повторно обрано вузол Leader для наступного слоту.
В цілому, вузли-лідери, що використовують механізм POH, можуть повністю підтвердити історичні транзакції. Основна одиниця часу в Solana - це Slot, вузол-лідер повинен транслювати блок протягом одного слоту. Користувачі передають транзакції через 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 для вирішення проблеми розповсюдження великих блоків.
) Турбіна
Лідер вузла розділяє блоки на підблоки, звані шредами, за допомогою процесу, відомого як шардінг, розмір яких відповідає максимальному обсягу передачі 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. Спочатку потрібно поширити дані до кореневого вузла, а потім цей кореневий вузол визначає, які валідатори знаходяться на якому рівні. Процес виглядає наступним чином:
Створення списку вузлів: кореневий вузол зібирає всіх активних валідаторів в один список, а потім сортує їх відповідно до частки кожного валідатора в мережі ), тобто кількості залікованих SOL (, де більша вага займає перший рівень, і так далі.
Групування вузлів: тоді кожен валідатор, що знаходиться на першому рівні, також створить свій список вузлів, щоб побудувати свій перший рівень.
Формування шарів: поділити вузли на шари з верхньої частини списку, визначивши два значення - глибину і ширину, можна визначити загальну форму всього дерева, цей параметр вплине на швидкість поширення 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, а також офіційно підтримувані напрямки розвитку застосунків.