Solana уже достаточно быстрая, объем уже достаточно большой. Так действительно "достаточно"?
Когда мы рассматриваем эти сделки, возникает вопрос: действительно ли все эти сделки создают ценность?
Объем торгов Solana не является результатом реального спроса на торговлю, а связан с высокочастотными арбитражниками, использующими миллисекундные информационные различия для получения прибыли. Эти "токсичные трейдеры" (Toxic-takers) используют свои технические преимущества, чтобы увеличить Gas, когда маркет-мейкеры (Maker) собираются отменить ордер, обеспечивая приоритет своей сделке и совершая арбитраж, что приводит к потерям для маркет-мейкеров. Чтобы компенсировать убытки, маркет-мейкеры вынуждены увеличивать спред.
В конечном итоге, обычные пользователи расплачиваются за это. Solana всегда мечтала реализовать на блокчейне книгу заказов, заменив централизованные биржи (CEX). Но таким образом, "токсичные трейдеры" стали препятствием на пути к осуществлению мечты. Это новая проблема, с которой сталкивается Solana: объем ≠ ликвидность. Настоящий здоровый рынок требует не большего количества сделок, а лучших сделок.
Как можно исключить токсичные сделки и лучше защитить ликвидность?
В текущей системе участники, принимающие ордера (Takers), благодаря периодическому механизму аукционов консенсуса Solana, имеют фактическое преимущество, что позволяет злонамеренному MEV влиять на честность рынка.
Как понять?
В текущем согласии Solana каждую временную единицу Slot транзакции сортируются по приоритету Gas-расходов. Кто предлагает больше, тот и выполняет свою транзакцию первым. Этот аукцион периодический, каждые 400 миллисекунд происходит новый Slot.
В этом процессе маркетмейкеры должны часто корректировать котировки, отменять ордера и выставлять новые. При изменении рыночной цены необходимо немедленно обновлять.
А те, кто принимает ордера (Taker), особенно высокочастотные арбитражники, следят за ценовыми различиями и сразу же совершают сделки, как только замечают возможность. Таким образом, арбитражники могут заплатить более высокую комиссию, чтобы успеть выполнить сделку до отмены ордера. Это приводит к тому, что маркет-мейкеры часто становятся "мишенями" и несут убытки.
Для ордерной книги DEX идеальной сортировкой должно быть следующее: сначала выполнять все отмены, затем новые ордера, и, наконец, сделки, по мере колебания цен. Это то, чего в настоящее время не может достичь консенсус Solana на микроуровне.
Аналогично и на уровне котировок оракула, идеальная ситуация заключается в том, чтобы сначала обновить цену оракула, а затем выполнить сделки, зависящие от этой цены. Однако в настоящее время в течение 400 миллисекунд интервала ситуация на рынке может резко колебаться, что приводит к тому, что сделки все равно заключаются по первоначальной цене.
Для кредитных соглашений лучше сначала внести маржу, а затем проводить ликвидацию.
Поэтому лучше иметь способ, позволяющий различным протоколам сортировать транзакции по мере необходимости, то есть ACE (управление выполнением приложений), на чем постоянно акцентирует внимание Solana.
BAM (Block Assembly Marketplace, рынок сборки блоков) именно ответ Solana.
BAM на блокчейне Solana создал уровень сортировки, или как его называют, уровень предварительной обработки, между приложениями и основной сетью.
Используйте доверенные среды выполнения (Trusted Execution Environments, TEEs) для создания приватного песочницы, в которой согласно заранее определенным правилам сортировки, или FIFO, выполняется сортировка транзакций.
лучше обслуживать книги заказов (CLOBs), биржи perpetual (Perpetual Exchanges), протоколы темных пулов (Dark Pools).
Solana обычно сравнивается с моделями BAM по упаковке сделок.
Как понять, что BAM построил уровень сортировки между приложениями Solana и основной сетью? Сначала давайте сделаем наглядное сравнение.
Нормальный процесс торговли Solana,
1）Пользователь подтверждает транзакцию в кошельке,
Отправка транзакции на RPC узел,
3）RPC отправляет текущему слоту, лидеру узла основной сети Solana,
Лидер собирает транзакции из пула транзакций, сортирует их, упаковывает в блок и транслирует,
Остальные узлы голосуют.
Если какое-либо приложение подключается к BAM, процесс сделки следующий,
1）Пользователь подтверждает транзакцию в кошельке,
2）Отправка сделки на RPC-узел,
Перенос трейдов на сеть BAM, сортировка в TEE-приватности. В процессе узлы могут добавлять дополнительные трейды через плагины, например, обновление цен оракулов, а затем генерировать доказательства,
4）объем данных о сделках отправляется на узел Leader основной сети Solana,
5）Лидер собирает транзакции, собирает пакет данных BAM, затем упаковывает его в блок и распространяет.
Остальные узлы голосуют.
Таким образом, BAM на самом деле не конфликтует с текущим процессом консенсуса основной сети Solana, а представляет собой "опциональность". BAM не работает напрямую в основной сети Solana, а выполняет сортировку транзакций заранее в так называемом "внецепочном" режиме, упаковывая транзакции, а затем отправляя их в основную сеть Solana.
BAM объем сортировка по режиму
BAM поддерживает три режима работы,
1）Solana режим по умолчанию；
2）Block-Engine режим; текущее решение Jito по MEV, основа которого - механизм аукциона.
BAM режим, валидаторы строго следуют порядку FIFO (первый пришёл - первый вышел).
Основные моменты ядра модели BAM следующие:
Достоверные исполняемые среды TEEs: конфиденциальность и справедливость Используя достоверные исполняемые среды TEEs, создайте конфиденциальную среду для сортировки транзакций. Другая сторона конфиденциальности называется справедливостью.
2）Система плагинов Plugin: сложная сортировка. Через систему плагинов BAM позволяет приложениям строить пользовательскую логику сортировки сделок. И эта пользовательская сортировка не означает, что узлы могут сортировать как хотят, а сортируется согласно заранее установленным правилам.
План плагина реализует сложную сортировку сделок, одновременно обеспечивая безопасность среды TEE. В настоящее время он находится на ранней стадии разработки.
Как упоминалось ранее,
Для книги заказов DEX идеальная сортировка должна быть следующей: сначала выполняются все отмены, затем новые ордера, и, наконец, сделки, в зависимости от колебаний цен. Это то, чего в настоящее время не может достичь консенсус Solana на микроуровне.
А на уровне котировок оракулов ситуация такая же: в идеале сначала обновляется цена оракула, а затем выполняются сделки, зависящие от этой цены. Но в текущем интервале в 400 миллисекунд рынок может подвергаться резким колебаниям, что приводит к тому, что сделки могут осуществляться по изначальной цене.
Для кредитных соглашений лучше сначала пополнить залог, а затем проводить ликвидацию. Это фактически реализует функцию управления выполнением приложений ACE.
Так что, что же на самом деле реализовал BAM?
Например,
Защита ликвидации займов
Для кредитных соглашений после обнаружения рисков ликвидации приоритетно выполняются операции по пополнению залога, затем проводится проверка ликвидации.
2）атомарные торговые комбинации
Для DEX сначала обновите цену оракула и выполните сделки, зависящие от этой цены. Если это контрактный DEX, также можно рассчитать соответствующие деривативы. Все вышеперечисленные операции выполняются в один и тот же временной интервал.
3）Защита от колебаний цен
Для DEX, обнаружение аномально больших ордеров, разделение больших ордеров на мелкие части, выполнение поэтапно, чтобы дать рынку время на реакцию, избежать цепной ликвидации или арбитража, что может привести к смертельной спирали.
4）Защита маркет-мейкеров
Произошло чрезвычайное событие, отмена ордера за миллисекунды, оракул обновляет цену, маркет-мейкер выставляет новый ордер. Избегайте злонамеренного арбитража, уменьшите спред.
BAM изначально должен был быть выпущен в конце июля.
Кроме того, с развертыванием BAM опыт торговли на Solana будет значительно улучшен. BAM сделает опыт использования приложений главной сети Solana более близким к CEX.
Таким образом,
BAM принес в процесс обработки транзакций Solana проверяемость, защиту конфиденциальности и программируемость, позволяя разработчикам создавать центральные лимитные ордерные книги (CLOBs), бессрочные биржи (Perpetual Exchanges), темные пулы (Dark Pools) и другую финансовую инфраструктуру, требующую контроля сортировки, детерминированного выполнения и защиты конфиденциальности, тем самым способствуя инновационному развитию экосистемы Solana.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Интерпретация рынка сборки Блоков Solana BAM: когда скорость больше не является единственным стремлением
Solana уже достаточно быстрая, объем уже достаточно большой. Так действительно "достаточно"?
Когда мы рассматриваем эти сделки, возникает вопрос: действительно ли все эти сделки создают ценность?
Объем торгов Solana не является результатом реального спроса на торговлю, а связан с высокочастотными арбитражниками, использующими миллисекундные информационные различия для получения прибыли. Эти "токсичные трейдеры" (Toxic-takers) используют свои технические преимущества, чтобы увеличить Gas, когда маркет-мейкеры (Maker) собираются отменить ордер, обеспечивая приоритет своей сделке и совершая арбитраж, что приводит к потерям для маркет-мейкеров. Чтобы компенсировать убытки, маркет-мейкеры вынуждены увеличивать спред.
В конечном итоге, обычные пользователи расплачиваются за это. Solana всегда мечтала реализовать на блокчейне книгу заказов, заменив централизованные биржи (CEX). Но таким образом, "токсичные трейдеры" стали препятствием на пути к осуществлению мечты. Это новая проблема, с которой сталкивается Solana: объем ≠ ликвидность. Настоящий здоровый рынок требует не большего количества сделок, а лучших сделок.
Как можно исключить токсичные сделки и лучше защитить ликвидность?
В текущей системе участники, принимающие ордера (Takers), благодаря периодическому механизму аукционов консенсуса Solana, имеют фактическое преимущество, что позволяет злонамеренному MEV влиять на честность рынка.
Как понять?
В текущем согласии Solana каждую временную единицу Slot транзакции сортируются по приоритету Gas-расходов. Кто предлагает больше, тот и выполняет свою транзакцию первым. Этот аукцион периодический, каждые 400 миллисекунд происходит новый Slot.
В этом процессе маркетмейкеры должны часто корректировать котировки, отменять ордера и выставлять новые. При изменении рыночной цены необходимо немедленно обновлять.
А те, кто принимает ордера (Taker), особенно высокочастотные арбитражники, следят за ценовыми различиями и сразу же совершают сделки, как только замечают возможность. Таким образом, арбитражники могут заплатить более высокую комиссию, чтобы успеть выполнить сделку до отмены ордера. Это приводит к тому, что маркет-мейкеры часто становятся "мишенями" и несут убытки.
Для ордерной книги DEX идеальной сортировкой должно быть следующее: сначала выполнять все отмены, затем новые ордера, и, наконец, сделки, по мере колебания цен. Это то, чего в настоящее время не может достичь консенсус Solana на микроуровне.
Аналогично и на уровне котировок оракула, идеальная ситуация заключается в том, чтобы сначала обновить цену оракула, а затем выполнить сделки, зависящие от этой цены. Однако в настоящее время в течение 400 миллисекунд интервала ситуация на рынке может резко колебаться, что приводит к тому, что сделки все равно заключаются по первоначальной цене.
Для кредитных соглашений лучше сначала внести маржу, а затем проводить ликвидацию.
Поэтому лучше иметь способ, позволяющий различным протоколам сортировать транзакции по мере необходимости, то есть ACE (управление выполнением приложений), на чем постоянно акцентирует внимание Solana.
BAM (Block Assembly Marketplace, рынок сборки блоков) именно ответ Solana.
BAM на блокчейне Solana создал уровень сортировки, или как его называют, уровень предварительной обработки, между приложениями и основной сетью.
Используйте доверенные среды выполнения (Trusted Execution Environments, TEEs) для создания приватного песочницы, в которой согласно заранее определенным правилам сортировки, или FIFO, выполняется сортировка транзакций.
лучше обслуживать книги заказов (CLOBs), биржи perpetual (Perpetual Exchanges), протоколы темных пулов (Dark Pools).
Solana обычно сравнивается с моделями BAM по упаковке сделок.
Как понять, что BAM построил уровень сортировки между приложениями Solana и основной сетью? Сначала давайте сделаем наглядное сравнение.
Нормальный процесс торговли Solana,
1）Пользователь подтверждает транзакцию в кошельке,
3）RPC отправляет текущему слоту, лидеру узла основной сети Solana,
Лидер собирает транзакции из пула транзакций, сортирует их, упаковывает в блок и транслирует,
Остальные узлы голосуют.
Если какое-либо приложение подключается к BAM, процесс сделки следующий,
1）Пользователь подтверждает транзакцию в кошельке,
2）Отправка сделки на RPC-узел,
4）объем данных о сделках отправляется на узел Leader основной сети Solana,
5）Лидер собирает транзакции, собирает пакет данных BAM, затем упаковывает его в блок и распространяет.
Таким образом, BAM на самом деле не конфликтует с текущим процессом консенсуса основной сети Solana, а представляет собой "опциональность". BAM не работает напрямую в основной сети Solana, а выполняет сортировку транзакций заранее в так называемом "внецепочном" режиме, упаковывая транзакции, а затем отправляя их в основную сеть Solana.
BAM объем сортировка по режиму
BAM поддерживает три режима работы,
1）Solana режим по умолчанию；
2）Block-Engine режим; текущее решение Jito по MEV, основа которого - механизм аукциона.
Основные моменты ядра модели BAM следующие:
2）Система плагинов Plugin: сложная сортировка. Через систему плагинов BAM позволяет приложениям строить пользовательскую логику сортировки сделок. И эта пользовательская сортировка не означает, что узлы могут сортировать как хотят, а сортируется согласно заранее установленным правилам.
План плагина реализует сложную сортировку сделок, одновременно обеспечивая безопасность среды TEE. В настоящее время он находится на ранней стадии разработки.
Как упоминалось ранее,
Для книги заказов DEX идеальная сортировка должна быть следующей: сначала выполняются все отмены, затем новые ордера, и, наконец, сделки, в зависимости от колебаний цен. Это то, чего в настоящее время не может достичь консенсус Solana на микроуровне.
А на уровне котировок оракулов ситуация такая же: в идеале сначала обновляется цена оракула, а затем выполняются сделки, зависящие от этой цены. Но в текущем интервале в 400 миллисекунд рынок может подвергаться резким колебаниям, что приводит к тому, что сделки могут осуществляться по изначальной цене.
Для кредитных соглашений лучше сначала пополнить залог, а затем проводить ликвидацию. Это фактически реализует функцию управления выполнением приложений ACE.
Так что, что же на самом деле реализовал BAM?
Например,
Для кредитных соглашений после обнаружения рисков ликвидации приоритетно выполняются операции по пополнению залога, затем проводится проверка ликвидации.
2）атомарные торговые комбинации
Для DEX сначала обновите цену оракула и выполните сделки, зависящие от этой цены. Если это контрактный DEX, также можно рассчитать соответствующие деривативы. Все вышеперечисленные операции выполняются в один и тот же временной интервал.
3）Защита от колебаний цен
Для DEX, обнаружение аномально больших ордеров, разделение больших ордеров на мелкие части, выполнение поэтапно, чтобы дать рынку время на реакцию, избежать цепной ликвидации или арбитража, что может привести к смертельной спирали.
4）Защита маркет-мейкеров
Произошло чрезвычайное событие, отмена ордера за миллисекунды, оракул обновляет цену, маркет-мейкер выставляет новый ордер. Избегайте злонамеренного арбитража, уменьшите спред.
BAM изначально должен был быть выпущен в конце июля.
Кроме того, с развертыванием BAM опыт торговли на Solana будет значительно улучшен. BAM сделает опыт использования приложений главной сети Solana более близким к CEX.
Таким образом,
BAM принес в процесс обработки транзакций Solana проверяемость, защиту конфиденциальности и программируемость, позволяя разработчикам создавать центральные лимитные ордерные книги (CLOBs), бессрочные биржи (Perpetual Exchanges), темные пулы (Dark Pools) и другую финансовую инфраструктуру, требующую контроля сортировки, детерминированного выполнения и защиты конфиденциальности, тем самым способствуя инновационному развитию экосистемы Solana.
Выше.