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

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


В заявлении о борьбе с биткойнами вновь заявляется новое требование.

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

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

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

Satoshi описал проект высокого уровня для SPV в бетонный лист , хотя он не был реализован до двух лет спустя, когда Майк Херн создал BitcoinJ ,


Ранние реализации SPV были весьма наивными – они загрузили весь блокчин, который был не более эффективным, чем полный узел с точки зрения пропускной способности.

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

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

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

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

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

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

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

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

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

с помощью Освоение биткойнов

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

с помощью Освоение биткойнов

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

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

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

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

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

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

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

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

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

Хруст числа

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

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

с помощью Bitnodes

Bitcoin Core по умолчанию имеет не более 117 входящих соединений, что создаст верхнюю границу 936 000 доступных сокетов в сети. Однако большинство этих гнезд уже потреблено сегодня.

По умолчанию каждый полный узел соединяется с восемью другими полными узлами. Разработчик Bitcoin Core Luke-Jr (очень грубый) количество узлов оценивает 100 000 общих узлов на момент написания; 92 000 из которых не делают сокеты доступными для клиентов SPV. Это съедает 800 000 доступных сокетов только для полных узлов, оставляя только 136 000 сокетов для клиентов SPV.

Это приводит меня к выводу, что около 85 процентов доступных сокетов потребляется сетевой сетью из всех узлов. (Стоит отметить, что метод оценки Luke-Jr не может определить, сколько времени не прослушивающие узлы проводят в Интернете, но, по крайней мере, некоторые из них периодически отключаются и повторно подключаются).

Мой узел, который работает statoshi.info в среднем 100 полных узлов (восемь исходящих, 92 входящих) и 25 клиентов SPV. Это 80 процентов доступных сокетов, потребляемых полными узлами.

Если мы хотим, чтобы даже один миллиард клиентов SPV мог использовать такую ​​систему, для их обслуживания потребуется достаточное количество ресурсов для всех узлов – сетевых сокетов, циклов ЦП, дискового ввода-вывода и т. Д. Можем ли мы выработать математику?

Чтобы придать утверждениям о масштабировании SPV преимущество сомнений, я буду использовать некоторые консервативные предположения, что каждый из миллиардов пользователей SPV:

– Отправлять и получать одну транзакцию в день.

Синхронизируйте свой кошелек с концом блокады один раз в день.

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

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

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

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

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

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

Это представляет собой немного загадку, потому что для каждого полного узла требуется постоянный считывать и фильтровать 167 ГБ данных в секунду на клиента SPV. На 20 SPV-клиентов на полный узел – 3,333 ГБ в секунду. Я не знаю о каких-либо устройствах хранения, способных к такой пропускной способности. Должно быть возможно создать огромный массив RAID 0 высокопроизводительные твердотельные диски которые могут достигать около 600 МБ / с каждый.

Для достижения целевой пропускной способности вам потребуется 5 555 дисков. Связанный пример диска стоит 400 долларов США в момент написания и имеет примерно 1 ТБ емкости – достаточно для хранения блоков в течение двух дней в этой теоретической сети. Таким образом, вам понадобится новый массив дисков каждые два дня, что обойдется вам в 2,2 миллиона долларов – это составляет более 400 миллионов долларов, чтобы хранить блоки на год, при этом сохраняя требуемую пропускную способность чтения.

Конечно, мы можем играть с этими предположениями и настраивать различные цифры. Можем ли мы создать сценарий, в котором стоимость узла более разумна?

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

Что, если бы у нас было 100 000 полных узлов, все работали на более дешевых, мощных вращающихся дисках, и мы каким-то образом убедили их всех принять клиентские соединения SPV? Что делать, если нам также удалось изменить полное программное обеспечение узла для поддержки 1000 подключенных клиентов SPV?

Это даст нам 100 миллионов сокетов, доступных для клиентов SPV, которые могут поддерживать 25 миллионов одновременных клиентов SPV в сети. Таким образом, каждый клиент SPV будет иметь 2160 секунд в день для синхронизации с сетью. Для того, чтобы полный узел не отставал от спроса, ему необходимо было поддерживать постоянную скорость чтения 231 МБ / с на клиента SPV, что привело бы к 231 ГБ / с при использовании 1000 подключенных клиентов SPV.

Жесткий диск на 7200 об / мин может читать около 220 МБ / с, поэтому вы можете достичь этой пропускной способности для чтения с массивом RAID 0, содержащим более 1000 дисков.

Во время написания вы можете приобрести Привод 10TB за 400 долларов , таким образом RAID-массив на 400 000 $ этих дисков позволит вам хранить блоки на 20 дней – это составляет гораздо более управляемый 7,2 млн. долл. США для хранения блоков в год, при этом все еще сохраняя требования к пропускной способности диска.

