Переслати оригінальну назву: Solana & Механізми комісії за транзакції Ethereum: Пропозиції щодо покращення TFM Solana

Дякуємо Ендрю Фіцджеральду, Харшу Пателю, Джону Шарбоно, Кевіну Галлеру, Ланре Іге, Мерту Мумтазу, Пранаву Гаріміді, Райану Черну, Тао Чжу і Таруну Чітрі за відгуки та рецензії.

Вступ

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

Як попередник майбутніх статей про наші міркування щодо ринків гонорарів, ця стаття проаналізує існуючий ринок гонорарів у Солані та пов'язані з ним пропозиції щодо його вдосконалення. Ми формулюємо ці пропозиції разом з основними теоретичними цілями для будь-якого механізму трансакційних зборів (МТЗ), значною мірою запозичуючи роботи Тіма Рафгардена, Мар'ям Бахрані, Пранава Гаріміді, Хао Чунга, Елейн Ши та інших авторів. Ми будемо позначати ключові визначення в тексті символом **.

Загалом, ПМФ визначає:

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

Зрештою, ця стаття має на меті об'єднати багатство досліджень TFM, орієнтованих на Ethereum, з інноваційними розробками Solana.

Огляд Solana & Поточні TFM Ethereum

Солана проти основ Ethereum

Ми почнемо з огляду TFM Solana і порівняємо його з Ethereum. Це дозволить краще контекстуалізувати відповідні пропозиції, щоб ми могли працювати над модифікацією та вдосконаленням ПМФ. Для початку:

Базова комісія Solana становить фіксовані 5 000 лампортів (0,000005 SOL) за підпис, а більшість транзакцій мають один підпис. Він не враховує ширші обчислювальні ресурси транзакції (вимірювані в одиницях виміру).

Базовий тариф Solana Tx = (5,000 Lamports) x (кількість підписів у Tx)

Механізм базової комісії Ethereum відрізняється двома основними способами:

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

Отже, базова комісія Ethereum за транзакцію становить:

Базова комісія Ethereum Tx =(Поточна ціна газу в gwei) x (використаний газ в tx)

Користувачі Solana також можуть додати додаткову плату за пріоритет, щоб підвищити ймовірність включення. На відміну від базової комісії, пріоритетна комісія стягується за кожні запитувані для транзакції одиниці виміру. Транзакції Solana можуть включати наступні інструкції Розрахувати бюджет:

1. SetComputeUnitLimit - Транзакції можуть встановити максимальну кількість одиниць, яку їм дозволено споживати (максимум 1.4M одиниць на транзакцію). При виконанні транзакція може використати до цього запитуваного ліміту в одиницях. Якщо інструкція SetComputeUnitLimit відсутня, ліміт одиниць транзакції обчислюється як (кількість інструкцій у транзакції) х(200k одиниць).
2. SetComputeUnitPrice - кількість мікролампортів на кожну одиницю, яку транзакція пропонує оплатити в якості плати за пріоритет.

Збираю їх разом:

Плата за пріоритет Tx = (Ліміт Tx ЕК) x (Ціна ЕК)

Зверніть увагу, що ця комісія за пріоритет сплачується з повного запитуваних одиниць (незалежно від того, чи буде транзакція використовувати всю запитувану суму), на відміну від Ethereum, де комісія залежить від того, скільки газу фактично використано транзакцією.

Винагорода за комісію проти винагороди за валідацію

Хоча стимул для валідаторів надавати пріоритет транзакціям з високими комісіями знаходиться поза межами консенсусу, консенсус передбачає, що базова комісія і пріоритетна комісія спалюються/відправляються лідеру (поточному виробнику блоку) в Солані в пропорції 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. Впорядкування - користувач не просто хоче бути включеним в блок де завгодно, він хоче мати пріоритетний доступ до певного стану в певний час.

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

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

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

У межах блоку для послідовного запису на один рахунок ("шматок держави") може бути використано максимум 12 000 000 одиниць CU. Це приблизно та кількість CU, яку можна обробити одним потоком за 400 мс слоту при розумних вимогах до вузла. Тоді ліміт Солани на один блок становить 48 000 000 ВО. Поточна реалізація планувальника використовує чотири потоки для неголосуючих транзакцій, і 12M x 4 = 48M. Теоретично це означає використання більшої кількості ядер = збільшення лімітів CU. Масштабування за допомогою обладнання.

Планувальник недетерміновано надає пріоритет транзакціям з більш високими комісіями. Однак, як правило, це забезпечує менш надійні гарантії визначення пріоритетів, ніж механізми, подібні до тих, що описані у випадку з Ефіріумом сьогодні.

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

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

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

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

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

Недоліки поточного МФМ Солани

Хоча ПМФ Солани є дуже багатообіцяючою, вона також має певні потенційні недоліки:

Стимул до спаму

Як згадувалося вище, транзакції впорядковуються в порядку черговості (FIFO), як тільки вони надходять до виробника блоків. Крім того, вони схильні до недетермінованості як від мережевого джиттера, так і від випадкового розподілу потоків планувальником за замовчуванням. Хоча плата за пріоритет може підвищити ймовірність включення за певних обставин, все ще існує значний стимул для спаму транзакцій, щоб максимізувати ймовірність якнайшвидшого включення (наприклад, пошуковик поспішає ліквідувати дефолтну позицію на ринку кредитування). Зображення нижче від Jito Labs допомагає продемонструвати неоптимальну природу спам-транзакцій.

Джерело: Фонд Джито

Аукціон першої ціни

У наївному аукціоні першої ціни (FPA) користувачі просто подають ставки, найвища з яких потрапляє в блок. Однією з проблем FPA є те, що вони не дуже зручні для користувача. Користувачі повинні вгадувати, які ставки роблять інші користувачі, думаючи про те, до якої суми вони готові піднятися, потенційно затінюючи свою ставку, щоб не переплачувати, наприклад, на основі того, що, на їхню думку, пропонують інші.

Більш формально, модель FPA не є DSIC:

**Домінуюча стратегія, сумісна зі стимулами (DSIC): Якщо припустити, що виробник блоків чесно впроваджує TFM, то встановлена стратегія торгів повинна бути домінуючою стратегією для користувачів. Це означає, що користувачі будуть робити ставки (у комісіях за транзакції) за точною вартістю, яку вони приписують включенню транзакції [Chu22].

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

І навпаки, TFM Солани - це наївна FPA. Йому бракує надійного механізму, який би дозволив користувачам точно висловлювати свої побажання щодо включення блоків, і він не є DSIC. На практиці встановити правильну плату за пріоритет у потрібний момент є неймовірно складним завданням. Це непропорційно сприяє досвідченим учасникам, які мають більше можливостей обійти джиттер мережі та планувальника (наприклад, за допомогою спільного розміщення або спам-транзакцій).

Виплата 50/50 Burn/Validator 50/50

Як зазначалося раніше, Ethereum спалює 100% базової комісії, одночасно відправляючи 100% пріоритетної комісії виробнику блоку, в той час як в Solana і базова комісія, і пріоритетна комісія спалюються/виплачуються виробнику блоку в пропорції 50/50. Як наслідок, TFM Solana не є захищеним від ОКА:

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

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

Нещодавно запропонований SIMD-0109 запровадить механізм перекидання (подібний до того, що використовувався в аукціоні поза протоколом Джито-Солани) в протокол як власну інструкцію.

Відсутність привілейованих типів транзакцій

Транзакції голосування в Solana публікуються в ланцюжку і повинні бути включені в блоки, але кожен валідатор повинен оплачувати витрати на ці транзакції. Це становить значні фіксовані витрати (оплачувані приватно валідаторами), незважаючи на позитивні зовнішні ефекти від включення транзакцій голосування. Ці витрати посилюються тим, що транзакції з голосуванням є надто дорогими порівняно з витраченими одиницями (тобто, вони використовують відносно мало одиниць порівняно з середньою транзакцією). Економічні чинники створюють тут централізуючий ефект, оскільки загальна вартість голосування є приблизно постійною для будь-якого валідатора, а отримана винагорода пропорційна вазі голосу.

Джерело: Ceteris, Солана Моноліт

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

Місцевий ринок гонорарів Солани

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

Можливо, це не є справжнім механізмом місцевих зборів. Механізм не працює на основі консенсусу (він працює лише на рівні планувальника), а зв'язок між платою за пріоритет і включенням блоку є досить недетермінованим (як зазначалося раніше). У ній також відсутнє поняття "еластичності", коли існують як цільові, так і максимальні межі ресурсів.

Неефективне використання коштів ТС & Запити

