Open zhuang-weiming opened 8 years ago
you cannot.
I'm sorry, I don't understand what you are asking.
So how we can get the final consensus of the whole chaincode? I image that coding block of event and authority can broadcasting its own result to other VPs. could you please kindly check and reivew?
Or
Let me change my question, what kind of code or API code needs consensus? Is it all of the chaincode? setEvent()? PutState()?
deploy and invoke is passed through consensus.
So how to make consensus when coding block of authority or event in the middle of program of deploy and invoke?
Is coding block of authority or event not a part of making consensus even they are in the middle of deploy and invoke?
i don't know what you mean by "coding block of authority or event".
My interpretation of the scenario above is that because the transaction can only run on node A, consensus cannot be reached, and the transaction is therefore treated at input only and is not executed on any nodes or appended to the ledger. I'll point some experts to this thread for their comment.
Taking into account the comments above, this question can be changed to something like this:
“An example asset_management.go has “isCaller” method which can be executed only by “caller”. How PBFT consensus can be reached in this case? ”
but this definition would be incorrect because all A, B, C and D Validation Peers can execute code in “transfer”, “assign” and “isCaller” if transaction is signed with original “admin” certificate.
Let’s go through this example and study it step by step.
“asset_management.go” chaincode can be deployed to the ledger by any user with role “client” During deployment, in Init method, this user’s certificate will be saved in the ledger as “admin”: adminCert, err := stub.GetCallerMetadata() ... stub.PutState("admin", adminCert) When somebody would like to submit assign or transfer transaction into the ledger he has to sign this request with his own certificate This request will be propagated to all VP in the network. Each of VP will load “admin” certificate from the ledger and compare it to the certificate which was used to sign this particular request: adminCertificate, err := stub.GetState("admin") ... ok, err := t.isCaller(stub, adminCertificate) If certificates are not the same - this request will not be accepted by VPs during PBFT consensus phase.
If certificates are the same - all VPs will know that this request is signed by original “caller” and will proceed with chaincode execution because they have all necessary information to do so.
could you kindly help to check and review?
1. This request will be propagated to all VP in the network.
does it means a broadcasting method? if it is an kindly of broadcasting, what contents were broadcasted?
2.If certificates are not the same and are the same
Can I think the PBFT consensus happens in each line of chaincode program coding? Otherwise, how PBFT can know the same
or not the same
in the middle of chaincode program?
Sergey Balashevich's answer on stackoverflow. Please kindly help to check and review==>
Each validation peer keeps open connection with all other VPs in the network. As a first step in consensus - the leader (one of VP who was selected as a leader) will prepare ordered list of transactions and broadcast it to other validation peers. The content is Chaincode id, function name, parameters etc. –
Consensus is not a “each line” level event. Each validation peer will execute all transaction in a list, then VP will calculate hash for new “state of the world”, then VP will calculate final hash for entire block. Then VP will check if other VPs have the same final hash. PBFT don’t care about intermediate results, in consensus phase PBFT verify that HASH for block is the same for all VPs and it means that all transactions were executed with the same result.
PBFT is not involved in transaction execution. VP has it’s own copy of entire ledger and chaincode can get an access to admin certificate at any time “adminCertificate, err := stub.GetState(“admin")". And, as a result, chaincode can verify if user, who submitted transaction is admin. Result of this transaction execution (both “rejected” or “executed successfully”) will be included in ledger and state of the world will be updated correspondingly. On a next step VP will check if they do have the same state of the world and decide if consensus is reached.
I read protocol specification https://github.com/hyperledger/fabric/blob/master/docs/protocol-spec.md#5-byzantine-consensus-1
I am wondering:
For example, there are A,B,C,D four parties, they are running on four Validating Peers. There is a coding block of authority in chaincode A , only party A has the authority to run the coding block. And there is a coding block of event in chaincode A, only party A can get the result of event.
So only party A can run into the coding block. Party B, C, D can not run into the coding block.
How PBFT make consensus of A,B,C,D in such situation?