Для чего нужен собственный полный узел?

Зачем запускать собственный полный узел (ноду) и какие это даёт преимущества? Это, вероятно, вопрос № 1, множество раз задававшийся в блокчейн-комьюнити. Одна вещь, которую я узнал – и продолжаю придерживаться этого мнения – заключается в том, что для успешного функционирования сети, подобной ETC, важно не только количество узлов ETC, но также их качество и безопасность.

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

Узлы в блокчейн-технологиях, подобной ETC, являются неотъемлемой частью всей экосистемы, особенно с учётом того, что ETC представляет собой 100% децентрализованную p2p-сеть (мы вернёмся к этому позже), и основное назначение узла – подключение к другим узлам, загрузка и синхронизация с данными из блокчейна, а также обработка новых операций или запросов – от исполнения смарт-контрактов до перечисления денежных средств – осуществляемые с помощью протокола консенсуса (в данном случае это протокол Proof of Work (PoW), поскольку мы говорим о ETC). Вероятно, слово «майнер» или «майнинг», сразу же возникло у вас в голове, особенно если вы уже слышали или читали раньше о блокчейнах типа PoW или о протоколе консенсуса PoW.

И вы правы: майнеры играют большую роль в блокчейнах типа PoW. Поскольку эта статья посвящена узлам, я ограничусь тем, что скажу, что майнеры получают работу от узлов. Когда узел получает или обрабатывает транзакцию, он создаёт из неё задание и отправляет его в сеть для майнинга (подтверждения), это может быть майнинг-пул или частный майнер, с которым напрямую коммуницирует указанный узел. О настройке узлов как для самостоятельного майнинга, так и для майнинг-пулов, мы расскажем в отдельной статье

В двух словах, вы запускаете программу-клиент по своему выбору – для ETC на данный момент есть несколько доступных вариантов, о которых мы тоже расскажем в следующих статьях. Программа-клиент устанавливается на операционную систему по вашему выборұ, при этом большинство клиентов для ETC поддерживают все основные операционные системы, такие как Linux, Windows и Apple MacOS. После запуска ПО узла, он подключается к другим узлам с помощью технологии p2p (Peer to peer).

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

После завершения синхронизации вы становитесь владельцем собственной базы данных и собственного банка. Узел готов принимать транзакции, распределять работу и связываться с другими узлами касательно обработки новых блоков. Он может производить практически любые операции: получать новые транзакции или отправлять средства, а затем направлять задания майнерам для подтверждения и создания новых блоков. Или ваш узел может быть настроен в качестве конечной точки RPC API для разработчиков dApp, устройств IoT – чтобы отправлять собранные данные в блокчейн – или для бирж и, надеюсь, в будущем, кроссчейн-коммуникаций. Но что важнее всего, теперь вы полностью контролируете свои данные и деньги.

Чем больше в распределённой сети – такой, как ETC – полностью синхронизированных узлов, тем более безопасной и устойчивой становится эта сеть.

Распределённая сеть

Обратите внимание на эту схему распределённой сети. Каждая из точек на ней является полностью синхронизированным узлом ETC, который содержит информацию обо всех блоках ETC, заключающих в себе сведения обо всех транзакциях, обработанных в блокчейне ETC, а также обо всех смарт-контрактах или децентрализованных приложениях. Теперь, если один из этих узлов (точек) по какой-либо причине – из-за аварии на сервере, отключения интернета и т. п. – внезапно исчезнет из этого пространства, сеть продолжит работать, и доступ к любым смарт-контрактам или dApp, используемым в ней, не потеряется, так как каждый узел (точка на схеме) является полностью синхронизированной базой данных, содержащей абсолютно те же данные, что и другие узлы. Чтобы уничтожить всю эту информацию, вам, без преувеличения, нужно будет убедиться, что уничтожены все узлы сети ETC. Потому что, если хотя бы один из этих узлов окажется снова подключенным к сети и получит возможность установить связь с другим узлом, то немедленно начнётся процесс синхронизации и восстановления данных.

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

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

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

Но как информация вообще попадает в блокчейн, и как мы получаем доступ к информации, хранящейся в базе данных? Программы-клиенты узлов для ETC имеют то, что называется JSON RPC API. Если вы когда-нибудь занимались разработкой веб-приложений, то, вероятно, слышали о JSON (упрощённый формат обмена данными, который может отображать числа, строки, упорядоченные последовательности значений и совокупность пар имя/значение).

