Description 

While Hyperledger Indy has proven to be incredibly robust and more than sufficiently scalable to this point in its evolution and application, we think it would be useful to enable further scalability by adding the concept of Indy Read Replicas to the project. An Indy read replica is a copy of the ledger transactions from one or more Indy ledgers that can be used by clients that trust the replica. While not intended to be accessed by arbitrary agents, an enterprise might run a read replica on their own servers for the use of their own agents – the agents "trust" the deployment of the read replica. In turn, the use of read replicas will reduce the read load on the ledger. Each replica will stay up to date with the transactions on the ledger, and the agents using the replica need not connect directly with the ledger. For this project, we will start from one of two existing, open source Indy "ledger browser" implementations that collect transactions from the ledger and maintain them in a database. A REST API will be added that provides replica clients with an HTTP version of the existing ledger API. Once a functioning Indy read replica implementation has been developed and tested, we will look at what optimizations can be accomplished to further lower the load on the ledger. For example, a new replica has to retrieve all of the transactions on the ledger, and, in the open source ledger browsers does so by do a read for all transactions starting at 1. Is there a good approach to getting a "trusted" batch of transactions to eliminate that startup load?  To find transactions added to the ledger, the read replicas poll the ledger "anything new added?" Can that load be reduced by enabling a transaction "pub/sub" API that notifies read replicas of new transactions, perhaps even pushing them to the replicas. Lots of interesting design and implementation questions!

...