Переслать оригинал названия：Solana & Механизмы платы за транзакции в Ethereum: Предложения по улучшению TFM Solana

Спасибо Эндрю Фитцджеральду, Харшу Пателю, Джону Шарбонно, Кевину Галлеру, Ланре Иге, Мерту Мумтазу, Пранаву Гаримиди, Райану Черну, Тао Жу и Таруну Читре за отзывы и рецензии.

Введение

Eclipse - это первая SVM L2 в Ethereum. Мы невероятно рады предоставить мощь существующей SVM большему числу пользователей, но мы также намерены продвигаться вперед по пути R&D вокруг самой SVM. Мы нацелены на то, чтобы развитие Eclipse приносило неоспоримую пользу всем цепочкам SVM, особенно Solana.

В качестве предваряющей статьи к будущим статьям о наших размышлениях о рынках гонораров, в этой статье мы проанализируем существующий рынок гонораров Соланы и связанные с ним предложения по его улучшению. Мы рассматриваем эти предложения наряду с основными теоретическими целями любого механизма взимания платы за транзакции (TFM), в значительной степени заимствуя работы Тима Рафгардена, Марьям Бахрани, Пранава Гаримиди, Хао Чунга, Элейн Ши и других. Мы будем обозначать основные определения **.

В общем, TFM определяет:

1. Какие транзакции включены в данный блок,
2. Комиссионные, которые платит данная транзакция, и
3. Как (и кому) распределяются накопленные комиссионные за транзакции.

В конечном итоге, эта статья призвана объединить богатство исследований в области TFM, ориентированных на Ethereum, с инновационными разработками Solana.

Обзор Solana & Ethereum Текущие TFM.

Основы Solana против Ethereum

Мы начнем с обзора TFM Solana и сравним его с TFM Ethereum. Это позволит лучше осмыслить соответствующие предложения, чтобы мы могли работать над изменением и улучшением TFM. Для начала:

Базовая плата Solana составляет фиксированные 5,000 ламопортов (0.000005 SOL) за подпись, и большинство транзакций имеют одну подпись. Он не учитывает более широкие вычислительные ресурсы транзакции (измеряемые в CU).

Базовый взнос Solana Tx = (5,000 лямпортов) x (количество подписей в Tx)

Механизм базовой платы Ethereum отличается двумя основными способами:

1. Динамическая - базовая плата Ethereum (измеряемая в гвеях за единицу газа) плавает на основе отслеживаемого рыночного спроса.
2. Более детализированная плата за единицу вычислений - базовая плата Ethereum за каждую транзакцию линейно зависит от количества потребляемого газа.

Таким образом, базовая комиссия Ethereum за каждую транзакцию составляет:

Ethereum Tx Base Fee =(Преобладающая цена на газ в gwei) x (количество газа, использованного в tx)

Пользователи Solana также могут добавить дополнительные приоритетные взносы, чтобы повысить вероятность включения. В отличие от базовой платы, плата за приоритет взимается за каждый CU, запрашиваемый для транзакции. Транзакции Solana могут включать следующие инструкции Compute Budget:

1. SetComputeUnitLimit - транзакции могут установить максимальное количество CU, которое им разрешено потреблять (максимум 1,4M CU на транзакцию). При выполнении транзакция может использовать до запрашиваемого лимита CU. Если инструкция SetComputeUnitLimit не предоставлена, лимит CU транзакции рассчитывается как (количество инструкций в транзакции) x(200k CU).
2. SetComputeUnitPrice - # микролампортов за запрашиваемый CU, которые транзакция предлагает оплатить в качестве приоритетной платы.

Соедините их вместе:

Приоритетная плата за Tx = (Лимит Tx CU) x (Цена CU)

Обратите внимание, что эта плата за приоритет выплачивается в отношении всего количества запрашиваемых CU (независимо от того, использовано ли в транзакции все запрашиваемое количество), в отличие от Ethereum, где плата зависит от того, сколько газа фактически использовано в транзакции.

Fee Burn против Validator Rewards

Хотя стимул для валидаторов отдавать предпочтение транзакциям с высокой комиссией находится за пределами консенсуса, в рамках консенсуса установлено, что и базовая комиссия, и комиссия за приоритет сжигаются/отправляются лидеру (текущему производителю блоков) в Solana 50/50:

1. Базовый взнос - обязателен для включения в блок. Транзакции, в которых отсутствует необходимая базовая плата, будут отклонены.
2. Приоритетный сбор - Не обязателен для включения в блок. Используется для опциональной приоритизации транзакций, которые хотят увеличить вероятность быстрого включения.

Пользователь не может избежать уплаты базовой платы, но он может избежать платы за приоритет и выразить свое желание получить приоритет другим способом. Мы уже видим это на практике - аукционы Jito-Solana выплачивают 100% (за вычетом комиссии) лидеру вне диапазона. SIMD-0096 предлагает простое решение этой проблемы, вознаграждая валидатора 100% от платы за приоритет.

