Sprint Release Notes

Changes in the current sprint effecting the external APIs or system behavior

4/07/2016 commit 33bc136 changed chaincode interface

1. Deploy Transaction calls chaincode Init function
2. Invoke Transaction calls chaincode Invoke function
3. Query Transaction calls chaincode Query function Please see examples for more detail

3/31/2016 POST /chaincode REST endpoint added (Sprint 2)

The /chaincode endpoint was added to replace the original /devops/deploy, /devops/invoke, and /devops/query endpoints, which are now deprecated. Please see the documentation here for further explanation and examples.

https://github.com/hyperledger/fabric/blob/master/docs/API/CoreAPI.md#chaincode

Performance improvement in Ledger for bucket-tree based state management implementation

4/11/2016 commit 9977ddc introduced caching of non-data buckets

The table below demonstrates the improvement in the transaction throughput enabled by the caching feature. Please note that these numbers are only at the ledger level and not for end-to-end system.

		Bucket-cache disabled	Bucket-cache disabled	Bucket-cache enabled	Bucket-cache enabled	% Improvement
NumReads	NumWrites	Benchmark Time (nanos)	Throughput (tx/sec)	Benchmark Time (nanos)	throughput (tx/sec)
1	1	19981045377	5004.74	15266998482	6550.08	30.88
1	4	62301879141	1605.09	46002859879	2173.78	35.43
4	1	25944935286	3854.32	21073280916	4745.35	23.12

The experiments are performed using golang's benchmark utility on a Mac book pro (Processor: 2.5 GHz Intel Core i7 - 4 cores, Memory: 16 GB 1600 MHz DDR3, SSD based storage).

Each row in the table represents one experiment. In each of the experiments, first, the Ledger is pre-populated with 1000,000 key-values and then 1000 batch of transactions are executed; each batch containing 100 transactions. Each of the transactions, performs a fixed numbers of reads and writes of pseudo-randomly selected keys (out of existing keys in the ledger). The size of the key-value used in the experiments is 100 bytes.

The first two columns in the table show the number of reads and writes performed by each of the transactions. The third and fourth columns show the performance numbers when the caching feature is not used. The third column shows the time reported by the benchmark utility of golang and the forth column shows the throughput numbers (derived as total transactions executed / time taken). The next two columns show the similar data when the caching feature is used and finally, the last column shows the improvement observed in the throughput.

As observed, that this feature is more helpful when the transactions are write heavy. For instance, in the table the maximum gain (35%) is observed in the second row which has a read to write ratio of 1:4. This is because, more writes cause modification in more data-buckets and hence cause more read requests for non-data buckets for recomputing of crypto-hashes. Similarly, the read heavy transactions (such as the third row in the table) reads more of the data keys than the non-data buckets and hence relatively a lower improvement (23%) is observed.

These experiments are performed by executing the script fabric/core/ledger/benchmark_scripts/ledger/randomTransactions.sh.