“Облачные” ноды Биткойна: полезны ли они для сети?
“Облачные” ноды Биткойна: полезны ли они для сети?
С момента запуска количество узлов Bitcoin Classic непрестанно увеличивалось. Pелиз альтернативного клиента “Classic 0.12” смог даже возглавить топ статистики, обозначив присутствие в сети 2552 узлов. Но если внимательно взглянуть на эту статистику, то в ней можно выявить некоторые странности.
Во-первых, данные по IP свидетельствуют о том, что многие узлы Bitcoin Classic могли вообще не быть настоящими нодами. Вместо этого один узел мог использовать несколько IP-адресов с целью подтасовки суммарного общего количества узлов. Такое предположение выглядит вероятным в свете наблюдений, что очень немногие узлы Bitcoin Core удалили клиента bitcoin-core и установили вместо него клиент Сlassic, а это говорит в пользу того, что это новые узлы, а не замена операторами узлов Core, которые они предварительно деинсталлировали.
Тем не менее, теоретически возможно, что многие новые пользователи просто запускают (и выключают) узлы Classic географически в одном и том же месте одновременно.
Но можно с определённостью утверждать, что львиная доля всех узлов Classic размещается в датацентрах, в основном на Amazon Web Services (AWS) и Choopa. Это неудивительно, так как специализированные веб-сайты предлагают подобного рода услуги, и такая практика поощряется сторонниками Classic. Кроме того, анализ показывает, что подавляющее большинство узлов в этих датацентрах почти наверняка были оплачены сравнительно небольшой группой людей.
В этой связи возникает вопрос: имеет ли смысл вообще содержать полные узлы в датацентрах? Выигрываeт ли Биткойн от резкого увеличения узлов Classic?
Давайте разберёмся почему кому-либо вообще может понадобиться запустить полный узел.
Проверка
Пожалуй, самая весомая причина содержать полный узел – это проверка транзакций.
Располагая полным узлом, пользователи могут проверить соответствует ли на самом деле транзакция всем правилами Биткойна. То есть, не используя ничего иного, кроме как программного обеспечения с открытым исходным кодом, операторы узлов могут удостовериться, что все полученные ими биткойны законно намайнены, правильно подписаны, и много в чём ещё. Это именно то, что делает Биткойн надёжным решением.
Также, это делает проверку популярным мерилом децентрализации, воплощенным в “стоимости содержания полного узла“. Ввиду того, что дешевле проверять (чем доверять), все больше людей могут участвовать в валидации, а это значит, что децентрализация Биткойна будет расти.
Кроме того, если пользователь может проверять транзакции с использованием своего собственного полного узла, то это даёт ему преимущество в конфиденциальности, так как у него отпадает необходимость показывать информацию об адресах кому-либо ещё.
Однако, технически эти рассуждения справедливы только тогда, когда узел на самом деле находится в месте физического расположения его оператора. Если пользователю приходится доверять датацентру в том, получает ли он верную информацию от узла, решение теоретически может перестать быть надежным. Хотя это и общепризнанный факт, что на практике пользователи всегда в определенной степени доверяют аппаратному и программному обеспечению, так что доверие по отношению к датацентру для большинства может быть приемлемым риском.
Что еще более важно: валидация действительно работает как задумано только тогда, когда используется для проверки входящих транзакций. Многие узлы сети Биткойна запущенные в датацентрах, однако, вообще не используются для проведения транзакций и, следовательно, не дают никаких преимуществ, касающихся проверки.
Вывод: Проверка транзакций Биткойн-узлами, запущенными в датацентре сомнительна. Если же узел, расположенный в датацентре, не занят проверкой транзакций, то с точки зрения валидации транзакций он бесполезен для сети.
Консенсус
Пересекается с предыдущей темой (но гораздо труднее измерим) – полные узлы также влияют на процесс сетевого консенсуса.
Полный узел добавляет “вес” к набору правил, которые он применяет: Любому, кто захочет обмениваться транзакциями с этим узлом (и оператором, который им управляет) придётся придерживаться правил этого узла. Чем больше узлов применяют одни и тех же правила, тем более эти правила “усиливаются” посредством коллективного сетевого эффекта.
Возможно, это и есть основная причина появления большого количества узлов Classic в сети. Они выступают в качестве голосов, давая понять, что пользователи готовы перейти на 2-мегабайтный максимальный размер блока.
Тем не менее, ввиду того, что в сети Биткойн есть нечто, напоминающее голосование, голоса не считаются по количеству узлов. Вместо этого, узлы по существу “голосуют” посредством своего экономического “веса”. Поскольку оператор, содержащий узел, предлагает бОльшую ценность сети – вспомните о влиятельных мерчантах, больших покупателях, крупных биржах и многих других – их экономический вес растёт.
Это значит, что совершенно не важно сколько узлов кто-то запустил. Использует ли влиятельный мерчант один узел или сотню – его общий экономический вес никак не меняется. А, следовательно, и его влияние на процесс сетевого консенсуса Биткойна также не меняется.
И опять же, большинство узлов, размещённых в датацентрах, вероятно, вообще не добавляют никакого экономического веса. Фактически они не используются для трансакций.
Вывод: Размещение узлов Classic в датацентрах не усиливает сколько-нибудь значимым образом процесс консенсуса сети Биткойн, если эти узлы не участвуют в проверке транзакций. Они смогли бы быть ролезны если бы использовались для транзакций, но наличие более чем одного узла у одного экономического субъекта бессмысленно с точки зрения консенсуса.
Децентрализация
Кроме стоимости эксплуатации узла, другое популярное мерило децентрализации это количество дверей, которые надо выбить, чтобы получить контроль над Биткойном или смочь его выключить.
Так как полные узлы служат хребтом Биткойна, полезно, чтобы их в сети было много … но только в случае, если они запущены большим количеством разных людей, и предпочтительно, чтобы эти люди были из разных географических регионов.
Если более чем один узел запущен в каком-то одном датацентре, то оператор этого датацентра полностью контролирует все эти узлы. А раз так, достаточно выбить всего одну дверь, чтобы взять под контроль все узлы в датацентре.
Вывод: Содержание более чем одного узла Classic в каждом из датацентров никак не добавляет децентрализации сети.
Ретрансляция
С технической точки зрения, пожалуй, самой важной задачей полного узла является ретрансляция транзакций и блоков другим узлам.
Более того, если большое количество узлов контролируется всего несколькими людьми, или тем более, если все узлы находятся физически в одном и том же месте, то они представляют собой единую точку отказа. Если такие узлы представляют значительную часть сети Биткойна и затем внезапно уходят в офлайн, или начинают ретрансляцию искаженных данных, это даже может временно стать дестабилизирующим фактором.
Тем не менее, существует сценарий, при котором размещение узлов в датацентрах может не быть бесцельным. Если произойдёт хардфорк Classic, но при этом из числа существующих узлов Bitcoin Core почти не будет переключений на Classic с целью начать принимать блоки большего размера, тогда узлы Classic, размещённые в датацентрах смогли бы помочь с ретрансляцией увеличенных блоков тем узлам, которые их принимают. Таким образом, запуск узлов Classic еще до того, как произошёл хардфорк, может служить сигналом для майнеров о том, что их потенциально большие блоки будут транслироваться в сеть. (К слову сказать, майнеров, предположительно, в первую очередь гораздо больше волнует раскол сети, а не потенциал ретрансляции в случае такого раскола.)
Вывод: Содержание узлов Classic в датацентрах в настоящее время не делает какого-либо значимого вклада в процесс ретрансляции блоков Биткойна и даже содержит небольшой риск. Существует сценарий, при котором узлы Classic, размещённые в датацентре, могут немного помочь Classic, но это преимущество носит по большей части теоретический характер.
Начальная загрузка
Всякий раз, когда новый узел Биткойн выходит в онлайн, он должен синхронизироваться с сетью. Для этого требуется, чтобы узел загрузил (и проверил) весь блокчейн, для чего ему необходимо подключиться к полностью синхронизированным узлам. Запуск узла в датацентре может помочь с этим.
Тем не менее, в данном случае многие новые узлы Classic, запущенные в датацентрах, работают на основе усечённого блокчейна. Они удаляют все данные блокчейна старше, чем пара дней. А значит, они бесполезны для синхронизации новых узлов.
Узлы Classic с полным блокчейном позволили бы загружать данные синхронизирующимся узлам. Но на самом деле это никогда не было действительно узким местом или проблемой, которая нуждается в решении. А если это когда-либо станет проблемой, то её на самом деле будет легко решить путём раскрутки полных узлов в датацентрах.
Вывод: Запуск узлов Classic в датацентрах мог бы быть полезен для синхронизации данных на новые узлы, но преимущество этого для сети незначительно.
SPV хосты
И последнее, полные узлы служат хостами для клиентов с Упрощенной Проверкой Оплаты (Simplified Payment Verification, SPV), таких как приложения мобильных кошельков. Поскольку SPV клиенты не хранят у себя весь блокчейн, они подключаются к полным узлам, на которых есть полная копия блокчейна, и запрашивают необходимые им данные.
Тем не менее, те узлы Биткойна, включая новые узлы Classic, на которых “устаревающие” данные блокчейна отсекаются, являются ограниченно годными для использования SPV узлами, поскольку они могут оказаться неспособны вернуть все запрашиваемые данные.
Более того, хостинг SPV клиентов никогда не был узким местом или проблемой, которая нуждается в решении. А если это когда-либо станет проблемой, то её будет легко решить.
Вывод: Запуск узлов Classic в датацентрах мог бы пойти на пользу процессу отдачи данных SPV узлам, но преимущество этого для сети незначительно.
Источник
07.08.2016, 19:43
