Швидкі блокчейни створюють нові виклики для управління пропускною здатністю та справедливості RPC. Сьогодні ми представляємо механізм формування доступу до RPC за допомогою зобов'язань ліквідного стейкінгу. Система працює через ShMonad RPC від FastLane. У цій темі досліджується архітектура та обґрунтування. 🧵

Мережі з високою пропускною здатністю, такі як Monad (~0,5 с часу блоку, ~1 с завершеності), залишають мало місця для реактивного троттлінгу. До того моменту, коли кінцева точка RPC виявляє, що вона зазнала спам-атаки, шкоди вже завдано. Пом'якшення наслідків має бути проактивним і орієнтованим на стимули. /2

Ключовим обмеженням є пропускна здатність. Вузли, суміжні з валідатором, обмежені ресурсами та чутливі до затримок. Якщо інклюзивний доступ надається без розбору, зловмисні клієнти можуть витіснити чесних учасників, що призведе до зниження витрат на UX і валідатор без регресу. /3

Наше рішення використовує ShMonad, програмований токен ліквідного стейкінгу (LST) з можливостями ончейн-зобов'язань. Користувачі отримують приватну URL-адресу RPC в обмін на зобов'язання ShMON дотримуватися ончейн «Політики RPC». Це зобов'язання регулює обмеження швидкості доступу. /4

Пропускна здатність розподіляється пропорційно: RPS користувача = (ShMON користувача / загальний ShMON) × RPS_max-глобальний Це дає динамічно спільну, зважену за часткою модель пропускної здатності без впровадження централізованих обмежувачів швидкості поза ланцюгом. 5/

Стейкінг здійснюється на певний термін (наразі 20 блоків), що дозволяє кешувати. Ретранслятор періодично опитує та робить знімки стану зобов'язань у мережі. Це запобігає дзвінкам EVM на критичному шляху та підтримує використання високих частот без додаткової затримки. 6/

Емпірично ця система призводить до стабільно нижчої затримки. Під час кількох незалежних порівняльних сесій ShMonad RPC від FastLane демонструє на ~20 мс нижчий медіанний/середній час відгуку, ніж другий найшвидший провайдер, з більшим розривом у порівнянні з публічними RPC. 7/

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

Але для того, щоб забезпечити дотримання обмежень пропускної здатності надійно та без довіри, нам потрібно більше, ніж обмеження швидкості... Нам потрібне доведене правозастосування. Поки що користувачі обмежені в реле. Але дорожня карта включає в себе ончейн-системи захисту на основі nonce delta і підписаних квитанцій про використання. 9/

Мінімалістичний дизайн може порівнювати нонсеси облікового запису між висотами блоків n і m, а також слеш (тобто «застосувати доплату» і передати її валідатору) надмірне використання вище максимального RPS. Але є проблема: він вразливий до атак пакетного випуску ретранслятора, через що txs виглядає вибуховим.

Щоб пом'якшити цю проблему, ми вводимо другий канал: асинхронні квитанції про використання з часовими мітками. Коли транзакція подана, вона буде багатоадресною як валідатору, так і окремому «емітенту квитанцій». Емітент повертає відправнику підписаний об'єкт із позначкою часу та з метаданими nonce перед виконанням. Це усуває накладні витрати на відстеження та верифікацію через гарячий шлях між користувачем і валідатором. 11/

Ці квитанції (які будуть підписані) служать подвійній меті: 1. Зворотний зв'язок з користувачами: Якщо чеки перестають надходити, клієнти можуть добровільно зупинити трафік, щоб уникнути комісії за перевищення. 2. Доказ у ланцюжку: квитанції закріплюють тимчасову активність, усуваючи неоднозначність реального спаму від пакетування, спричиненого ретрансляцією. 12/

Ця модель підтримує як EOA, так і 4337 userOps (за умови непоширених пакетів або вертикальної інтеграції з нашим власним paymaster). У майбутніх версіях ми можемо вимагати, щоб особа, яка підписала транзакцію, збігалася з власником полісу або була внесена до білого списку під час виконання зобов'язань щодо політики. Уточнюється. 13/

Наша мета – перенести контроль у мережу без шкоди для продуктивності. Завдяки великому блоковому простору та швидкій завершеності Monad, подання державних доказів, перевірка квитанцій та стягнення плати за перевищення є життєздатними в мережі... Щось нездійсненне в більш дорогих мережах. 14/

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

Пропускна здатність RPC в даний час вимірюється в сукупності (txs + eth_call), але майбутні оновлення будуть дезагрегувати класи пропускної здатності. Запити на зчитування будуть спрямовуватися через регіонально оптимізовані вузли, видаляючи їх із вузького місця, створеного обмеженнями пропускної здатності валідатора. 16/

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

Це є відходом від традиційного ПКР «найкращих зусиль». При запитах на зчитування до RPC сума вкладеного стейку визначає кількість запитів. Для блоків, відправлених з наших вузлів, сума вкладеного стейкінгу визначає порядок відправки. 18/

Контроль доступу без довіри є життєздатним у ланцюгах з високою пропускною здатністю, якщо стимули, контроль і спостережливість розроблені на основі перших принципів. РПК «Шмонад» є еталонною реалізацією цієї тези. Ми з нетерпінням чекаємо на ітерацію та зовнішню перевірку. 19/