Быстрые блокчейны создают новые проблемы для управления пропускной способностью и справедливости RPC. Сегодня мы представляем механизм формирования доступа к RPC с использованием обязательств по ликвидному стекингу. Система работает через ShMonad RPC от FastLane. Эта тема исследует архитектуру и обоснование. 🧵

Сети с высокой пропускной способностью, такие как Monad (~0,5 с время блока, ~1 с финализация), оставляют мало места для реактивного ограничения. К тому времени, как RPC-эндпоинт обнаруживает, что он подвергается спам-атаке, ущерб уже нанесен. Меры по смягчению последствий должны быть проактивными и согласованными с интересами.

Ключевое ограничение — это пропускная способность. Узлы, соседствующие с валидаторами, ограничены в ресурсах и чувствительны к задержкам. Если доступ без разрешения предоставляется без разбора, недоброжелательные клиенты могут вытеснить честных участников, что приведет к ухудшению пользовательского опыта и увеличению затрат валидаторов без возможности возмещения.

Наше решение использует ShMonad, программируемый токен ликвидного стекинга (LST) с возможностями обязательств на блокчейне. Пользователи получают приватный URL RPC в обмен на обязательство ShMON к "RPC Policy" на блокчейне. Это обязательство регулирует лимиты доступа.

Пропускная способность распределяется пропорционально: RPS пользователя = (обязанный ShMON пользователя / общий обязательный ShMON) × RPS_max-global Это дает динамически совместимую модель пропускной способности с учетом доли стейка без введения централизованных ограничителей скорости вне цепи. 5/

Ставка фиксируется на определенный срок (в настоящее время 20 блоков), что позволяет кэшировать данные. Релей периодически опрашивает и делает снимки состояния обязательств в блокчейне. Это предотвращает вызовы EVM в критическом пути и поддерживает высокочастотное использование без дополнительной задержки. 6/

Эмпирически, эта система обеспечивает постоянно более низкую задержку. В ходе нескольких независимых сессий бенчмаркинга, RPC ShMonad от FastLane демонстрирует медианное/среднее время отклика примерно на 20 мс ниже, чем у второго по скорости провайдера, с еще большим разрывом по сравнению с публичными RPC. 7/

ShMON, привязанный к политике RPC, ставится с валидаторами, участвующими в сети реле FastLane (в настоящее время >90% валидаторов Monad). Это создает согласованность: потребители пропускной способности поддерживают тех же валидаторов, которые обслуживают их трафик, а валидаторы имеют возможность получать компенсацию напрямую через штрафы за превышение.

Но для того, чтобы надежно и без доверия применять ограничения по пропускной способности, нам нужно больше, чем просто лимиты скорости... нам нужно доказуемое принуждение. На данный момент пользователи ограничены на реле. Но дорожная карта включает в себя системы доказательства на блокчейне, основанные на дельтах nonce и подписанных квитанциях об использовании. 9/

Минимальный дизайн может сравнивать нонсы аккаунтов между высотами блоков n и m и накладывать штраф (т.е. "применить надбавку" и передать её валидатору) за превышение максимального RPS. Но есть проблема: это уязвимо для атак с пакетным выпуском со стороны реле, заставляющего транзакции выглядеть всплесковыми.

Чтобы смягчить это, мы вводим второй канал: асинхронные квитанции об использовании с временными метками. Когда транзакция отправляется, она будет многократно передана как валидатору, так и отдельному "эмитенту квитанций". Эмитент возвращает подписанный объект отправителю, с временной меткой и включая метаданные nonce до выполнения. Это снимает нагрузку по отслеживанию и проверке с горячего пути между пользователем и валидатором. 11/

Эти квитанции (которые будут подписаны) служат двойной цели: 1. Обратная связь от пользователей: Если квитанции перестанут приходить, клиенты могут добровольно остановить трафик, чтобы избежать дополнительных сборов. 2. Доказательство в блокчейне: Квитанции фиксируют временную активность, различая настоящий спам и пакетирование, вызванное реле. 12/

Эта модель поддерживает как EOA, так и 4337 userOps (при условии, что используются несмешанные пакеты или вертикальная интеграция с нашим собственным платёжным мастером). В будущих версиях мы можем установить требование, чтобы подписывающий транзакцию соответствовал держателю политики или был внесён в белый список во время обязательства по политике. TBD. 13/

Наша цель — перенести исполнение в блокчейн, не жертвуя производительностью. Благодаря обильному блочному пространству Monad и быстрой финализации, подача доказательств состояния, проверка квитанций и взимание дополнительных сборов возможны в блокчейне... что невозможно на более дорогих сетях. 14/

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

Пропускная способность RPC в настоящее время измеряется в совокупности (txs + eth_call), но будущие обновления разделят классы пропускной способности. Запросы на чтение будут направляться через регионально оптимизированные узлы, что устранит узкое место, созданное ограничениями пропускной способности валидатора. 16/

Для приложений, чувствительных к задержке (например, полные узлы, маркет-мейкеры), мы поддерживаем пиринг и прямую подачу блоков через p2p. Для полных блоков приоритет распространения будет основан на весе доли (LSWQoS): пользователи с более высоким объемом зафиксированных ShMON получают блоки немного раньше, при этом учитываются пороговые значения включения. 17/

Это представляет собой отход от традиционного RPC с "лучшим усилием". При чтении запросов к RPC сумма зафиксированной ставки определяет количество запросов. Для блоков, отправленных с наших узлов, сумма зафиксированной ставки определяет порядок отправки. 18/

Безопасный доступ к контролю возможен на цепочках с высокой пропускной способностью, если стимулы, принуждение и наблюдаемость разработаны с нуля. ShMonad RPC является эталонной реализацией этой концепции. Мы с нетерпением ждем итераций и внешней проверки. 19/