Create a 2nd layer modular hivemind app (essentially a 2nd layer app framework) that uses trigger/dataflow actions to generate auxiliary tables from block/operation data injected by hived
The point of this prototype is to test the programming paradigm and the performance of generating auxiliary tables from database triggers as new blocks and operations are streamed into the Postgres database. The purposes of these auxiliary tables is to provide data sources for API calls. For example, one such set of auxiliary tables would be to maintain state data about hive accounts.
By testing the programming paradigm, I mean testing the ease-of-use in terms of development of 2nd layer apps using triggers and the various scripting languages supported by Postgres (e.g. plpgsql, python, etc).
In terms of performance, we should analyze both "streaming" performance (when block data and operations are coming in at a normal rate relative to the speed of the blockchain) and also potential methods for accelerating the creation of auxiliary data in the case where the block/operation data is being bulk loaded into the database (e.g. like hivemind's "initial sync" process). While we should look at both, the primary performance metric should be acceptable streaming performance.
Another thing to examine is how to "incrementally" upgrade a modular hivemind app. For example, say an existing modular hivemind instance only supports wallet functionality, and the operator wants to add support for a new feature such as serving up data about social media posts or a game. The assumption here is that the new features to be added are orthogonal to the existing features, so that the associated triggers for the new feature data can be fed the block/operations data in the database's tables, without needing to replay the triggers for the auxiliary data that has already been generated.
Some parts of this task require that we have basic streaming of block/operations data working (namely real-world measurement of performance under streaming conditions), but investigation of possible methods of replaying from existing data and programming paradigm ease-of-use can begin without this functionality.
A logical choice for the initial prototype is a simple wallet as per the example above, that records the creation of accounts, and updates coin balances in those accounts as operations change them. This baseline code could then serve as a prototype for maintaining balances in 2nd layer coins.