Повторное изучение архитектуры технологии 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 достигла определенных успехов в техническом и рыночном принятии, ей необходимо постоянно Innovate и улучшать, чтобы справляться с вызовами со стороны конкурентов, таких как 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, среди всех валидаторов (Validator) сети выбирается один ведущий узел (Leader). Этот ведущий узел собирает транзакции, сортирует их и выполняет, создавая последовательность POH, после чего генерируется блок, который распространяется на другие узлы.

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

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

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

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

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

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

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

Идея этой системы аналогична механизму одиночного узла в узле Leader. В процессе распространения блока также существуют некоторые приоритетные узлы, которые первыми получают группы фрагментов shreds для формирования полного блока с целью достижения консенсуса голосования. Углубление избыточности значительно ускоряет процесс Финальности и максимизирует пропускную способность и эффективность. Поскольку на самом деле несколько первых уровней могут представлять 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-636ac72327705b9f93e62e394355436f.webp(

Экология发