Sovrin Release Notes¶

Disclosure¶

Although every attempt has been made to make this information as accurate as possible, please know there may be things that are omitted, not fully developed yet, or updates since this publication that were not included in the information below. Only the most pressing or significant items have been listed. For the entire list of tickets and or specific information about any given item, please visit the list at Hyperleder Indy’s Jira. Once logged in, simply navigate to Projects > Indy.

1.1.34¶

Notices for Stewards¶

(!) There are possible OOM issues during 3+ hours of target load or large catch-ups at 8 GB RAM nodes pool so 32 GB is recommended.

(!) Pool upgrade to sovrin 1.1.32 should be performed simultaneously for all nodes due to txn format changes.

(!) indy-node 1.6.82 isn

’

t using the latest versions of libindy-crypto (must be 0.9.5) and python3-indy-crypto(must be 0.9.5). Set these packages versions in case of new node manual installation.

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.6.57 | | indy-node | 1.6.82 | | release version number | 1.1.34 | | | | |

Major Fixes¶

’

1.1.33¶

Notices for Stewards¶

There are possible OOM issues during 3+ hours of target load or large catch-ups at 8 GB RAM nodes pool so 32 GB is recommended.

Pool upgrade to sovrin 1.1.32 should be performed simultaneously for all nodes due to txn format changes.

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.6.55 | | indy-node | 1.6.80 | | release version number | 1.1.33 | | | | |

Major Fixes¶

1.1.32¶

Notices for Stewards¶

Warning: Embedded command-line tool indy is no longer available. For further pool interaction use the indy-cli package https://github.com/hyperledger/indy-sdk/tree/master/cli

There are possible OOM issues during 3+ hours of target load or large catch-ups at 8 GB RAM nodes pool so 32 GB is recommended.

Validator-info output has been changed. If you use validator-info as a data source make sure that you have done necessary changes for compatibility.

The INDY-1818 (Init Indy Node should output Base58-encrypted verkey already) affects nodes adding.

Pool upgrade to sovrin 1.1.32 should be performed simultaneously for all nodes due to txn format changes.

There are still some issues with token functionality.

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.6.54 | | indy-node | 1.6.79 | | release version number | 1.1.32 | | | | |

Major Fixes¶

’

t validating CLAIM_DEF

’

s filed ref. | | INDY-1862 | | Fixed an issue where the Sovrin package couldn

’

’

t on the network was showing as

‘

unreachable

’

. | | INDY-1842 | | There wasn

’

t enough information about upgrade in journalctl. | | INDY-1834 | | Fixed

‘

aws_manage

’

playbook that was failing when inventory directory wasn

’

’

Changes - Additions - Known Issues¶

1.1.30¶

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.6.53 | | indy-anoncreds | 1.0.11 | | indy-node | 1.6.78 | | release version number | 1.1.30 | | | | |

Major Fixes¶

’

’

Changes - Additions - Known Issues¶

| Description | Workaround | Ticket | | — | — | — | | Switch off a replica that stopped because disconnected from a backup primary. | | INDY-1681 | | Extended load scripts emulating non-smooth load according to the changes in the core script. | | INDY-1667 | | Proof of stability under load. | | INDY-1607 | | Investigate Out of memory issues with the current load testing. | | INDY-1688 | | Do not re-verify signature for Propagates with already verified requests. | | INDY-1649 | | POA: Require multiple signatures for important transactions. | | INDY-1704 | | Support all FEEs txns in the load script. | | INDY-1665 | | Test domain transactions with FEEs. | | INDY-1661 | | 3PC Batch should preserve the order of requests when applying PrePrepare on non-primary. | | INDY-1642 | | Ability to switch off (remove) replicas with no changes of F value. | | INDY-1680 | | A node should be able to participate in BLS multi-signature only if it has a valid proof of possession. | | INDY-1589 | | Make validator info as a historical data. | | INDY-1637 | | | | | | Known Issue: There are possible OOM issues during 3+ hours of target load or large catch-ups at 8 GB RAM nodes pool so 32 GB is recommended. | | | | Known Issue: INDY-1447 - Upgrade failed on pool from 1.3.62 to 1.4.66 | Note that INDY-1447 was fixed in indy-node 1.5.68, but it still presents in indy-node 1.3.62 and 1.4.66 code. So, some of the nodes may not to be upgraded during simultaneous pool-upgrade. If this problem will appear, stewards should perform manual upgrade of indy-node in accordance with this instruction. | || | | | |

