Was ist neu bei Hyperledger Fabric 3.0

Was ist neu bei Hyperledger Fabric 3.0

Die Aufzeichnung ist auch verfügbar

Zero knowledge design patterns for Hyperledger Fabric

 Link: https://www.youtube.com/watch?v=yonQleefbTM

Viewing channel transaction and genesis block in Hyperledger Fabric

Channel transaction and genesis block in Hyperldger Fabric are stored in an encoded way. However you can take a look on the content of the files with either with the configtxgen or with the configtxlator tool tool and with the help of the following commands: 

Viewing the content of the genesis block with configtxgen:

  configtxgen -inspectBlock genesis.block

With configtxlator, you have to start the tool first:

  configtxlator start

Viewing the content of the genesis block with configtxlator:

  curl -X POST --data-binary @genesis.block http://127.0.0.1:7059/protolator/decode/common.Block >    genesis.json

Viewing the content of the channel.tx with configtxlator:

 curl -X POST --data-binary @mychannel.tx         http://127.0.0.1:7059/protolator/decode/common.Envelope > mychannel.json

Viewing the content of the anchor transaction Org1MSPanchor.tx with configtxlator:

 curl -X POST --data-binary @Org1MSPanchors.tx       http://127.0.0.1:7059/protolator/decode/common.Envelope > Org1MSPanchors.json

 

Hyperledger Fabric CLI commands summarized

 

Some of the most important Fabric CLI commands are the followings.

Create channel:

  peer channel create

Fetching block and channel information, it is required at new peer joining the netwotk:

  peer channel fetch

Joining the channel:  

  peer channel join

Listing channels:

  peer channel list

Updating channels: (like at sending anchor peer update)

  peer channel update

Package chanincode:

  peer lifecycle chaincode package

Installing chaincode (must be executed at each peer):

  lifecycle chaincode install

Query installed chaincode

  lifecycle chaincode install

Approve chaincode (it must be executed at each organisation)

  peer lifecycle chaincode approveformyorg

Check if chaincode is ready for the commitment

  lifecycle chaincode checkcommitreadiness

Committing chaincode

  peer lifecycle chaincode commit

Check if chaincode is committed

  peer lifecycle chaincode querycommitted

Invoking chaincode

  peer chaincode invoke

Query chaincode

  peer chaincode query

 

CA backup and recovery in Hyperledger Fabric

 

Certificate Authority (CA) plays a critical role in production Hyperledger Fabric networks although this role is not always visible for the first sight. Some of the important characteristics:

- CA is not necessary to run continuously in the Hyperledger Farm

- in case CA is down no new certificate can be registered or rolled in, but the remaining of the farms works further without error. 

- If the CA database is faulty or lost, no new certificate enrollment can be done for already registered users.

- If the CA database user information is compromised, attackers might enroll new certificates for existing logins. 

   

Hyperledger Fabric Java SDK timeout parameters

Decentralized consensus is difficult to fine-tune. It is even more complicated if the whole consensus is separated into several layers like at Hyperledger Fabric. Supposing you need to to fine-tune, or getting timeout error from the client SDK side during transaction execution, the following timeout parameters are to be considered:

 public static final String PROPOSAL_WAIT_TIME =  "org.hyperledger.fabric.sdk.proposal.wait.time";

public static final String CHANNEL_CONFIG_WAIT_TIME = "org.hyperledger.fabric.sdk.channelconfig.wait_time";

public static final String TRANSACTION_CLEANUP_UP_TIMEOUT_WAIT_TIME = "org.hyperledger.fabric.sdk.client.transaction_cleanup_up_timeout_wait_time";

public static final String ORDERER_RETRY_WAIT_TIME = "org.hyperledger.fabric.sdk.orderer_retry.wait_time";

public static final String ORDERER_WAIT_TIME = "org.hyperledger.fabric.sdk.orderer.ordererWaitTimeMilliSecs";

public static final String PEER_EVENT_REGISTRATION_WAIT_TIME = "org.hyperledger.fabric.sdk.peer.eventRegistration.wait_time";

