Анализ технологической архитектуры Solana: высокие показатели производительности и существующие вызовы. Экосистема сталкивается с новыми возможностями для развития.
Переосмысление архитектуры 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, быстро увеличивает количество активных адресов на своем блокчейне. В то же время, хотя общий объем заблокированных средств (TVL) в области DeFi Solana достиг исторического максимума, такие конкуренты, как одна торговая платформа, также быстро завоевывают долю рынка, и объем финансирования экосистемы одной торговой платформы впервые в квартале Q2 превысил Solana.
Несмотря на то, что Solana добилась определенных успехов в техническом плане и в принятии на рынке, ей необходимо постоянно innovировать и улучшаться, чтобы справляться с вызовами со стороны таких конкурентов, как некоторые торговые платформы. В частности, в таких областях, как повышение стабильности сети, снижение уровня неудачных транзакций, решение проблемы 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 создается лидер-узел, который собирает транзакции, сортирует их и выполняет, генерируя последовательность POH, после чего создается блок, который распространяется на другие узлы.
Чтобы избежать возникновения единой точки отказа на узле Leader, было введено ограничение по времени. В Solana единицей времени является эпоха, каждая эпоха содержит 432,000 слотов, каждый слот длится 400 мс. В каждом слоте система ротации назначает узел Leader, который должен опубликовать блок в течение установленного времени слота (400 мс), в противном случае слот будет пропущен, и будет проведена повторная выборка узла Leader для следующего слота.
В общем, узлы-лидеры, использующие механизм POH, могут зафиксировать все исторические транзакции. Основная единица времени в Solana — это слот, узел-лидер должен транслировать блок в течение одного слота. Пользователи отправляют транзакции узлу RPC, который передает их узлу-лидеру, узел-лидер упаковывает и сортирует транзакции, а затем выполняет их, создавая блок, который распространяется среди других валидаторов. Валидаторы должны достичь консенсуса по транзакциям и их порядку в блоке с помощью механизма, который использует консенсус Tower BFT.
Механизм консенсуса ### Tower BFT
Протокол согласия Tower BFT основан на алгоритме согласия BFT и является его конкретной инженерной реализацией, этот алгоритм все еще связан с алгоритмом POH. При голосовании за блок, если голосование валидатора само по себе является транзакцией, то хэш блока, сформированный транзакцией пользователя и транзакцией валидатора, также может служить историческим доказательством, детали транзакции какого пользователя и детали голосования какого валидатора могут быть уникально подтверждены.
В алгоритме Tower BFT предусмотрено, что если все валидаторы голосуют за этот блок и более 2/3 валидаторов проголосовали за одобрение, то этот блок может быть утвержден. Преимущество этого механизма заключается в экономии значительного объема памяти, так как для подтверждения блока достаточно голосовать только за хэш-секвенцию. Однако в традиционных механизмах консенсуса обычно используется широковещательная передача блоков, то есть когда один валидатор получает блок, он отправляет его окружающим валидаторам, что приводит к значительному избыточному трафику в сети, так как один валидатор получает один и тот же блок не один раз.
В Solana, из-за большого количества голосований валидаторов и высокой эффективности, вызванной централизованностью узлов Leader и временем слота в 400 мс, общий размер блока и частота выпуска блоков особенно высоки. При распространении больших блоков это также создает значительное давление на сеть. Solana использует механизм Turbine для решения проблемы распространения больших блоков.
Турбина
Лидирующий узел разбивает блоки на подблоки, называемые шредами, с помощью процесса, называемого шардированием, размер которых специфицирован в единицах MTU (максимальный размер передаваемого пакета, максимальный объем данных, который можно передать от одного узла к следующему без необходимости делить на более мелкие единицы). Затем для обеспечения целостности и доступности данных используется схема кодирования Рида-Соломона.
Разделяя блоки на четыре Data Shreds и используя кодирование Рида-Соломона для кодирования четырех пакетов в восемь пакетов, чтобы предотвратить потерю и повреждение данных во время передачи, эта схема может выдержать до 50% потерь пакетов. В реальных тестах уровень потерь пакетов в Solana составляет около 15%, поэтому эта схема хорошо совместима с текущей архитектурой Solana.
В нижнем уровне передачи данных обычно рассматриваются протоколы UDP/TCP. Поскольку Solana имеет высокую терпимость к потерям пакетов, для передачи используется протокол UDP. Его недостатком является то, что при потере пакетов повторная передача не осуществляется, но его преимуществом является более высокая скорость передачи. Напротив, протокол TCP будет многократно повторно передавать данные при потере пакетов, что значительно снижает скорость передачи и пропускную способность. С появлением Reed-Solomon эта схема может значительно увеличить пропускную способность Solana; в реальных условиях пропускная способность может увеличиться в 9 раз.
После того как Turbine разделит данные на фрагменты, он использует многоуровочный механизм распространения. Узел-лидер передаст блок любому валидатору блока до окончания каждого слота, после чего этот валидатор разобьет блок на Shreds и сгенерирует код исправления ошибок. Затем этот валидатор инициирует распространение Turbine. Сначала нужно распространить данные до корневого узла, после чего этот корневой узел определит, какие валидаторы находятся на каком уровне. Процесс выглядит следующим образом:
Создание списка узлов: корневой узел собирает всех активных валидаторов в один список, а затем сортирует их в зависимости от доли каждого валидатора в сети (то есть от количества заложенных SOL), при этом узлы с более высоким весом находятся на первом уровне и так далее.
Группировка узлов: затем каждый валидатор, находящийся на первом уровне, также создаст свой собственный список узлов, чтобы построить свой собственный первый уровень.
Формирование уровней: Разделите узлы на уровни от верхней части списка, определив два значения - глубину и ширину, чтобы установить приблизительную форму всего дерева. Этот параметр влияет на скорость распространения шредов.
Узлы с высоким уровнем доли прав имеют возможность на более высоком уровне иерархии, поэтому они могут заранее получить полные shreds, что позволяет восстановить полный блок. Узлы на более низких уровнях, из-за потерь при передаче, имеют меньшую вероятность получения полных shreds. Если этих shreds недостаточно для построения полного фрагмента, то требуется, чтобы лидер повторно передал данные. В этом случае передача данных будет происходить внутрь дерева, а узлы первого уровня уже построили полное подтверждение блока, и тем больше времени пройдет до голосования валидаторов на нижних уровнях после завершения построения блока.
Идея этой системы аналогична механизму единого узла в узловом механизме Leader. В процессе распространения блоков также существуют некоторые приоритетные узлы, которые первыми получают фрагменты shreds для формирования полного блока с целью достижения консенсуса голосования. Углубление избыточности может значительно ускорить процесс окончательности и максимизировать пропускную способность и эффективность. Поскольку на самом деле первые несколько уровней могут представлять собой 2/3 узлов, голосование последующих узлов становится несущественным.
СВМ
Solana может обрабатывать тысячи транзакций в секунду, что обусловлено ее механизмом POH, консенсусом Tower BFT и механизмом распространения данных Turbine. Однако, SVM, выступая в качестве виртуальной машины для состояния переходов, может снизить общую пропускную способность системы, если скорость обработки SVM оказывается медленной во время выполнения транзакций узлом Leader. Поэтому для SVM Solana предложила параллельный движок выполнения Sealevel для ускорения выполнения транзакций.
В SVM инструкции состоят из 4 частей, включая ID программы, инструкции программы и список аккаунтов для чтения/записи данных. Определив, находится ли текущий аккаунт в состоянии чтения или записи, а также есть ли конфликты в операциях, которые должны изменить состояние, можно разрешить параллелизацию транзакционных инструкций аккаунта, где нет конфликтов, при этом каждая инструкция представляется через Program ID. Это также одна из причин, по которой требования к валидаторам Solana очень высоки, так как требуется, чтобы GPU/CPU валидатора поддерживали SIMD (одна инструкция, множество данных) и AVX.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
13 Лайков
Награда
13
5
Поделиться
комментарий
0/400
FancyResearchLab
· 07-30 11:46
Снова изучаешь какую-то навороченную функцию, мне за твой Кошелек так обидно.
Посмотреть ОригиналОтветить0
FundingMartyr
· 07-28 11:16
вера в sol запустила то, что принадлежит
Посмотреть ОригиналОтветить0
FarmHopper
· 07-28 11:15
sol пришел!
Посмотреть ОригиналОтветить0
ChainSauceMaster
· 07-28 11:13
sol действительно хорош
Посмотреть ОригиналОтветить0
LuckyBlindCat
· 07-28 11:11
Это можно назвать второй весной? Похоже, вы зашли слишком далеко.
Анализ технологической архитектуры Solana: высокие показатели производительности и существующие вызовы. Экосистема сталкивается с новыми возможностями для развития.
Переосмысление архитектуры 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, быстро увеличивает количество активных адресов на своем блокчейне. В то же время, хотя общий объем заблокированных средств (TVL) в области DeFi Solana достиг исторического максимума, такие конкуренты, как одна торговая платформа, также быстро завоевывают долю рынка, и объем финансирования экосистемы одной торговой платформы впервые в квартале Q2 превысил Solana.
Несмотря на то, что Solana добилась определенных успехов в техническом плане и в принятии на рынке, ей необходимо постоянно innovировать и улучшаться, чтобы справляться с вызовами со стороны таких конкурентов, как некоторые торговые платформы. В частности, в таких областях, как повышение стабильности сети, снижение уровня неудачных транзакций, решение проблемы 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 создается лидер-узел, который собирает транзакции, сортирует их и выполняет, генерируя последовательность POH, после чего создается блок, который распространяется на другие узлы.
Чтобы избежать возникновения единой точки отказа на узле Leader, было введено ограничение по времени. В Solana единицей времени является эпоха, каждая эпоха содержит 432,000 слотов, каждый слот длится 400 мс. В каждом слоте система ротации назначает узел Leader, который должен опубликовать блок в течение установленного времени слота (400 мс), в противном случае слот будет пропущен, и будет проведена повторная выборка узла Leader для следующего слота.
В общем, узлы-лидеры, использующие механизм POH, могут зафиксировать все исторические транзакции. Основная единица времени в Solana — это слот, узел-лидер должен транслировать блок в течение одного слота. Пользователи отправляют транзакции узлу RPC, который передает их узлу-лидеру, узел-лидер упаковывает и сортирует транзакции, а затем выполняет их, создавая блок, который распространяется среди других валидаторов. Валидаторы должны достичь консенсуса по транзакциям и их порядку в блоке с помощью механизма, который использует консенсус Tower BFT.
Механизм консенсуса ### Tower BFT
Протокол согласия Tower BFT основан на алгоритме согласия BFT и является его конкретной инженерной реализацией, этот алгоритм все еще связан с алгоритмом POH. При голосовании за блок, если голосование валидатора само по себе является транзакцией, то хэш блока, сформированный транзакцией пользователя и транзакцией валидатора, также может служить историческим доказательством, детали транзакции какого пользователя и детали голосования какого валидатора могут быть уникально подтверждены.
В алгоритме Tower BFT предусмотрено, что если все валидаторы голосуют за этот блок и более 2/3 валидаторов проголосовали за одобрение, то этот блок может быть утвержден. Преимущество этого механизма заключается в экономии значительного объема памяти, так как для подтверждения блока достаточно голосовать только за хэш-секвенцию. Однако в традиционных механизмах консенсуса обычно используется широковещательная передача блоков, то есть когда один валидатор получает блок, он отправляет его окружающим валидаторам, что приводит к значительному избыточному трафику в сети, так как один валидатор получает один и тот же блок не один раз.
В Solana, из-за большого количества голосований валидаторов и высокой эффективности, вызванной централизованностью узлов Leader и временем слота в 400 мс, общий размер блока и частота выпуска блоков особенно высоки. При распространении больших блоков это также создает значительное давление на сеть. Solana использует механизм Turbine для решения проблемы распространения больших блоков.
Турбина
Лидирующий узел разбивает блоки на подблоки, называемые шредами, с помощью процесса, называемого шардированием, размер которых специфицирован в единицах MTU (максимальный размер передаваемого пакета, максимальный объем данных, который можно передать от одного узла к следующему без необходимости делить на более мелкие единицы). Затем для обеспечения целостности и доступности данных используется схема кодирования Рида-Соломона.
Разделяя блоки на четыре Data Shreds и используя кодирование Рида-Соломона для кодирования четырех пакетов в восемь пакетов, чтобы предотвратить потерю и повреждение данных во время передачи, эта схема может выдержать до 50% потерь пакетов. В реальных тестах уровень потерь пакетов в Solana составляет около 15%, поэтому эта схема хорошо совместима с текущей архитектурой Solana.
В нижнем уровне передачи данных обычно рассматриваются протоколы UDP/TCP. Поскольку Solana имеет высокую терпимость к потерям пакетов, для передачи используется протокол UDP. Его недостатком является то, что при потере пакетов повторная передача не осуществляется, но его преимуществом является более высокая скорость передачи. Напротив, протокол TCP будет многократно повторно передавать данные при потере пакетов, что значительно снижает скорость передачи и пропускную способность. С появлением Reed-Solomon эта схема может значительно увеличить пропускную способность Solana; в реальных условиях пропускная способность может увеличиться в 9 раз.
После того как Turbine разделит данные на фрагменты, он использует многоуровочный механизм распространения. Узел-лидер передаст блок любому валидатору блока до окончания каждого слота, после чего этот валидатор разобьет блок на Shreds и сгенерирует код исправления ошибок. Затем этот валидатор инициирует распространение Turbine. Сначала нужно распространить данные до корневого узла, после чего этот корневой узел определит, какие валидаторы находятся на каком уровне. Процесс выглядит следующим образом:
Создание списка узлов: корневой узел собирает всех активных валидаторов в один список, а затем сортирует их в зависимости от доли каждого валидатора в сети (то есть от количества заложенных SOL), при этом узлы с более высоким весом находятся на первом уровне и так далее.
Группировка узлов: затем каждый валидатор, находящийся на первом уровне, также создаст свой собственный список узлов, чтобы построить свой собственный первый уровень.
Формирование уровней: Разделите узлы на уровни от верхней части списка, определив два значения - глубину и ширину, чтобы установить приблизительную форму всего дерева. Этот параметр влияет на скорость распространения шредов.
Узлы с высоким уровнем доли прав имеют возможность на более высоком уровне иерархии, поэтому они могут заранее получить полные shreds, что позволяет восстановить полный блок. Узлы на более низких уровнях, из-за потерь при передаче, имеют меньшую вероятность получения полных shreds. Если этих shreds недостаточно для построения полного фрагмента, то требуется, чтобы лидер повторно передал данные. В этом случае передача данных будет происходить внутрь дерева, а узлы первого уровня уже построили полное подтверждение блока, и тем больше времени пройдет до голосования валидаторов на нижних уровнях после завершения построения блока.
Идея этой системы аналогична механизму единого узла в узловом механизме Leader. В процессе распространения блоков также существуют некоторые приоритетные узлы, которые первыми получают фрагменты shreds для формирования полного блока с целью достижения консенсуса голосования. Углубление избыточности может значительно ускорить процесс окончательности и максимизировать пропускную способность и эффективность. Поскольку на самом деле первые несколько уровней могут представлять собой 2/3 узлов, голосование последующих узлов становится несущественным.
СВМ
Solana может обрабатывать тысячи транзакций в секунду, что обусловлено ее механизмом POH, консенсусом Tower BFT и механизмом распространения данных Turbine. Однако, SVM, выступая в качестве виртуальной машины для состояния переходов, может снизить общую пропускную способность системы, если скорость обработки SVM оказывается медленной во время выполнения транзакций узлом Leader. Поэтому для SVM Solana предложила параллельный движок выполнения Sealevel для ускорения выполнения транзакций.
В SVM инструкции состоят из 4 частей, включая ID программы, инструкции программы и список аккаунтов для чтения/записи данных. Определив, находится ли текущий аккаунт в состоянии чтения или записи, а также есть ли конфликты в операциях, которые должны изменить состояние, можно разрешить параллелизацию транзакционных инструкций аккаунта, где нет конфликтов, при этом каждая инструкция представляется через Program ID. Это также одна из причин, по которой требования к валидаторам Solana очень высоки, так как требуется, чтобы GPU/CPU валидатора поддерживали SIMD (одна инструкция, множество данных) и AVX.