Чи може SPV підтримувати мільярд користувачів Bitcoin ? Оцінка вимоги про масштабування

Джеймсон Лопп — інженер-програміст у BitGo, творець statoshi.info та засновник bitcoinsig.com.

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

У дебатах щодо масштабування Bitcoin з’явилося нове твердження.

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

Давайте розберемося в цьому твердження та розглянемо його з різних точок зору.

Як працює SPV

Сатоші

описав дизайн високого рівня для SPV у білий папір Bitcoin, хоча це T реалізовано лише через два роки, коли створив Майк Хірн BitcoinJ.

Викинувши транзакції, які T стосувалися гаманця клієнта SPV, вдалося отримати значну економію використання диска. Знадобилося ще 18 місяців БІП 37 буде опубліковано, надаючи специфікацію для фільтрації транзакцій Блумом, таким чином покладаючись на корінь Merkle заголовка блоку для підтвердження включення транзакції в блок, як описав Сатоші. Це значно зменшило використання пропускної здатності.

Коли SPV-клієнт синхронізується з мережею Bitcoin , він підключається до ONE або кількох повністю перевірених вузлів Bitcoin , визначає останній блок на кінці ланцюжка, а потім запитує всі заголовки блоків за допомогою команди "getheaders" для блоків від останнього блоку, який він синхронізував, до кінця ланцюга.

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

Після синхронізації заголовків блоків і, можливо, завантаження фільтра Bloom, SPV-клієнт надсилає команду "getdata", щоб Request кожен окремий (можливо, відфільтрований) блок, який вони пропустили з моменту останнього входу в Інтернет, послідовно.

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

Масштабування клієнта SPV

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

Кожен заголовок блоку Bitcoin складається лише з 80 байтів, тож на момент написання це лише 38 мегабайт даних за всю восьмирічну історію блокчейну. Щороку (приблизно 52 560 блоків) додається лише 4,2 мегабайта, незалежно від розміру блоків у блокчейні.

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

через Освоєння Bitcoin

Деревоподібна структура даних Merkle настільки ефективна, що може представляти 16 мільйонів транзакцій із глибиною лише 24 – цього достатньо для представлення блоку 8 ГБ. Проте розмір доказу дерева Merkle для такої транзакції не перевищує 1 КБ!

📷через Освоєння Bitcoin

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

Але, на жаль, масштабувати мережу Bitcoin не так просто.

Масштабування сервера SPV

Хоча SPV неймовірно ефективний для клієнтів, це не стосується сервера, тобто повного вузла(ів), до якого клієнти SPV надсилають запити. Цей метод демонструє погану масштабованість з ряду причин.

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

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

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

Клієнтів BIP 37 SPV можна обманути через упущення. Щоб боротися з цим, клієнти SPV підключаються до кількох вузлів (зазвичай чотири), хоча це ще не гарантія – клієнти SPV можуть бути відокремлені від основної мережі через атаку Sybil. Це збільшує навантаження на мережу повних вузлів у чотири рази.

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

Збираємо цифри

На момент написання статті працює приблизно 8300 повних вузлів, які приймають вхідні з’єднання; близько 8000 з них рекламують NODE_BLOOM і, таким чином, повинні мати можливість обслуговувати запити від клієнтів SPV. Але скільки клієнтів SPV може обґрунтовано підтримувати поточна кількість повних вузлів прослуховування?

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

За замовчуванням у Bitcoin CORE встановлено максимум 117 вхідних з’єднань, що створить верхню межу в 936 000 доступних сокетів у мережі. Проте більшість із цих розеток уже спожито сьогодні.

Кожен повний вузол за замовчуванням підключається до восьми інших повних вузлів. Люк-молодший, розробник Bitcoin CORE (дуже грубо) кількість вузлів оцінює 100 000 загальних вузлів на момент написання; 92 000 з них T роблять розетки доступними для клієнтів SPV. Це з’їдає 800 000 доступних сокетів лише для повних вузлів, залишаючи лише 136 000 сокетів доступними для клієнтів SPV.

Це приводить мене до висновку, що близько 85 відсотків доступних сокетів споживаються мережевою сіткою повних вузлів. (Варто зазначити, що метод оцінки Люка-молодшого T може визначити, скільки часу вузли, які не слухають, проводять онлайн; звичайно, принаймні деякі з них періодично відключаються та знову підключаються.)

Мій вузол, який живить statoshi.info в середньому 100 однорангових вузлів (вісім вихідних, 92 вхідних) і 25 SPV-клієнтів. Це 80 відсотків доступних сокетів, які використовуються повними вузлами.

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

Щоб дати перевагу твердженням щодо масштабування SPV, я використаю деякі консервативні припущення, що кожен із мільярда користувачів SPV:

– Надсилайте та отримуйте ONE транзакцію на день.

– Синхронізувати свій гаманець із кінчиком блокчейну раз на день.

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

Мільярд транзакцій на день, якщо їх рівномірно розподілити (а вони точно не були б), призведе до приблизно 7 мільйонів транзакцій на блок. Завдяки великій масштабованості дерев Merkle, для підтвердження включення транзакції в такий блок знадобиться лише 23 хеші: 736 байт даних плюс у середньому 500 байт для транзакції.

Додайте ще 12 КБ заголовків блоків на день, і клієнт SPV все одно буде використовувати лише близько 20 КБ даних на день.

Однак 1 мільярд транзакцій на день генерує 500 ГБ даних блокчейну для повних вузлів для зберігання та обробки. І кожного разу, коли SPV-клієнт підключається та просить знайти будь-які транзакції для свого гаманця за минулий день, чотири повних вузли повинні прочитати та відфільтрувати 500 ГБ даних кожен.

Нагадаємо, що наразі для клієнтів SPV доступно близько 136 000 сокетів у мережі з 8 000 повних вузлів, що обслуговують SPV. Якщо кожен клієнт SPV використовує чотири сокети, то лише 34 000 клієнтів можуть синхронізуватися з мережею в будь-який момент часу. Якби в Інтернеті було більше людей одночасно, інші користувачі, які намагалися відкрити свій гаманець, отримували б помилки підключення під час спроби синхронізуватися з кінцем блокчейну.

Таким чином, для того, щоб поточна мережа підтримувала 1 мільярд SPV-користувачів, які синхронізуються один раз на день, тоді як лише 34 000 можуть синхронізуватися в будь-який момент часу, це 29 400 «груп» користувачів, які повинні підключатися, синхронізуватися та відключатися: кожен користувач повинен мати можливість синхронізувати дані попереднього дня менш ніж за три секунди.

Це створює BIT головоломку, оскільки вимагатиме, щоб кожен повний вузол міг безперервно зчитувати та фільтрувати 167 ГБ даних на секунду для кожного клієнта SPV. При 20 SPV-клієнтах на повний вузол це становить 3333 ГБ на секунду. Мені невідомо про пристрої зберігання даних із такою пропускною здатністю. Має бути можливість створити величезний масив RAID 0 твердотільні диски високого класу що може досягати приблизно 600 МБ/с кожен.

Вам знадобиться 5555 дисків, щоб досягти цільової пропускної здатності. Пов’язаний приклад диска коштує 400 доларів США на момент написання та має приблизно 1 ТБ ємності – достатньо для зберігання блоків на два дні в цій теоретичній мережі. Таким чином, вам знадобиться новий масив дисків кожні два дні, що обійдеться вам у понад 2,2 мільйона доларів США – це становить понад 400 мільйонів доларів США для зберігання блоків на рік із забезпеченням необхідної пропускної здатності читання.

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

Давайте спробуємо:

