Release 0.1.6

fabric-peer-ext Release Notes - Mar 4, 2021

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

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

Added block handler to Block Publisher #552

Clients may now register to handle entire published blocks.

Asynchronous Gossip app-data request handler #550

The responses for app-data requests are now asynchronous. The request handler is provided a 'responder' to which the handler may respond immediately or in the (near) future.

Distributed Validation #556, #558, #560

When a committing peer receives a block from the Orderer a request is immediately sent (via Gossip) to validating peers within its own org to partially validate the block (according to validation policy). The validating peer receives the request and determines whether it is capable of validating the block. If the received block's number is greater than the local block height of the peer then the request is cached and validated once it has caught up. As the validating peers respond with results, the committer validates the responses against the validation policy (i.e. signature, etc.) and then merges them with the results received from other peers. The committer then validates the remaining transactions for which results were not received.

Register a query executor provider along with state DB #566

When a channel is created then, along with registering a state database, a query executor provider is also registered. The query executor provider returns query executors with and without a commit lock. In some cases (such as with off-ledger and transient data) a commit lock is not required and this will improve performance when reading data.

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).

Release 0.1.4

fabric-peer-ext Release Notes - Aug 27, 2020

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

This release is based on the Fabric 2.2 codebase. Along with various bug fixes, the following features were added:

Application-specific Gossip data #401

A Gossip handler registry that allows applications to register a handler for an application-specific message type. When a Gossip message of a certain app-specific type is received then the registered handler is invoked and the handler may respond to the request.

Auth filter registry #405

An Auth Filter registry that allows applications to register an Auth filter (in-process) which is managed by the Resource Manager (similar to in-process chaincode).

Enhancements to the Transaction Service

• Commit type option was added to EndorseAndCommit #408
• Peer filter option was added to EndorseAndCommit #409
• Async option was added to EndorseAndCommit #415
• New CommitEndorsements function which allows a client to commit a set of endorsements #407
• New VerifyProposalSignature function which verifies the signature on a signed proposal #423
• New ValidateProposalResponses function which validates a set of proposal responses #427

Support for collection hash r/w sets in Block Publisher #431

Clients can now receive private collection hash read and write block events.

Support for private data reads and writes in Block Publisher #455

Clients can now receive private collection read and write block events.

Support for Fabric 2 chaincode lifecycle #451

In-process chaincode can be approved and committed using Fabric 2 chaincode lifecycle, as well as the legacy lifecycle.

Access control for ledger config #497

Ledger configuration operations are now controlled using channel-specific ACL entries.

State database provider resource #505

A State Database Provider resource is available for applications wishing to read from the state database directly without having the read show up on the ledger.

Other changes

• The full set of Fabric integration and unit tests have been re-enabled (some tests were disabled in the initial update to Fabric 2.0)
• Various performance improvements such as caching blockchain info in the Couch blocks database

Release 0.1.3

fabric-peer-ext Release Notes - May 6, 2020

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

Along with various bug fixes, the following features were added:

Implicit org policy for off-ledger collections #378

An implicit-org collection policy is defined as ORG('IMPLICIT-ORG.member'), which indicates that data for the collection are stored and distributed only within the peer's local org.

Release 0.1.2

fabric-peer-ext Release Notes - Feb 24, 2020

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

In-process user chaincode versioning #349

In-process user chaincode may now specify a version such that multiple versions of the same chaincode may coexist.

A chaincode is registered with a version that consists of a major version and optional minor version, e.g. v1, v1.0. A chaincode may be instantiated and/or upgraded with an optional revision, e.g. v1.0.1, but the revision is not used when resolving the chaincode implementation but only as a means by which to update a chaincode's policies.

Shared CouchDB instance/cluster #348

Added a PartitionType peer config that allows databases to be partitioned by peer ID or MSP, allowing multiple peers to share the same CouchDB instance/cluster.

In non-clustered mode (i.e. each peer has a dedicated database), PartitionType is set to PEER which results in the peer ID being prefixed to the name of the database. In clustered mode (i.e. all peers in the same org share a database) the PartitionType is set to MSP which causes the database name to be prefixed with the MSP ID.

Application-specific configuration validation plugins #255

Added a configuration validator registry that manages application-specific configuration validators. When ledger configuration is added/updated then an app-specific validator is invoked to ensure that the config is valid.

Txn config validator #359

Registered a configuration validator for the Txn service configuration which also validates the SDK config.

Other changes

• Updated codebase to Fabric v2.0.0
• Point to the latest Fabric SDK

Release 0.1.1

fabric-peer-ext Release Notes - Jan 29, 2020

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

System managed resources with dependency injection #259

Added a mechanism to inject dependencies to resources on peer startup. A resource 'creator' function is registered with the peer and then the peer manages the lifecycle of the resource:

• Create: A new instance of the resource is created by calling the creator function, injecting in all of the declared arguments
• Channel Joined: If the resource defines a function called 'ChannelJoined' then the function is invoked when a peer joins a channel
• Close: If the resource defines a function called 'Close' then it is invoked on peer shutdown

In-process User Chaincode #258

Added a new type of chaincode that is similar to user chaincode but runs in the peer's process. In this case the chaincode does not need to be installed (since it is built with the peer) but needs to be instantiated with an endorsement and (optional) collection policy.

Ledger Configuration User Chaincode #324

Converted the ledger configuration system chaincode to in-process user chaincode so that ledger writes may be enforced by endorsement policies.

Transaction Service #315

Added a (shared) service within the peer that can be used to gather endorsements and submit endorsements to the orderer.

Other Changes

• Updated codebase to Fabric v2.0.0-beta
• Switched to Azure Pipelines for the CI

Release 0.1.0

Features:

• Ability to customize peer build with custom modules.
• Distributed content addressable (DCAS) off-ledger collection.
• Transient data collection storage.
• CouchDB block storage.
• Consortium configuration ledger allowing validated application-specific configuration to be managed.
• Cluster mode - separate committer and endorser roles against a common CouchDB cluster.