Прямой перевод*: Координируется через аукционы MEV-Boost / Jito-Solana

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

В последнее время Solana достигла рекордных показателей по сетевым сборам, что было вызвано резким увеличением приоритетных сборов. Ниже показаны недавние случаи разделения гонораров:

Источник: Solana Compass

Ethereum Block Builder против Solana Scheduler

Производство блоков в Ethereum в целом проще для понимания, поэтому мы начнем с него. Почти все валидаторы (они же провайдеры) передают производство блоков внепротокольным строителям через MEV-Boost. Строители создают блоки каждые 12 секунд (время работы слотов Ethereum) и передают целые блоки предлагающему (через ретранслятор), который выбирает блок с наибольшей стоимостью.

И в Ethereum, и в Solana производители блоков имеют право произвольно заказывать транзакции внутри блока. У них есть стимул делать это таким образом, чтобы максимизировать свою прибыль. Например, различные разработчики Ethereum могут конкурировать, используя собственные алгоритмы, которые более эффективно максимизируют прибыль по сравнению с конкурентами.

Это означает, что даже в Ethereum отправка высокоприоритетной платы не дает никакой внутрипротокольной детерминированной гарантии включения или упорядочивания блока. Тем не менее, он с большой вероятностью достигнет ожидаемого результата благодаря природе текущего процесса построения блоков в Ethereum, в котором строитель строит полный блок, максимизирующий прибыль, в конце каждого дискретного слота.

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

Вы заметите, что здесь есть две разные гарантии, которых пытаются добиться платы:

1. Включение - Пользователь хочет, чтобы его транзакция была включена в этот блок, но ему неважно, где она находится в блоке.
2. Заказ - Пользователь не просто хочет быть включенным в блок в любом месте; он хочет получить приоритетный доступ к определенному состоянию в определенное время.

Механизм EIP-1559 в Ethereum оказался весьма эффективным, позволяя пользователям легко делать ставки на включение блока с высокой вероятностью успеха. Существует глобальная резервная цена, которую все знают, что нужно платить, и ее оплата (обычно вместе с номинальной платой за приоритет) должна надежно обеспечить оперативное включение транзакции пользователя. Однако этот механизм не стремится предоставить какие-либо гарантии относительно упорядочивания (т.е. приоритетного доступа к состоянию), в то время как внепротокольные механизмы надежны для пользователей, ищущих такие гарантии (например, непосредственно от строителей).

Процесс создания блока Соланы работает совсем по-другому. Валидаторы не передают полное производство блоков в дискретные временные интервалы строителям, не входящим в протокол. Планировщик" - это алгоритм по умолчанию, включенный в клиент валидатора Solana Labs, который планирует транзакции для выполнения и непрерывно строит блоки.

Кроме того, транзакции Solana определяют, какие учетные записи должны быть заблокированы на чтение и запись для выполнения. Это позволяет планировщику итеративно сортировать транзакции, которые могут выполняться одновременно - ведь транзакции, не затрагивающие одно и то же состояние, могут выполняться параллельно.

В пределах одного блока для последовательной записи в один аккаунт ("часть состояния") может быть использовано не более 12 000 000 CU. Это примерно то количество CU, которое может быть обработано одним потоком за 400 мс в слот при разумных требованиях к узлам. Тогда ограничение Solana на один блок составляет 48 000 000 CU. Текущая реализация планировщика использует четыре потока для транзакций, не связанных с голосованием, и 12M x 4 = 48M. Теоретически, это означает, что использование большего количества ядер = увеличение пределов CU. Масштабирование с помощью оборудования.

Планировщик недетерминированно отдает приоритет транзакциям с более высокими приоритетами. Однако это, как правило, обеспечивает менее надежные гарантии приоритетности, чем механизмы, подобные тем, что описаны сегодня в случае с Ethereum.

В Solana валидаторы, работающие с планировщиком по умолчанию, строят блоки непрерывно, поэтому транзакции могут быть добавлены в текущий блок и выполнены, не дожидаясь окончания слота, чтобы упорядочить их исключительно по приоритету. Замысел состоит в том, чтобы планировщик очень приблизительно максимизировал прибыль, расставляя приоритеты транзакций на основе их общей цены CU.

Многопоточный планировщик Solana по умолчанию также вносит дополнительный "джиттер". Транзакции назначаются случайным образом одному из четырех потоков, при этом каждый поток ведет свою очередь транзакций, ожидающих выполнения. Плата за приоритет затем используется для определения приоритета внутрипотоковых транзакций. Однако они не помогают определить приоритет транзакций между потоками.