Вам нужно добавить по крайней мере 2 из них каждый день!

Стоит отметить, что никто в здравом уме не будет запускать массив RAID 0 с этим большим количеством дисков, потому что сбой одного диска повредит весь массив дисков. Таким образом, массив RAID с отказоустойчивостью будет еще более дорогим и менее эффективным. Также невероятно оптимистично, что 100 000 организаций будут готовы понижать миллионы долларов в год, чтобы запустить полный узел.

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

В противном случае многие клиенты SPV не смогут синхронизировать часы пиковой нагрузки.

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

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

Ищу среднюю землю

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

Но что, если мы перевернем этот расчет на его голове и вместо этого попытаемся найти формулу для определения стоимости добавления нагрузки в сеть за счет увеличения пропускной способности транзакции по цепочке?

Чтобы сеть биткойнов поддерживала целевое количество транзакций в секунду (добавив емкость для 86 400 чистых новых ежедневных пользователей), мы можем вычислить требования к пропускной способности диска для каждого узла:

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

Для следующие расчеты , Я использовал эти предположения:

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

– Общее количество пользователей SPV = 1 на транзакцию в день.

– Сокеты, потребляемые клиентом SPV = стандарт из четырех.

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

– Общие сетевые сокеты, доступные для клиентов SPV = предварительно рассчитанное количество 136 000.

– Стоимость пропускной способности жесткого диска и пространства = $ 400 10TB 7,200 RPM дисков в конфигурации RAID 0.

Мы видим, что с точки зрения пропускной способности диска он остается достаточно разумным, пока мы не превысим 100 транзакций в секунду. В этот момент вам нужно будет купить несколько дисков и разбить их в RAID-массиве, чтобы достичь требований к производительности.

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

Для справки, напомним, что Visa обрабатывает около 2000 транзакций в секунду. На биткойне для этого требовалось бы почти 200 000 долларов дисков, чтобы не отставать от спроса SPV. Следует отметить, что эти диаграммы содержат число постоянных узлов на уровне 8000 – в действительности они, вероятно, будут уменьшаться по мере увеличения стоимости, что повысит требования к пропускной способности и затраты на работу остальных узлов, которые будут расти еще быстрее.

Это, по-видимому, является составной силой централизации узлов.

Как я заключил в ” Как сохранить сеть узлов Bitcoin от централизации », одна из главных проблем конкуренции вокруг увеличения размера блока – это стоимость операции с узлом. Вышеприведенные вычисления дают нам представление о сложностях вычисления стоимости операции узла, поскольку в них задействовано так много переменных – эти вычисления сохранялись большая часть переменных постоянна и ориентирована только на стоимость дискового ввода-вывода.

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

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

Другие недостатки SPV

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

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

  1. Клиенты SPV доверяют шахтерам правильно проверять и обеспечивать соблюдение правил биткойна; они предполагают, что блок-цепочка с наибольшим кумулятивным доказательством работы также является действительной цепью. Вы можете узнать о различии между SPV и моделями безопасности полного узла в Эта статья ,
  2. Клиенты SPV предполагают, что полные узлы не будут лгать им бездействия. Полный узел не может лгать и сказать, что транзакция существовала в блоке, когда она на самом деле не существовала, но может заключаться в том, что транзакция, которая существует в блоке, не произошла.
  3. Поскольку клиенты SPV стремятся к эффективности, они запрашивают данные только для транзакций, принадлежащих им. Это приводит к массовой утрате конфиденциальности.

Интересно, что соавтор BIP 37, Мэтт Коралло, сожалеет о его создании :

«Сегодня большая проблема для конфиденциальности пользователей в системе – это фильтры Blo37 SPV. Извините, я это написал».

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

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

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

Автор доказательной концепции атаки, главный разработчик Питер Тодд, объясняет:

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

Даже по сей день предупреждения о мошенничестве, которые Сатоши описал в «Белой книге», не были реализованы. Фактически, исследовательские усилия в этой области показали, что, возможно, даже невозможно обеспечить легкие предупреждения о мошенничестве.

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

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

Потенциальные улучшения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть также множество вариантов, которые можно изучить:

– Централизованные схемы лишения свободы с идеальной конфиденциальностью, которые используют C Хаум такие как HashCash ,

– Централизованные системы контроля знаний, не связанные с лишением свободы, такие как TumbleBit ,

– Федеративные (полунадежные многозначные) боковые цепи ,

– Предохраняемая от мин (полу-доверенная) drivechains ,

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

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

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


Спасибо Мэтту Коралло, Марку Эрхардту и Питеру Тодду за просмотр и предоставление отзывов для этой статьи

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

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here