New Feature: Support Light-weight Read-only Transaction Design

[cjcchen]

In the current version of ResilientDB, "get" transactions (i.e., read-only transactions) retrieve the values of some keys. To guarantee data consistency, these transactions are forced through the consensus layer to obtain the correct results. Due to the nature of consensus design, each transaction will be written to the chain and written to the disk to support durability and recovery.

To improve read-only transactions, we can explore alternative designs without the need to participate in consensus yet retrieve consistent results.

Here are a set of important considerations:

1. How to identify read-only transactions?
2. Should a fee be paid to process read-only transactions, if so, then read-only transactions will require payment, which must pass through consensus.
3. How to ensure data consistency without engaging in consensus. Without consensus, each replica will return different data. How to verify the data is consistent? Could we introduce read-only caching services (e.g., Coordination-Free Byzantine Replication with Minimal Communication Costs, ICDT'20)? Can we relax the need to provide the latest data, instead maybe we can support snapshot reads, where each query from the same client returns the same version of the data, i.e., repeatable.