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. 

An Austrian economical interpretation for the last 3 years of Blockchain

The Austrian school of economics provide a pretty good interpretation what was happening in the Blockchain space in the last couple of years. The ICO and token sales hype for three years caused a lot of investment coming into the space totally uncoordinated. The reason for this money pump was not only a speculation in the technology but the fact that the token sales technology liberated and disrupted the whole funding a investment industry. Due to regulation issues the investment source  was basically cut and a lot of company found itself in the situation of having the invested money but not capable to build up a system that can be sold to any customers. The last two years of market and technology free fall was among the others a cause that these companies not able to find real market for their products were slowly liquidated. 

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. 

Timing attacks against naive atomic swaps

Naive atomic swaps are asymmetrical games. In a standard atomic swap two HTLC-s are created with the h secret and T time lock and the idea is that either each party reveals the h secret or the timeout expires and all transactions are reverted. However the game is a little bit asymmetric, because one party, let we call it Alice creates and knows the h secret value so she can choose the exact time when she reveals this secret. If she chooses to activate that h secret right before the expiry of the T timelock, she has the chance that her counterparty, let we call Bob misses the time windows, so Alice gets the money from both blockchain. She might as well influence the chance of Bob to miss the time window with trying to force the counterparty blockchain, or with bribing some of the miners in the counterparty blockchain to delay the transaction.     

It is an open question, if modified swaps with HTLC contracts can be defined in a way that they reflect the assymetric behaviour of information sharing. 

parity tips and tricks - parity docker and persistent storage

If you use parity above 2.3.5 and you want to run with docker in a way that your chain is synced on a persistent storage, like under /srv/parity on an ubuntu machine, you can use something similar to the  following script:

sudo docker run -ti -d --name parity --network=host --user=root --restart=unless-stopped  -v /srv/parity:/home/parity/.local/share/io.parity.ethereum  parity/parity:v2.3.5 --chain=ropsten --geth --jsonrpc-apis "web3,eth,net,parity,parity_accounts,traces,rpc,parity_set,personal" --base-path /home/parity/.local/share/io.parity.ethereum

parity tips and tricks - ancient block sync error

If you use parity 2.3.5 syncing your blockchain and you open a geth console with the synchronization as well, your geth console might show that everything is synced but you can and error with ancient block syncing.

Like the following error: "Block information is incomplete while ancient block sync is still in progress, before it's finished we cant`t determine the existence of item"
In this case check the following :

 curl --data '{"method":"parity_chainStatus","params":[],"id":401697,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

if it shows that there is still and existing blockgap it means that an ancient block syncing is still in progress, so wait until it finishes. If the sync does not improve check if you did not coicidently start parity with the --no-ancient option.  

Phases of learning solidity programming

Month 1: Yes, I can program in Solidity ! This is an easy language, similar to Javascript, with some types.

Month 2: Wait, Underflow / overflow ? I thought they can not cause problems.

Month 3: But, I should upgrade my contract ? Because it contains already ether and I forgot to implement an etherTransfer function ?

Month 4: Cool, I have some upgrade patterns, but they cost too much ether.

Month 5: Ooh, msg.sender, tr.origin, contract in the middle attacks ?

Month 6: Or, Fallback function ? Reentrancy ?

Month 7: Hmm, A transaction is always atomic, right ? So what is with address.transfer or address.call.value ?

Month 8: And, Libraries, Delegate calls ?

Month 9: Hence,  Stack, call stack attacks and front running?

Month 10: So, How about just reusing some ready libraries ? Like OpenZeppelin ?

Month 11: Or, Formal verification, bug-bounty, military programming ?

Month 12: No, I can not program in Solidity !