public static final String PEER_EVENT_RETRY_WAIT_TIME = "org.hyperledger.fabric.sdk.peer.retry_wait_time";

 public static final String EVENTHUB_CONNECTION_WAIT_TIME = "org.hyperledger.fabric.sdk.eventhub_connection.wait_time";

 public static final String EVENTHUB_RECONNECTION_WARNING_RATE = "org.hyperledger.fabric.sdk.eventhub.reconnection_warning_rate";

public static final String PEER_EVENT_RECONNECTION_WARNING_RATE = "org.hyperledger.fabric.sdk.peer.reconnection_warning_rate";

 public static final String GENESISBLOCK_WAIT_TIME = "org.hyperledger.fabric.sdk.channel.genesisblock_wait_time";

The default values are the followings:

defaultProperty(PROPOSAL_WAIT_TIME, "20000");
defaultProperty(CHANNEL_CONFIG_WAIT_TIME, "15000");
defaultProperty(ORDERER_RETRY_WAIT_TIME, "200");
defaultProperty(ORDERER_WAIT_TIME, "10000");
defaultProperty(PEER_EVENT_REGISTRATION_WAIT_TIME, "5000");
defaultProperty(PEER_EVENT_RETRY_WAIT_TIME, "500");
defaultProperty(EVENTHUB_CONNECTION_WAIT_TIME, "5000");
defaultProperty(GENESISBLOCK_WAIT_TIME, "5000");
defaultProperty(TRANSACTION_CLEANUP_UP_TIMEOUT_WAIT_TIME, "600000"); //10 min.

Hyperledger Fabric Sizing: vCPU, RAM, Disk

Hyperledger Fabric sizing might be a little tricky. One way of doing is to design the number of Fabric specific components, like CA (Certificate Authorities), Peers and Ordering Services components, getting some baselines for the designed system and accumulating the result. 

Simple development or test systems, might contain one peer, one ordering services, one certificate authorities and one channel. Complex productive systems usually have several organizations containing at least two but rather three peers for each organization, several certificate authorities like one for each organization and a complex ordering services usually containing at least five ordering containers. 

Baselines for the container resources can be gained from different resources, like this one. The following tables contains possible sizing for each container as virtual resource. 

Dev / Demo system: 

- CA: 0.1 vCPU / 0.2 GB RAM / 20 GB Disk

- PEER: 1.1 vCPU / 2.8 GB RAM / 100 GB Disk

- ORDERING: 0.35 vCPU / 0.7 GB RAM / 100 GB Disk

Test / Pilot system: 

- CA: 0.1 vCPU / 0.2 GB RAM / 20 GB Disk

- PEER: 2 vCPU / 4 GB RAM / 200 GB Disk

- ORDERING: 1 vCPU / 1 GB RAM / 200 GB Disk

Productive system: 

- CA: 0.1 vCPU / 0.2 GB RAM / 20 GB Disk

- PEER: 4 vCPU / 8 GB RAM / 500+ GB Disk

- ORDERING: 1 vCPU / 1 GB RAM / 500+ GB Disk

Certainly the above number can be modified based on the used containerization and virtualization technology. 

Hyperledger Fabric tips and tricks - using time or date in chaincode

If you want to use in your chaincode the exact time or date, it is not a straigtforward thing, because, the different endorsement peers might have different time set and if your commitment information is not the same in all of your commitment peers, the transaction will not be accepted as a valid one. What you can use, is the timestamp of the transaction itself, like with the help of a chaincodeStub.getTxTimestamp() call.

Hyperledger Fabric tips and tricks - chaincode log ID

If you log your chaincode activity, like with the help of a standard logger, it is always a good idea to know for which call was your log message generated. You can use the  getTxId() function call to log the transaction ID for you message. 

Hyperledger Fabric tips and tricks - static variables in chaincode

Do not use static variables in your chaincode in Hyperedger Fabric to store general settings, beacuse if the docker containers are restarted, your setting can be lost. Store instead everything in the ledger, or optionally in the private store.