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

  1. Access the ObjectStore tool.

    ./object_store_utility

    There are three types of configuration options you can use:

    • MANDATORY_OPTIONS

    • validate

    • restore

  2. 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
  3. 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
  4. 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