Chaincode lifecycle flow is used in 2.x where all the organization
have their say in chaincode to be used in channel in which chaincode
definition is committed to ledger. At what point this committed
chaincode definition is used? Is this chaincode definition committed
to channel later used by peer and orderer when ordering the
transaction to check if there are correct endorsements?
The 1.x lifecycle has a definition in the "lscc" namespace.
Similarly, the 2.x lifecycle has a definition in the "_lifecycle" namespace.
The chaincode definition is used at the validation of the transaction.
The lifecycle namespace (lscc or _lifecycle namespace) can be thought of as a table that has a row for each application chaincode, and the primary key of the table is the application chaincode name.
Lifecycle 2.x allows to add different chaincode logic on the peers and
checkcommit readiness still returns true when organization even
approves different chaincode packages.
Right, what is important for the 2.x lifecycle is the endorsement policy of the chaincode, and the code itself is not important because the code content does not end up being part of the lifecycle namespace.
This is to make the smart contracts more flexible and to support different logic for different organizations, or have organizations be able to update the dependencies of their chaincodes without needing to collaborate with other organizations on a chaincode upgrade.
How this works? Why different fingerprint is not detected as was
detected in v1.4? At what point this fingerprint check is done
In 1.x, the code package of the chaincode was part of the fingerprint. Now, in 2.x it's not part of the fingerprint anymore and you only care about the "chaincode sequence".
For more info check the lifecycle playback, Jason mentions fingerprinting at time ~ 30m in the video and about sequences at ~ 25m.
