Я буду отвечать на масштабируемости секции Dan Kaminskys слайдов. Может быть, теперь Дэн белый список, он может комментировать.

   http://www.slideshare.net/dakami/bitcoin-8776098

Я считаю, что он представил это в Blackhat. Как автор страницы Масштабируемость, я был удивлен, чтобы прочитать "Эпическая масштабируемость цитата" который пришел от меня

Хорошо, первый, я на самом деле не думаю, что построение распределенной supernode было бы очень трудно. Возможно, мои взгляды на построения распределенных систем были извращены потратив ~ 5 лет на Google, но Bitcoin узлы являются одним из самых простых вещей, которые я видел распространиться на куче машин. Честно говоря, я не описывал, как сделать это на вики-странице, и страница сама мешанина вещей вместе взятых в разное время. Постараюсь и очистить его немного на следующей неделе. В частности, он смешивает вещи, которые и сегодня с вещами, которые могли бы быть тривиально в будущем, и это не всегда ясно, что есть что.

Ядро узкое в узле Bitcoin проверяет сделки, как они поступают из сети вещания. Другие вещи, узлы делают либо редко (с рецидивами Orgs) или уже распределены (добыча) или потенциально дорогие в нескольких необычных ситуациях, например, если вы отправлять и получать тонны тратит от вашего кошелька конкретно (большой BitBank как InstaWallet) , Если вы постоянный торговец, поставщик услуг или даже радиолюбителям ваш узел будет тратить 99% своего времени проверки операций.

Вот один из способов вы можете распределить нагрузку проверки ТЕ: добавить новый ключ командной строки, вызовите его -trustednode = 1.2.3.4: 8333. Операции, полученные от доверенного узла не будет проверяться, они неявно предполагается действительным и включен в текущем блоке. Очевидно, что это очень опасно для обозначения любого узла, кроме других вы бежите себя как надежные. Поднимают некоторые узлы на разных машинах и установить их все, чтобы соединиться друг с другом в качестве доверенных узлов. Эти движки не подвергается непосредственно к сети p2p. Вместо балансировка нагрузки ставятся перед ними. Балансировки нагрузки не является доверенным узлом. Он не может даже быть основан на Satoshis коде. Его работа состоит в том, чтобы принять сделку, а затем отправить его на один из движков на основе некоторой функции сегментирования, например, деление на ОМ хэше. При получении ОГО от балансировки нагрузки, базовая машина проверяет его, а затем передает его на другие бэкэндов, которые затем пропускают проверку. Узлы должны оставаться в синхронизации, как они видят одни и те же операции.

Будет ли балансировочный груз стать узким местом? Я сомневаюсь в этом. Серверы в Google способны обрабатывать тысячи RPCs в секунду на ядро. Один 16-ядерный сервер может уравновесить весь трафик Bitcoin потребности в течение многих лет роста. Если один день трафик настолько велик, одна машина не может даже загружать их баланс, фильтрация может быть добавлена ​​к протоколу поэтому соединение может выбрать, чтобы получить только часть всего трафика (например, выбранный хэш снова).

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

При хранении, Дэн не говоря уже о возможности сделать ТХ обрезку (возможно, потому что это, как и многое другое, пока не реализовано). были вычислены около 70% дискового пространства, учитывая текущее состояние экономики, хотя изменения в том, как используется Bitcoin бы изменить эту цифру, а также экономия. Tx обрезка делает выдающиеся линейные хранения в количестве неизрасходованных результатов, а не общая истории экономики.

Дэн утверждает, что суперузлов являются в основном банки. Я не согласен. Слово "банка" сочетает в себе много разных вещей вместе. Высокая емкость Bitcoin узла не имеет свойства традиционных банков - они не делают кредиты, взять на себя клиент и т.д. Они просто отслеживать и проверять сделки. Dans предположение, что суперузлы будут часто в сочетании с другими функциями, как хостинг народов бумажников и добычи. Я не вижу каких-либо технических причин, которые должны быть так, хотя это может оказаться, что путь по другим причинам.

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