Как точно достичь консенсуса, когда в коде Chaincode имеется блок полномочий или событие?

Question

Я прочитал спецификацию протокола https://github.com/hyperledger/fabric/blob/master/docs/protocol-spec.md#5-byzantine-consensus-1

Я интересно:

1. Что именно произошло, когда chaincode имеет блок кодирования полномочий?
2. Что именно произошло, когда код цепи имеет кодирующий блок события?

Например, существуют A, B, C, D четыре стороны, они работают на четырех валидирующих одноранговых узлах. В коде цепи A имеется кодирующий блок полномочий, только сторона A имеет право запускать блок кодирования. И есть код кодирования события в цепочке кодов A, только сторона A может получить результат события.

Таким образом, только сторона A может работать в блоке кодирования. Сторона B, C, D не может работать в блоке кодирования.

Как PBP сделать консенсус A, B, C, D в такой ситуации?

Answer 1

Принимая во внимание замечания выше, этот вопрос может быть изменен на что-то вроде этого:

«Пример asset_management.go имеет„“метод, который может быть выполнен только„isCaller вызывающим“. Как можно достичь консенсуса по PBFT в этом случае? «

, но это определение было бы неверным, поскольку все сверстники проверки A, B, C и D могут выполнять код в« передаче »,« назначить »и« isCaller », если транзакция подписана с оригинальным сертификатом« admin ».

Давайте рассмотрим этот пример и изучим его шаг за шагом.

1. chaincode «asset_management.go» может быть развернут в главной книгу любого пользователя с ролью «клиентом»

2. Во время развертывания в Init методы, сертификат участника будет сохранен в книге как «администратор» :

   adminCert, err := stub.GetCallerMetadata() 
   ... 
   stub.PutState("admin", adminCert) 
   

3. Когда кто-то хотел бы представить assign или transfer сделки в книге он должен подписать этот запрос со своим собственным сертификатом

4. Этот запрос будет передаваться всем VP в сети.

5. Каждый из VP загрузит «админ» сертификат от книги и сравнить его с сертификатом, который был использован подписать этот конкретный запрос:

   adminCertificate, err := stub.GetState("admin") 
   ... 
   ok, err := t.isCaller(stub, adminCertificate) 
   

Если сертификаты не то же самое - этот запрос не будет принят VP на этапе согласования PBFT.

Если сертификаты одинаковы - все VP будут знать, что этот запрос подписан оригинальным «вызывающим абонентом» и продолжит выполнение цепочки, потому что у них есть вся необходимая информация для этого.