Releases: trustbloc/sidetree-fabric
Release 0.6.0
sidetree-fabric Release Notes - Mar 5, 2021
What's new in sidetree-fabric v0.6.0
This release is based on Fabric 2.2.1 and sidetree-core-go v0.6.0.
Release 0.1.5
sidetree-fabric Release Notes - Dec 4, 2020
What's new in sidetree-fabric v0.1.5
This release is based on Fabric 2.2.1 and sidetree-core-go v0.1.5. Along with various bug fixes, the following features were added:
Protocol version manager #422
The protocol version manager returns the protocol version implementation associated with a transaction time (block number). One protocol version is currently implemented: 0.1. As new protocol versions are implemented, documents created with older versions may still be resolved.
Sidetree version endpoint returns protocol version and parameters #432
The existing Sidetree version endpoint was modified to return the protocol version instead of the component version. The protocol parameters are also returned in the response. The version endpoint accepts a 'time' parameter which, if specified, returns the protocol version applicable to that transaction time (block number). If not specified then the protocol for the latest block number is returned.
Change JSON documents in REST APIs to use camel-case #446
All snake-case fields in JSON documents have been changed to camel-case to be consistent with the Sidetree spec.
Document cache #413
Documents are now cached the first time they are resolved and subsequent requests for documents are retrieved from the cache. A cached document is invalidated by the Observer if an operation is applied to the document.
Release 0.1.4
sidetree-fabric Release Notes - Aug 27, 2020
What's new in sidetree-fabric v0.1.4
This release is based on the Fabric 2.2 codebase. Along with various bug fixes, the following features were added:
Combine Monitor with Observer #312
The Monitor functionality is added to the Observer so that a separate Monitor is no longer necessary. The Observer now processes batches from block events (as before) and also runs periodically in order to ensure that all blocks are processed. Should processing fail due to a transient error then the block is retried at the next scheduled interval.
Standby Observer role #313
An Observer is active if it has the sidetree-observer role and standby if it has the sidetree-observer-standby role. A standby Observer becomes active when there are no 'alive' active Observers in the cluster. There may be multiple active Observers and multiple standby Observers, although, only one Observer can process any given block. The metadata has a new field, LeaseOwner, which specifies the endpoint of the peer that currently holds a lease to process a range of blocks. The lease is relinquished after all blocks (up to the current block height) have been processed, at which time a new lease owner is chosen for the next range of blocks (using a deterministic algorithm based on block number).
Discovery provider for service endpoints #328
The Discovery Provider manages the service endpoints available at each peer joined to a channel. It manages local service endpoints and uses Gossip to request endpoints from remote peers. The data from remote peers are cached with an expiration time. After expiration, a new Gossip request is broadcast to fetch the latest services.
Discovery endpoint handler #330
Add a discovery REST endpoint that returns the services hosted by the peers on a channel. The service allows clients to filter on service name, domain, HTTP method, API version, and path.
Switch BDD test to Fabric 2 capabilities #381
The channel capabilities were set to v2_0 and the BDD tests were updated to use chaincode lifecycle.
Fabric logging provider for sidetree-core logging #399
Sidetree-core logs are now integrated with the Fabric logger so that logging levels may be set using the standard Fabric mechanism.
Release 0.1.3
sidetree-fabric Release Notes - May 6, 2020
What's new in sidetree-fabric v0.1.3
Configurable store for Sidetree operations #171
The operation store for each namespace is configurable in the Sidetree consortium configuration.
Configurable DCAS store #190
The DCAS store for each namespace is configurable in the Sidetree consortium configuration.
CAS REST endpoint #169
REST endpoint to upload and retrieve content (https://trustbloc.github.io/sidetree-fabric/docs/api/#/Content%20Addressed%20Storage)
Blockchain REST endpoints
REST endpoints to query for Sidetree transactions and Fabric blocks on the blockchain (https://trustbloc.github.io/sidetree-fabric/docs/api/#/Blockchain)
File handler REST endpoints #145
Framework to support multiple HTTP endpoints that serve up files (e.g. schemas, .well-known, etc.) which are stored in DCAS. A file is uploaded to DCAS through one of the configured endpoints and a DCAS ID is returned. The ID is then mapped to a resource name and stored in a Sidetree 'index' document. The ID of the index document is referenced in the ledger configuration for the given HTTP path so that a client may retrieve the file (which is stored in DCAS) using a friendly name.
Bearer token authorization #152
Authorization tokens are configured at the peer config (core.yaml) and then referenced in the REST handler configuration. If tokens are defined for a REST endpoint, then an authorization handler is first invoked in order to validate that a valid token was passed in the request header. If the token is valid then the request is allowed to proceed, otherwise an HTTP 401 (UNAUTHORIZED) is returned.
Persistent queue for batch operations #32
Operations are written to a LevelDB-backed queue so that queued operations aren't lost on peer restart.
Fabric 'cluster' mode for BDD tests #173
The BDD test now runs using Fabric clustered peers, i.e.the peers in one org share a database.
Release 0.1.2
sidetree-fabric Release Notes - Feb 26, 2020
What's new in sidetree-fabric v0.1.2
Configuration validator #126
Configuration validators were added to validate both peer-specific Sidetree configuration and consortium config, which includes protocol config.
Release 0.1.1
sidetree-fabric Release Notes - Jan 29, 2020
What's new in sidetree-fabric v0.1.1
Convert Document and TXN chaincode to in-process user chaincode #99
The Document and SidetreeTXN chaincodes now run in the peer's process. They no longer need to be installed but they do need to be instantiated.
Implement REST API's in the peer process #66
The external, Sidetree Docker container has been removed and the REST endpoints are now inside of the peer(s). Each peer exposes a REST endpoint according to its role. If the peer has the 'sidetree-resolver' role then the document resolver REST endpoint is exposed. If the peer has the 'sidetree-batch-writer' role then the document update endpoint is exposed.
Read Sidetree configuration from the ledger #65
Sidetree configuration is now stored on the ledger (which is channel-specific). Multiple Sidetree namespaces may be defined on each channel and a single REST server serves all of the namespaces (on a single port). For example, you can define the following namespace/path combinations:
- Channel: mychannel, Namespace: did:sidtree, Base path: /document
- Channel: mychannel, Namespace: did:bloc:trustbloc.dev, Base path: /trustbloc.dev
- Channel: yourchannel, Namespace: did:bloc:yourdomain.com, Base path: /yourdomain.com
Dynamic updates are also supported. A new namespace may be added/removed dynamically, or the configuration for an existing namespace may be updated (e.g. a new protocol version added or the base path modified).