Например, два поисковика могут одновременно отправить транзакцию, чтобы воспользоваться одной и той же арбитражной возможностью, и тот, кто отправит плату с более низким приоритетом, может даже выиграть, поскольку случайно попадет в менее забитую очередь. Это снижает эффективность платы за приоритет и увеличивает стимул к спаму по сравнению с Ethereum - особенно с учетом того, что включение транзакций также зависит от того, когда, в рамках заданного слота, транзакция попадает к производителю текущего блока.

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

Хотя это в основном выходит за рамки данной статьи, клиент Jito-Solana позволяет поисковикам более эффективно собирать майнеры/максимальную извлекаемую ценность (MEV) таким образом, чтобы свести к минимуму негативные внешние воздействия на Solana. Jito-Solana отклоняется от стандартного планировщика Solana, вводя внепротокольные дискретные 200-миллисекундные аукционы пакетов в стиле Flashbots, которые проводятся параллельно с непрерывным производством блоков по умолчанию и частным mempool (который снова отклоняется от стандартного TFM Solana). Принятие клиента Jito-Solana валидаторами Solana (>50% валидаторов используют его сегодня) помогло решить некоторые проблемы с существующим TFM Solana - а именно, распространенность спама, вызванного MEV.

Недостатки нынешней ПМФ Соланы

Хотя TFM Соланы весьма многообещающа, она также имеет некоторые потенциальные недостатки на данный момент:

Стимул к спаму

Как уже упоминалось выше, транзакции упорядочиваются по принципу "кто первый пришел, тот и ушел" (FIFO), как только они попадают к производителю блоков. Кроме того, они подвержены недетерминированности как со стороны сетевого джиттера, так и со стороны рандомизированного распределения потоков в планировщике по умолчанию. Несмотря на то, что в определенных обстоятельствах плата за приоритет может способствовать повышению вероятности включения, все равно существует значительный стимул для спама сделок с целью максимизации наиболее быстрой вероятности включения (например, искатель, стремящийся ликвидировать дефолтную позицию на рынке кредитования). Приведенное ниже изображение от Jito Labs помогает продемонстрировать неоптимальную природу спам-транзакций.

Источник: Фонд Jito

Аукцион первой цены

В наивном аукционе первой цены (FPA) пользователи просто подают заявки, и самая высокая из них попадает в блок. Одна из проблем с FPA заключается в том, что они не очень удобны в использовании. Пользователи должны угадывать ставки других пользователей, думая о том, на что они готовы пойти, и, возможно, затеняя свою ставку, чтобы не переплачивать, основываясь, например, на том, что, по их мнению, ставят другие.

Более формально, модель FPA является не-DSIC:

**Совместимость доминирующей стратегии со стимулом (DSIC): Если предположить, что производитель блокчейна честно реализует TFM, то предписанная стратегия торгов должна быть доминирующей стратегией для пользователей. Это означает, что пользователи будут делать ставки (в виде платы за транзакцию) именно в том значении, которое они приписывают включению транзакции [Chu22].

DSIC - одно из ключевых свойств, которое создатели EIP-1559 стремились внедрить в TFM Ethereum с помощью своей реализации, и, как мы описали ранее, это можно считать успешным. Пользователям легче узнать публичную резервную цену для включения в блок в данный момент времени (благодаря динамической базовой плате), поэтому заплатив ее (плюс любую номинальную плату за приоритет), Вы почти всегда сможете быстро включить свою сделку в блок.

И наоборот, TFM Соланы - это наивный FPA. В нем отсутствует надежный механизм, позволяющий пользователям точно выразить свои предпочтения по включению блоков, и он не является DSIC. На практике попытка установить именно ту приоритетную плату, которая нужна в нужное время, является невероятно сложной. Это непропорционально благоприятствует сложным участникам, которые способны обойти джиттер сети и планировщика (например, с помощью совместного размещения или спам-транзакций).

Выплата 50/50 ожог/валидатор

Как отмечалось ранее, Ethereum сжигает 100% базовой платы и отправляет 100% приоритетной платы производителю блока, в то время как в Solana и базовая, и приоритетная плата сжигаются/выплачиваются производителю блока в соотношении 50/50. В результате этого Solana TFM не имеет защиты от ОКА:

**Достоверность внецепочечного соглашения (OCA-достоверность или SCP): Никакое внецепочечное соглашение между пользователями и производителем блока не может Парето улучшить результат TFM для данного блока [Rou21]. Протокол c-SCP устойчив к тому, что коалиция, состоящая из производителя блоков и до c пользователей, может получить прибыль, отклонившись от правдивого отчета.

