Вступ: чому мої транзакції не включаються?

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

Чи допоможуть пріоритетні комісії?​

Пріоритетні комісії вирішують цю проблему, правильно? На жаль, не для більшості користувачів.

Уявіть собі такий сценарій. Ви хочете піти в кінотеатр на 100 місць у вашому місті, але в кінотеатрі діє ненормальна система продажу квитків: вони не публікують ціну квитка. Замість цього ви повинні сказати їм, скільки ви готові заплатити. (Скажімо, це 50 доларів.) Якщо попит високий, і хоча б 100 інших людей запропонували вищу ціну, пощастило. Якщо попит низький, ви в грі! Заковика: ви платите 50 доларів, навіть якщо театр порожній. Але на цьому досвід продажу квитків не закінчується. У цієї системи є ще одна дивина: ви повинні сказати театру про свою готовність заплатити перед тим, як вийти з дому. Очевидно, що придбання квитка в театр у цій системі є потенційно небезпечним досвідом для звичайної людини. Заможні, досвідчені люди, навпаки, можуть точно оцінити ціну квитка. Вони можуть встановлювати камери поруч із кінотеатром, щоб стежити за дорожнім рухом у режимі реального часу. Вони можуть використовувати цей трафік і зібрані історичні дані для оцінки попиту в той чи інший день. І вони навіть можуть купити гелікоптер, щоб швидше дістатися до театру, сказавши театру про свою готовність заплатити. Хоча можна ефективно використовувати цю систему продажу квитків, досвід жахливий для більшості людей, які хочуть піти в театр. Коли театр переповнений, багато хто з цих людей може взагалі не намагатися піти.

Точно так само важко оцінити «правильну» пріоритетну плату, необхідну для проведення транзакції на Solana.Це дуже коливається. Під час періодів великої конгестії гаманці, які використовують останні середні значення, ймовірно, переоцінюватимуть необхідну комісію, що призведе до переплати користувачів за включення транзакції. (І навіть з високою пріоритетною комісією, транзакція може ще не бути включеночерез природу багатопотокового постійного виробництва блоків.) У теорії пріоритетні комісії можуть оптимально розподіляти блок-простір. На практиці вони абсолютно невдаються. На щастя, є способи вирішення цих проблем, в кінцевому підсумку призводячи до дешевших транзакцій з кращим шансом на включення для більшості користувачів. Перш ніж поглиблюватися у рішення, давайте розглянемо деякі властивості ресурсу, який ми намагаємося розподілити: блок-простір.

Блокпростір: фіксована кількість, дико коливаючий попит​

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