Що, якби у нас було 100 000 повних вузлів, на яких працюють дешевші обертові диски великої ємності, і ми якимось чином переконали їх усіх прийняти підключення клієнтів SPV? Що, якби нам також вдалося модифікувати повне програмне забезпечення вузла для підтримки 1000 підключених клієнтів SPV?

Це дасть нам 100 мільйонів розеток, доступних для клієнтів SPV, які зможуть підтримувати 25 мільйонів одночасних клієнтів SPV у мережі. Таким чином, кожен SPV-клієнт матиме 2160 секунд на день для синхронізації з мережею. Щоб повний вузол KEEP попиту, йому потрібно буде підтримувати постійну швидкість читання 231 МБ/с на клієнта SPV, що призведе до 231 ГБ/с за умови наявності 1000 підключених клієнтів SPV.

Жорсткий диск зі швидкістю 7200 об/хв може зчитувати приблизно 220 МБ/с, тому ви можете досягти такої пропускної здатності зчитування за допомогою масиву RAID 0 із BIT більше ніж 1000 дисків.

На момент написання статті ви можете придбати a Диск на 10 ТБ за 400 доларів, таким чином, RAID-масив цих дисків вартістю 400 000 доларів США дозволить вам зберігати блоки вартістю 20 днів – це означає набагато більш керовану суму в 7,2 мільйона доларів США для зберігання блоків вартістю в рік, дотримуючись вимог щодо пропускної здатності диска.

Варто зазначити, що ONE при здоровому глузді не запустить масив RAID 0 із такою кількістю дисків, тому що вихід з ладу одного диска пошкодить весь масив дисків. Таким чином, RAID-масив із відмовостійкістю буде ще дорожчим і менш продуктивним. Також здається неймовірно оптимістичним, що 100 000 організацій будуть готові вкладати мільйони доларів на рік, щоб запустити повний вузол.

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

Інакше багато клієнтів SPV не синхронізувалися б у години пікового використання.

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

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

Шукати золоту середину

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

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

Для того, щоб мережа Bitcoin підтримувала цільову кількість транзакцій на секунду (додаючи ємність для 86 400 чистих нових щоденних користувачів), ми можемо розрахувати вимоги до пропускної здатності диска для кожного вузла як:

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

Для наступні розрахунки, я використав такі припущення:

– Середній розмір транзакції в байтах = 500 байт на основі statoshi.info.

– Загальна кількість користувачів SPV = ONE на транзакцію на день.

– Сокети, споживані клієнтом SPV = стандарт із чотирьох.

– Кількість сокетів, доступних для клієнтів SPV на кожному повному вузлі = попередньо розраховане число 20.

– Загальна кількість мережевих розеток, доступних для клієнтів SPV = попередньо розраховане число 136 000.

– Вартість пропускної здатності жорсткого диска та простору = 400 доларів США за накопичувачі ємністю 10 Тбайт, 7200 об/хв у конфігурації RAID 0.

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

Для довідки нагадаємо, що Visa обробляє близько 2000 транзакцій в секунду. Для Bitcoin для цього знадобляться диски на суму майже 200 000 доларів, щоб KEEP від попиту на SPV. ONE момент, який варто відзначити, полягає в тому, що ці діаграми KEEP постійну кількість повних вузлів на рівні 8000 – насправді вони, ймовірно, зменшаться зі зростанням вартості, таким чином підвищуючи вимоги до пропускної здатності та витрати на експлуатацію решти вузлів, щоб зростати ще швидше.

Це, здається, додаткова сила централізації вузла.

(Ненаукові) опитування, які я проводив роком раніше, показали, що 98% операторів вузлів не платили б більше 100 доларів на місяць за керування вузлом, навіть якщо вони інвестували в Bitcoin. Я готовий посперечатися, що збільшення транзакцій біткойна в ланцюжку на порядок призведе до втрати більшості повних вузлів, тоді як збільшення на два порядки призведе до втрати 90% або більше вузлів.

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

