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

Хотя Solana добилась значительной доли рынка в блокчейн-индустрии благодаря высокой пропускной способности и низким транзакционным затратам, она также сталкивается с жесткой конкуренцией со стороны других новых публичных блокчейнов. Base, как потенциальный соперник в экосистеме EVM, быстро увеличивает количество активных адресов на своей цепочке. В то же время, общий заблокированный объем в области DeFi Solana, (TVL), хотя и достиг исторического максимума, но такие конкуренты, как Base, также быстро захватывают долю рынка. Объем финансирования экосистемы Base впервые превысил Solana в квартале Q2.

Несмотря на определенные достижения Solana в технологиях и принятии на рынке, ей необходимо постоянно инновацировать и улучшаться, чтобы справляться с вызовами со стороны таких конкурентов, как Base. Особенно в таких областях, как повышение стабильности сети, снижение уровня неудачных транзакций, решение проблемы MEV и замедление роста состояния, Solana нужно продолжать оптимизировать свою техническую архитектуру и сетевые протоколы, чтобы сохранить свои лидерские позиции в блокчейн-индустрии.

Техническая архитектура

Solana известна своим алгоритмом POH, механизмом согласия Tower BFT, а также сетью передачи данных Trubine и виртуальной машиной SVM, которые обеспечивают высокую TPS и быструю финализацию. Мы кратко представим, как работают эти компоненты, как они достигают своих высокопроизводительных целей в архитектурном проектировании, а также недостатки и возникающие проблемы, связанные с этой архитектурой.

алгоритм POH

POH(Доказательство истории) — это технология, определяющая глобальное время, которая не является механизмом консенсуса, а представляет собой алгоритм, определяющий порядок транзакций. Технология POH основана на самой базовой криптографической технологии SHA256. SHA256 обычно используется для вычисления целостности данных: для данного входа X существует только один уникальный выход Y, поэтому любое изменение X приводит к совершенно другому Y.

В последовательности POH Solana, с помощью применения алгоритма sha256 можно обеспечить целостность всей последовательности, тем самым подтверждая целостность транзакций в ней. Например, если мы упакуем транзакции в блок и сгенерируем соответствующее значение sha256 хеша, то транзакции внутри этого блока будут подтверждены, любое изменение приведет к изменению хеша, после чего этот блок хеш будет использоваться как часть X следующей функции sha256, добавляя хеш следующего блока, тогда оба предыдущий и следующий блоки будут подтверждены, любое изменение приведет к новому Y.

Это и есть основное значение технологии Proof of History: хеш предыдущего блока будет частью следующей функции sha256, подобно цепочке, где последний Y всегда содержит доказательство истории.

В диаграмме потока транзакций Solana описан процесс транзакций в механизме POH. В рамках механизма ротации лидеров, называемого Leader Rotation Schedule, создается узел-лидер среди всех валидаторов цепи. Этот узел-лидер собирает транзакции, сортирует их для выполнения и генерирует последовательность POH, после чего создает блок и передает его другим узлам.

Чтобы избежать возникновения единой точки отказа на узлах Leader, было введено ограничение по времени. В Solana временные единицы делятся на эпохи, каждая эпоха состоит из 432,000 слотов(, каждый слот длится 400 мс. В каждом слоте система ротации назначает узел Leader, который должен опубликовать блок в течение заданного времени слота)400мс(, иначе этот слот будет пропущен, и будет заново избран узел Leader для следующего слота.

В общем, узлы Leader, использующие механизм POH, могут обеспечить окончательность всех исторических транзакций. Основная единица времени в Solana — это Slot, узел Leader должен передать блок в течение одного слота. Пользователи отправляют транзакции через RPC-узлы узлу Leader, который упаковывает транзакции, сортирует их и затем выполняет генерацию блока, который распространяется среди других валидаторов. Валидаторы должны достичь консенсуса с помощью механизма, чтобы согласовать транзакции и порядок внутри блока, при этом используется механизм консенсуса Tower BFT.

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

Протокол согласия Tower BFT является конкретной инженерной реализацией алгоритма согласия BFT и по-прежнему связан с алгоритмом POH. При голосовании по блоку, если голосование валидатора само по себе является транзакцией, то хэш блока, сформированный транзакцией пользователя и транзакцией валидатора, также может служить историческим доказательством, и детали транзакции каждого пользователя, а также детали голосования валидатора могут быть уникально подтверждены.

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

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

Турбина

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

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

![Еще раз о технической архитектуре Solana: ждет ли она второе весеннее обновление?])https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

