консенсус среди пиров в структуре hyperledger после совершения транзакции - PullRequest
Новая
       6

консенсус среди пиров в структуре hyperledger после совершения транзакции

0 голосов
/ 05 ноября 2018

Предположим, я запустил фабрику с двумя пирами в одной организации. После запуска моего приложения / rest-сервера через composer и отправки транзакций. Я смог внести изменения в значения экземпляра Couchdb peer1, перейдя по адресу http://localhost:6984/_utils/#/_all_dbs. Теперь два узла не синхронизированы друг с другом - приложение должно выдать ошибку, но это не так. Главным образом, потому что он получает данные только от первого партнера, то есть peer1.

Итак, во-первых, как я могу получить данные от нескольких пиров - если я хочу получить данные от peer2 также?

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

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

Ответы [ 2 ]

0 голосов
/ 06 ноября 2018

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

Сама бухгалтерская книга, блоки и содержащиеся в них транзакции хранятся в физическом файле. БД мирового состояния - это просто набор текущего состояния для каждого актива. Это хороший дизайн, потому что приложение не будет заботиться о каждом изменении состояния, через которое прошел элемент, оно будет заботиться только о текущем состоянии. Мировое состояние db может быть легко воссоздано, когда в этом есть необходимость.

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

С точки зрения того, где вы должны получить данные, ответ таков: это не имеет значения. У каждого однорангового узла будет точная копия регистра, поэтому, если вы получаете данные из однорангового узла 1 или 2, не имеет значения, это будет то же самое.

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

0 голосов
/ 06 ноября 2018

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

  2. База данных состояний и регистр не одно и то же. это должно помочь вам понять разницу между ними.

  3. Каждый участвующий член сети Hyperledger Fabric является известной сущностью как таковой (поскольку Fabric является разрешенной цепочкой блоков). Сказано, что изменение в базе данных состояний одного узла снова приведет к приведенному выше сценарию № 1, где наборы Чтение / Запись в транзакции не будут совпадать для нескольких узлов (поскольку их базы данных состояния содержат разные значения актива). Это приведет к аннулированию транзакций. Теперь это просто становится вопросом о том, как сеть может узнать о поврежденном одноранговом узле (и последующем состоянии db). Может быть несколько решений для одного и того же.

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

...