Мы видим наглядный пример этого: внепротокольные аукционы Jito-Solana выплачивают 100% ставок (за вычетом доли Jito) производителям блоков, а не сжигают 50% - Jito-Solana является примером внецепочечного соглашения, используемого производителями блоков. Однако мы отмечаем, что чаевые Jito-Solana не эквивалентны приоритетным комиссионным, поскольку первые выплачиваются только в случае успешного выполнения соответствующей транзакции (и пакета).

Недавно предложенный SIMD-0109 вводит в протокол механизм опрокидывания (подобный тому, который используется в Jito-Solana в out-protocol-auction) в качестве собственной инструкции.

Отсутствие привилегированных типов транзакций

Транзакции голосования Solana публикуются на цепочке и должны быть включены в блоки, однако каждый валидатор должен оплачивать расходы на эти транзакции. Это представляет собой значительные постоянные расходы (оплачиваемые валидаторами в частном порядке), несмотря на положительный внешний эффект от включения транзакций голосования. Эти расходы усугубляются тем, что транзакции с голосованием оплачиваются по завышенной стоимости относительно потребляемых единиц (т.е. они используют относительно мало единиц по сравнению со средней транзакцией). Экономика создает здесь централизующий эффект, поскольку общая стоимость голосования примерно постоянна для любого валидатора, в то время как полученное вознаграждение пропорционально весу ставки.

Источник: Ceteris, Solana the Monolith

Кроме того, подобную логику можно распространить и на надежные оракульные обновления, за которые сети обычно берут плату, несмотря на положительный внешний эффект от точной передачи цен по цепочке. Цепочка с более выраженным мнением, которая извлекает большую пользу из определенного надежного оракула, может выбрать для закрепления механизм, который субсидирует его стоимость.

Местный рынок сборов Соланы

Предложенная Соланой аппроксимация механизма локальной комиссии существует потому, что ни один счет не может записать более 12 млн. единиц CU на 48-мегабайтный лимит блоков. Это, наряду с многопоточностью планировщика Solana по умолчанию, означает, что максимум 25% транзакций в блоке могут соответствовать одному фрагменту востребованного состояния. Теоретически, пользователи, находящиеся в состоянии меньшего спроса, не должны увеличивать плату за приоритет для получения сильных гарантий включения по сравнению с пользователями, находящимися в состоянии большего спроса.

Это, пожалуй, не настоящий механизм местных сборов. Механизм не обеспечивается консенсусом (он действует только на уровне планировщика), а взаимосвязь между приоритетными платежами и включением блоков довольно недетерминирована (как уже говорилось ранее). В нем также отсутствует понятие "эластичности", когда существуют как целевые, так и максимальные ограничения ресурсов.

Неэффективное использование ТС & Запросы

Поскольку базовая комиссия Solana не учитывает ТС, она не стимулирует проведение транзакций:

1. Используйте CU эффективно - Транзакция с 1,4 млн CU влечет за собой такую же базовую комиссию, как и транзакция с 100 тыс. CU при прочих равных условиях.
2. Запрашивайте CU эффективно - Даже если транзакция использует 50 тыс. CU, она несет одинаковую базовую плату независимо от того, запрашивает ли она 100 тыс. CU или 1 млн. CU.

Это может привести к переоценке планировщиком вычислений, необходимых для данного блока, и к снижению эффективности по сравнению с ресурсами, необходимыми производителю блока в данный слот. DSIC TFM устранит эту проблему, поскольку доминирующая стратегия пользователя будет соответствовать предписанной стратегии торгов - в данном случае, точно представляющей ожидаемое использование CU.

Записывать счета блокировки без затрат

Как уже упоминалось ранее, транзакции Solana заранее указывают все счета, с которых они будут считывать или записывать данные во время выполнения. Однако сегодня этим механизмом можно злоупотреблять, чтобы глобально заблокировать любую учетную запись практически без затрат. Например:

1. Я посылаю_TxA, который указывает, что он будет писать на_счетА.
2. Лидер получает_TxA, планирует его и начинает выполнять. _СчетА теперь заблокирован - никакая другая транзакция, касающаяся_счетаА, не может быть выполнена, пока не завершится выполнение_TxA.

Проблема связана с тем, что любой человек может отправлять транзакции, блокирующие запись на любые счета. Блокировка учетных записей не требует никаких затрат, и транзакции могут блокировать даже те учетные записи, которыми они не пользуются, что является очевидным вектором спамерской атаки. Более того, владельцы учетных записей не могут контролировать, кто может заблокировать их учетную запись.

Предложения TFM & Frameworks

Каждый блокчейн должен в конечном итоге решить, как распределить дефицитный ресурс своего ограниченного пространства блоков между пользователями, что он и делает с помощью своего TFM. Ниже мы рассмотрим несколько соответствующих предложений и рамок ПМФ, которые могут оказаться полезными для Соланы.

Многомерные рынки сборов блокчейна