В процессе передачи данных на нижнем уровне обычно рассматриваются протоколы UDP/TCP. Поскольку Solana обладает высокой устойчивостью к потере пакетов, для передачи используется протокол UDP. Его недостаток заключается в том, что потерянные пакеты не будут retransmit, но преимущество заключается в более высокой скорости передачи. Напротив, протокол TCP будет многократно retransmit потерянные пакеты, что значительно снижает скорость передачи и пропускную способность. С введением Reed-Solomon эта схема может значительно увеличить пропускную способность Solana, в реальных условиях пропускная способность может увеличиться в 9 раз.

После разбивки данных с помощью Turbine используется многоуровневый механизм распространения. Узел-лидер передает блок любому валидатору блока до завершения каждого слота, затем этот валидатор разбивает блок на Shreds и генерирует код исправления ошибок. Затем этот валидатор запускает распространение Turbine. Сначала данные распространяются к корневому узлу, затем этот корневой узел определяет, какие валидаторы находятся на каком уровне. Процесс показан ниже:

1. Создание списка узлов: корневой узел собирает всех активных валидаторов в один список, а затем сортирует их по правам на сети ), то есть по количеству заложенных SOL (. Узлы с более высоким весом находятся на первом уровне, и так далее.

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

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

У узлов с высоким долевым участием, при делении на уровни, будет более высокий уровень, что позволит им заранее получить полные shreds, в этом случае они смогут восстановить полный блок. В то время как узлы на более низких уровнях, из-за потерь при передаче, имеют меньше шансов получить полные shreds. Если этих shreds недостаточно для построения полного фрагмента, это потребует от лидера повторной передачи. В этом случае передача данных будет происходить внутрь дерева, а узлы первого уровня уже давно создали полное подтверждение блока, и чем дольше время, необходимое для завершения построения блока проверяющими на более низких уровнях, тем дольше будет время голосования.

Эта система основана на идеях одноузлового механизма для ведущих узлов. В процессе распространения блоков существуют определенные приоритетные узлы, которые первыми получают фрагменты (shreds) для формирования полного блока и достижения процесса голосования. Углубление избыточности может значительно ускорить процесс окончательности (Finality) и максимизировать пропускную способность и эффективность. Поскольку на самом деле первые несколько уровней могут представлять уже 2/3 узлов, дальнейшие голосования узлов становятся не столь важными.

![Повторное объяснение архитектуры технологии Solana: ждет ли она второе весеннее пробуждение?])https://img-cdn.gateio.im/webp-social/moments-d55d3cfbc13036ed0d5747abb521cc1a.webp(

) СВМ

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

В SVM инструкции состоят из 4 частей, включая ID программы, инструкции программы и список аккаунтов для чтения/записи данных. Определив, находится ли текущий аккаунт в состоянии чтения или записи, а также есть ли конфликты в операциях, требующих изменения состояния, можно разрешить параллелизацию транзакционных инструкций аккаунта, в которых нет конфликтов состояния, каждая инструкция обозначается ID программы. Это также одна из причин, почему требования к валидаторам Solana очень высоки, так как требуется, чтобы GPU/CPU валидаторов могли поддерживать SIMD### однокомандные многоданные( и возможности расширения AVX.

![Еще раз о технической архитектуре Solana: ждёт ли её второе рождение?])https://img-cdn.gateio.im/webp-social/moments-e9bc35d0c790496c59c20979e5af1491.webp(

Экологическое развитие

В процессе текущего развития экосистемы Solana наблюдается всё большее стремление к реальной полезности, например, к проектам с определённым смартфоном, приложением для магазинов или даже мобильным устройствам, в то время как официальная поддержка развития приложений также больше ориентирована на потребительские приложения, а не на бесконечные внутренние конкуренции в инфраструктуре. В настоящее время производительность Solana достаточно высока.