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

Hyperledger és a digitális személyazonosság

 A Hyperledger és a digitális személyazonosság videó elérhető:

Intermediate CA with Explorer or Gatweway on Hyperlegder Fabric

 

If you use Hyperledger Fabric with hieararchical CA-s and want to use Hyperledger Explorer or gateway, you might as well face with the situation that the tlsCACerts property for the TLS communication must be configured. The thing is that neither intermediate TLS certs or root TLS certs will work here you should create a file that contains the whole certificate chain (just copy in one file first the root cert then the direct intermediate cert, then the next intermediate cert and son on). 

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. 

Fabric composer tips and tricks - working with current identity

If you work with Fabric Composer, the ACL (Access Control List) language is meant to handle access rules in the system. However there might be the case that you need to define access rules directly in the smart contract code in a hard coded way. If that is the case, you can ask the current identity with the getCurrentIdentity() API call and implement the corresponding access logic based on the identity information:

 var identity = getCurrentIdentity();    

 console.log(identity);

 console.log("identity namespace : " + identity);

 console.log("identity certificate : " + identity.certificate);

 console.log("identity identityId : " + identity.identityId);

 console.log("identity name : " + identity.name);

 console.log("identity participant identifier : " + identity.participant.$identifier);

 console.log("identity participant namespace : " + identity.participant.$namespace);

 console.log("identity participant type : " + identity.participant.$type);

Double spending and replay attacks in different distributed ledger systems

Double spending, avoiding double spending and avoiding replay attacks work differently in the different blockchain and distributed ledger systems, especially if we consider the ledger structure. 

- Bitcoin: in Bitcoin, there are only unspent transaction outputs that behave as coins. At proof of work, the winner miner defines an order of the transactions that are applied to the ledger, to the unspent coins. The rule is that every unspent output can be spent only once, so considering the transaction order of the winning miner, the first valid transaction spending an unspent transaction output will really spend it, the next such a transaction will be considered as double spending. Similarly, old transactions can not be replayed, because the output is already spent. 

- Corda: in some sense Corda uses a similar UTXO, unspent transaction based system as Bitcoin. However, the unspent outputs are not "coins", but complex state information of a contract. Similarly to Bitcoin, one output can be spent only once, realizing an efficient way of avoiding both double spending and replay attacks. As opposed to Bitcoin, there is no proof of work or mining, instead a special dedicated node, called the notary service is responsible for the ordering of the transactions. 

- Ethereum: Ethereum is not an UTXO but an account based system. Practically, every account has some kind of a value field with a nonce that is incremented at every transaction. So a transaction not simply referring to an account but to an  account with a certain nonce. At proof of work or proof of stake, the winning miner or validator creates a block that contain an ordering of the transactions. If there are two transactions referring to the same account with the same nonce, than the first will be executed and the second one will be recognized as double spending. 

- Hyperledger Fabric: Fabric has a little bit similar mechanism than Ethereum. Each transaction is simulated by the smart-contracts at the endorsement peers and read write sets are defined. A read operator is not only defined to a variable but to a version of a variable. As a consequence, two transactions referring to the same input variable in a way that one reads and one writes that variable can be executed only in one specific order. If in one round a transaction already wrote into a variable the version of that variable will be increased, so in the same round, the variable can not be the read input of another transaction. In Fabric, the is no proof of work, but a specific service, called the ordering service is responsible for creating a valid order of the transactions. 

Fabric composer tips and tricks - Cyclic ACL Rule detected, rule condition is invoking the same rule

If one of your asset or participant is not updated and you get the following error message like in the javascript console if you the use fabric composer online playground:"Fabric composer tips and tricks - Cyclic ACL Rule detected, rule condition is invoking the same rule" . The problem can be that you do not use the statement await before an update and two updates might happen parallel.  

Fabric composer tips and tricks - deleting asset from array

If you want to delete an element from an asset or participant that as a reference array to another asset or participant, the process is pretty similar to deleting an element from a javascript array:

1. Getting a registry for the asset or participant
const assetReg = await getAssetRegistry(namespace + '.Asset'); 

2. Getting an index of the asset or participant to be deleted
var index = asset.arrayOfReferences.indexOf(assetToBeDeleted);

3. Delete the index in a javascript style
  if (index > -1) {
     asset.arrayOfReferences.splice(index, 1);
  }

4. Update the asset
assetReg.update(asset);

Fabric composer tips and tricks - not updating without error message

Working with fabric composer, you can sometimes get the phenomena that some item is not being updated, however there is no error message or anything, the transaction is executed without any problems, only something is not updated. This can be caused by exchanging the getAssetRegistry with the getParticipantRegistry statement. If you experience such a phenomena, check if you try to update assets with the getAssetRegistry and update participants with the getParticipantRegistry statements.   

Fabric composer tips and tricks - importing external javascript library

In Hyperledger Fabric Composer at smart contact development importing external javascript libraries are not really supported at the moment. What you can basically do:

1. use the extra functionality on the client and server side and not directly in the smart contract. Pay attention that the smart contract is executed and evaluated on each endorsement peers of the Hyperledger Fabric architecture. This security guarantee is not always possible for most of the logic. Sometimes you can reconstruct your business logic in a way that the functionality provided by the external javascript library is executed on the client side and only the result is presented on the smart-contract side. 

2. if the code of the external javascript functionality is not huge, you can try to integrate the javascript files as extra files in your business network archive file. The framework references automatically the added javascript files. Certainly, you added files can not have external references. 

Fabric composer tips and tricks - return value of a transaction

Unfortunately there isn't possible to return value from a transaction in Hyperledger Fabric Composer. What you can do however:

- Emitting an event, like

  let retValEvent = getFactory().newEvent(namespace, 'RetValEvent');
  retValEvent.RetValue = "value";
    emit(retValEvent);

- writing the return value into the variables of an asset or participants. For fine-tuning the access rules, it might be possible to define a separate asset containing only the return values of the different transactions:

  asset ReturnValueAsser identified by retId {

    o String retId

    o String retValTransaction1

    o String retValTransaction2

    --> RelatedAsset relatedAsset

 }

Fabric composer tips and tricks - item with ID already exist but not visible

Sometimes if you work with the Fabric Composer online playground and you create an item from a transaction you get the error message that the given id already exist even if it is not directly visible in the asset list. This is actually a "feature" of the online playground, it happens if the old item with the old id already existed but it was deleted. For some reasons it is sometimes cached somewhere that can not be explicitly deleted. What you can do in such situations that you redeploy the business network archive file:

- Make sure that the latest version of the .bna (business network archive) is downloaded.

- Delete the existing business network in the online playground.

- Rdeploy the business network from the downloaded .bna file.