The operator container uses the ObjectStore tool for data integrity assessment. The data integrity evaluation includes proof of origination and tamper-detection capabilities of the data stored on the ObjectStore.
Prerequisites
Verify that the operator container is instantiated. See Instantiate the Concord Operator Container for AWS.
Procedure
- Access the ObjectStore tool.
./object_store_utility
There are three types of configuration options you can use:
MANDATORY_OPTIONS
validate
restore
- Configure the ObjectStore tool MANDATORY_OPTIONS.
Option
Description
--keys-file arg
Add the file path for the cryptography keys configuration.
The blockchain configuration should reflect the existing Replica Network, excluding the Full Copy Client nodes, and include the BFT F and C values.
You can retrieve the AES encrypted key and IV from the Replica Network.
$ curl -X GET 127.0.0.1:8546/api/encryption/key {"algorithm":"AES/CBC/PKCS5Padding","key":"5022ae1e143037e75d8202dfa075646968ad06e2f286d762335fe3acaa37aa4b","iv":"ea2f789c04a1fdf3e4941d7822cd896e","key_length":256,"additional_info":null}
The latest set of Replica Network RSA keys must be specified. You can decrypt the encrypt keys using OpenSSL. Define the key and IV values as arguments for K and IV respectively.
$ sudo openssl enc -base64 -aes-256-cbc -d -in /config/concord/config-local/secrets.config.enc -K 5022ae1e143037e75d8202dfa075646968ad06e2f286d762335fe3acaa37aa4b -iv ea2f789c04a1fdf3e4941d7822cd896e commit_cryptosys: multisig-eddsa ED25519 commit_public_key: uninitialized optimistic_commit_cryptosys: multisig-eddsa ED25519 optimistic_commit_public_key: uninitialized slow_commit_cryptosys: multisig-eddsa ED25519 slow_commit_public_key: uninitialized tls_cipher_suite_list: TLS_AES_256_GCM_SHA384 node: - client_proxy: - principal_id: 4 replica: - commit_verification_key: 2998030A180E7A7FD862AFC3F890B4D75CDB1A8CBEC62055AE23B3153F8018DF optimistic_commit_verification_key: AA554C647331FF4C67E1B91E3CE7173CB6660AAE309F16862AD9D6E1CD4FA8E8 principal_id: 0 public_key: 8A4CEF40063A70974633EBCA694DA8BDD4DD3C0195A11D06322D84F74AC9E4CF slow_commit_verification_key: 9EA31F098EC511F1EAF87FDA7AD390284CB9C4055BB319BC7507676E43A86467 - client_proxy: - principal_id: 5 replica: - commit_verification_key: 42659827DBA10EFDBAD6D4E76732241AA4F450E414D3753D1C375BFC4CF89802 optimistic_commit_verification_key: 258AC15415F782516183766AA4543D11A9539A142C919907102148216CB54C6E principal_id: 1 public_key: A478CCEDC1AE51DA374D7C3125B29441C52584D77AAA4EFCE655D663266D7FD9 slow_commit_verification_key: AD911746FCFC0E9102D93F0F9095132702BAC92776CDCF3C1EBA337D3E02C41B - client_proxy: - principal_id: 6 replica: - commit_verification_key: A1BD4AA5CC96A6F021C5B2C76723E9EE568F1978C0EDDFE37025E6ABE694032B optimistic_commit_verification_key: 7A5731834A6F15A7A32B5515361A6FCF5EF3DC8D2439F7BABA098B47BACD24EF principal_id: 2 public_key: 199C3E5C1C74E4B0A399F8FC0CCE5326953C1FAC2F67695EACA33270DD5EDEB5 slow_commit_verification_key: 6A7DB22C08B7CD5A1B74FA4C101597872C85F88EDF97F475BA001E14E5E39B68 - current_node: true client_proxy: - principal_id: 7 replica: - commit_verification_key: 02698E88A7F51BC25BE3A0AC173BC60C49930034F239AB98743B76C72170F465 commit_private_key: 2E0BB343C9F12AB6E8ADF4888A732DEC2AEFF95025261B83A3C73A69B6E66381 optimistic_commit_private_key: 98833D731A3DF2A00009CF6DCB14D787835E8E7479C54BEE16A5170D11558F22 optimistic_commit_verification_key: C41B87885082B85423C4FDB54C92F87885B2CA8B62F78F1C379A9CBBC95BBA6E principal_id: 3 private_key: 2E6792BCAA0FAB3D501A698DF115A6B03AB40DC300CAD32BEDF0991CA039E41D public_key: 13F9C8AEDB391C1E21FE66070B22285ABEB8BB59B0D122571735BA33A7BB1A12 slow_commit_private_key: BEBB4DDC672EB450472BE12604EA02E935F50BB00F929F0D7808AC144FF9E94F slow_commit_verification_key: 99894A66B73AA3DCC6F15810C73DD6AF9DA22555519F456AEECDA3EE1546212B
View and use the extracted keys.
$ cat config-local/keys.yaml #number of replicas in cluster num_replicas: 4 #SBFT F value f_val: 1 #SBFT C value c_val: 0 # Non-threshold replica public keys replica_public_keys: - 8A4CEF40063A70974633EBCA694DA8BDD4DD3C0195A11D06322D84F74AC9E4CF - A478CCEDC1AE51DA374D7C3125B29441C52584D77AAA4EFCE655D663266D7FD9 - 199C3E5C1C74E4B0A399F8FC0CCE5326953C1FAC2F67695EACA33270DD5EDEB5 - 199C3E5C1C74E4B0A399F8FC0CCE5326953C1FAC2F67695EACA33270DD5EDEB5
--s3-config-file arg
Add the S3 ObjectStore configuration file path.
The S3 ObjectStore configuration is used for blockchain replication.
Note:Validate that the S3 ObjectStore configuration file parameter is running and accessible from the operator container node to avoid connection errors.
Sample S3 ObjectStore configuration file.
$ cat config-local/s3_object_store_config.txt # S3 Object Store Configuration s3-bucket-name: blockchain s3-access-key: concordbft s3-protocol: HTTP s3-url: minio:9000 s3-secret-key: concordbft # optional s3-path-prefix: concord
- Validate the data integrity of the blockchain.
A CheckPoint is created when there is an agreement of f+1 Replica nodes. The signed CheckPoints are saved on the ObjectStore. As part of the data integrity validation, the ObjectStore tool verifies the existence of these signed CheckPoints.
Option
Description
--all
Validates the entire blockchain data integrity from the block specified in the latest CheckPoint descriptor up to the genesis block.
./object_store_utility --keys-file config-local/keys.yaml --s3-config-file config-local/s3_object_store_config.txt validate --all
--range arg
Validates the blockchain data integrity starting from the block specified in the latest CheckPoint descriptor to the block specified by the --range argument.
$ ./object_store_utility --keys-file config-local/keys.yaml --s3-config-file config-local/s3_object_store_config.txt validate --range 500
--key arg
Validates a specific key.
The validation starts with the latest block the key resides in and the process parses the block and extracts the key value.
Note:This validation option is deactivated by default.
$ ./object_store_utility --keys-file config-local/keys.yaml --s3-config-file config-local/s3_object_store_config.txt validate --key 0000000000000061
- Restore the RocksDB data.
The RocksDB directory might contain a RocksDB snapshot created by a backup and restore procedure. The restore process starts at the block specified in the latest CheckPoint descriptor and ends at the last_reachable_block in the RocksDB.
If the RocksDB directory does not exist or is empty, the entire blockchain is restored to the RocksDB directory.
Option
Description
--db-path arg
Add the local file system RocksDB directory path.
The command restores the blockchain to the default version 4.
./object_store_utility --keys-file config-local/keys.yaml --s3-config-file config-local/s3_object_store_config.txt restore --db-path /tmp/db
--blockchain-version arg
Add the blockchain version.
The supported versions are 1 and 4.
The command restores the blockchain to version 1.
./object_store_utility --keys-file config-local/keys.yaml --s3-config-file config-local/s3_object_store_config.txt restore --db-path /tmp/db --blockchain-version 1