Анализ технологической архитектуры и экосистемного развития Solana

Solana является высокопроизводительной блокчейн платформой, использующей уникальную архитектуру технологии для достижения высокой пропускной способности и низкой задержки. Ее ключевые технологии включают алгоритм Proof of History (POH), который обеспечивает порядок транзакций и глобальные часы, расписание ротации лидеров и механизм консенсуса Tower BFT, который увеличивает скорость создания блоков. Механизм Turbine оптимизирует распространение больших блоков с помощью кодирования Рида-Соломона. Solana Virtual Machine (SVM) и параллельный исполнительный движок Sealevel ускоряют скорость выполнения транзакций. Все эти элементы представляют собой архитектурный дизайн Solana для достижения высокой производительности, но одновременно они также привносят некоторые проблемы, такие как сбои в сети, неудачи транзакций, проблемы MEV, слишком быстрое увеличение состояния и проблемы централизации.

Экосистема Solana развивается стремительно, все показатели данных в первой половине года значительно выросли, особенно в сферах DeFi, инфраструктуры, GameFi/NFT, DePin/AI и потребительских приложений. Высокая пропускная способность Solana (TPS) и стратегия, ориентированная на потребительские приложения, а также слабый брендинговый эффект экосистемы предоставляют предпринимателям и разработчикам множество возможностей для стартапов. В сфере потребительских приложений Solana демонстрирует свою визию по продвижению технологий блокчейн в более широких областях. Поддерживая такие инициативы, как Solana Mobile и специально разработанный SDK для потребительских приложений, Solana стремится интегрировать технологии блокчейн в повседневные приложения, что, в свою очередь, повышает степень принятия и удобство для пользователей.

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

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

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

алгоритм POH

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

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

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

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

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

) Механизм согласия Tower BFT

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

![Еще раз о технической архитектуре Solana: ждет ли ее второе веселье?]###panews/images/90Jj8P8FH5.webp(

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

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

) Турбина

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

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

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

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

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

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

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

![Еще раз о технической архитектуре Solana: ждет ли нас второе весеннее пробуждение?])panews/images/iQ41c4b6DM.webp(

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

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

) СВМ

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

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

![Снова разбирая техническую архитектуру Solana: ждёт ли её второе дыхание?])panews/images/Czi5MR4h94.webp(

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

В процессе текущего развития экосистемы Solana все больше внимания уделяется практической полезности, такой как Blinks, Actions и даже Solana Mobile. Официальная поддержка направлена больше на развитие потребительских приложений, а не на бесконечное углубление в инфраструктуру. При достаточной производительности Solana разнообразие приложений становится более широким. Что касается Ethereum, то из-за низкой TPS экосистема Ethereum по-прежнему ориентирована на инфраструктуру и технологии масштабирования. Когда инфраструктура не может поддерживать приложения, нельзя строить потребительские приложения, что приводит к несбалансированному состоянию, когда инвестиции слишком велики в инфраструктуру, но слишком малы в приложения.

) DeFi

В DeFi-протоколах на Solana существует множество проектов, которые еще не выпустили токены, включая Kamino### Первый Lending(, Marginfi) Lending + Restaking(, SoLayer) Restaking(, Meteora и другие. Благодаря единой экосистеме Solana, обычно, когда один проект объявляет о выпуске токенов, другие проекты стараются избегать этого периода, чтобы привлечь достаточное внимание рынка.

В настоящее время конкуренция на рынке DEX очень высока, и его лидеры также неоднократно меняли свои позиции, от Raydium, Orca до текущего доминирования Jupiter.

Стоит отметить, что около 50% сделок на DEX инициируются MEV-ботами, что в основном связано с низкими комиссиями и активной торговлей мемами, способствующими прибыльности MEV. Это также является одной из основных причин частых сбоев и неудач в пиковых сделках пользователей.

Дефи-протоколы на Solana вместе с ростом цены SOL также продемонстрировали взрывной рост номинального TVL в USD. Тренд роста TVL по-прежнему не прекращается, формируя новую волну роста.

![Еще раз о технической архитектуре Solana: ждет ли нас второе весеннее пробуждение?])