Оскільки базовий збір Солани не враховує МС, він не стимулює транзакції до укладання угод:

1. Ефективно використовуйте одиниці - транзакція з 1,4 мільйонами одиниць має таку ж базову комісію, як і транзакція з 100 тисячами одиниць, за інших рівних умов.
2. Ефективно запитуйте одиниці - навіть якщо транзакція використовує 50 тис. одиниць, базова комісія за неї однакова незалежно від того, чи запитується 100 тис. одиниць, чи 1 млн. одиниць.

Це може призвести до переоцінки планувальником обчислень, необхідних для даного блоку, і втрати ефективності порівняно з ресурсами, необхідними виробнику блоків у даному слоті. ЦФМ DSIC вирішить цю проблему, оскільки домінуючою стратегією користувача буде стратегія встановлених торгів - в даному випадку, точно відображаючи очікуване використання ОУ.

Безкоштовне створення облікових записів для блокування

Як згадувалося раніше, транзакції Solana заздалегідь визначають всі облікові записи, які вони будуть читати або писати під час виконання. Однак сьогодні цим механізмом можна зловживати для глобального блокування будь-якого облікового запису фактично без жодних витрат. Наприклад:

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

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

Заявки на фінансування в рамках ПМФ & Рамки

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

Багатовимірні ринки блокчейн-платежів

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

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

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

У цій статті 2022 року Діамандіс, Еванс, Чітра та Ангеріс аналізують, як побудувати багатовимірні ринки гонорарів, подібні до цього. У своїй роботі вони розглядають проблему побудови TFM з точки зору дизайнера мережі, який прагне максимізувати добробут (або загальну корисність) користувачів блокчейну за вирахуванням споживання ресурсів цими користувачами, з урахуванням обмежень на транзакції та блоки (наприклад, лімітів смарт-контрактів або лімітів ТС/газу). Основний результат роботи полягає в тому, що, незважаючи на те, що добробут невідомий, вони розробляють механізм, який максимізує його, і показують, як явно побудувати цей механізм.

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

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

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

Хоча в документі 2022 року загалом обговорюється багатовимірне ціноутворення на базові ресурси (наприклад, обчислення, пропускна здатність, зберігання), також можна впровадити багатовимірне ціноутворення на ресурси за обліковим записом (тобто, за "частиною держави"). Кожен обліковий запис розглядається як окремий ресурс. Про це йдеться в цій нещодавній статті, яка ґрунтується на оригінальній статті. Індивідуальне ціноутворення на акаунти(а не на обчислення, зберігання, пропускну здатність тощо) як на базовий ресурс також може бути більш простим у впровадженні зі зниженим ризиком атак на вичерпання ресурсів.

Експоненціальна комісія за акаунти з блокуванням запису

Після нещодавньої публікації Анатолія про економіку виконання SVM, Тао Чжу, у співпраці з Анатолієм, запропонував SIMD-0110. Його основна мотивація полягає в тому, щоб стримувати спам за допомогою економічного тиску (тобто цілеспрямовано збільшувати плату з часом, щоб зменшити стимули для спаму), що призведе до більш ефективного використання мережевих ресурсів. Невдалі арбітражні транзакції продовжують заповнювати приблизно половину (або більше) блокчейну Solana, тому що спам - це раціонально і неймовірно дешево.

Для цього рекомендується відстежувати експоненціальну ковзну середню (ЕКС) використання одиниць кожного рахунку за блок, щоб досягти цього. Вартість блокування облікового запису зростатиме в геометричній прогресії на основі використання відповідних задніх одиниць, що стримуватиме спам. Основна логіка схожа на те, як EIP-1559 встановлює глобальну базову плату Ethereum як функцію використання газу в трейлінгових блоках. Однак ця SIMD є набагато більш деталізованою у встановленні локальних ринків базових платежів для кожного облікового запису.

Основна ідея реалізації змінної плати за блокування запису на основі облікового запису полягає у наступному:

1. Відстежуйте використання EMA-обчислювальних ресурсів кожного спірного рахунку за останні 150 слотів.
2. Максимальна кількість акаунтів, які будуть відстежуватися - 2048, при цьому відстежуються лише найбільш спірні акаунти з найвищою вартістю блокування запису.
3. Якщо використання обчислювальних одиниць EMA акаунта становить >50% від максимального ліміту CU, вартість блокування запису збільшиться на X%. Якщо він <50% від свого ліміту, то ставка витрат зменшиться на X%.
4. V0 рекомендує початкову вартість блокування запису в 1000 мікроламортів/UU і швидкість коригування вартості в 1% за слот (зверніть увагу, що точні відсотки тут можуть бути змінені, враховуючи ранній характер пропозиції).
5. Комісія за блокування запису для рахунку в даному блоці розраховується шляхом множення ставки вартості блокування запису на запитувані транзакцією одиниці виміру.
6. Транзакції продовжують сплачувати комісію за підпис, і необов'язкова плата за пріоритет також залишається.
7. Зібрані збори за блокування запису спалюються на 100%.
8. Зібрані пріоритетні збори винагороджуються на 100%.
9. Зібрані підписи на 50% спалюються, а на 50% винагороджуються.

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

Ми можемо визначити властивість MMIC наступним чином:

**Сумісність стимулювання короткозорих майнерів (MMIC): Виробник блоків максимізує свою корисність, не створюючи фальшивих транзакцій і дотримуючись встановлених правил TFM. Короткозорий означає, що ця мета стосується лише поточного блоку при оцінці максимізації корисності [Rou21].

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

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

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

Потенційна критика полягає в тому, що локальні ринки, які базуються на рахунках (особливо ця пропозиція, яка вимагає постійного розрахунку ЕМА для кожного рахунку), можуть бути дорогими в обчислювальному плані. Цей тип багатовимірної комісії є необмеженим, враховуючи, що будь-який рахунок може бути перевантажений, що, ймовірно, створить труднощі для такого TFM. Однак у випадку SIMD-0110 цього можна уникнути, встановивши верхню межу на кількість рахунків, EMA використання яких може бути відстежено в певний момент часу.

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

Враховуючи, що включення блоків Solana все одно буде недетермінованим, навіть якщо ця пропозиція буде реалізована, потенційно можуть виникнути проблеми з тим, щоб користувачі точно оновлювали свої заявки в реальному часі, щоб забезпечити включення їх транзакцій в блоки. Подальше вирішення цієї проблеми вимагає внесення змін до планувальника, про що ми поговоримо в наступному розділі.

Зміни у планувальнику за замовчуванням Solana

Як обговорювалося раніше, "планувальник" - це алгоритм за замовчуванням, включений в клієнт валідатора Solana Labs, який планує транзакції на виконання і безперервно збирає блоки. Він відіграє неймовірно важливу роль на ринку комісій Solana, навіть якщо його поведінка за замовчуванням не передбачена протоколом, оскільки валідатори можуть використовувати інші алгоритми. Тут ми зосередимося на поточному планувальнику та майбутніх запропонованих змінах, над якими працює Ендрю Фіцджеральд (Andrew Fitzgerald).

Поточний планувальник Solana вносить "джиттер" в обробку транзакцій користувачів, випадковим чином призначаючи їх на один з чотирьох потоків транзакцій без права голосу (ще два потоки зарезервовані для обробки транзакцій з правом голосу) перед тим, як спробувати відсортувати невиконані транзакції за пріоритетністю і перевірити відповідні блокування ("захоплення блокування"), як показано на діаграмі нижче. Кілька пакетів транзакцій витягуються для розподілу на потоки під час "Банківської стадії" - процесу, що виконується валідатором Solana, в якому обробляються транзакції, і під час якого відбувається процес планування.

Джерело: Ендрю Фіцджеральд, банківський менеджер і планувальник Solana

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

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

Джерело: Ендрю Фіцджеральд, банківський менеджер і планувальник Solana

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

Планувальник використовує алгоритм, який називається "пріо-граф", що є прямим акриловим графом, який починається з транзакцій з найвищим пріоритетом (комісією) і лініями (або, точніше, ребрами) між даною транзакцією з найвищим пріоритетом і наступними транзакціями з найвищим пріоритетом, які конфліктують з нею через перекриття блокувань. Це (попередньо) зроблено для вікна "look-ahead" з попередньо налаштованим розміром 2,048 (може бути змінено) транзакцій, які можуть бути додані до графа - наступні діаграми показують роботу пріо-графа для заданого набору транзакцій, де ребра між ними представляють конфліктуючі блокування.

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

Плата за списання коштів з рахунку, що підлягає відшкодуванню (PRAW)