У деяких відношеннях ринок може керувати розподілом блок-простору через ціноутворення; транзакції з більшою корисністю для відправника готові платити вищу ціну. Однак цей механізм не працює, коли користувачі не знають, яка ціна за блок-простір! Як вже обговорювалося вище, тільки пріоритетна комісія призводить до важких у визначенні цін на транзакції для більшості користувачів і має погані гарантії включення транзакцій. Інші блокчейни вирішили це питання, впровадивши механізм комісії за транзакцію (наприклад,EIP-1559 в Ethereum, та багатовимірні комісії в ЛавинаіПенумбраЦі механізми комісій реалізують легко оцінюваний базовий збір, який забезпечує передбачуваний «вступний збір» для мережі; цей базовий збір наближається до ​​справжньої ціни на включення транзакції.

Огляд: комісії Solana сьогодні​

Наразі Solana реалізує два механізми комісій: базову та пріоритетну. Ми можемо думати про базову комісію як про «плату за вхід» за використання мережі, а про комісію за пріоритет як про додаткову пораду, щоб стимулювати валідаторів включати одну транзакцію над іншою. Базова комісія Solana становить фіксовані 5000 lamport за підпис (зазвичай один за транзакцію). Як наслідок, користувачі, які надсилають прості перекази, сплачують таку саму базову комісію, як і користувачі, які грають у важкі комп'ютерні ігри в ланцюжку, а також як шукачі, які намагаються скористатися складними можливостями MEV. Таким чином, поточна базова комісія, що стягується, не точно відображає використання ресурсів транзакції (і «екстерналія», кажучи економічною мовою), що потенційно призводить до погано використанийблокпростір.

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

Чому механізм базової комісії?​

Базові комісії повинні бути функцією використаних ресурсів. Це споживання наразі вимірюється в обчислювальних одиницях (CUs), але може також включати інші ресурси, такі як доступ до облікового запису. Ми хочемо, щоб у користувача була більш передбачувана вартість участі, яка визначається динамічною базовою комісією. Ці комісії важко належним чином встановити. (Є багато академічних досліджень, включаючи наші власні, намагаючись впоратися з цим!) Однак будь-хто, хто стикався з невдалими транзакціями через мережеву затор, знає, що важливо також правильно налаштувати комісії, якщо ми хочемо, щоб мережа розвивалася.

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

Окрім того: пріоритетні комісії та MEV​

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

Оптимальні блоки

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

Хоча цей вигаданий механізм побудови блоків недосяжний, виявляється, що ми можемо придумати еквівалентний механізм, який можна втілити на практиці. Цей еквівалентний механізм спрямований на знаходження цін на ресурси, які мінімізують різницю між добробутом мережі і користувачів. Правильне встановлення цін на ресурси спрямовує стимули таким чином, що вартість ресурсів для мережі точно збалансована користю, отриманою користувачами та валідаторами, навіть якщо мережа не знає, яка це користь, і користувачі ніколи цього явно не вказують. Ці ціни потім призводять до блоків, які в середньому є «оптимальними». Таким чином, ми можемо зосередитися тільки на встановленні цих цін. (Для отримання більш технічних подробиць див.)цей документ.)

До механізму

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

Динамічні базові комісії

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

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

Багатовимірні комісії: місцеві ринки комісій​

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

Як конкретний приклад, розглянемо популярний розподіл NFT. Без ринків зі ставкою за рахунок цей розподіл значно збільшить базову комісію для всіх інших транзакцій. З ринками зі ставкою за рахунок вартість подання транзакцій для отримання NFT (і доступ до цієї частини стану) може збільшитися, тоді як комісії за інші транзакції (наприклад, поповнення застави по кредиту) залишаються в основному не змінними. Такий тип ринку місцевої комісії за рахунок, який розглядається в Чернетка документа про поліпшення Solana.

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

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

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

Альтернативні механізми​

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

1. подивіться на витрати ресурсів найновіших блоків (результат включених транзакцій);
2. обчислити функцію витрати (наприклад, відхилення від цілі);
3. потім оновіть ціни ресурсів, використовуючи вихід кроку 2 і просте правило.

У вищезазначених прикладах ми використовували різні варіанти ресурсів на кроці 1 та механізм оновлення на кроках 2 та 3. Метод перетворення вподобань у використанні ресурсів у конкретне правило оновлення комісії обговорюється в ця стаття.

Чи працює ця багатовимірна штука?

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

Стійка поведінка​

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

Розподіл зсувів​

Ми також тестуємо поведінку механізму під час зсуву розподілу: ми додаємо 150 транзакцій у блок 10, які потребують значної кількості ресурсу 2. Такий сценарій може з'явитися, наприклад, при виготовленні NFT. Багатовимірна ціноутворення призводить до значно вищої пропускної здатності, коли розподіл зсувається (ліворуч), відповідно налаштовуються ціни на ресурси (праворуч).

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

Висновок

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

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

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

1. Ця стаття розміщена з [Solanaumbraresearch], Пересилайте оригінальний заголовок«До багатовимірних комісій Solana», Усі авторські права належать оригінальному автору [@theo_diamandis、@tarunchitra、@0xShitTrader]. Якщо є зауваження до цього перепублікування, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно займуться цим.

2. Відповідальність за відмову: Погляди та думки, висловлені у цій статті, належать виключно автору і не становлять жодної інвестиційної поради.

3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат статей з перекладом заборонені.-