Большинство существующих рынков гонораров одномерны и построены вокруг одной взаимозаменяемой единицы счета (например, газа в Ethereum). Однако этот единственный приобретенный ресурс является косвенным показателем для многих базовых ресурсов, не относящихся к категории легкодоступных (например, пропускная способность, вычисления и хранение).

Например, каждый опкод Ethereum потребляет определенное фиксированное количество газа (например, ADD потребляет 3 газа, а MUL - 5). Цена газа для каждого опкода была установлена как приблизительная оценка базовых ресурсов, которые они используют, и того, насколько дорогими они считаются для узлов сети. Например, эта неявная мера стоимости операции может быть определена путем выполнения контрольных тестов на реальном оборудовании.

Однако можно также построить многомерные рынки платы, которые по отдельности устанавливают цену на эти различные недробимые ресурсы, а не объединяют их в одну единицу. EIP-4844 - это прямой двухмерный рынок комиссий, поскольку блокчейн данных имеет свой собственный рынок комиссий, не зависящий от газа исполнения Ethereum.

В этом документе 2022 года Диамандис, Эванс, Читра и Ангерис анализируют, как построить многомерные рынки гонораров, подобные этому. В их работе проблема построения TFM рассматривается с точки зрения дизайнера сети, стремящегося максимизировать благосостояние (или общую полезность) пользователей блокчейна за вычетом потребления ресурсов этими пользователями, с учетом ограничений цепи на транзакции и блоки (например, ограничений на смарт-контракты или ограничений на CU/газ). Главный результат статьи заключается в том, что, несмотря на то, что благосостояние неизвестно, они разрабатывают механизм, который его максимизирует, и показывают, как явно построить этот механизм.

** Максимизация благосостояния: Предполагаемые правила распределения и оплаты подразумевают, что сумма потребительского и шахтерского излишков (приблизительно) максимизируется.

Их ключевой вывод заключается в том, что можно реализовать эквивалентную TFM, в которой цена ресурса устанавливается таким образом, чтобы минимизировать разницу между благосостоянием валидаторов и его пользователей - такая цена должна приводить к блокам, которые, в теории, оптимальны с точки зрения максимизации благосостояния. Хотя эту работу можно рассматривать скорее как академическую основу для разработки оптимальных TFM, она помогает показать, что раздельное ценообразование на ресурсы может сделать блокчейн более эффективным и более устойчивым к периодам высокой перегруженности или спама. Механизмы базовой платы на основе контроллеров, такие как EIP-1559, выделены в качестве потенциального подхода, который может исключительно хорошо работать в цепочках Solana и SVM, учитывая короткое время блокировки, что позволяет базовой плате быстро подстраиваться под изменения пользовательского спроса и доступности ресурсов.

Как уже говорилось ранее, один из выводов из этой статьи заключается в том, что можно разработать систематические и эффективные с точки зрения вычислений способы, которые помогут определить и обновить ценообразование многомерных ресурсов для блокчейн. Однако естественным вопросом должен быть следующий: на какие ресурсы имеет смысл устанавливать разные цены? В других контекстах блокчейна была проделана определенная практическая работа по принятию таких решений. Например, компания Penumbra реализовала форму многомерного ценообразования на ресурсы, чтобы установить в своем блокчейне, ориентированном на конфиденциальность, отдельную цену на ресурсы, используемые полными узлами и устройствами конечных пользователей.

Хотя в документе 2022 в целом рассматривается многомерное ценообразование на базовые ресурсы (например, вычисления, пропускная способность, хранение), можно также реализовать многомерное ценообразование на ресурсы для каждого аккаунта (т.е. для каждого "фрагмента состояния"). Каждый аккаунт рассматривается как отдельный ресурс. Об этом говорится в этой недавней статье, которая основана на оригинальной статье. Индивидуальное ценообразование учетных записей (а не вычислений, хранения данных, пропускной способности и т.д.) в качестве основного ресурса также может быть более простым в реализации и снижать риск атак на исчерпание ресурсов.

Экспоненциальная плата за блокировку записи

После недавнего поста Анатолия об экономике выполнения SVM, Тао Жу (Tao Zhu) в сотрудничестве с Анатолием предложил SIMD-0110. Его основная цель - предотвратить спам с помощью экономического давления (т.е. целенаправленного увеличения платы с течением времени, чтобы уменьшить стимул к спаму), что приведет к более эффективному использованию сетевых ресурсов. Неудачные арбитражные сделки продолжают заполнять примерно половину (или даже больше) блокчейн-пространства Solana, потому что спамить рационально и невероятно дешево.

Для достижения этой цели предложение рекомендует отслеживать экспоненциальное скользящее среднее (EMA) использования CU каждого счета в блоке. Стоимость записи-блокировки учетной записи будет расти экспоненциально в зависимости от соответствующего использования CU, что будет препятствовать распространению спама. Основная логика похожа на то, как EIP-1559 устанавливает глобальную базовую плату Ethereum в зависимости от использования газа в последующих блоках. Однако эта SIMD гораздо более детализирована в определении местных рынков базовых платежей на каждый счет.

