Из глоссария Hyperledger Fabri c:
Endorser
Специфическая c роль партнера, за которую отвечает партнер Endorser для моделирования транзакций и, в свою очередь, предотвращения прохождения нестабильных или недетерминированных c транзакций через сеть. Транзакция отправляется индоссанту в форме предложения транзакции. Все подтверждающие одноранговые узлы также фиксируют одноранговые узлы (т.е. они записывают в реестр).
Для того, чтобы все одноранговые узлы всех организаций имели одинаковое состояние, транзакция в Hyperledger Fabri c проходит три фазы.
- Выполнить
- Заказ
- Проверить
Подробнее о потоке транзакции .
Первое, на что следует обратить внимание, - это разделение между выполнением транзакции (этап «Выполнить») и фактическим обновлением реестра (этап «Проверка»). Это разделение имеет полезные эффекты:
Всем одноранговым узлам необходимо обновить реестр, поэтому все одноранговые узлы выполняют этап проверки. Но не каждому партнеру необходимо выполнять смарт-контракт. Hyperledger Fabri c использует политики подтверждения, чтобы определить, какие узлы должны выполнять какие транзакции. Это означает, что данный цепной код (смарт-контракт) может быть закрыт для одноранговых узлов, которые не являются частью политики одобрения.
Транзакции могут быть выполнены до того, как они будут упорядочены. Это позволяет одноранговым узлам выполнять транзакции параллельно, что может улучшить пропускную способность.
В трехэтапной модели проверки порядка выполнения в Fabric результаты выполнения цепного кода для транзакции явно согласовываются (в соответствии с политикой подтверждения) перед добавлением транзакции в реестр.
Политики подтверждения :
Каждые У цепного кода есть политика подтверждения, которая определяет набор одноранговых узлов на канале, которые должны выполнить цепной код и подтвердить результаты выполнения, чтобы транзакция считалась действительной. Эти политики одобрения определяют организации (через своих партнеров), которые должны «одобрить» (т.е. одобрить) выполнение предложения.
В рамках этапа проверки транзакции, выполняемого одноранговые узлы, каждый проверяющий узел проверяет, что транзакция содержит соответствующее количество подтверждений и что они получены из ожидаемых источников (оба из них указаны в политике подтверждения). Подтверждения также проверяются, чтобы убедиться, что они действительны (т. Е. Что они являются действительными подписями от действительных сертификатов).
Давайте рассмотрим сценарий, в котором у нас две организации с одним партнером каждый (peer0.org1.example.com, peer0.org2.example.com). Предположим, они оба поддерживают своих коллег. По какой-то причине peer0.org2.example.com становится вредоносным (может быть вызвано любой причиной, например, тайным и прямым изменением мирового состояния ключа в ассоциированном CouchDB однорангового узла) и начинает одобрять предложения о мошеннических транзакциях. Теперь, как наша сеть решит, какое предложение транзакции является действительным, а какое - нет, если они оба одобрены одним действительным и одним недействительным? Консенсус никогда не будет достигнут, и предложение о сделке никогда не достигнет последующих этапов и будет отклонено. Вот почему нам необходимо найти баланс между безопасностью и производительностью, установив правильное количество поддерживающих партнеров. Как правило, чем больше количество одобряющих пиров, тем выше шанс смягчить эти виды атак. политика подтверждения cie
политики подтверждения на уровне коллекции политики подтверждения на уровне ключей Если на одноранговом узле установлен чейнкод, может действовать как индоссант. Если клиенты вызывают установленный чейнкод на одноранговом узле, то он будет действовать как индоссант.
Вы можете решить, может ли конкретный одноранговый узел действовать как подтверждающий одноранговый узел или нет, установив значение endorsingPeer на true / false в network-config . Хотя этот файл принадлежит к версии 1.4, я уверен, что вы найдете соответствующую конфигурацию сети и в последних версиях.
Ссылки: