Release 0.1.5

fabric-peer-ext Release Notes - Dec 1, 2020

What's new in fabric-peer-ext v0.1.5

This release is based on Fabric 2.2.1. Following is a list of bug fixes and new features:

Enable cache for DCAS collections #382

Off-ledger collections cannot reliably cache data since updates to a key may not be propagated to all peers and a subsequent 'Get' may retrieve stale data from the cache. Although, DCAS collections can reliably be cached since an update to a DCAS value will always result in the same value. By default, the cache is enabled for DCAS collection types and disabled for off-ledger collection types. (Note that the cache may still be disabled for DCAS collection types by setting the off-ledger cache size to 0.)

Retrieve transient data from other peers if not found on initial set of peers #518

A deterministic algorithm is used to select a set of orgs and peers within those orgs to which to disseminate transient data. The same algorithm is then used to select the peers from which to retrieve the data. The algorithm is based on a modulus operator on the hash of the key and the length of the set of orgs and peers within the orgs. If the length of the set of orgs or peers within the orgs changes between the time the data was disseminated and the time it is retrieved then (most likely) one or more peers that do not have the data may be selected. This commit adds a fallback mechanism such that, if none of the selected peers has the data, then an attempt is made to retrieve the data from the remaining set of peers within each of the orgs that are selected (based on the key hash). If the data is still not found then the peers of the other orgs are queried.

Option to always persist transient data #520

Previously, transient data were only stored in memory unless the maximum cache size was exceeded, at which time the oldest entries were offloaded to a database. This commit adds a configuration parameter to allow transient data to always be persisted (as well as cached). This way, if a peer goes down temporarily then the transient data will still be available when it comes back up.

Use IPFS encoding in DCAS #526

The DCAS is now using IPFS libraries to properly encode the content and generate standard content IDs. DCAS now supports storing objects and files. Objects may be stored with the following encodings:

• Raw - The data is stored exactly as input by the client without trying to interpret the data. (This is the default encoding.)
• CBOR - Concise Binary Object Representation (or dag-cbor)
• Protobuf - The protobuf (or dag-pb) encoding contains data and links to other data

File data is either stored as a raw node or, if it's a large file then it is broken up into chunks and stored as a Merkle DAG.

Cache for CouchDB block store #534

The last N blocks are cached and also the latest config block is pinned. Blocks are mapped by both number and hash.

Config to skip checks for duplicate transaction IDs on endorser #539

On each endorsement a database read is performed in order to ensure that the transaction ID in the transaction proposal is unique. During block validation, the same check is performed and the transaction is rejected if a duplicate transaction ID is used. In order to improve performance by reducing database queries, a config option on the endorsers was added in order to disable this check, since in almost 100% of the endorsements the transaction ID is unique. The validation step will ultimately reject transactions attempting to use a duplicate transaction ID.

Pre-populate state cache on endorser #536

As blocks are committed, the state cache is updated on the committing peer and the cache-updates are temporarily stored. When an endorsing peer receives a validated block from the committing peer, a request is made to the committing peer for the cache-updates. When the cache-updates are received then the cache on the endorsing peer is updated (pre-populated).