Неограниченное количество организаций на Hyperledger Fabric

Question

Обзор

Моя архитектура блокчейна требует, чтобы каждый отдельный пользователь сохранял свои данные в секрете. Там может быть неограниченное количество пользователей (скажем, в миллионах). Согласно документации Hyperledger Fabric

Организация может быть размером с многонациональную корпорацию или размером с отдельное лицо

Вот архитектура, которая приходит мне в голову:

1. Моя компания будет иметь Организацию А в деловой сети
2. Каждый раз, когда пользователь регистрируется, я создаю новую Организацию N и новый Канал C. в деловой сети.
3. Каждый новый канал будет состоять из двух участников: Организация A и вновь добавленная организация пользователя N

Я специально не выбрал Личные данные , потому что Добавление учебного пособия по организации в канал предполагает, что если N организаций существуют в определенном канале, то организации N-1 должны подписать транзакцию, чтобы новая организация. Ввиду отсутствия обмена данными между каждой пользовательской организацией, я создаю неограниченное количество каналов (по одному каналу для каждого пользователя org).

Вопросы:

1. Я пытаюсь уклониться от линейной сложности, которая возникает, когда я пытаюсь добавить новую организацию в существующий канал. Эффективно ли моя архитектура решает линейное увеличение сложности?
2. У меня возникла какая-то другая проблема с этим дизайном?
3. Что-то нелогичное в моем дизайне?

Answer 1

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

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

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

Answer 2

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

С другой стороны, вы можете взглянуть на использование личных данных в сочетании с одобрением на основе состояния. Вместо того, чтобы создавать канал между Org A и каждым пользователем, вы можете вместо этого создать коллекцию Org A / Org N и затем использовать одобрение на основе состояния, чтобы требовать одобрения только от Org A и Org N. Недостатком здесь является то, что Org N + 1 ... Org N + X будет содержать хэши всех ключей / значений для всех пользователей ... которые вы, возможно, не захотите (тем более что требуется, чтобы пользователи хранили данные, которые не относятся к ним).