Основная идея реализации варьируемой платы за блокировку записи на основе учетной записи будет выглядеть следующим образом:

1. Отследите использование вычислительных единиц EMA каждым спорным счетом за последние 150 слотов.
2. Максимальное количество учетных записей, которые будут отслеживаться, составляет 2048, при этом отслеживаются только самые спорные учетные записи с самым высоким уровнем затрат на списание.
3. Если использование вычислительных единиц EMA учетной записи составляет >50% от максимального лимита CU, стоимость блокировки записи увеличится на X%. Если он <50% от своего лимита, уровень затрат снизится на X%.
4. V0 рекомендует начальную стоимость блокировки записи в 1000 микролапортов/КУ и корректировку стоимости в 1% за слот (обратите внимание, что точные проценты здесь могут быть изменены, учитывая ранний характер предложения).
5. Плата за блокировку записи для счета в данном блоке рассчитывается путем умножения стоимости блокировки записи на количество запрошенных CU транзакции.
6. За транзакции по-прежнему взимается плата за подпись, а также сохраняется плата за опциональный приоритет.
7. Собранная плата за блокировку записи сгорает на 100%.
8. Собранные приоритетные сборы вознаграждаются на 100%.
9. Собранные сборы за подписи 50% сгорают и 50% вознаграждаются.

Это предложение сделает функцию блокировки записи в Solana (обычно) DSIC похожей на то, как EIP-1559 сделал TFM Ethereum (обычно) DSIC и MMIC [Rou23] - за исключением случаев внезапных скачков платы.

Мы можем определить свойство MMIC следующим образом:

**Миопический майнерский стимул (MMIC): Производитель блока максимизирует свою полезность, не создавая поддельных транзакций и следуя установленным правилам TFM. Близорукость означает, что эта цель касается только текущего блока при оценке максимизации полезности [Ру21].

Любой механизм отслеживания несовершенен, поскольку он может неточно отражать текущее состояние спроса. Например, спрос может быть низким в течение длительного периода времени (и, следовательно, динамическая базовая плата низкая), а затем внезапно подскочить для монетного двора NFT. Это может происходить на глобальном уровне (как в TFM в Ethereum) и может быть еще более нестабильным на локальном уровне для каждого аккаунта (как рассматривается в SIMD-0110).

Однако Solana также выигрывает от того, что здесь невероятно низкое время блокировки. Они могут позволить базовой плате быстрее приспособиться к внезапному шоку спроса, в зависимости от того, насколько агрессивно настроена кривая. Форма регулятора платы здесь невероятно важна.

Тот факт, что плата за блокировку записи взимается с запрашиваемых CU, также стимулирует пользователей и разработчиков к точной оценке использования CU в транзакции. Это позволит избежать проблемы, которую мы обсуждали ранее, когда текущая база плоских подписей не предусматривает наказания за запрос гораздо большего количества CU, чем требуется (даже до максимального количества 1,4 мм CU). В противном случае, только плата за приоритет несет в себе этот стимул сегодня (поскольку она также взимается запрашиваемыми ТС).

Одно из возможных критических замечаний заключается в том, что рынки локальных тарифов на основе счетов (особенно это касается данного предложения, которое требует постоянного расчета EMA для каждого счета) могут быть очень дорогими с точки зрения вычислений. Этот тип многомерной платы является неограниченным, поскольку любой счет может быть перегружен, что, вероятно, создаст трудности для такого TFM. Однако в случае с SIMD-0110 этого можно избежать, установив верхний предел на количество счетов, чье использование CU EMA можно отслеживать в данный момент времени.

**Эффективно вычисляемый: Механизм аукциона блоков должен быть разработан таким образом, чтобы его можно было эффективно вычислить для данного производителя (или строителя) блоков - слоты Eclipse и Solana занимают менее 400 мс, что накладывает жесткое ограничение на максимальное время вычисления для данного блока.

Учитывая, что включение блоков Solana будет по-прежнему недетерминированным даже при реализации этого предложения, потенциально могут возникнуть проблемы с тем, что пользователи будут точно обновлять свои заявки в режиме реального времени, чтобы их транзакции были включены в блоки. Дальнейшее решение этой проблемы требует изменений в планировщике, о чем мы поговорим в следующем разделе.

Изменения в планировщике по умолчанию Solana

