Improve database design

[srderson]

The database design needs to support two modes of operation.

1. Running transactions and consensus
2. Queries from clients
   • Consensus will primarily be performed by validating peers. It involves
   • Updating the state
   • Calculating the state hash
   • Storing a block on the blockchain
   • Sending transaction results and state deltas to peers that do not have access to a private transaction
   • Queries from clients
   • Get block by number
   • Get block by hash
   • Get transactions in a block
   • Get transaction by index in a block
   • Get transaction by hash
   • Get transaction by address
   • Get transaction by identity
   • Get chaincodes I have access to

Currently the database format is Block number -> Block bytes which is fast for consensus, but my be slow for queries. We could consider

Block number -> block hash
block hash -> block bytes` (where block bytes contains an array of transaction hashes
transaction hash -> transaction bytes

but this may be slower for consensus. However, this could reduce the overall size of the DB as we do not need to store duplicate transactions.

Should we consider two different database schemas, one optimized for validating peers and one optimized for non-validating peers?

[srderson]

@manish-sethi and I met this morning to discuss the DB design. @manish-sethi made many good points as to why the transactions should not be separated from the block bytes. These include

• Query performance: Much faster to read a block from the DB
• Storage performance: No need to calculate hash of every transaction when storing a block
• Size: Transaction data may actually be smaller than the hash

The plan is to create column families that will act as indexes and map transaction hashes to the block # and transaction index in the block. Calculating the transaction hash will be performed in a separate thread so that it does not slow down transaction processing.

[srderson]

One though about the column family that maps transactions hashes to block # and transaction index number. Currently, a transaction hash is not unique. You could send the same transaction in different blocks or the same block. To make transaction hashes unique, we need to do one of the following

1. Create a GUID and store that in the transaction
2. Transactions will need a sender. Maybe this is always unique due to our use of butterfly keys? Is every token unique?
3. Some other idea to make the transaction hash unique

@jeffgarratt If we do one of these, the transaction hash will be unique and that can be used as the ID.

[manish-sethi]

Added a separate column family to RocksDB for maintaining a mapping between queries keys and (blockId,txIndex). When a new block is committed, the entries in this column families are made in a separate thread. The client query thread waits for index completion up to the block level that the client thread notices when the query arrives.

@srderson we can make this configurable to add entries into this column families if we prefer to have these only on the peer nodes and not on the validator.

Deferring the implementation of some of the queries to issue #73 because of missing information in proto structures as yet.