Mempool Bitcoin: динаміка реле мережі

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

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

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

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

Скільки тертя перешкоджає поширенню

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

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

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

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

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

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

Толерантна меншина

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

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

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

Що робити, якщо немає меншини?

То що робити, якщо немає толерантної меншини? Що буде з цим класом транзакцій у цьому випадку?

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

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

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

Політика естафета не є заміною консенсусу

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

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

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