Анализ архитектуры технологий Solana и развития экосистемы
Solana является высокопроизводительной блокчейн-платформой, использующей уникальную технологическую архитектуру для достижения высокой пропускной способности и низкой задержки. Ключевые технологии включают алгоритм Proof of History (POH), который обеспечивает последовательность транзакций и глобальные часы, расписание ротации лидеров и механизм консенсуса Tower BFT, который повышает скорость создания блоков. Механизм Turbine оптимизирует распространение больших блоков с помощью кодирования Рида-Соломона. Solana Virtual Machine (SVM) и параллельный исполнительный движок Sealevel ускоряют скорость выполнения транзакций. Все это является архитектурным дизайном Solana для достижения высокой производительности, но одновременно это привело к некоторым проблемам, таким как сбои сети, неудачи транзакций, проблемы MEV, чрезмерный рост состояния и проблемы централизации.
Экосистема Solana быстро развивается, все показатели за первое полугодие стремительно растут, особенно в сферах DeFi, инфраструктуры, GameFi/NFT, DePin/AI и потребительских приложений. Высокая пропускная способность Solana и стратегический подход к потребительским приложениям, а также слабая экосистема с точки зрения брендинга предоставляют богатые возможности для стартапов и разработчиков. В области потребительских приложений Solana демонстрирует свою цель по продвижению применения блокчейн-технологий в более широких областях. Поддерживая такие проекты, как Solana Mobile, и создавая SDK специально для потребительских приложений, Solana стремится интегрировать блокчейн-технологии в повседневные приложения, что повысит уровень принятия и удобства для пользователей.
Хотя Solana завоевала значительную долю рынка в индустрии блокчейна благодаря своей высокой пропускной способности и низким транзакционным затратам, она также сталкивается с жесткой конкуренцией со стороны других новых публичных цепей. Base, будучи потенциальным соперником в экосистеме EVM, быстро увеличивает количество активных адресов на своей цепи. В то же время, общий объем заблокированных средств в области DeFi Solana (TVL), хотя и достиг исторического максимума, конкуренты, такие как Base, также быстро завоевывают долю рынка, и объем финансирования экосистемы Base впервые в квартале Q2 превысил объем финансирования Solana.
Несмотря на определенные достижения Solana в техническом плане и уровне рыночного принятия, ей необходимо постоянно внедрять инновации и улучшения, чтобы справляться с вызовами со стороны конкурентов, таких как Base. Особенно в таких областях, как повышение стабильности сети, снижение уровня неудачных транзакций, решение проблемы MEV и замедление роста состояния, Solana необходимо постоянно оптимизировать свою техническую архитектуру и сетевые протоколы, чтобы сохранить свои лидирующие позиции в блокчейн-индустрии.
Техническая архитектура
Solana известна своим алгоритмом POH, механизмом согласования Tower BFT, а также высокими TPS и быстрой окончательностью, обеспечиваемыми сетью передачи данных Trubine и виртуальной машиной SVM. Как работают различные компоненты, как они достигают своей высокой производительности в архитектурном дизайне, а также недостатки и возникающие проблемы, связанные с этой архитектурной концепцией.
алгоритм 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 должны транслировать блок в течение одного slot. Пользователи передают транзакции узлам Leader через узлы RPC, узлы Leader упаковывают транзакции, сортируют их, а затем выполняют для генерации блока. Блок распространяется к другим валидаторам, которые должны достигнуть консенсуса через определенный механизм по транзакциям внутри блока и их порядку, для чего используется механизм консенсуса Tower BFT.
) Механизм согласования Tower BFT
Протокол консенсуса Tower BFT основан на алгоритме консенсуса BFT и является его конкретной инженерной реализацией, при этом этот алгоритм все еще связан с алгоритмом POH. Когда происходит голосование по блоку, если голосование валидатора само по себе является транзакцией, то хэш блока, сформированный транзакцией пользователя и транзакцией валидатора, также может служить историческим доказательством, благодаря чему детали транзакции пользователя и детали голосования валидатора могут быть уникально подтверждены.
![Снова разбираем архитектуру технологий Solana: ждет ли нас второе весеннее пробуждение?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
В алгоритме Tower BFT предусмотрено, что если все валидаторы голосуют за этот блок и более 2/3 валидаторов проголосовали за одобрение, тогда этот блок может быть подтвержден. Преимуществом этого механизма является экономия большого объема памяти, так как для подтверждения блока достаточно голосовать только за хэш-последовательность. Однако в традиционных механизмах консенсуса обычно используется затопление блока, то есть один валидатор, получив блок, отправляет его окружающим валидаторам, что приводит к значительному избыточному трафику в сети, так как один валидатор получает один и тот же блок более одного раза.
В Solana, из-за большого количества валидаторов, голосующих за транзакции, а также благодаря централизации узлов лидеров и времени слота в 400 мс, это приводит к тому, что общий размер блока и частота создания блоков особенно высоки. При распространении больших блоков это также создает значительное давление на сеть. Solana использует механизм Turbine для решения проблемы распространения больших блоков.
) Турбина
Лидер-узел делит блоки на подблоки, называемые shreds, в процессе, известном как Sharding. Размер этих подблоков соответствует максимальному размеру передачи MTU###, что позволяет отправлять максимальный объем данных ( от одного узла к следующему без необходимости делить его на более мелкие единицы. Затем с помощью схемы кодирования Reed-Solomon обеспечивается целостность и доступность данных.
Разделяя блоки на четыре Data Shreds, и затем для предотвращения потерь и повреждений данных во время передачи используется кодирование Рида-Соломона для кодирования четырех пакетов в восемь, эта схема может терпеть до 50% уровня потерь пакетов. В реальных тестах уровень потерь пакетов Solana составляет примерно 15%, поэтому эта схема хорошо совместима с текущей архитектурой Solana.
В базовой передаче данных обычно рассматриваются протоколы UDP/TCP. Поскольку Solana имеет высокую устойчивость к потере пакетов, для передачи используется протокол UDP, который, однако, имеет недостаток в том, что потерянные пакеты не будут повторно переданы, но его преимуществом является более высокая скорость передачи. Напротив, протокол TCP будет многократно повторно передавать данные при потере пакетов, что значительно снижает скорость передачи и пропускную способность. С появлением Reed-Solomon эта схема может значительно увеличить пропускную способность Solana, в реальных условиях пропускная способность может увеличиться в 9 раз.
![Снова исследуем архитектуру технологии Solana: ждет ли нас второе весеннее пробуждение?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
После разбиения данных Turbine использует многослойный механизм распространения. Узел-лидер передает блок любому валидатору блока до окончания каждого слота, затем этот валидатор разбивает блок на Shreds и генерирует код исправления ошибок. После этого валидатор начинает распространение Turbine. Сначала нужно распространить данные до корневого узла, затем этот корневой узел определяет, какие валидаторы находятся на каком уровне. Процесс показан ниже:
Создание списка узлов: корневой узел собирает всех активных валидаторов в один список, а затем сортирует их по количеству SOL, которое они ставят в сети ), то есть по их доле (. Узлы с более высоким весом находятся на первом уровне, и так далее.
Группировка узлов: затем каждый валидатор, находящийся на первом уровне, также создаст собственный список узлов, чтобы построить свой собственный первый уровень.
Формирование слоев: Разделите узлы на слои от верхней части списка, определив два значения: глубину и ширину, что позволит определить общую форму дерева. Этот параметр будет влиять на скорость распространения shreds.
У узлов с высокой долей прав на участие, при делении на уровни, будет возможность находиться на более высоком уровне, что позволит им заранее получить полные фрагменты (shreds). В этот момент можно восстановить полный блок, тогда как узлы на более низких уровнях, из-за потерь при передаче, будут иметь меньшую вероятность получения полных фрагментов. Если этих фрагментов недостаточно для построения полного блока, лидеру потребуется заново передать данные. В этом случае передача данных будет происходить внутрь дерева, а узлы первого уровня уже давно создали полное подтверждение блока, поэтому время, необходимое для голосования после завершения построения блока последующими валидаторами, будет только увеличиваться.
Идея этой механики аналогична механике одного узла для Leader-узлов. В процессе распространения блоков также существуют некоторые приоритетные узлы, которые первыми получают фрагменты shreds для формирования полного блока с целью достижения голосования и консенсуса. Углубление избыточности может значительно ускорить процесс финализации и максимизировать пропускную способность и эффективность. Поскольку на самом деле первые несколько уровней могут представлять уже 2/3 узлов, дальнейшее голосование узлов становится несущественным.
) СВМ
Solana может обрабатывать тысячи транзакций в секунду, что в основном обусловлено его механизмом POH, консенсусом Tower BFT и механизмом передачи данных Turbine. Однако, поскольку SVM является виртуальной машиной для состояния перехода, если лидер-узел медленно обрабатывает транзакции, это приведет к снижению пропускной способности всей системы. Поэтому для SVM Solana предложила движок параллельного выполнения Sealevel, чтобы ускорить выполнение транзакций.
![Еще раз о технической архитектуре Solana: ждет ли нас второе весеннее пробуждение?]###https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(
В SVM инструкции состоят из 4 частей, включая ID программы, инструкции программы и список аккаунтов для чтения/записи данных. Определив, находится ли текущий аккаунт в состоянии чтения или записи, а также есть ли конфликты в операциях, которые необходимо изменить состояние, можно разрешить параллелизацию в транзакционных инструкциях аккаунта, где нет конфликтов по состоянию, каждая инструкция обозначается ID программы. И это одна из причин, почему требования к валидаторам Solana так высоки, поскольку от валидаторов требуется, чтобы их GPU/CPU поддерживали SIMD) одноинструкционную многоданные( и возможности AVX для расширения векторных операций.
Экологическое развитие
В процессе текущего развития экосистемы Solana все больше внимания уделяется практической полезности, такой как Blinks и Actions, а также Solana Mobile. Официальная поддержка направлена на развитие потребительских приложений, а не на бесконечное углубление инфраструктуры. При достаточной производительности Solana разнообразие приложений становится более богатым. Что касается Ethereum, то из-за низкого TPS экосистема Ethereum по-прежнему сосредоточена на инфраструктуре и технологиях масштабирования. Когда инфраструктура не может поддерживать приложения, невозможно создавать потребительские приложения, что приводит к несбалансированному состоянию, когда слишком много инвестиций идет в инфраструктуру, а слишком мало — в приложения.
) DeFi
В DeFi-протоколах на Solana существует множество проектов, которые еще не выпустили токены, включая Kamino### Первое кредитование(, Marginfi) Кредитование + Рестейкинг(, SoLayer) Рестейкинг(, Meteora и другие. Благодаря единой экосистеме Solana, как правило, один проект старается избегать даты выпуска токенов других проектов, чтобы привлечь достаточно внимания на рынке.
В настоящее время конкуренция на всем DEX-рынке очень высока, и его лидеры несколько раз менялись: от Raydium, Orca до текущего доминирующего DEX.
Стоит отметить, что около 50% сделок на DEX осуществляются с помощью MEV-ботов.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
19 Лайков
Награда
19
6
Поделиться
комментарий
0/400
staking_gramps
· 07-16 11:08
производительность sol действительно хороша
Посмотреть ОригиналОтветить0
0xSunnyDay
· 07-15 15:18
Какой производитель серверов еще хвастается производительностью?
Посмотреть ОригиналОтветить0
CoconutWaterBoy
· 07-14 03:35
Снова дуть на sol?
Посмотреть ОригиналОтветить0
SandwichTrader
· 07-14 03:21
Лучше избегать, чем зажимать, а то подумаешь, и все зависнет.
Анализ технологической архитектуры Solana и текущее состояние развития экосистемы
Анализ архитектуры технологий Solana и развития экосистемы
Solana является высокопроизводительной блокчейн-платформой, использующей уникальную технологическую архитектуру для достижения высокой пропускной способности и низкой задержки. Ключевые технологии включают алгоритм Proof of History (POH), который обеспечивает последовательность транзакций и глобальные часы, расписание ротации лидеров и механизм консенсуса Tower BFT, который повышает скорость создания блоков. Механизм Turbine оптимизирует распространение больших блоков с помощью кодирования Рида-Соломона. Solana Virtual Machine (SVM) и параллельный исполнительный движок Sealevel ускоряют скорость выполнения транзакций. Все это является архитектурным дизайном Solana для достижения высокой производительности, но одновременно это привело к некоторым проблемам, таким как сбои сети, неудачи транзакций, проблемы MEV, чрезмерный рост состояния и проблемы централизации.
Экосистема Solana быстро развивается, все показатели за первое полугодие стремительно растут, особенно в сферах DeFi, инфраструктуры, GameFi/NFT, DePin/AI и потребительских приложений. Высокая пропускная способность Solana и стратегический подход к потребительским приложениям, а также слабая экосистема с точки зрения брендинга предоставляют богатые возможности для стартапов и разработчиков. В области потребительских приложений Solana демонстрирует свою цель по продвижению применения блокчейн-технологий в более широких областях. Поддерживая такие проекты, как Solana Mobile, и создавая SDK специально для потребительских приложений, Solana стремится интегрировать блокчейн-технологии в повседневные приложения, что повысит уровень принятия и удобства для пользователей.
Хотя Solana завоевала значительную долю рынка в индустрии блокчейна благодаря своей высокой пропускной способности и низким транзакционным затратам, она также сталкивается с жесткой конкуренцией со стороны других новых публичных цепей. Base, будучи потенциальным соперником в экосистеме EVM, быстро увеличивает количество активных адресов на своей цепи. В то же время, общий объем заблокированных средств в области DeFi Solana (TVL), хотя и достиг исторического максимума, конкуренты, такие как Base, также быстро завоевывают долю рынка, и объем финансирования экосистемы Base впервые в квартале Q2 превысил объем финансирования Solana.
Несмотря на определенные достижения Solana в техническом плане и уровне рыночного принятия, ей необходимо постоянно внедрять инновации и улучшения, чтобы справляться с вызовами со стороны конкурентов, таких как Base. Особенно в таких областях, как повышение стабильности сети, снижение уровня неудачных транзакций, решение проблемы MEV и замедление роста состояния, Solana необходимо постоянно оптимизировать свою техническую архитектуру и сетевые протоколы, чтобы сохранить свои лидирующие позиции в блокчейн-индустрии.
Техническая архитектура
Solana известна своим алгоритмом POH, механизмом согласования Tower BFT, а также высокими TPS и быстрой окончательностью, обеспечиваемыми сетью передачи данных Trubine и виртуальной машиной SVM. Как работают различные компоненты, как они достигают своей высокой производительности в архитектурном дизайне, а также недостатки и возникающие проблемы, связанные с этой архитектурной концепцией.
алгоритм 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 должны транслировать блок в течение одного slot. Пользователи передают транзакции узлам Leader через узлы RPC, узлы Leader упаковывают транзакции, сортируют их, а затем выполняют для генерации блока. Блок распространяется к другим валидаторам, которые должны достигнуть консенсуса через определенный механизм по транзакциям внутри блока и их порядку, для чего используется механизм консенсуса Tower BFT.
) Механизм согласования Tower BFT
Протокол консенсуса Tower BFT основан на алгоритме консенсуса BFT и является его конкретной инженерной реализацией, при этом этот алгоритм все еще связан с алгоритмом POH. Когда происходит голосование по блоку, если голосование валидатора само по себе является транзакцией, то хэш блока, сформированный транзакцией пользователя и транзакцией валидатора, также может служить историческим доказательством, благодаря чему детали транзакции пользователя и детали голосования валидатора могут быть уникально подтверждены.
![Снова разбираем архитектуру технологий Solana: ждет ли нас второе весеннее пробуждение?]###https://img-cdn.gateio.im/webp-social/moments-c210b4025cb64385890634a405838d05.webp(
В алгоритме Tower BFT предусмотрено, что если все валидаторы голосуют за этот блок и более 2/3 валидаторов проголосовали за одобрение, тогда этот блок может быть подтвержден. Преимуществом этого механизма является экономия большого объема памяти, так как для подтверждения блока достаточно голосовать только за хэш-последовательность. Однако в традиционных механизмах консенсуса обычно используется затопление блока, то есть один валидатор, получив блок, отправляет его окружающим валидаторам, что приводит к значительному избыточному трафику в сети, так как один валидатор получает один и тот же блок более одного раза.
В Solana, из-за большого количества валидаторов, голосующих за транзакции, а также благодаря централизации узлов лидеров и времени слота в 400 мс, это приводит к тому, что общий размер блока и частота создания блоков особенно высоки. При распространении больших блоков это также создает значительное давление на сеть. Solana использует механизм Turbine для решения проблемы распространения больших блоков.
) Турбина
Лидер-узел делит блоки на подблоки, называемые shreds, в процессе, известном как Sharding. Размер этих подблоков соответствует максимальному размеру передачи MTU###, что позволяет отправлять максимальный объем данных ( от одного узла к следующему без необходимости делить его на более мелкие единицы. Затем с помощью схемы кодирования Reed-Solomon обеспечивается целостность и доступность данных.
Разделяя блоки на четыре Data Shreds, и затем для предотвращения потерь и повреждений данных во время передачи используется кодирование Рида-Соломона для кодирования четырех пакетов в восемь, эта схема может терпеть до 50% уровня потерь пакетов. В реальных тестах уровень потерь пакетов Solana составляет примерно 15%, поэтому эта схема хорошо совместима с текущей архитектурой Solana.
В базовой передаче данных обычно рассматриваются протоколы UDP/TCP. Поскольку Solana имеет высокую устойчивость к потере пакетов, для передачи используется протокол UDP, который, однако, имеет недостаток в том, что потерянные пакеты не будут повторно переданы, но его преимуществом является более высокая скорость передачи. Напротив, протокол TCP будет многократно повторно передавать данные при потере пакетов, что значительно снижает скорость передачи и пропускную способность. С появлением Reed-Solomon эта схема может значительно увеличить пропускную способность Solana, в реальных условиях пропускная способность может увеличиться в 9 раз.
![Снова исследуем архитектуру технологии Solana: ждет ли нас второе весеннее пробуждение?])https://img-cdn.gateio.im/webp-social/moments-224796bc8e080649730bb8736334abba.webp(
После разбиения данных Turbine использует многослойный механизм распространения. Узел-лидер передает блок любому валидатору блока до окончания каждого слота, затем этот валидатор разбивает блок на Shreds и генерирует код исправления ошибок. После этого валидатор начинает распространение Turbine. Сначала нужно распространить данные до корневого узла, затем этот корневой узел определяет, какие валидаторы находятся на каком уровне. Процесс показан ниже:
Создание списка узлов: корневой узел собирает всех активных валидаторов в один список, а затем сортирует их по количеству SOL, которое они ставят в сети ), то есть по их доле (. Узлы с более высоким весом находятся на первом уровне, и так далее.
Группировка узлов: затем каждый валидатор, находящийся на первом уровне, также создаст собственный список узлов, чтобы построить свой собственный первый уровень.
Формирование слоев: Разделите узлы на слои от верхней части списка, определив два значения: глубину и ширину, что позволит определить общую форму дерева. Этот параметр будет влиять на скорость распространения shreds.
У узлов с высокой долей прав на участие, при делении на уровни, будет возможность находиться на более высоком уровне, что позволит им заранее получить полные фрагменты (shreds). В этот момент можно восстановить полный блок, тогда как узлы на более низких уровнях, из-за потерь при передаче, будут иметь меньшую вероятность получения полных фрагментов. Если этих фрагментов недостаточно для построения полного блока, лидеру потребуется заново передать данные. В этом случае передача данных будет происходить внутрь дерева, а узлы первого уровня уже давно создали полное подтверждение блока, поэтому время, необходимое для голосования после завершения построения блока последующими валидаторами, будет только увеличиваться.
Идея этой механики аналогична механике одного узла для Leader-узлов. В процессе распространения блоков также существуют некоторые приоритетные узлы, которые первыми получают фрагменты shreds для формирования полного блока с целью достижения голосования и консенсуса. Углубление избыточности может значительно ускорить процесс финализации и максимизировать пропускную способность и эффективность. Поскольку на самом деле первые несколько уровней могут представлять уже 2/3 узлов, дальнейшее голосование узлов становится несущественным.
) СВМ
Solana может обрабатывать тысячи транзакций в секунду, что в основном обусловлено его механизмом POH, консенсусом Tower BFT и механизмом передачи данных Turbine. Однако, поскольку SVM является виртуальной машиной для состояния перехода, если лидер-узел медленно обрабатывает транзакции, это приведет к снижению пропускной способности всей системы. Поэтому для SVM Solana предложила движок параллельного выполнения Sealevel, чтобы ускорить выполнение транзакций.
![Еще раз о технической архитектуре Solana: ждет ли нас второе весеннее пробуждение?]###https://img-cdn.gateio.im/webp-social/moments-46a028270f3c2da92e7056c17c1d9e16.webp(
В SVM инструкции состоят из 4 частей, включая ID программы, инструкции программы и список аккаунтов для чтения/записи данных. Определив, находится ли текущий аккаунт в состоянии чтения или записи, а также есть ли конфликты в операциях, которые необходимо изменить состояние, можно разрешить параллелизацию в транзакционных инструкциях аккаунта, где нет конфликтов по состоянию, каждая инструкция обозначается ID программы. И это одна из причин, почему требования к валидаторам Solana так высоки, поскольку от валидаторов требуется, чтобы их GPU/CPU поддерживали SIMD) одноинструкционную многоданные( и возможности AVX для расширения векторных операций.
Экологическое развитие
В процессе текущего развития экосистемы Solana все больше внимания уделяется практической полезности, такой как Blinks и Actions, а также Solana Mobile. Официальная поддержка направлена на развитие потребительских приложений, а не на бесконечное углубление инфраструктуры. При достаточной производительности Solana разнообразие приложений становится более богатым. Что касается Ethereum, то из-за низкого TPS экосистема Ethereum по-прежнему сосредоточена на инфраструктуре и технологиях масштабирования. Когда инфраструктура не может поддерживать приложения, невозможно создавать потребительские приложения, что приводит к несбалансированному состоянию, когда слишком много инвестиций идет в инфраструктуру, а слишком мало — в приложения.
) DeFi
В DeFi-протоколах на Solana существует множество проектов, которые еще не выпустили токены, включая Kamino### Первое кредитование(, Marginfi) Кредитование + Рестейкинг(, SoLayer) Рестейкинг(, Meteora и другие. Благодаря единой экосистеме Solana, как правило, один проект старается избегать даты выпуска токенов других проектов, чтобы привлечь достаточно внимания на рынке.
В настоящее время конкуренция на всем DEX-рынке очень высока, и его лидеры несколько раз менялись: от Raydium, Orca до текущего доминирующего DEX.
Стоит отметить, что около 50% сделок на DEX осуществляются с помощью MEV-ботов.