Насколько ваши данные безопасны в Hyperledger Fabric, когда можно вносить изменения непосредственно в данные couchdb
Мне интересно, как ваши данные в безопасности, когда администратор может изменить последнее состояние в Couchdb с помощью Fauxton или же cURL предоставлено Couchdb непосредственно.
Согласно моему пониманию Hyperledger Fabric обеспечивает функцию неизменяемых данных и лучше всего подходит для предотвращения мошенничества (функция Blockchain).
Вопрос в следующем:- Я могу легко изменить данные в couchdb и когда я запрашиваю из моего chaincode это показывает измененные данные. Но когда я запрашиваю ledger используя GetHistoryForKey() это не показывает, что я сделал изменения couchdb, Можно ли как-то предотвратить такое мошенничество? Потому что пользователь всегда будет видеть последнее состояние, т.е. данные из couchdb не из ledger
Любой ответ будет оценен.
Спасибо
4 ответа
В Hyperledger Fabric v1.2 каждый узел имеет свою собственную CouchDB. Так что даже если вы измените данные непосредственно из CouchDB одного пира. Одобрение потерпит неудачу. Если одобрение не получится, ваши данные не будут записаны ни в мировом состоянии, ни в текущем состоянии.
Вы не должны открывать порт CouchDB за пределами одноранговой сети, чтобы избежать несанкционированного доступа к данным. Только администратор однорангового узла должен иметь доступ к CouchDB, и у администратора нет стимула подделывать свои собственные данные. Позвольте мне объяснить подробнее...
База данных состояний Hyperledger Fabric аналогична базе данных неизрасходованных транзакций в биткойнах, так как если одноранговый администратор вмешивается в базу данных своего однорангового узла, одноранговый узел не сможет убедить другие одноранговые узлы в том, что транзакции, исходящие из нее, действительны. В обоих случаях базу данных можно рассматривать как кэш текущего состояния блокчейна. И в обоих случаях, если база данных повреждена или повреждена, ее можно восстановить на одноранговом узле из блокчейна. В случае биткойнов это делается с помощью флага -reindex. В случае Fabric это делается путем удаления базы данных состояний и перезапуска однорангового узла.
В Fabric одноранговые узлы из разных организаций, как указано в политике одобрения, должны возвращать одинаковые результаты выполнения цепного кода для транзакций, подлежащих проверке. Если данные состояния бухгалтерской книги были изменены или повреждены (в файловой системе CouchDB или LevelDB) на одноранговом узле, то результаты выполнения цепного кода будут несовместимы между подтверждающими одноранговыми узлами, будет обнаружен "плохой" одноранговый узел / организация, и клиент приложения должен выкинуть результаты из плохого партнера / организации перед отправкой транзакции для заказа / фиксации. Если клиентское приложение пытается отправить транзакцию с несогласованными результатами одобрения, независимо от этого, это будет обнаружено на всех узлах во время проверки, и транзакция будет признана недействительной.
Вы должны защитить свой couchdb от изменения другими процессами, кроме однорангового, так же, как вы обычно должны защищать свою файловую систему или память.
Если вы сделаете свою файловую систему доступной для записи, другие пользователи могут перезаписать содержимое книги. Точно так же, если вы не включите контроль доступа в записи couchdb, вы потеряете свойства неизменяемости.
В этом прелесть децентрализованной распределенной системы. Даже если вы или кто-либо другой изменит состояние вашей базы данных / регистра, оно не будет совпадать с состоянием других в сети, равно как и не будет совпадать с хэшем блока транзакций, что делает индоссаторами недопустимые транзакции, если только вы не сможете восстановить фактически согласованные условия. состояние регистра из участников сети или заказчика. Чтобы воспользоваться неизменяемостью регистра, вы должны запросить его. Запросы к базе данных не используют возможности блокчейна и, следовательно, должны быть защищены таким же образом, как и доступ к любой другой базе данных.
Вы должны понять 2 вещи здесь
Хотя данные couchdb однорангового узла могут быть подделаны, вы должны настроить свою политику одобрения таким образом, чтобы она была одобрена всеми участниками.
Вы не можете выставить ваш couchdb для изменения, я рекомендую посмотреть Cilium
Как объяснили другие - одобрение / консенсус является ключом. Несмотря на то, что состояние главной книги подтверждающего однорангового узла может быть изменено извне - в этом случае все транзакции, одобренные этим одноранговым узлом, будут отброшены, поскольку другие подтверждающие одноранговые узлы будут отправлять правильные транзакции (при условии, что состояние другого мира также не было подделано) и консенсус будет играть ключевую роль здесь, чтобы помочь выбрать правильную транзакцию.
В худшем случае все транзакции потерпят неудачу.
Состояние мира фабрики Hyperledger (состояние ГК) можно в любой момент восстановить из цепочки блоков (Журнал транзакций). И, в случае отказа равноправного узла, эта регенерация происходит автоматически. При некоторой тщательной настройке можно создать самовосстанавливающуюся сеть, в которой равноправный узел автоматически восстанет из пепла (каламбур).
Ключевым моментом, который следует здесь рассмотреть, является протокол распространения данных Сплетни, который можно считать мистическим целителем. Все узлы в сети постоянно подключаются и обмениваются данными с другими узлами в сети.
Цитировать документацию -
Одноранговые узлы, на которые влияют задержки, сетевые разделы или другие причины, приводящие к пропущенным блокам, будут в конечном итоге синхронизированы до текущего состояния регистра, связываясь с одноранговыми узлами, имеющими эти недостающие блоки.
а также...
Любой одноранговый узел с данными, которые не синхронизированы с остальной частью канала, идентифицирует отсутствующие блоки и синхронизирует себя путем копирования правильных данных.
Вот почему всегда рекомендуется иметь все больше и больше сторонников в сети и в организациях. Чем больше сеть - тем сильнее она будет побита злым умыслом.
Я надеюсь, я мог бы помочь. Ссылка на ссылку: https://hyperledger-fabric.readthedocs.io/en/release-1.4/gossip.html
"процесс согласования состояния синхронизирует мировое состояние между одноранговыми узлами на каждом канале. Каждый одноранговый узел постоянно извлекает блоки от других одноранговых узлов на канале, чтобы исправить свое собственное состояние в случае выявления расхождений".
Несмотря на то, что это правдоподобно, политика поддержки является основным средством защиты себя (системы) от последствий такого действия.