Анализ архитектуры 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 заняла значительную долю рынка в индустрии блокчейна благодаря высокой пропускной способности и низким транзакционным затратам, она также сталкивается с жесткой конкуренцией со стороны других новых публичных цепей. Base, как потенциальный соперник в экосистеме EVM, быстро увеличивает количество активных адресов на своей цепи, в то время как общий объем заблокированных средств в DeFi на Solana, составивший (TVL), хотя и достиг исторического максимума, конкуренты, такие как Base, также быстро завоевывают долю рынка, и объем финансирования экосистемы Base впервые превысил Solana в квартале Q2.

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

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

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

алгоритм POH

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

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

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

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

![Снова обсуждаем архитектуру технологий Solana: ждет ли нас второе весеннее пробуждение?]###https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(

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

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

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

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

) СВМ

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 все больше акцентируется на реальной полезности, такой как Blinks, Actions и даже Solana Mobile, а направление развития официально поддерживаемых приложений также более ориентировано на потребительские приложения, а не на бесконечное углубление инфраструктуры. При достаточной производительности Solana разнообразие приложений становится более обширным. Что касается Ethereum, то из-за его низкого TPS,