JSON-RPC – это протокол удалённого вызова процедур (RPC) без сохранения состояния. В первую очередь эта спецификация определяет особые структуры данных и правила их обработки. Это средство передачи является независимым в том плане, что данные могут использоваться в рамках одного и того же процесса, через сокеты, HTTP, или в различных средах передачи сообщений. При этом в качестве спецификация структуры данных используется JSON (RFC 4627).

Даже если то, что вы сейчас узнали о JSON и RPC или API, всё ещё напоминает вам чёрную магию, не волнуйтесь: это не так сложно. Всё вышесказанное – это стандарт, согласованный разработчиками ПО узлов для ETC или Ethereum, который позволяет сторонним разработчикам обращаться к этим узлам. Чтобы узнать больше о API и JSON, можете воспользоваться Google.

Но приведу простой пример. Допустим, вы хотите создать пользовательский интерфейс, который ищет средства по определённому указанному адресу на блокчейне ETC. Тогда вам понадобится узел, дающий доступ к вышеупомянутому API JSON RPC. Настройка доступа к API JSON RPC сама по себе может быть рискованным делом, если вы каким-то образом сохранили учётную запись ETC на своём узле. Этот вопрос мы рассмотрим позже.

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

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

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

Большинство клиентских программ для узлов на самом деле не предусматривает безопасной работы в сети. Подключение Ethereum JSON-RPC API к общедоступному интернету небезопасно, так как даже с отключенными частными API это создаёт возможность для DDOS-атак. Но на самом деле программам-клиентам и не нужно обеспечивать базовую сетевую безопасность, поскольку такая встроенная функциональность добавит сложности и увеличит поверхность атаки критически важным частям программного обеспечения узла. Также большая часть программ-клиентов для узлов позволяет по желанию настроить JSON RPC API, IP-адрес и порт для JSON-RPC-вызовов, если вы не храните учётные данные на своём узле либо если храните и эти данные оказались заблокированы. Вам не стоит опасаться чего-то, кроме заваливания вашего узла RPC-вызовами, независимо от их назначения, и, конечно, DDOS-атак и т. п.

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

Если нет, я вкратце расскажу об этом и о том, как проводятся некоторые DNS-атаки типа «человек посередине» (или атаки посредника) на кошельки, как установить клиентское ПО для узла и на какие настройки безопасности следует обратить внимание. Являетесь ли вы разработчиком децентрализованных приложений или UI/UX и полагаетесь на данные из блокчейна, или просто пользуетесь кошельком, этот раздел для вас.

Давайте начнём с кошельков и узлов. Кошелёк ETC – это, в сущности, пользовательский интерфейс, обычно написанный на Javascript, который использует вызовы API JSON RPC, обычно через библиотеки для разработчиков на Javascript – как web3.js. Если коротко, то «с точки зрения внутреннего устройства, кошелёк осуществляет связь с локальным узлом через вызовы RPC. web3.js работает с любым узлом Ethereum, использующим RPC».

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

Было бы здорово, если вы могли запустить ETC-кошелёк на своём телефоне и похвастаться своими ETC перед друзьями. При том что я не думаю, что в ближайшее время можно будет запустить на телефоне полностью синхронизированный узел с уровнем RPC просто для установки приложения-кошелька.

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

Большинство хороших кошельков с открытым исходным кодом – даже онлайн-кошельков – теперь дают возможность подключиться к собственному узлу, что может стать наилучшим вариантом для онлайн-кошелька, как, например, https://ethereumproject.github.io/etherwallet / Classic Ether Wallet.

Самый безопасный кошелёк для ETC из всех рассмотренных мной – это Emerald Wallet, по той простой причине, что он при первом запуске предлагает вам опцию автоматического запуска и синхронизации собственного узла для локального использования кошелька через него, или, если у вас на этой машине уже есть клиент GETH-ETC с открытым уровнем RPC, Emerald Wallet автоматически его определит и попробует подключиться. Вариант с автоматической настройкой полного узла при первом запуске, на мой взгляд, является самым простым, безопасным и просто лучшим.

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

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

И, конечно, давайте не будем забывать об устройствах IoT. Если у вас есть несколько работающих IoT-устройств, скорее всего, вам потребуется удалённый узел для отправки транзакций. Сейчас, при отправке информации с IoT-устройства в конечную точку на ненадёжные серверные адреса, вам остаётся надеяться, что они окажутся в нужной базе данных. В случае необходимости, вы настраиваете собственный узел с JSON RPC API и указываете его в качестве адреса для обработки информации на своих IoT-устройствах, после чего ваш узел делает всё остальное и распространяет информацию для дальнейшей обработки.

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

Источник: cryptocurrency.tech