Как говорилось ранее, "планировщик" - это алгоритм по умолчанию, включенный в клиент валидатора Solana Labs, который планирует транзакции для выполнения и непрерывно создает блоки. Он играет невероятно важную роль на рынке вознаграждений Solana, несмотря на то, что его поведение по умолчанию не обеспечивается в протоколе, поскольку валидаторы могут выбрать другие алгоритмы. Здесь мы сосредоточимся на текущем планировщике и предстоящих изменениях, над которыми работает Эндрю Фитцджеральд.

Текущий планировщик Solana вносит "дрожание" в обработку транзакций пользователей, случайным образом назначая их на один из четырех потоков транзакций, не связанных с голосованием (еще два потока зарезервированы для обработки транзакций с голосованием), прежде чем попытаться отсортировать оставшиеся транзакции по приоритету и проверить соответствующие блокировки ("захват блокировки"), как показано на диаграмме ниже. Несколько партий транзакций вытягиваются для распределения по потокам во время "Банковского этапа" - процесса, выполняемого валидатором Solana, в ходе которого обрабатываются транзакции и происходит процесс составления расписания.

Источник: Эндрю Фитцджеральд, Solana Banking Stage and Scheduler

Одной из существенных проблем планировщика по умолчанию было то, что в периоды интенсивной сетевой активности очередь каждого потока часто заполнялась конфликтующими транзакциями (например, перед майнингом NFT или широко ожидаемым событием генерации токенов). Каждый поток может содержать транзакции с одинаковыми или перекрывающимися блокировками на чтение или запись, что означает, что эти транзакции должны быть перенесены на более позднее выполнение. В результате этого, однако, в самом худшем случае только один из четырех потоков планировщика по умолчанию может выполнять транзакции в данный момент времени.

Суть обновления планировщика по умолчанию в Solana заключается в переходе от устаревшего подхода (названного режимом ThreadLocalMultiIterator) к новому подходу к планированию, названному режимом CentralScheduler. В этой статье представлен лишь обзор и анализ изменений. Однако дополнительную информацию можно найти в статье Эндрю Фитцджеральда и сопутствующем <a href="https://medium.com/@harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7"> summary blogpost Харша Пателя из команды Tiny Dancer. Ниже представлен обзор нового процесса планирования.

Источник: Эндрю Фитцджеральд, Solana Banking Stage and Scheduler

Новый планировщик включает в себя центральный единый планировщик, который получает транзакции из канала, а затем проверяет наличие соответствующих блокировок. После этого транзакции назначаются на выполнение определенным параллельным рабочим потокам. Центральный планировщик имеет представление о различных блокировках на чтение и запись, используемых данным рабочим потоком, что позволяет ему определить лучший поток для новой транзакции. По мере того, как транзакции выполняются и обрабатываются данным рабочим потоком, центральному планировщику отправляется сообщение, чтобы он мог заново оценить, какие части состояния Solana считаются заблокированными.

Планировщик использует алгоритм, называемый "prio-graph", который представляет собой прямой акриловый граф, начинающийся с транзакций с наивысшим приоритетом (платой) и линий (или, более точно, ребер) между данной транзакцией с наивысшим приоритетом и следующими транзакциями с наивысшим приоритетом, которые конфликтуют с ней из-за перекрывающихся блокировок. Это (ориентировочно) делается для "окна вперед" заранее настроенного размера в 2 048 (может быть изменено) транзакций, которые могут быть добавлены в график - следующие графики показывают работу прио-графа для заданного набора транзакций, где ребра между ними представляют конфликтующие блокировки.

В дополнение к использованию планировщика prio-graph, в этой версии введены дополнительные преимущества, помогающие сократить накладные расходы на обработку, например, удалены лишние элементы банковского этапа. Новый планировщик должен улучшить работу, значительно снизив вероятность неудачных записей и блокировок чтения в периоды высокой активности на Solana. Мы могли бы ожидать уменьшения джиттера благодаря новому планировщику по умолчанию. Тем не менее, учитывая непрерывный характер процесса создания блоков, в процессе включения блоков по-прежнему будет присутствовать недетерминизм.

Комиссионные за списание средств со счета, подлежащего возмещению в рамках программы (PRAW)

Авторство Godmode Galactus и Max Schneider, SIMD-0016 предлагает плату за программную перезаписываемую учетную запись (PRAW). Они предоставят разработчикам приложений значительный контроль, поскольку те смогут устанавливать критерии оплаты и возврата этих сборов, позволяя стимулировать и дестимулировать поведение пользователей по своему усмотрению.

В настоящее время программы Solana не имеют возможности наказывать транзакции за получение блокировок записи на их состояние. Плата за PRAW позволит владельцам счетов Solana взимать плату за неудачные транзакции, которые приводят к блокировке их состояния. Эти сборы будут перечислены на счет, который блокируется. Однако владельцы счетов могут установить эти сборы таким образом, что они будут возвращены пользователю в конце транзакции, если она соответствует заданным критериям.

