Skip to content

Frequently Asked Questions

Jump to bottom
Gennady Laventman edited this page Nov 17, 2020 · 7 revisions

  1. Is the BDB server completely trusted by clients?

    • Yes, the client trusts the server completely.

  2. If a BDB server is compromised, what kind of attacks can be detected?

    • Provided that client submits a signed transaction, if an attacker at the server tampers the client's transaction before validation and commit to the block store, it can be detected as the client's signature verification would fail during the audit.
    • Provided that client holds a transaction receipt, i.e., a block header, if an attacker at the server tampers any past state or transaction, it can be detected. The transaction Merkle tree, skipchain, and state Merkle tree would help in detecting the tampering.
    • Provided that clients compare headers periodically and trust one another, if an attacker at the server provides different block headers to each client, it can be detected.

  3. If a BDB server is compromised, what kind of attacks cannot be detected?

    • If an attacker tampers the validation logic (ACL, rules, etc...), it may not be easy to detect as there is no replication of validation logic on nodes owned by individual client + no BFT consensus.
    • If clients do not trust each other and an attacker at the server provides a different block header to each client, it cannot be detected.

  4. How data privacy is achieved in a BDB server?

    • Provided that the server is trusted, read and write ACL helps in achieving strict data privacy.

  5. What are all the uses of ACL other than enabling data privacy?

    • With AND based write ACL, we can enable multisign transactions in the future to easily integrate various programming models such as Flows.
    • Especially when clients do not trust each other but the BDB server, ACL plays a significant role in enabling trust between them.

  6. Why proofs are needed when the client trusts the server completely?

    • Cryptographically verifiable proofs can be used later, even after the server seizes to exist, but his CA still exists.
    • In case that server become malicious, different clients can compare proofs returned by the server to discover such behaviour.

  7. How can a client prove to another client (who is also a user of the BDB) that a particular state is valid and active/inactive (i.e., a past state) as of a given time?

    • Each proof is based on receipt client keeps after submitting transaction and includes 2 stages - proof that block in question is part of ledger and proof block in question contains required transaction/state.
    • Step zero - store receipt and provide it upon request
      • Client A (prover) keeps receipt pair (BlockHeader, tx sequence number) for the block contains specific state change/transaction , which he provides to Client B as proof. Tx sequence number used to check transaction validity inside BlockHeader ValidationInfo data. We call (blockHeader,txNum) pair as Receipt. Please note Receipt contains server id and its signature.
    • Step one - prove that receipt block is part of ledger
      • Client B (verifier) asks server for genesis block and last (ledger.height) block in the ledger.
      • Client B asks server to provide a path in Merkle Skip List from ledger.height block to receipt.block.num block and from receipt.block.num to 1 and check validity of provided paths, including comparing genesis, last block and receipt.block with blocks returned by the server inside paths.
    • Step three - state and tx proof
      • Each BlockHeader contains root of Merkle-Patricia database content tree relevant to this block time - state_merkel_tree_root_hash and root of all block transactions merkle tree - tx_merkel_tree_root_hash.
      • Client B asks server to provide Merkle-Patricia tree path from state in question to root stored in receipt.
      • After path validation Client B knows that state in question was valid at time of blockX finalization.
      • Same way proof of tx existence in blockX can be provided.

Proof diagram

  • We use in receipt "full" BlockHeader composed of data created before block dissemination/consensus and data from transaction validation stage, including Merkle Skip List hashes.
message BlockHeaderBase {
  uint64 number = 1;
  // Hash of (number - 1) BlockHeaderBase
  bytes previous_base_header_hash = 2;
  // Root of Merkle tree that contains all transactions, without validation data
  bytes tx_merkel_tree_root_hash = 3;
  // Hash of BlockHeader of last block already committed to ledger
  bytes last_committed_block_hash = 4;
  // Number of last block already committed to ledger
  uint64 last_committed_block_num = 5;
}

message BlockHeader {
  BlockHeaderBase base_header = 1;
  // Skip chain hashed, based of BlockHeader hashed of blocks connected in blocks skip list
  repeated bytes skipchain_hashes = 2;
  // Root hash of system wide state merkle-particia tree
  bytes state_merkel_tree_root_hash = 3;
  // Validation info for transactions in block.
  repeated ValidationInfo validation_info = 4;
}
  • Note - To make really strong ledger consistency proof validation, one extra step to step two cans be added: in addition to skip list path validation of blockX existence, existence of block that points to receipt.block using last_committed_block_hash and path between them using previous_base_header_hash validated as well.

  1. How can a client prove to an external auditor (who is not a user of the BDB) that a particular state is valid and active/inactive?

    • Using same schema as in 7, but Client A plays both prover and verifier (proxy for an auditor) parts.
    • Given all server responses, including receipt, contains verifiable server signature, Client that acts as proxy can't forge ledger locally.
    • Although, client can hide recent changes in ledger, but once he exposed any receipt and ledger height X, there is no way to hide any information happen before time X.

  2. How BDB ensures immutability?

  3. How can a client prove to another client that a particular transaction was valid or invalid?

    • Say we have two clients, client A and client B, whereas client A want to prove that tx1 is valid/invalid transaction. Client A, could leverage schema described at 7, to generate proof of tx1 inclusion into chain. Next, client B can play a role of verifier in scheme 7 and check for proof correctness. That's client A has to provide path from genesis down to the tail of the ledge thru the block which includes tx1 inside.
Clone this wiki locally