Upgrade Scripts:¶

Pool upgrade from indy-node 1.3.62 to indy-node 1.6.78 should be performed simultaneously for all nodes due to txn format changes.

Additional Information:¶

To reduce the risk of reproducing INDY-1447, it is recommended to use the old CLI for pool upgrade from indy-node 1.3.62.

All indy-cli pools should be recreated with actual genesis files. For more details about txn format changes see [INDY-1421]((https://jira.hyperledger.org/browse/INDY-1421).

1.1.17¶

Important: Several iterations were done very rapidly between the last release and this one. All of the changes, upgrades, etc… are included in this new release. Simply upgrading will include them all from 1.1.13 until 1.1.17. To see further, specific numerous changes, please reference the appropriate tickets in the Hyperledger Jira ticketing system.

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.6.51 | | indy-anoncreds | 1.0.11 | | indy-node | 1.6.73 | | release version number | 1.1.17 | | | | |

Major Fixes¶

’

Changes - Additions - Known Issues¶

| Description | Workaround | Ticket | | — | — | — | | Made it so that the 3PC Batch should preserve the order of requests when applying PrePrepare on non-primary. | | INDY-1642 | | Made it so that Monitor takes into account requests not passing the dynamic validation when triggering view change. | | INDY-1643 | | Improved throughput calculation to reduce a chance of false positive View Changes. | | INDY-1565 | | Made it so that the performance of monitor is improved. | | INDY-1660 | | Made it so that Stewards, can have a script that can generates Proof of possession for their BLS key. That value can now be used in a NODE txn. | | INDY-1588 | | Added Support Proof of Possession for BLS keys. | | INDY-1389 | | Made it so that the average is not used when calculating total throughput/latency of backups. | | INDY-1582 | | Made it so that any client requests are discarded during view change. | | INDY-1564 | | Created a simple tool to show graphical representation of some common metrics. | | INDY-1568 | | Changed default configs for better performance and stability. | | INDY-1549 | | | | | | Known Issue: Upgrade failed on pool from 1.3.62 to 1.4.66. | Note that INDY-1447 was fixed in indy-node 1.5.68, but it still presents in indy-node 1.3.62 and 1.4.66 code. So, some of the nodes may not to be upgraded during simultaneous pool-upgrade. If this problem will appear, stewards should perform manual upgrade of indy-node in accordance with this instruction (!) To reduce the risk of reproducing INDY-1447, it is recommended to use old CLI for pool upgrade. | INDY-1447 | | | | | |

Upgrade Scripts:¶

Pool upgrade from indy-node 1.3.62 to indy-node 1.6.73 should be performed simultaneously for all nodes due to txn format changes.

There must be sovrin package upgrade to 1.1.17 version after indy-node package upgrade. You need to specify package=sovrin in pool-upgrade command to do this.

Additional Information:¶

All indy-cli pools should be recreated with actual genesis files.

For more details about txn format changes see INDY-1421 .

There are possible OOM issues during 3+ hours of target load or large catch-ups at 8 GB RAM nodes pool so 32 GB is recommended.

1.1.13¶

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.6.49 | | indy-anoncreds | 1.0.11 | | indy-node | 1.6.70 | | release version number | 1.1.13 | | | | |

Major Fixes¶

Changes - Additions - Known Issues¶

’

t be built because of new python3-indy-crypto in sdk repo. The problem described in INDY-1517 will be fixed in the next release of indy-node. | Workaround for this problem is to add python3-indy-crypto=0.4.1 to the list of packages to be installed. | INDY-1517 | | Known Issue: Upgrade failed on pool from 1.3.62 to 1.4.66. Note that INDY-1447 was fixed in indy-node 1.5.68, but it still presents in indy-node 1.3.62 and 1.4.66 code. | So, some of the nodes may not to be upgraded during simultaneous pool-upgrade. If this problem will appear, stewards should perform manual upgrade of indy-node in accordance with this instruction:(!) To reduce the risk of reproducing INDY-1447, it is recommended to use old CLI for pool upgrade. | INDY-1447 | | | | | |

Upgrade Scripts:¶

Pool upgrade from indy-node 1.3.62 to indy-node 1.6.70 should be performed simultaneously for all nodes due to txn format changes.

There must be sovrin package upgrade to 1.1.13 version after indy-node package upgrade. You need to specify package=sovrin in pool-upgrade command to do this.

Additional Information:¶

All indy-cli pools should be recreated with actual genesis files.

For more details about txn format changes see INDY-1421 .

1.1.12¶

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.5.47 | | indy-anoncreds | 1.0.11 | | indy-node | 1.5.67 | | release version number | 1.1.12 | | | | |

Major Fixes¶

| Description | Additional Information | Ticket Number | | — | — | — | | Fixed and issue where logs were appearing in the old CLI. | | INDY-1471 | | Fixed an issue where there were numerous blacklists under high loads. | | INDY-1461 | | Fixed an issue where the pool stopped writing after 1114k txns (different view_no). | | INDY-1460 | | Fixed an issue where the “AttributeError: NoneType object has no attribute ‘request’ during load”; was appearing. | | INDY-1464 | | Fixed an issue where the validator-info was reading an empty file. | | INDY-1406 | | Fixed an issue where validator-info -v –json wasn’t producing valid JSON. | | INDY-1443 | | Fixed an issue where the first Pre-Prepare message had incorrect state trie root right after view_change (on master replica). | | INDY-1459 | | Fixed an issue where the pool could not order transactions because Node set incorrect watermarks after its restart. | | INDY-1455 | | Fixed an issue where the pool stopped working due to several incomplete view changes. | | INDY-1454 | | Fixed an issue where the node crashes on _remove_stashed_checkpoints. | | INDY-1427 | | Fixed an issue where memory was running out during non-completed viewChange process (under load). | | INDY-1360 | | Fixed an issue where part of nodes continued ordering txns after incorrect state trie under load. | | INDY-1422 | | Fixed an issue where the upgrade failed on pool from 1.3.62 to 1.4.66. | |INDY-1447 ||Fixed an issue where a forced upgrade from 1.3.62 -> 1.5.67 without one node in schedule failed. | |INDY-1519 || | | | |

Changes - Additions - Known Issues¶

Upgrade Scripts:¶

Pool upgrade from indy-node 1.3.62 should be performed simultaneously for all nodes due to txn format changes.

Additional Information:¶

All indy-cli pools should be recreated with actual genesis files. For more details about txn format changes see INDY-1421.

1.1.11¶

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.4.45 | | indy-anoncreds | 1.0.11 | | indy-node | 1.4.66 | | release version number | 1.1.11 | | | | |

Major Fixes¶

Changes - Additions - Known Issues¶

Upgrade Scripts:¶

Pool upgrade should be performed simultaneously for all nodes due to txn format changes.

All indy-cli pools should be recreated with actual genesis files.

CLI Upgrading:¶

Old CLI (indy):

upgrade from 1.3 to 1.4 version delete ~.ind-cli/networks/<network_name>/data folder replace both old genesis files by new ones (from 1.4 node or from sovrin repo)

New CLI (indy-cli):

upgrade from 1.4 to 1.5 version recreate indy-cli pool using 1.4 pool genesis file (from 1.4 node or from sovrin repo)

Additional Information:¶

List of breaking changes for migration from indy-node 1.3 to 1.4:

https://github.com/hyperledger/indy-node/blob/master/docs/1.3_to_1.4_migration_guide.md

IndyNode 1.4 and LibIndy 1.5 compatibility:

General

By default LibIndy 1.5 will be compatible with IndyNode 1.3 (current stable), and not 1.4 (the new one).

LibIndy 1.5 can become compatible with IndyNode 1.4 if indy_set_protocol_version(2) is called during app initialization.

Guideline for teams and apps

Applications can freely update to LibIndy 1.5 and still use stable Node 1.3

If an app wants to work with the latest master or Stable Node 1.4, then they need to support breaking changes (there are not so many, mostly a new reply for write txns as txn format is changed, see 1.3_to_1.4_migration_guide.md)

call indy_set_protocol_version(2) during app initialization

Use https://github.com/hyperledger/indy-sdk/blob/b4a2bb82087e2eafe5e55bddb20a3069e5fb7d0b/cli/README.md#old-python-based-cli-migration to export dids from your old CLI wallet to the new one (new indy-cli).

1.1.10¶

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.2.42 | | indy-anoncreds | 1.0.11 | | indy-node | 1.3.62 | | release version number | 1.1.10 | | | | |

Major Fixes¶

Changes - Additions - Known Issues¶

Upgrade Scripts:¶

None for this release.

Additional Information:¶

None at this time.

1.1.9¶

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-node | 1.3.56 | | release version number | 1.1.9 | | | | |

Major Fixes¶

| Description | Additional Information | Ticket Number | | — | — | — | | The Node was restarting because of an

"

Out of memory

"

‘

attr_names

’

"

View change

"

was not occurring if the Primary node was stopped. | | INDY-1151 | | There was a failed restart after getting the

"

unhandled exception (KeyError)

"

. | | INDY-1152 | | Fixed a bug where you were unable to install indy-node if sdk repo is in sources.list | |INDY-1269 || | | | |

Changes - Additions - Known Issues¶

’

s stashing all the reqs and there is a risk of running out of memory. | | INDY-1250 | | Known Issue: Re-promoted node cannot hook up to a lower viewChange. | | INDY-1199 | | Known Issue: One of the nodes does not respond to libindy after several running load test. | | INDY-1180 | | Known Issue: One node fails behind others during the load_test with a high load. | | INDY-1188 | |Known Issue: Pool can be broken by primary node reboot in case of network issues between nodes. Note: RocksDB was added as dependency (INDY-1205). It is used for revocation, but the rest part of node functionality is still using LevelDB. | |INDY-1256 | | | | | |

Upgrade Scripts¶

None for this release.

Additional Information:¶

None at this time.

1.1.8¶

Important: Upgrade to this version should be performed simultaneously for all nodes (with force=True).

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.2.34 | | indy-anoncreds | 1.0.11 | | indy-node | 1.3.55 | | release version number | 1.1.8 | | | | |

Major Fixes¶

’

’

t working. | | INDY-995 | | ATTRIB transaction with ENC and HASH wasn

’

t working. | | INDY-1074 | | When returning N-F nodes to the pool, View Change does not occur if Primary node is stopped. | | INDY-1151 | | We were unable to recover write consensus at n-f after f+1 descent. | | INDY-1166 | | Newly upgraded STN fails to accept transactions (pool has been broken after upgrade because of one not upgraded node). | |INDY-1183 ||We were unable to submit upgrade transactions to STN. | |INDY-1190| | | | |

Changes - Additions - Known Issues¶

"

Getting Started with Indy

"

. | | INDY-1062 | | Updated information in

"

Setting Up a Test Indy Network in VMs

"

. | | INDY-1062 | | Add iptables rules to limit the number of clients connections. | | INDY-1087 | | Knowledge transfer on Indy build processes. | | INDY-1088 | | Incubation: Move CI part of pipelines to Hyperledger infrastructure. | | INDY-837 | | Made it so that a user can revoke a connection by rotating the new key to nothing. | | INDY-582 | | Client needs to be able to make sure that we have the latest State Proof. | | INDY-928 | | Created it so that anyone could have access to an up-to-date Technical overview of plenum and indy. | | INDY-1022 | | Known Issue: Pool has lost consensus after primary demotion (with 4 nodes setup only). | | INDY-1163 | | Known Issue: Ambiguous behavior after node demotion. | | INDY-1179 | | Known Issue: One of the nodes does not respond to libindy after several running load test. | | INDY-1180 | |Known Issue: Pool does not work after not simultaneous manual pool upgrades. | |INDY-1197 ||Known Issue: Pool stops working if the primary node was not included to schedule in the upgrade transaction. | |INDY-1198 | | | | | |

Additional Information:¶

Node promoting is not recommended for 1.3.52 version according to known issues because backup protocol instances may work incorrectly until next view change.

As mentioned above, upgrade to this version should be performed simultaneously for all nodes (with force=True).

1.1.7¶

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.2.29 | | indy-anoncreds | 1.0.11 | | indy-node | 1.2.50 | | release version number | 1.1.7 | | | | |

Major Fixes¶

"

NodeRequestSuspiciousSpike suspicious spike has been noticed.

"

Changes - Additions - Known Issues¶

Additional Information:¶

Mapping of all file/folder changes are located here.

Upgrade Steps¶

Send Pool Upgrade command so all nodes upgrade.
Sometime later each Steward will need to do the following steps to add their BLS Keys:

Steps to Add BLS Keys¶

From the Validator Node:

Generate a new 32-byte seed for the bls key (we recommend pwgen):

$ sudo apt install pwgen

$ pwgen -s -y -B 32 1

If the output has a single-quote symbol (‘), rerun until it doesn’t.

NOTE: This is not your Steward or Node seed.

Record the seed somewhere secure.
Switch to the indy user.

$ sudo su - indy

Configure the BLS key.

$ init_bls_keys --name <NODE_ALIAS> --seed '<SEED>'

The --seed is the seed you generated above, and will be used to create the BLS key.

Example with Seed:

$ init_bls_keys --name Node1 --seed 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

Capture the stdout at the end of the output, which looks like the following, and record it.

BLS Public key is 3AfkzUZVn2WT9mxW2zQXMgX39FXSY5qzohnMVpdvNS5KSath1YG5Ux4u9ubTFTaP6W55XX9Yx7xPWeYos489oyY53WzwNBG7X4o32ESnZ9xacLmNsQLBjqc6oqpWGTbEXv4edFTrZ88n93sEh4fjFhQMumaXxDfWJgd9aj7KCSpf38F

Exit the indy user.

$ exit

From the CLI Node:

Manually upgrade the CLI.

$ sudo apt update

$ sudo apt upgrade

Launch the CLI.

$ indy

The first time running the upgraded CLI you will be prompted to migrate your previous settings. Answer “Yes.”

Connect to the pool.

indy> connect live

Set your Steward as the signer in the CLI.

indy@live> use DID <Steward DID>

Example:

indy@live> use DID Th7MpTaRZVRYnPiabds81Y

Note: If your DID is not found in the wallet, you will need to use your steward seed:

indy@live> new key with seed <steward_seed>

Now you will send a node transaction like what you did when you added the node to the pool. You will add the BLS key as a new parameter to the transaction to update the pool ledger with this additional public key. For ‘dest’, use the same base58 value for this that was used when you initially onboarded your VM onto the provisional pool.

indy@live> send NODE dest=<node_dest> data={'alias':'<node name>','blskey': '<key_generated_by_init_bls_keys>'}

Example:

indy@live> send NODE dest=Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv data={'alias':'Node1','blskey': '3AfkzUZVn2WT9mxW2zQXMgX39FXSY5qzohnMVpdvNS5KSath1YG5Ux4u9ubTFTaP6W55XX9Yx7xPWeYos489oyY53WzwNBG7X4o32ESnZ9xacLmNsQLBjqc6oqpWGTbEXv4edFTrZ88n93sEh4fjFhQMumaXxDfWJgd9aj7KCSpf38F'}

Note: The ‘node_dest’ value can be found on the node with sudo read_ledger --type pool.

Questions and Answers¶

BLS Keys for State Proofs¶

What does BLS stand for?

Boneh-Lynn-Shacham - The BLS signature scheme is used to verify that a signer is authentic.

How does the CLI use State Proof for confirmation?

When the CLI requests information about a transaction it checks the BLS signatures to verify the transaction was written by nodes that are part of the validator pool. The CLI sends a request to one node (arbitrary one). If the Reply doesn’t have a State Proof, or the reply is incorrect/invalid, then CLI falls back to sending requests to all Nodes and waiting for f+1 equal Replies.

What if not all nodes in the pool have BLS signing keys for a transaction?

Transactions only get signed if all nodes reaching consensus can sign it (>= n-f Nodes with correct BLS signatures).

Can the bls_seed be any 32 character seed like the Steward seed?

Yes.

When adding a new node to an existing pool where do I find my BLS key?

When initializing your node using init_indy_node the output will display the keys for the node including the BLS key. It can be found in /var/lib/indy/<network_name>/keys/<node_name>/bls_keys/bls_pk file (e.g.: /var/lib/indy/sandbox/keys/Node1/bls_keys/bls_pk)

When you send the transaction to add the new node to the pool it will also contain the BLS key in the transaction shown in this example.

Example of send node command with BLS for 5th node in test pool:

send NODE dest=4Tn3wZMNCvhSTXPcLinQDnHyj56DTLQtL61ki4jo2Loc data= {'client_port': 9702, 'client_ip': '10.0.0.105', 'alias': 'Node5', 'node_ip': '10.0.0.105', 'node_port': 9701, 'services': ['VALIDATOR'], 'blskey':'2RdajPq6rCidK5gQbMzSJo1NfBMYiS3e44GxjTqZUk3RhBdtF28qEABHRo4MgHS2hwekoLWRTza9XiGEMRCompeujWpX85MPt87WdbTMysXZfb7J1ZXUEMrtE5aZahfx6p2YdhZdrArFvTmFWdojaD2V5SuvuaQL4G92anZ1yteay3R'}

Can I use a seed when generating my BLS keys?

For a new node when using init_indy_node if you specify a seed for this script that same seed is used to generate your BLS keys.

For existing nodes being upgraded to 1.2.50, which includes state proofs, you would use the script init_bls_keys where you can specify a 32-character seed on the command line.

init_bls_keys --name <NODE_ALIAS> --seed '<SEED>'

After running init_bls_keys, Stewards of existing nodes will be required use their CLI node to update their validator’s information on the ledger to include the bls keys:

send NODE dest=<node_dest> data={'alias':'<node name>', 'blskey': '<key_generated_by_init_bls_keys>'}

Multi-network and indy_config.py¶

Where do I find the configuration file settings?

With file and folder changes the new location for indy_config.py is in the directory location /etc/indy/. The configuration file has a new setting called "NETWORK_NAME" which is used to identify which network and associated genesis transaction files to use, such as sandbox or live. If adding a new node to a live pool, change this setting before initializing the node. The genesis files are now located in their own directory based off the network name “/var/lib/indy/NETWORK_NAME”. The defaults are live, local, and sandbox. Setting the "NETWORK_NAME" in the indy_config.py file will determine which network is used. The default setting in the indy_config.py file is “"NETWORK_NAME=sandbox".

1.1.6 Hot Fix¶

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.1.27 | | indy-anoncreds | 1.0.10 | | indy-node | 1.1.43 | | release version number | 1.1.6 | | | | |

Major Fixes¶

| Description | Additional Information | Ticket Number | | — | — | — | | Added a migration script which eliminates redundant fields with null values from legacy transactions in the domain ledger. | | INDY-895 INDY-869 | | Added a constraint on version field of POOL_UPGRADE transaction that denies values lower than the current installed version. | | INDY-895 INDY-869 | | Added prevention of upgrade to a lower version to Upgrader class. | | INDY-895 INDY-869 | | Fixed a bug in Upgrader class in search for a POOL_UPGRADE cancel transaction for the last POOL_UPGRADE start transaction. | | INDY-895 INDY-869 | | Added a test verifying prevention of upgrade to a lower version. | | INDY-895 INDY-869 | | Corrected existing tests according to introduced prevention of upgrade to a lower version. | | INDY-895 INDY-869 | | | | | |

1.1.6¶

Component Version Information¶

| Components | Version Numbers | | — | — | | indy-plenum | 1.1.27 | | indy-anoncreds | 1.0.10 | | indy-node | 1.1.37 | | release version number | 1.1.6 | | | | |

Major Fixes¶

’

Changes - Additions - Known Issues¶

| Description | Workaround | Ticket | | — | — | — | | New ledger serialization is supported and Leveldb is used as a storage for all ledgers : msgpack is used for the ledger serialization (both transaction log and merkle tree). | | | | The new serialization change created changes to the directory structure for the nodes. The directory name changes are located on a node under .sovrin/data/nodes/

<

node name

>

/

<

directories

>

. The change removes the ledger files as plain text files and creates them as binary files. A new tool was created to view the ledger entries called read_ledger. This tool also provides you with a count of the transactions. To learn more about this tool and to see a list of available commands, run this as the sovrin user: read_ledger --h | | | | Genesis transaction files are renamed adding a _genesis to the end of each file name. | | | | Added the commands to the POOL_UPGRADE to support downgrade and re-installation. However both have issues and should not be used at this time. | | INDY-735 INDY-755 | | Fixes to upgrade procedure, in particular an issue which caused an infinite loop. | | INDY-316 | | A new CLI command was added to ease the process of rotating a verification key (verkey). The command is change current key or change current key with seed xxxxx. | | | | Improvements to log messages. | | | | Publishing only to repo.sovrin.org | | | | In your sources.list you only need the entry

"

deb https://repo.evernym.com/deb xenial stable

"

. | | | | Implemented a command line tool to provide validator status. | | INDY-715 | | "
Debug
"
mode for tests was moved to parameter. | | INDY-716 | | Log levels were changed on some debug level messages to an info level. | | INDY-800 | | If the pool loses enough nodes and cannot reach consensus when enough nodes become available, the pool will still not reach consensus. | If you restart all the nodes in the pool, it will start reaching consensus again. | INDY-849 |

1.0¶

Major Features¶

| Description |Additional Information | | —| —| | Identities can be created, and their exercise and evolution can be controlled by ed25519 key pairs (where the public verkey is stored and updated on the ledger). | | | Identities are fully self-sovereign by default. Guardianship, as described in The Sovrin Provisional Trust Framework, is also possible. | The Sovrin Provisional Trust Framework | | Identities can have an agent, and the agent endpoint can be declared on the ledger. | | | Identities are associated with the roles defined in The Sovrin Provisional Trust Framework. Specifically see: trustee, steward, trust anchor, TGB member, and normal identity. | The Sovrin Provisional Trust Framework | | Identities with special roles have the appropriate permissions. | http://bit.ly/2eRfeIV | | The ledger supports a core set of transaction types suitable for early workflows | http://bit.ly/2v1OAmO | | Byzantine consensus is robust and transparent, providing diffuse trust. | | | Ledger state is enstructured as a Patricia Trie. This is the precondition for implementing Observer nodes and for having high-trust answers with any number of invalid high-trust answers with any number of malicious intermediaries. | | | The network generates log files that stewards can use as an audit trail. | | | The network can be upgraded without manual tasks for stewards, using a POOL_UPGRADE transaction. | | | Batching is functional, allowing bulk submission and reasonable throughput. (Note, however, that very large batches of more than a few thousand transactions are discouraged because they consume network resources unfairly and may cause brownouts for other users.) | | | Simple safeguards are in place to react to hacking and DDoS attempts. | | | Terminology in the CLI has been updated to align with usage in the Provisional Trust Framework and the DID specification. In particular, this release is DID-centric, whereas earlier previews were cryptonym-centric. | | | Registering simple schemas for claims, and then deriving claims and proofs from them, is possible. This supports many of the use cases envisioned for simple verifiable claims, but not the advanced privacy-preserving features offered by Camenisch-Lysyanskya-style schemes. | | | | | |

Deferred Features¶

| Description | Additional Information | | — | — | | DDO support: Currently, the DID support in Sovrin uses ATTRIB transactions. This limits the complexity and granularity of identity control. Full DDO support will be necessary to support models such as individual signers being empowered to represent a corporation, for example. | | | Rich schema: W3C verifiable claim schema thinking is still evolving, and we need time to experiment with the best ways to represent certain constructs. Very complex credential types may not yet be representable. | | | Revocation: Although the cryptographic foundation for revocation is fully implemented in the anoncreds component that Sovrin depends on, the ledger currently lacks a transaction type to update accumulators. This means initial claims won

’

t support revocation. | | | Observers and state proofs: Although the state trie is present in the ledger, code to return a state proof with each answer from the ledger has not yet been released. This means clients need to hear f+1 consistent answers from validator nodes before they can trust any response from the ledger. The Indy SDK supports this type of response checking, and will cut over to using the more efficient state proof mechanism as soon as Sovrin does. Once we have that mechanism in place, observer nodes become trustworthy because they cannot simulate state proofs. This drastically increases the scale and performance of the system. | Indy SDK | | | | |

Known Issues¶

| Description | Workaround | Ticket | | — | — | — | | Stewards demoting a node: Stewards should be able to demote and promote their own node. Demoting a node removes it from the pool so it does not participate in the pool reaching consensus. | | INDY-410 | | Ubuntu 17.04 support: Currently the CLI and Node are not supported on Ubuntu 17.04. | | INDY-8 | | Timezones not matching: If a system timezone of the primary does not match that of the other nodes the pool cannot function. | 1. Shut down the sovrin-node service. 2. Use “sudo dpkg-reconfigure tzdata” to change your timezone to UTC. (Select “None of the Above” and then “UTC”.) | INDY-466 | | Installing client as root: Installing the client as root does not allow users to access the transaction files and they are not able to connect to the pool. | | INDY-24 | | | | | |

New Terminology Changes to the CLI¶

Please be aware that the following terminology has changed:

. keyring is now
"
wallet
"
. link is now
"
connection
"
. invitation is now
"
request
"
. identifier is now
"
DID
"

Emergencies¶

For emergencies where the Network is under a DOS attack, there is a new command for Trustees only that will put the Pool into a read-only mode.

send POOL\_CONFIG writes=False

or optional

send POOL\_CONFIG writes=False force=False

The following are bool parameters: writes and force. Writes is required. Force is not required. The default for force is False.

Other Important Information¶

Keyrings to Wallets Directory¶

With the terminology change from

"

keyring

"

to

"

wallet,

"

the wallets that have already been created will be the client in the .sovrin/keyrings/live directory. When you upgrade, you

’

ll have to start the CLI and connect to live just once for the wallet directory to be created. The new directory is .sovrin/wallets/live. The upgrade does not move your existing wallets from /keyrings/live to /wallets/live since the wallet directory does not exist until you connect for the first time. You will need to move the existing wallets from /keyrings/live to /wallets/live and they will be ready for use.

Time Stamps¶

With the latest builds (which will be on your new stable) you will start to see a time stamp in the ledger for the transactions. It will look like the following:

V4SGRU86Z58d6TV7PBUe6f|1500090331922505|5iBLSL3iujkNsX4RiGN7RjDk5UVtE8GHsn8XHsRsmhUUN9Jz8GEmYtpPrso8e96jo3YafhYSwPkd9QXYA3wYyst4|1500090332|1|Pqs6Tyj1huDsjKYsiF8w4f|~WwZD24Fk4ka7ZY47MPopoo||||||2||

The time stamp is the entry that shows 1500090332.

The 1500090332 is the utc epoch and a converter can be found at this site https://www.epochconverter.com/ so you can see the human readable version of the time.

Sovrin Release Notes¶

Disclosure¶

1.1.34¶

Notices for Stewards¶

Component Version Information¶

Major Fixes¶

1.1.33¶

Notices for Stewards¶

Component Version Information¶

Major Fixes¶

1.1.32¶

Notices for Stewards¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Sovrin-related Issues¶

1.1.30¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Upgrade Scripts:¶

Additional Information:¶

1.1.17¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Upgrade Scripts:¶

Additional Information:¶

1.1.13¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Upgrade Scripts:¶

Additional Information:¶

1.1.12¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Upgrade Scripts:¶

Additional Information:¶

1.1.11¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Upgrade Scripts:¶

CLI Upgrading:¶

Additional Information:¶

1.1.10¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Upgrade Scripts:¶

Additional Information:¶

1.1.9¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Upgrade Scripts¶

Additional Information:¶

1.1.8¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Additional Information:¶

1.1.7¶

Component Version Information¶

Major Fixes¶

Changes - Additions - Known Issues¶

Additional Information:¶

Upgrade Steps¶

Steps to Add BLS Keys¶

Questions and Answers¶

BLS Keys for State Proofs¶

Multi-network and indy_config.py¶

1.1.6 Hot Fix¶

Component Version Information¶

Major Fixes¶

1.1.6¶

Component Version Information¶

Major Fixes¶