Чому продуктивність Blockchain важко виміряти

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

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

Масштабованість проти продуктивності

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

Ця відмінність є важливою: багато підходів до покращення продуктивності взагалі не покращують масштабованість, якщо їх правильно визначити. Простим прикладом є використання більш ефективної схеми цифрового підпису, такої як підписи BLS, які приблизно вдвічі менші за розмір підписів Schnorr або ECDSA. Якщо біткойн перейде з ECDSA на BLS, кількість транзакцій на блок може зрости на 20-30%, покращуючи продуктивність за ніч. Але ми можемо зробити це лише один раз — немає ще більшої схеми підпису, на яку можна перейти (підписи BLS також можна агрегувати, щоб заощадити більше місця, але це ще один одноразовий прийом).

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

Розуміння цієї різниці також допомагає уникнути поширеної помилки категорії, яка зустрічається у твердженнях на кшталт: «Блокчейн X дуже масштабований, він може обробляти Y транзакцій за секунду!» Друге твердження може бути вражаючим, але це а продуктивність метрика, а не метрика масштабованості. Це не говорить про можливість покращити продуктивність шляхом додавання ресурсів.

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

Затримка проти пропускної здатності

Класично продуктивність системи блокчейну оцінюється за двома вимірами, затримкою та пропускною здатністю: затримка вимірює, наскільки швидко може бути підтверджена окрема транзакція, тоді як пропускна здатність вимірює загальну швидкість транзакцій за час. Ці осі застосовуються як до систем рівня 1, так і до систем рівня 2, а також до багатьох інших типів комп’ютерних систем (таких як системи запитів до баз даних і веб-сервери).

На жаль, і затримку, і пропускну здатність важко виміряти та порівняти. Крім того, окремі користувачі фактично не піклуються про пропускну здатність (яка є системним показником). Що їх справді хвилює, так це затримки та комісії за транзакції — точніше, щоб їхні транзакції підтверджувалися якнайшвидше та якомога дешевше. Хоча багато інших комп’ютерних систем також оцінюються за принципом «витрати/продуктивність», комісія за транзакції є дещо новою віссю продуктивності для блокчейн-систем, яка насправді не існує в традиційних комп’ютерних системах.

Проблеми з вимірюванням затримки

Затримка спочатку здається простою: скільки часу потрібно для підтвердження транзакції? Але завжди є кілька різних способів відповісти на це питання.

По-перше, ми можемо вимірювати затримку між різними моментами часу й отримувати різні результати. Наприклад, ми починаємо вимірювати затримку, коли користувач натискає кнопку «відправити» локально або коли транзакція потрапляє в mempool? І чи зупиняємо ми годинник, коли транзакція знаходиться в запропонованому блоці, чи коли блок підтверджується одним наступним блоком чи шістьма?

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

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

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

Затримка – це розподіл, а не окреме число.

Спільнота дослідників мереж давно це зрозуміла (див., наприклад, це чудовий виступ Гіла Тене). Особливий акцент робиться на «довгий хвіст» розподілу, оскільки висока затримка навіть у 0.1% транзакцій (або запитів до веб-сервера) буде серйозно вплив кінцеві користувачі.

У блокчейнах затримка підтвердження може змінюватися з кількох причин:

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

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

Дисперсія консенсусного рівня: Для підтвердження транзакції на Рівні 1 зазвичай потрібен розподілений набір вузлів для досягнення консенсусу щодо блоку, що може додавати змінні затримки незалежно від перевантаження. Системи підтвердження роботи знаходять блоки в непередбачуваний час (також абстрактно процес Пуассона). Системи підтвердження ставки також можуть додавати різні затримки (наприклад, якщо недостатня кількість вузлів онлайн для формування комітету в раунді або якщо потрібна зміна перегляду у відповідь на збій лідера).

З цих причин хорошим керівництвом є:

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

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

Хорошим прикладом є мережі платіжних каналів (наприклад, Lightning Network). Класичне рішення для масштабування L2, ці мережі пропонують дуже швидкі підтвердження платежів більшу частину часу, але іноді вони вимагають скидання каналу, що може збільшити затримку на порядки.

І навіть якщо ми маємо хорошу статистику щодо точного розподілу затримок, вона, ймовірно, змінюватиметься з часом, оскільки змінюватиметься система та вимоги до неї. Також не завжди зрозуміло, як порівнювати розподіли затримок між конкуруючими системами. Наприклад, розглянемо одну систему, яка підтверджує транзакції з рівномірно розподіленою затримкою від 1 до 2 хвилин (із середнім значенням і медіаною 90 секунд). Якщо конкуруюча система підтверджує 95% транзакцій точно за 1 хвилину, а інші 5% – за 11 хвилин (із середнім значенням 90 секунд і медіаною 60 секунд), яка система краща? Відповідь, ймовірно, полягає в тому, що деякі програми віддадуть перевагу першому, а деякі другому.

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

Затримка складна. Чим більше даних повідомляється, тим краще. В ідеалі повні розподіли затримок повинні вимірюватися за різних умов перевантаження. Розбивка затримки на різні компоненти (локальна, мережева, пакетна, затримка консенсусу) також корисна.

Проблеми з вимірюванням пропускної здатності

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

Хоча «транзакції в секунду» (або tps) є фактичним стандартом для вимірювання продуктивності блокчейну, транзакції є проблематичними як одиниця вимірювання. Для систем, які пропонують програмування загального призначення («розумні контракти») або навіть обмежені функції, такі як мультиплексні транзакції біткойнів або опції багатопідписної перевірки, фундаментальна проблема:

Не всі операції однакові.

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

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

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

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

Загалом:

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

Компроміс між затримкою та пропускною здатністю

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

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

Оплата за транзакції

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

1. Наскільки великий ринковий попит на здійснення транзакцій?
2. Яка загальна пропускна здатність досягається системою?
3. Який загальний дохід система забезпечує валідаторам або майнерам?
4. Яка частина цього доходу базується на комісії за транзакції чи на інфляційних винагородах?

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

Зокрема, пункти 3 і 4 вище є фундаментальними питаннями проектування системи блокчейн, але нам бракує хороших принципів для жодного з них. У нас є певне розуміння переваг і недоліків надання майнерам доходу від інфляційних винагород порівняно з комісіями за транзакції. Однак, незважаючи на численні економічні аналізи консенсусних протоколів блокчейну, ми все ще не маємо загальновизнаної моделі того, скільки доходу має йти валідаторам. Сьогодні більшість систем будують обґрунтоване припущення про те, скільки прибутку достатньо, щоб валідатори поводилися чесно, не перешкоджаючи практичному використанню системи. У спрощених моделях можна показати, що вартість встановлення атаки 51% масштабується з винагородою для валідаторів.

Підвищення вартості атак — це добре, але ми також не знаємо, наскільки безпеки «достатньо». Уявіть, що ви збираєтеся відвідати два парки розваг. Один із них стверджує, що витрачає на 50% менше на обслуговування поїздок, ніж інший. Чи гарна ідея піти в цей парк? Цілком можливо, що вони більш ефективні та отримують еквівалентну безпеку за менші гроші. Можливо, інший витрачає більше, ніж потрібно, щоб забезпечити безпеку атракціонів без користі. Але також може бути так, що перший парк є небезпечним. Системи блокчейн подібні. Якщо ви виключите пропускну здатність, блокчейни з нижчими комісіями матимуть нижчі комісії, оскільки вони менше винагороджують (і, отже, стимулюють) своїх валідаторів. Сьогодні у нас немає хороших інструментів, щоб оцінити, чи це нормально, чи робить систему вразливою для атак. Загалом:

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

Висновок

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

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