АвторамиSIMD-0016 є Godmode Galactus та Макс Шнайдер (Max Schneider ), які пропонують плату за запис на програмний рахунок, що підлягає відшкодуванню (PRAW). Це дало б розробникам додатків значний контроль, оскільки вони могли б встановлювати критерії сплати та знижки на ці збори, що дозволило б їм стимулювати та дестимулювати поведінку користувачів на свій розсуд.

Наразі програми Solana не мають можливості штрафувати транзакції за отримання блокування запису над їхнім станом. Плата за PRAW дозволить власникам акаунтів Solana стягувати плату за невдалі транзакції, які блокують їхній стан. Ці збори будуть перераховані на рахунок з можливістю запису, який вони заблокують. Однак власники акаунтів можуть встановлювати ці комісії таким чином, щоб вони поверталися користувачеві в кінці транзакції, якщо вона відповідає визначеним критеріям.

Зокрема, це може утримати користувачів від блокування облікових записів, які вони насправді не використовують для виконання транзакцій. Наразі це можливо, враховуючи те, що в Солані наразі немає перевірки, чи буде певний обліковий запис апріорі використовуватися певною транзакцією, яка заблокувала його на запис. PRAW пропонують програмам спосіб дестимулювати транзакції, які блокують стан програми в спробі виявити можливість з наміром повернутися назад, якщо ця можливість більше не є дійсною на момент виконання. Ці комісії застосовуються, навіть якщо транзакція зазнає невдачі під час виконання.

І навпаки, користувачі можуть вказати максимальну суму комісії PRAW, яку вони готові сплатити за транзакцію. Будь-яка комісія, зазначена в транзакції, що перевищує поточну комісію PRAW для даного рахунку з блокуванням запису, буде відшкодована.

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

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

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

На противагу цьому, хоча члени дослідницької спільноти Солани, безперечно, розділилися в думках щодо запровадження базових зборів ЕМА, існує загальна згода щодо додавання певного компоненту до базового збору, який би масштабувався відповідно до МС. Це може стимулювати точну оцінку ТС та ефективне використання ТС розробниками.

Прощальні думки

Унікальні інженерні та експлуатаційні цілі Solana вимагають унікальних міркувань щодо ПЦМ. Звичайно, просте перенесення існуючого ринку комісій Ethereum на Solana не є рішенням проблеми, але з цього можна винести цінні уроки. Це дуже актуально для механізмів, які є одночасно і тими, і іншими:

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

Як для Solana, так і для Ethereum, внутрішньопротокольні та позапротокольні механізми, ймовірно, співіснуватимуть і розвиватимуться разом у майбутньому. Баланс між ними - одне з фундаментальних питань при проектуванні цих систем. Дебати навколо SIMD-0110 часто зосереджуються навколо двох протилежних точок зору:

1. Покращення планувальника та мережі для зменшення джиттера достатньо для вирішення описаних тут проблем, тому серйозні зміни у внутрішньому протоколі TFM не потрібні.
2. Хоча позапротокольні покращення планувальника та мережі є необхідними, вони за своєю суттю є недостатніми. Потрібен внутрішньопротокольний економічний тиск.

Багатовимірне ціноутворення на ресурси в тій чи іншій формі, безумовно, є цінним в обох випадках. Ethereum починає впроваджувати такий TFM на рівні базових ресурсів, з EIP-4844, який відокремлює дані blob з ринку виконання. І навпаки, Солана просуває багатовимірне ціноутворення на ресурси на рівні індивідуальних рахунків, щоб започаткувати "місцеві ринки платежів".

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

Оскільки Eclipse наближається до запуску нашої магістральної мережі, ми також раді поділитися інформацією про те, як ми будемо застосовувати цю існуючу роботу в нашому власному TFM, який, безумовно, буде продовжувати розвиватися протягом наступних років. Ми маємо намір експериментувати і просувати механізми в цій сфері. Суттєвою перевагою модульної парадигми є те, що вона дозволяє легше перехресно запилювати дослідження та інженерію з різних екосистем. Цей темп експериментів тепер тільки зростатиме, приносячи користь усім, хто будує тут у довгостроковій перспективі.

Відмова від відповідальності:.

1. Ця стаття передрукована з[Eclipse], Переслати оригінальну назву 'Solana & Механізми плати за транзакції Ethereum: Пропозиції щодо покращення TFM Solana", всі авторські права належать оригінальному автору[Eclipse]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.