динамическое управление членством в узле в блокчейне Ethereum

Я новичок в блокчейне Ethereum и реализую это как потенциальное решение для децентрализованного приложения. В процессе поиска решения я столкнулся с проблемой, когда я хочу динамически управлять созданием/удалением узлов в существующей/функционирующей цепочке блоков.

Например: если у меня есть частная цепочка блоков, которая изначально была создана с 5 работающими и взаимодействующими узлами. У каждого узла есть файл static-nodes с информацией (enode) для пиринга друг с другом. Теперь, если я хочу загрузить один из узлов из сети блокчейна, я бы обновил статический узел, исключив нечетный узел из списка узлов и реплицировав его на каждом узле. Это потенциально выкинет удаленный узел из сети Blockchain.

Что, если я хочу управлять этим удалением узлов, не касаясь каждого из узлов (при условии, что узлы не в нашей способности реализовать изменения). Есть ли решение для динамического добавления/удаления узлов без внесения изменений в каждый узел? также без сброса данных Blockchain (без сброса генезис-блока).

Если у кого-то есть сомнения по моему вопросу, пожалуйста, напишите мне.

Любая помощь высоко ценится.

Спасибо.

вы можете изменить протоколы, чтобы добавить ACL в свою цепочку блоков. Для этого потребуется изменить протокол обнаружения ( github.com/ethereum/wiki/wiki/Node-discovery-protocol ) и, возможно, протокол Ethereum Wire ( github.com/ethereum/wiki/wiki/Ethereum-Wire-Protocol )
Я не вижу смысла закрывать приложение на основе блокчейна. Создание централизованного приложения в вашем случае будет лучше. Весь смысл использования технологии блокчейна заключается в том, чтобы распространять приложение на других узлах, поэтому вы не можете контролировать узлы. Ваша попытка контролировать узлы противоречит концепции использования технологии блокчейн.
Спасибо за ваш ответ. Рассмотрим сценарий, в котором вы хотели бы создать распределенное приложение. Это приложение позволит создавать узлы для каждого нового клиента. Теперь это частная цепочка, в которой разрешено совершать транзакции только уполномоченным клиентам. Клиенты будут динамично расти в сети, также они могут покинуть сеть в какой-то момент времени. Если я уже создал частную цепочку блоков, как бы я добавил нового члена (узла) в эту работающую цепочку блоков, а также как удалить узел. Вы думаете о каком-либо решении для такого сценария? Спасибо.

Ответы (1)

Я бы порекомендовал добавить в заголовок блока ( types.Header) новое поле с именем CustomerHash, этот хэш будет генерироваться алгоритмом sha256 для данных клиента (имя + адрес + любая информация, которую вы хотите). У каждого клиента будет уникальный хэш.

Теперь, когда у вас есть хэши для всех ваших клиентов, вы должны разместить этот список клиентов в сети Swarm, чтобы он был общедоступным. Каждый узел будет загружать список один раз каждые 1000 блоков (или что-то в этом роде).

Чтобы быть уверенным, что этот список создается только вами (поскольку вы являетесь здесь центральным органом власти), вы должны включить механизм шифрования. Вы должны зашифровать список своим закрытым ключом, и каждый узел будет уверен, что это список, созданный вами. Таким образом, вы сделаете блокчейн пригодным для использования только вашими клиентами, потому что только они смогут добывать блок. Если незнакомец попытается поставить блок CustomerHash, которого нет в этом списке, другие майнеры отклонят его блок как недействительный.

Результат: у вас есть общедоступный блокчейн, но его могут добывать только те, кто заплатил. И он будет доступен для всех, кто заинтересован в получении данных в сети.

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

Благодарю за ваш ответ. Я понял, как комбинация файлов статических узлов вместе с динамической командой для добавления однорангового узла будет использовать обязанности администратора для (административных) узлов в сети Blockchain. Однако, безусловно, существует более разумный способ управления динамическим управлением членством в сети Blockchain, но на данный момент я принимаю это решение в качестве исходного решения, и я собираюсь строить и импровизировать поверх него.