Понимание взаимодействия между цепочечным кодом / одноранговым узлом и локальной копией регистра

Question

вопрос 1:

Цепной код (hyperledger/fabric/examples/chaincode/go/examplexx/chaincode.go) обращается к регистру через ChaincodeStubInterface, например, stub.GetState(.), stub.PutState(.).

ChaincodeStubInterface реализовано hyperledger/fabric/core/chaincode/shim/chaincode.go.

Если я правильно понимаю, stub, используемый для PutState и GetState, создается handleInit(.) из hyperledger/fabric/core/chaincode/shim/handler.go:

stub := new(ChaincodeStub)

handleInit вызывается handleReady, который вызывается handleMessage, который вызывается chatWithPeer, который вызывается Start (hyperledger/fabric/core/chaincode/shim/chaincode.go), который вызываетсяmain функция hyperledger/fabric/examples/chaincode/go/examplexx/cmd/main.go

a) С какой командой вызывается эта main функция?По $peer chaincode install?

б) И где в коде ткани вызывается эта функция main, которая затем вызывается (я был бы рад по поводу некоторых указателей).

вопрос 2:

Предположим, $peer chaincode invoke .. '{"Args":["yy","a","b","10"]}' вызывает метод транзакции yy в файле chaincode.go (hyperledger/fabric/examples/chaincode/go/examplexx/chaincode.go).Предположим, что эта транзакция оправдывает stub.GetState(.), который вызывает stub.handler.handleGetState(.).

a) Является ли этот обработчик своего рода промежуточным звеном между цепным кодом и одноранговым / бухгалтерским регистром?

b) Принадлежит ли обработчиксверстнику?Если да, есть ли один обработчик на одноранговый узел или несколько обработчиков (по одному на каждый цепной код)?

c) Когда создается этот обработчик?

d) Когда создается экземпляр локальной книги для однорангового узла?

Я знаю, что это много вопросов.Но я был бы очень рад некоторым подсказкам, чтобы я мог выяснить, как создается локальная копия регистра и как с ней связывается цепной код / ​​узел.Спасибо!

Answer 1

а) С какой командой вызывается эта основная функция?При установке $ peer chaincode?

b) И где в матричном коде эта функция вызывается, а затем вызывается (я был бы рад по поводу некоторых указателей).

Основная функция определена вкод сверстника.Когда одноранговый узел решает запустить контейнер с цепочечным кодом, он просто запускает образ стыковки shim цепочечного кода (golang, java, node.js) и просто запускает команду в соответствии с языком цепочечного кода .

    switch ccType {
    case pb.ChaincodeSpec_GOLANG.String(), pb.ChaincodeSpec_CAR.String():
        lc.Args = []string{"chaincode", fmt.Sprintf("-peer.address=%s", c.PeerAddress)}
    case pb.ChaincodeSpec_JAVA.String():
        lc.Args = []string{"/root/chaincode-java/start", "--peerAddress", c.PeerAddress}
    case pb.ChaincodeSpec_NODE.String():
        lc.Args = []string{"/bin/sh", "-c", fmt.Sprintf("cd /usr/local/src; npm start -- --peer.address %s", c.PeerAddress)}
default:

a) Является ли этот обработчик своего рода промежуточным звеном между цепным кодом и одноранговым / бухгалтерским регистром?

b) Принадлежит ли обработчик одноранговому узлу?Если да, есть ли один обработчик на одноранговый узел или несколько обработчиков (по одному на каждый цепной код)?

c) Когда создается этот обработчик?

d) Когда копируется локальная книгадля экземпляра однорангового узла?

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

Что касается обработчиков - для одноцепочечного кода имеется обработчик на узле.

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

Затем узел извлекает блок, проверяет подпись (изодобрение) партнера, который выполнил цепной код, и если подпись действительна, то он обновляет свою локальную базу данных.