Может ли SPV поддержать миллиард пользователей Bitcoin ? Оценка масштабируемости заявления

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

В этой Мнение Лопп подробно разбирает утверждения о том, что можно безопасно снять ограничение на размер блока биткоина и вместо этого положиться на существующие методы «упрощенной проверки платежей» (SPV).

В дебатах о масштабировании Bitcoin появилось новое утверждение.

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

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

Как работает SPV

Сатоши

описал высокоуровневую разработку SPV вБелая книга Bitcoin, хотя это T было реализовано до тех пор, пока два года спустя Майк Хирн не создал BitcoinJ.

Отбрасывая транзакции, которые T имели отношения к кошельку клиента SPV, он смог получить существенную экономию использования диска. Потребовалось еще 18 месяцев для БИП 37для публикации, предоставляя спецификацию для фильтрации транзакций по Блуму, таким образом, полагаясь на корень Меркла заголовка блока, чтобы доказать включение транзакции в блок, как описал Сатоши. Это обеспечило значительное снижение использования полосы пропускания.

Когда клиент SPV синхронизируется с сетью Bitcoin , он подключается к ONE или нескольким полностью проверяющим узлам Bitcoin , определяет последний блок на конце цепочки, затем запрашивает все заголовки блоков с помощью команды «getheaders» для блоков, начиная с последнего синхронизированного им блока до конца цепочки.

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

После синхронизации заголовков блоков и, возможно, загрузки фильтра Блума, клиент SPV отправляет команду «getdata», чтобы последовательно Request каждый отдельный (возможно, отфильтрованный) блок, который он пропустил с момента своего последнего выхода в сеть.

После синхронизации клиент, если он остается подключенным к полному узлу(ам), будет получать только сообщения инвентаризации «inv» для транзакций, соответствующих загруженному фильтру Блума.

Масштабирование SPV-клиента

С точки зрения клиента, фильтрация Блума является очень эффективным средством поиска соответствующих транзакций в блокчейне, используя при этом минимальные ресурсы ЦП, пропускную способность и дисковое пространство.

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

Дерево Меркла, которое используется для доказательства включения транзакции в блок, также очень хорошо масштабируется. Поскольку каждый новый «слой», добавляемый к дереву, удваивает общее количество «листьев», которые оно может представлять, вам T нужно очень глубокое дерево, чтобы компактно доказать включение транзакции, даже среди блока с миллионами транзакций.

с помощью Освоение Bitcoin

Структура данных дерева Меркла настолько эффективна, что может представлять 16 миллионов транзакций с глубиной всего 24 — этого достаточно для представления блока размером 8 ГБ. Тем не менее, доказательство дерева Меркла для такой транзакции остается размером менее 1 КБ!

📷черезОсвоение Bitcoin

Совершенно очевидно, что с точки зрения клиента SPV сеть Bitcoin может быть масштабирована до блоков размером в несколько гигабайт, и у клиентов SPV не возникнет никаких проблем с обработкой небольших объемов требуемых данных — даже на мобильном телефоне с подключением 3G.

Но, увы, масштабировать сеть Bitcoin не так-то просто.

Масштабирование SPV-сервера

Хотя SPV невероятно эффективен для клиентов, то же самое не относится к серверу – то есть к полному узлу(ам), к которому клиенты SPV делают запросы. Этот метод демонстрирует плохую масштабируемость по ряду причин.

Узлы в сети должны обрабатывать чрезвычайно большой объем данных, чтобы вернуть результаты только для одного пира, и они должны повторять эту работу для каждого блока для каждого пира, который ее запрашивает. Дисковый ввод-вывод быстро становится узким местом.

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

Поскольку блокчейны являются формой реестра, предназначенного только для добавления, эта сумма никогда не перестанет расти. Без значительных изменений протокола обрезка блокчейна несовместима с BIP 37 — она ожидает, что все блоки будут доступны на всех полных узлах, которые рекламируют NODE_BLOOM.

Клиенты BIP 37 SPV могут быть обмануты путем умолчания. Чтобы бороться с этим, клиенты SPV подключаются к нескольким узлам (обычно четыре) хотя это все еще не гарантия – SPV-клиенты могут быть отрезаны от основной сети с помощью атаки Сивиллы. Это увеличивает нагрузку на сеть полных узлов в четыре раза.

