Как повлияет на протокол Биткойн, если узлы будут хранить только те блоки, которые им нужны?

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

Такие ситуации довольно распространены, например:

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

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

  • очищать блоки, о которых они «не заботятся», если место для хранения ограничено
  • в типичном случае начинайте отправлять и получать биткойны после загрузки только нескольких наиболее релевантных блоков (и, конечно, всех заголовков)
  • и т.п.

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

Редактировать: я ищу лучший ответ, чем «я думаю, что это дестабилизирует сеть» здесь — я хочу увидеть некоторые предполагаемые воздействия на доступность блоков, накладные расходы сети вверх или вниз, когда меньшее количество загрузок контрастирует с повторным загрузка позже и т. д. Некоторые статистические данные о том, насколько взаимозависимы блоки сами по себе, будут иметь большое значение для получения надежного ответа.

Редактировать 2: прямо сейчас эта награда будет передана Шейддерсу через пару часов. Но если бы у кого-то была более подробная информация об информации, которую я запрашивал в своем первом редактировании, они определенно могли бы ее вырезать. Есть берущие?

Это актуально: gist.github.com/1059233
Для тех, кому лень нажимать ^ Гэвин рассматривает возможность использования этой техники для улучшения запуска в обычном клиенте.

Ответы (3)

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

Я думаю, что если это станет масштабным, это дестабилизирует всю сеть. Поскольку никто этого не хочет, он не станет обширным.

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

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

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

Следует отметить, что в основном такие «эгоистичные клиенты» используются во встроенных устройствах, где не только память, но и сетевые ресурсы и ресурсы ЦП находятся в большом почете. Текущие клиенты Android все «эгоистичны» и, вероятно, будут таковыми в течение некоторого времени. Поскольку у людей, использующих Биткойн на своих телефонах, почти наверняка есть узел с полным блокчейном дома, они, вероятно, не будут значительным источником сетевых проблем.
Я думаю, что в целях анализа сети Биткойн вы можете относиться к ней так, как будто этих клиентов не существует. Таким образом, они не приносят никакой пользы сети (хотя приносят пользу своим пользователям и валюте в целом), но и не наносят вреда. Они «эгоистичны», но их потребности также довольно минимальны. Они в полной безопасности, когда у них есть «известный доверенный» узел для подключения.
Проблема возникает, когда эти «эгоистичные» узлы становятся настолько многочисленными, что люди за брандмауэрами и т. д., которые ограничены 8 подключениями, не могут найти неэгоистичного клиента для подключения. Такие клиенты, безусловно, могут addnodeиспользовать один или несколько запасных вариантов , но в лучшем случае это некачественный обходной путь.
Надеюсь, к тому времени будет достаточно людей, управляющих «щедрыми» узлами, чтобы компенсировать недостаток. (Я управляю несколькими такими узлами, каждый из которых может обрабатывать более 1500 подключений. Самые загруженные редко видят более 300.) Все заинтересованы в том, чтобы сеть была стабильной и надежной.
BitcoinJ позволяет создавать таких клиентов. «Как я могу проверить цепочку хэшей, если я не могу убедиться, что каждая входная транзакция в ней действительно требует выходных данных предыдущей транзакции? Как я могу сделать это без полной таблицы транзакций?» Поскольку BitcoinJ подключается к доверенному узлу, он знает, что полученные блоки были проверены и содержат только входы, для которых есть выходы.
Пока сложность остается на приличном уровне, проверка совокупной сложности блокчейна через его заголовки будет чертовски хорошим индикатором того, с чего начать. Что касается проверки блоков или транзакций, вам придется просмотреть их «зависимости». Я ищу лучший ответ, чем «я думаю, что это дестабилизирует сеть» здесь — я хочу увидеть некоторые предполагаемые воздействия на доступность блоков, накладные расходы сети вверх или вниз, когда меньшее количество загрузок контрастирует с повторной загрузкой позже , так далее.
Т.е. некоторые статистические данные о том, насколько взаимозависимы блоки сами по себе, могли бы иметь большое значение для надежного ответа.

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