Анализ технической архитектуры 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 достигла определенных успехов в техническом и рыночном принятии, ей необходимо постоянно инновировать и улучшать, чтобы справляться с вызовами со стороны конкурентов, таких как Base. Особенно в таких областях, как повышение стабильности сети, снижение уровня неудачных транзакций, решение проблемы MEV и замедление роста состояния, Solana необходимо постоянно оптимизировать свою техническую архитектуру и сетевые протоколы, чтобы сохранить свое лидерство в блокчейн-отрасли.

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

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

алгоритм POH

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

) СВМ

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

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

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

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

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