В частности, это может удержать пользователей от блокировки учетных записей, которые они фактически не используют при выполнении транзакции. В настоящее время это возможно, поскольку в Solana нет никаких проверок, чтобы априори определить, будет ли данный счет использоваться данной транзакцией, которая заблокировала его на запись. PRAW предлагают программам способ дестимулировать транзакции, которые блокируют состояние программы в попытке определить возможность с намерением вернуться назад, если эта возможность больше не актуальна на момент выполнения. Эти сборы будут взиматься даже в том случае, если во время выполнения транзакции произойдет сбой.

И наоборот, пользователи могут указать максимальную сумму комиссии PRAW, которую они готовы заплатить за транзакцию. Любая плата, указанная в транзакции, превышающая текущую плату PRAW для данного счета с блокировкой записи, будет возвращена.

Члены сообщества Solana отметили проблемы, связанные с этим предложением: возможность для различных программ работать полностью автономно кажется неоптимальной, а возможность точной оценки сборов окажется сложной. Более того, потенциально существуют более простые и единообразные способы решения проблем с грифингом вокруг аккаунтов с блокировкой записи, например, SIMD-0110.

**Сопротивление грифингу: Подмножество DSIC, в котором у пользователей нет стимула искажать свои списки доступа - неправильно указывать ресурсы, необходимые для выполнения операции[Gar23].

Предложение PRAW потенциально не сможет предотвратить спам, поскольку оно полагается на то, что разработчики приложений в достаточной степени: 1) способности отличить спам от "нормального поведения" и 2) добровольного решения взимать большую плату за негативное внешнее воздействие, за которое они частично ответственны, когда это может быть не в их интересах, и они могут просто решить не делать этого.

В отличие от этого, хотя члены исследовательского сообщества Solana, несомненно, разошлись во мнениях относительно введения базовых сборов EMA, в целом они согласны с тем, чтобы добавить в базовый сбор некий компонент, который бы масштабировался в зависимости от CU. Это может стимулировать точную оценку ТС и эффективное использование ТС разработчиками.

Размышления на прощание

Уникальные инженерные и эксплуатационные цели Solana требуют уникальных соображений относительно TFM. Простое перенесение существующего рынка сборов Ethereum на Solana, конечно, не является решением проблемы, но из этого можно извлечь ценные уроки. Это очень важно для механизмов, которые одновременно являются и механизмами:

1. Внутрипротокольные - ПФМ с принудительным консенсусом (например, EIP-1559 и SIMD-0110)
2. Вне протокола - PBS с помощью MEV-Boost, улучшений планировщика Solana и аукционов Jito

Как для Solana, так и для Ethereum, внутрипротокольные и внепротокольные механизмы, вероятно, будут сосуществовать и развиваться вместе в будущем. Баланс между ними - один из фундаментальных вопросов при проектировании таких систем. Споры вокруг SIMD-0110 часто ведутся вокруг двух противоположных мнений:

1. Усовершенствования планировщика и сети, направленные на уменьшение джиттера, в достаточной степени решат описанные здесь проблемы, поэтому серьезные изменения внутрипротокольного TFM не нужны.
2. Хотя внепротокольные улучшения планировщика и сети необходимы, они по своей сути недостаточны. Требуется экономичное обратное давление в протоколе.

Многомерное ценообразование на ресурсы в той или иной форме, несомненно, ценно и в обоих случаях. Ethereum начинает реализовывать такую TFM на уровне базовых ресурсов, а EIP-4844 отделяет данные о блобах от рынка исполнения. И наоборот, компания Solana продвигает многомерное ценообразование на ресурсы на уровне индивидуальных счетов, чтобы создать "местные рынки гонораров".

Исследования в области TFM здесь являются передовыми, и исследователи постоянно находят новые и инновационные способы улучшить работу комиссий в Solana и других цепочках. Мы уверены, что все обсуждаемые здесь предложения позволят сделать Solana еще более эффективной, масштабируемой, удобной для пользователя и экономически устойчивой.

По мере того, как Eclipse приближается к запуску нашей основной сети, мы также с нетерпением ждем возможности рассказать о том, как мы будем применять эти наработки в нашей собственной TFM, которая, несомненно, будет продолжать развиваться еще долгие годы. Мы намерены экспериментировать и продвигать механизмы в этой области. Существенным преимуществом модульной парадигмы является то, что она позволяет легче проводить перекрестное опыление исследований и разработок из разных экосистем. Теперь темпы экспериментов будут только расти, принося пользу всем, кто строит здесь в долгосрочной перспективе.

Отказ от ответственности：

1. Эта статья перепечатана с сайта[Eclipse], Forward the Original Title'Solana & Механизмы платы за транзакции в Ethereum: Предложения по улучшению TFM Solana', Все авторские права принадлежат оригинальному автору[Eclipse]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.