Для каждого подключенного клиента 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 миллионов транзакций на блок. Благодаря большой масштабируемости деревьев Меркла, для доказательства включения транзакции в такой блок потребуется всего 23 хеша: 736 байт данных плюс в среднем 500 байт для транзакции.

Добавьте еще 12 КБ заголовков блоков в день, и SPV-клиент по-прежнему будет использовать всего около 20 КБ данных в день.

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

Напомним, что в настоящее время для клиентов SPV в сети из 8000 полных узлов, обслуживающих SPV, доступно около 136 000 сокетов. Если каждый клиент 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 дисков.

На момент написания статьи вы можете приобрестиДиск на 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. Извините, я это написал».

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

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

Проблему низкой Политика конфиденциальности SPV можно обойти, разделив фильтры Блума между множеством одноранговых узлов, хотя это еще больше ухудшит масштабируемость SPV, поскольку увеличит нагрузку на большее количество полных узлов.

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

Автор концепции атаки, CORE разработчик Питер Тодд, объясняет:

«Основная проблема заключается в том, что вы можете потреблять непропорционально большую часть пропускной способности дискового ввода-вывода при очень небольшой пропускной способности сети».

Даже по сей день оповещения о мошенничестве, описанные Сатоши в white paper, не были реализованы. Фактически, исследовательские работы в этой области показали, что реализация даже легких оповещений о мошенничестве может оказаться невозможной.

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

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

Возможные улучшения

Безопасность и масштабируемость SPV потенциально можно улучшить несколькими способами с помощью доказательств мошенничества, подсказок о мошенничестве, доказательств ввода, доказательств трат и т. д. Но, насколько мне известно, ни одно из них не прошло стадию концепции, не говоря уже о готовности к развертыванию в производстве.

Обязательства по фильтру Блума

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

Это снизит нагрузку на пропускную способность диска полного узла, но взамен увеличится пропускная способность как клиентов SPV, так и полных узлов, поскольку по сети придется передавать целые блоки.

Этот недавно предложенная компактная фильтрация на стороне клиента устраняет проблемы с Политика конфиденциальности , но требует загрузки целых блоков в случае соответствия фильтру (хотя и не обязательно через p2p-сеть!).

Обязательства UTXO

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

Защититься от DoS-атак с использованием фильтра Блума можно, потребовав от клиентов SPV либо предоставить доказательство выполнения работы (невозможно на устройстве с питанием от батареи, например, на телефоне), либо использовать микроплатежи на основе каналов (их невозможно инициализировать, если клиент еще T получил деньги), но ни один из этих вариантов не предлагает простого решения.

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

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

Достаточно сказать, что возможностей для совершенствования предостаточно — необходимо будет преодолеть множество проблем, чтобы улучшить масштабируемость в рамках сети.

Подходящие решения для масштабирования

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

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

С точки зрения масштабирования без доверия протоколы уровня 2, такие как Lightning, предлагают гораздо более эффективное масштабирование, поскольку большие объемы передаваемых данных отправляются только между небольшим числом сторон, напрямую вовлеченных в данную транзакцию вне цепочки. Вы можете думать об этом как о разнице между широковещательным-всем уровнем связи Ethernet и маршрутизируемым уровнем IP — T не может масштабироваться без маршрутизации, как и Интернет денег.

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

Также существует множество промежуточных вариантов, которые можно изучить:

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

– Централизованные системы доказательства с нулевым разглашением, не связанные с тюремным заключением, такие какTumbleBit.

– Федеративные (полудоверенные мультиподписные) сайдчейныhttps://elementsproject.org/sidechains/.

– Защищено майнерами (полудоверенно)приводные цепи.

Я все еще убежден что в долгосрочной перспективе Bitcoin потребуются гораздо более крупные блоки.

Но давайте проявим терпение и тактичность, постаравшись максимально эффективно масштабировать систему, сохранив при этом ее свойства безопасности и Политика конфиденциальности .

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

Благодарим Мэтта Коралло, Марка Эрхардта и Питера Тодда за рецензирование и предоставление отзывов по этой статье.

Раскрытие информации: CoinDesk является дочерней компанией Digital Currency Group, которая владеет долей в Blockstream.