Я больше озабочен количеством интер-узлов трафика.
Клиент может принять решение не хранить все, но информация все же должна быть передана в соответствии с проектом.
Проще говоря - когда число пользователей является большим сам размер блока будет слишком большой, чтобы быть полезным.
Блок должен провести 10 минут _все_ сделок или система начинает отстающую и время транзакции будет расти до бесконечности.
Давайте предположим, что каждый пользователь делает по крайней мере 1 транзакцию в день. Есть 144 блоков в день.
Миллион пользователей *, скажем, 100 байт на транзакции / 144 = почти 1 МБ в каждом блоке = 6 Мб / час постоянной входящий трафик к каждому клиенту.
Вот почему я не думаю, что это то, что может быть легко решена. Люди делают вид, что масштабируемость это просто функция, которую можно легко добавить "при необходимости",
Это может быть не так. Будучи программистом, я знаю, как трудно решить O (n2) алгоритмы.
Я боюсь, что это вся конструкция Bitcoin, что делает его неприступным, и что это не может быть решено без серьезной модернизации.
По существу, создавая совершенно новую валюту. Вот почему я не вижу Bitcoin как любое доказательство правильности концепции.
Кажется, что вы до сих пор игнорирует кэшированные / общие & Запрашиваемые / Опрошенные варианты данных, доступных для программистов (вы говорите, что вы один).
Давайте не будет неправильно считать, что каждый клиент должен видеть каждую транзакцию. Многие клиенты даже не были изобретены еще, например, для многих мобильных устройств, а также для тех, кто на медленных или дорогостоящих соединений. Так что вы говорили о проблемах "по дизайну" не нужно применять к ним. ("По дизайну" это термин Microsoft используется для оправдания компании делать надлежащего проектирования программного обеспечения и на самом деле решения проблем. "По замыслу, эта ошибка существует во всех версиях Windows, начиная с Windows 3.1, и мы не имеем никакого намерения ее фиксации.")
Любой клиент, который не может обрабатывать весь блок цепи может просто установить безопасное низкоскоростное соединение с доверенным клиентом, который может. Например, по вашему запросу на вершине горы телефон на базе компьютера с дорогим подключением к спутниковой интернет может просто спросить (опрос) на рабочем столе назад в городе на текущий баланс вашего кошелька, так и для текущего количества подтверждений есть для горстка платежей он лично отправлено или получено. Таким образом, мобильный телефон или коммутируемого клиент только должен запросить хорошо подключен один за несколько кусков данных на нерегулярной основе.
Давайте также не претендуем Интернет не может расти, если это необходимо, чтобы приспособить критическую финансовую инфраструктуру - хотя значительное увеличение пропускной способности не должно быть необходимо, как только что обсуждал.
Что касается распределения всех или части истории массивного блока цепи касается, в кэше (зеркальная) скопировать из облака (при условии, скажем, Akamai) будет достаточно, при условии, что сохраняется возможность подключения к отдельным клиентам в случайном порядке, чтобы получить копии из последних блоков. Последние блоки проверка предшествующих блоков (а не только наоборот), так что Akamai не может просто изобрести ложный блок-цепь для распространения для удовольствия & прибыль.