Повторный анализ технической архитектуры 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 достигла значительной доли рынка в индустрии блокчейна благодаря высокой пропускной способности и низким транзакционным издержкам, она также сталкивается с жесткой конкуренцией со стороны других новых публичных цепей. Определенная торговая платформа, являющаяся потенциальным соперником в экосистеме EVM, быстро увеличивает количество активных адресов на своей цепи. В то же время, общий объем заблокированных средств в DeFi Solana, (TVL), хотя и достиг исторического максимума, но такие конкуренты, как определенная торговая платформа, также быстро захватывают долю рынка, и объем финансирования экосистемы определенной торговой платформы впервые в 2 квартале превысил Solana.
Несмотря на то, что Solana достигла определенных успехов в техническом и рыночном признании, ей необходимо постоянно innovar и улучшаться, чтобы справляться с вызовами от конкурентов, таких как определенные торговые платформы. Особенно в таких областях, как повышение стабильности сети, снижение уровня неудачных сделок, решение проблем MEV и замедление роста состояния, Solana необходимо продолжать оптимизировать свою техническую архитектуру и сетевые протоколы, чтобы сохранить свои лидирующие позиции в блокчейн-индустрии.
Техническая архитектура
Solana известна своим алгоритмом POH, механизмом согласования Tower BFT, а также сетью передачи данных Trubine и виртуальной машиной SVM, которые обеспечивают высокую TPS и быструю финализацию. Мы кратко представим, как работают ее различные компоненты, как они достигают целей высокой производительности в архитектурном проектировании, а также недостатки и возникающие проблемы, связанные с этой архитектурой.
алгоритм POH
POH(Доказательство истории) — это технология, определяющая глобальное время, которая не является механизмом согласия, а представляет собой алгоритм для определения порядка транзакций. Технология POH основана на основной криптографической технологии SHA256. SHA256 обычно используется для вычисления целостности данных: данное значение X всегда имеет уникальный выход Y, и любое изменение этого X приведет к совершенно другому Y.
В последовательности POH Solana, применение алгоритма sha256 позволяет обеспечить целостность всей последовательности, что также подтверждает целостность сделок в ней. Например, если мы упакуем сделки в блок и сгенерируем соответствующее значение hash sha256, то сделки в этом блоке будут подтверждены, любое изменение приведет к изменению значения 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 должен транслировать блок в рамках одного слота. Пользователи передают транзакции узлу 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, из-за большого количества транзакций, связанных с голосованием валидаторов, а также высокой эффективности, обусловленной централизацией узлов Leader и временем слота в 400 мс, это приводит к особенно высокому общему размеру блока и частоте формирования блоков. Большие блоки при распространении также создают значительное давление на сеть, и Solana использует механизм Turbine для решения проблемы распространения больших блоков.
) Турбина
Лидер-узел разбивает блоки на подблоки, называемые shreds, с помощью процесса, известного как Sharding. Размеры этих подблоков соответствуют MTU###, максимальному объему данных, который может быть отправлен от одного узла к следующему без необходимости разбивать его на более мелкие единицы, равному (. Затем для обеспечения целостности и доступности данных используется схема кодирования Reed-Solomon.
Разделяя блоки на четыре 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. Сначала нужно распространить информацию до корневого узла, затем этот корневой узел определит, какие валидаторы находятся на каком уровне. Процесс показан ниже:
Создание списка узлов: корневой узел собирает всех активных валидаторов в один список, затем сортирует их по доле каждого валидатора в сети ), то есть по количеству заложенного SOL (, с более высоким весом, расположенным на первом уровне, и так далее.
Группировка узлов: затем каждый валидатор, находящийся на первом уровне, также создаст свой собственный список узлов, чтобы построить свой собственный первый уровень.
Формирование слоев: Разделите узлы на слои от верхней части списка, определив два значения: глубину и ширину, можно установить общую форму всего дерева, этот параметр повлияет на скорость распространения шредов.
У узлов с высокой долей прав, при делении на уровни, на более высоком уровне, будет возможность заранее получить полные шреды, в этом случае можно восстановить полный блок. Узлы на более низком уровне, из-за потерь при передаче, будут иметь меньшую вероятность получения полных шредов. Если этих шредов недостаточно для построения полного фрагмента, Leader будет запрашивать повторную передачу. В этот момент передача данных будет происходить внутрь дерева, а узлы первого уровня уже давно построили полное подтверждение блока, тем временем, чем дольше займет голосование после завершения построения блока валидаторами более низкого уровня.
Идея этой системы аналогична механизму одиночного узла в узле Leader. В процессе распространения блоков также существуют некоторые приоритетные узлы, которые первыми получают фрагменты 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 частей, включая ID программы, инструкции программы и список аккаунтов для чтения/записи данных. Определив, находится ли текущий аккаунт в состоянии чтения или записи, и есть ли конфликты с операциями, которые необходимо изменить, можно разрешить параллелизацию инструкций транзакции аккаунта, где нет конфликтов со статусом, каждая инструкция представляется с помощью Program ID. Именно поэтому требования к валидаторам Solana так высоки, поскольку требуется, чтобы GPU/CPU валидаторов поддерживали SIMD) однокомандные многоданные( и возможности AVX для расширения высоких векторов.
Экологическое развитие
В процессе развития текущей экосистемы Solana все больше акцентируется внимание на практической полезности, такой как Blinks и Actions, а также Solana Mobile, и направление развития приложений, поддерживаемое официально, также
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
25 Лайков
Награда
25
7
Репост
Поделиться
комментарий
0/400
FlyingLeek
· 08-16 08:29
sol опять хочет большой памп?
Посмотреть ОригиналОтветить0
NervousFingers
· 08-15 01:45
Так быстро бегать, значит, продать.
Посмотреть ОригиналОтветить0
MemeTokenGenius
· 08-13 22:07
Новая волна пришла, не верю, что sol сможет подняться.
Глубина анализа технологической архитектуры Solana: вызовы и возможности за высоким TPS
Повторный анализ технической архитектуры 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 достигла значительной доли рынка в индустрии блокчейна благодаря высокой пропускной способности и низким транзакционным издержкам, она также сталкивается с жесткой конкуренцией со стороны других новых публичных цепей. Определенная торговая платформа, являющаяся потенциальным соперником в экосистеме EVM, быстро увеличивает количество активных адресов на своей цепи. В то же время, общий объем заблокированных средств в DeFi Solana, (TVL), хотя и достиг исторического максимума, но такие конкуренты, как определенная торговая платформа, также быстро захватывают долю рынка, и объем финансирования экосистемы определенной торговой платформы впервые в 2 квартале превысил Solana.
Несмотря на то, что Solana достигла определенных успехов в техническом и рыночном признании, ей необходимо постоянно innovar и улучшаться, чтобы справляться с вызовами от конкурентов, таких как определенные торговые платформы. Особенно в таких областях, как повышение стабильности сети, снижение уровня неудачных сделок, решение проблем MEV и замедление роста состояния, Solana необходимо продолжать оптимизировать свою техническую архитектуру и сетевые протоколы, чтобы сохранить свои лидирующие позиции в блокчейн-индустрии.
Техническая архитектура
Solana известна своим алгоритмом POH, механизмом согласования Tower BFT, а также сетью передачи данных Trubine и виртуальной машиной SVM, которые обеспечивают высокую TPS и быструю финализацию. Мы кратко представим, как работают ее различные компоненты, как они достигают целей высокой производительности в архитектурном проектировании, а также недостатки и возникающие проблемы, связанные с этой архитектурой.
алгоритм POH
POH(Доказательство истории) — это технология, определяющая глобальное время, которая не является механизмом согласия, а представляет собой алгоритм для определения порядка транзакций. Технология POH основана на основной криптографической технологии SHA256. SHA256 обычно используется для вычисления целостности данных: данное значение X всегда имеет уникальный выход Y, и любое изменение этого X приведет к совершенно другому Y.
В последовательности POH Solana, применение алгоритма sha256 позволяет обеспечить целостность всей последовательности, что также подтверждает целостность сделок в ней. Например, если мы упакуем сделки в блок и сгенерируем соответствующее значение hash sha256, то сделки в этом блоке будут подтверждены, любое изменение приведет к изменению значения 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 должен транслировать блок в рамках одного слота. Пользователи передают транзакции узлу 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, из-за большого количества транзакций, связанных с голосованием валидаторов, а также высокой эффективности, обусловленной централизацией узлов Leader и временем слота в 400 мс, это приводит к особенно высокому общему размеру блока и частоте формирования блоков. Большие блоки при распространении также создают значительное давление на сеть, и Solana использует механизм Turbine для решения проблемы распространения больших блоков.
) Турбина
Лидер-узел разбивает блоки на подблоки, называемые shreds, с помощью процесса, известного как Sharding. Размеры этих подблоков соответствуют MTU###, максимальному объему данных, который может быть отправлен от одного узла к следующему без необходимости разбивать его на более мелкие единицы, равному (. Затем для обеспечения целостности и доступности данных используется схема кодирования Reed-Solomon.
Разделяя блоки на четыре 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. Сначала нужно распространить информацию до корневого узла, затем этот корневой узел определит, какие валидаторы находятся на каком уровне. Процесс показан ниже:
Создание списка узлов: корневой узел собирает всех активных валидаторов в один список, затем сортирует их по доле каждого валидатора в сети ), то есть по количеству заложенного SOL (, с более высоким весом, расположенным на первом уровне, и так далее.
Группировка узлов: затем каждый валидатор, находящийся на первом уровне, также создаст свой собственный список узлов, чтобы построить свой собственный первый уровень.
Формирование слоев: Разделите узлы на слои от верхней части списка, определив два значения: глубину и ширину, можно установить общую форму всего дерева, этот параметр повлияет на скорость распространения шредов.
У узлов с высокой долей прав, при делении на уровни, на более высоком уровне, будет возможность заранее получить полные шреды, в этом случае можно восстановить полный блок. Узлы на более низком уровне, из-за потерь при передаче, будут иметь меньшую вероятность получения полных шредов. Если этих шредов недостаточно для построения полного фрагмента, Leader будет запрашивать повторную передачу. В этот момент передача данных будет происходить внутрь дерева, а узлы первого уровня уже давно построили полное подтверждение блока, тем временем, чем дольше займет голосование после завершения построения блока валидаторами более низкого уровня.
Идея этой системы аналогична механизму одиночного узла в узле Leader. В процессе распространения блоков также существуют некоторые приоритетные узлы, которые первыми получают фрагменты 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 частей, включая ID программы, инструкции программы и список аккаунтов для чтения/записи данных. Определив, находится ли текущий аккаунт в состоянии чтения или записи, и есть ли конфликты с операциями, которые необходимо изменить, можно разрешить параллелизацию инструкций транзакции аккаунта, где нет конфликтов со статусом, каждая инструкция представляется с помощью Program ID. Именно поэтому требования к валидаторам Solana так высоки, поскольку требуется, чтобы GPU/CPU валидаторов поддерживали SIMD) однокомандные многоданные( и возможности AVX для расширения высоких векторов.
Экологическое развитие
В процессе развития текущей экосистемы Solana все больше акцентируется внимание на практической полезности, такой как Blinks и Actions, а также Solana Mobile, и направление развития приложений, поддерживаемое официально, также