Multi-org/peer example/test

hyperledger / fabric-private-chaincode

FPC enables Confidential Chaincode Execution for Hyperledger Fabric using Intel SGX.

Apache License 2.0

159 stars 91 forks source link

Multi-org/peer example/test #98

Open g2flyer opened 5 years ago

g2flyer commented 5 years ago

To make sure all our design really work and also to illustrate to users how a multi-org (and hence, multi-peer) would work we should have a test-case with at least 2 orgs and peers ...

mbrandenburger commented 5 years ago

This is a good idea! For solid multi-peer testing the use of the client SDK will make our life much easier.

In such a test we would execute (endorse) a transaction on peer A and check if peer B successfully commits this tx.

We could use the peer CLI for that (https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peerchannel.html#peer-channel-fetch) but this requires polling blocks and parsing them in order to check. Not nice.

mbrandenburger commented 5 years ago

Using the fabric client SDK (https://github.com/hyperledger/fabric-sdk-go) one can easily register for events. Eg.

client.RegisterChaincodeEvent(ccID, eventID)

mbrandenburger commented 5 years ago

seems the peer CLI indeed provides an event listener, which we can use here (and also remove the sleep command)

--waitForEvent                   Whether to wait for the event from each peer's deliver filtered service signifying that the 'invoke' transaction has been committed successfully
--waitForEventTimeout duration   Time to wait for the event from each peer's deliver filtered service signifying that the 'invoke' transaction has been committed successfully (default 30s)

See here https://hyperledger-fabric.readthedocs.io/en/release-1.4/commands/peerchaincode.html#peer-chaincode-invoke

g2flyer commented 5 years ago

relevant pointers of setting up multi-peer/multi-org: https://hyperledger-fabric.readthedocs.io/en/latest/channel_update_tutorial.html

g2flyer commented 5 years ago

While the peer.sh wrapper tries to handle multi-peer, e.g., in setup as described in PR #144, it was not tested with multi-org/peer, so be warned ...

g2flyer commented 4 years ago

Note: while in old lifecycle, our peer.sh wrapper logic should have worked with multiple peers and the ercc install&instantiate and the ecc onDemand setup, with the new lifecyle this is not true anymore, e.g., the ercc configuration in channel join would require tighter coordination between multiple peers. So this might require now more explicit additional management commands but also has to be looked at from the perspective of the additional steps necessary for th new key-managment protocols

g2flyer commented 4 years ago

depends on resolution of issue #12

g2flyer commented 4 years ago

Done in conjunction with #394 ..

bvavala commented 4 years ago

Another useful feature and test that can be added in this setting is the following:

3 peers/orgs, only one of which is the SGX-capable FPC endorser, and only that has the code; the remaining two, however, must still be FPC peers (because of the validation plugins)
ensure that the LifecycleEndorsement policy is set to majority of orgs (i.e., only the majority can modify the chaincode definition; #313 handles upgrades)
ensure that the fabric network can go through the approveformyorg step (note: this requires a majority, and requires an org to install a package; so it should be checked whether an empty package or an empty package id is necessary at some org; the Fabric code here suggests that using an empty package id should be viable.)

g2flyer commented 3 years ago

fabric-sample test-network does already do now in a minimalistical cut multi-peer setup (though no automated test yet)