Інші недоліки SPV

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

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

• Клієнти SPV довіряють майнерам правильно перевіряти та застосовувати правила Bitcoin; вони припускають, що блокчейн з найбільшим сукупним доказом роботи також є дійсним ланцюгом. Ви можете Навчання про різницю між моделями безпеки SPV і повного вузла в цій статті.
• Клієнти SPV припускають, що повні вузли не будуть брехати їм через пропуск. Повний вузол T може збрехати і сказати, що транзакція існувала в блоці, хоча її насправді T існувало, але він може збрехати, сказавши, що транзакція, яка існує в блоці, не відбулася.
• Оскільки клієнти SPV прагнуть до ефективності, вони Request дані лише для транзакцій, які їм належать. Це призводить до значної втрати Політика конфіденційності.

Цікаво, що співавтор BIP 37, Метт Коралло, шкодує про створення:

«Сьогодні великою проблемою для Політика конфіденційності користувачів у системі є фільтри BIP37 SPV. Вибачте, я це написав».

BIP 37 клієнти SPV з фільтром Bloom в основному немає Політика конфіденційності, навіть при використанні невиправдано високих показників хибнопозитивних результатів. Джонас Нік [інженер із безпеки в Blockstream] виявив, що за допомогою одного відкритого ключа він може визначити 70% інших адрес, що належать певному гаманцю.

[вставити]https://www.youtube.com/watch?v=HScK4pkDNds[/вставити]

Ви можете обійти низьку Політика конфіденційності SPV, розділивши фільтри Bloom між багатьма одноранговими вузлами, хоча це погіршило б масштабованість SPV, навантаживши більше повних вузлів.

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

Автор концепції атаки, CORE розробник Пітер Тодд, пояснює:

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

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

Наприклад, попередження про шахрайство працює, лише якщо ви дійсно можете отримати дані, необхідні для підтвердження шахрайства – якщо майнер не надає цих даних, попередження про шахрайство створити T . Таким чином, клієнти SPV T мають того рівня безпеки, який передбачав Сатоші.

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

Потенційні покращення

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

Зобов'язання фільтра Блума

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

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

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

Зобов'язання UTXO

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

Можливо, можна захиститися від DoS-атак фільтра Bloom, вимагаючи від клієнтів SPV надати докази роботи (неможливо на пристрої з живленням від батареї, як-от телефон) або мікроплатежі на основі каналів (неможливо запустити, якщо клієнт ще T отримав гроші), але жодне з них не пропонує прямого рішення.

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

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

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

Відповідні рішення для масштабування

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

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

З точки зору масштабування без довіри, протоколи рівня 2, такі як Lightning, пропонують набагато ефективніше масштабування, оскільки великі обсяги даних, що передаються, надсилаються лише невеликій кількості сторін, безпосередньо залучених до даної транзакції поза мережею. Ви можете подумати про це як про різницю між рівнем зв’язку Broadcast-to-all Ethernet і рівнем маршрутизації IP – Інтернет не міг T масштабуватися без маршрутизації, як і Інтернет грошей.

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

Існує також багато варіантів між ними, які можна вивчити:

– Централізовані схеми зберігання з ідеальною Політика конфіденційності , які використовують токени Chaum, наприклад HashCash.

– Централізовані системи підтвердження нульових знань, не пов’язані з позбавленням волі, такі як TumbleBit.

– Федеративні (напівдовірені мультипідписні) бічні ланцюгиhttps://elementsproject.org/sidechains/.

– Захищений майнером (напівнадійний) приводні ланцюги.

я все ще переконаний що в довгостроковій перспективі Bitcoin знадобляться набагато більші блоки.

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

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

Дякуємо Метту Коралло, Марку Ерхардту та Пітеру Тодду за рецензування та відгуки щодо цієї статті

Повідомлення: CoinDesk є дочірньою компанією Digital Currency Group, яка має частку власності в Blockstream.