I've discussed this some already in our roadmap post, but I'll reiterate here briefly: the microservice app itself is quite simple, the idea is to have hived directly deliver blockchain data to a stripped down version hivemind with jus t basic data: block history including operations, plus account information and balances. This would all be coded in python/sql, just like hivemind itself. Next apps can build whatever particular features they want on top.
And we'll have modular sets of auxiliary data and API calls that can then be added, for apps that want more standard features as part of their design. By modularly designing such features, we can have standardized subsets of the entire API that can be provided by different types of API nodes as well.
The smart contract platform would be built as an additional modular layer on top of this basic framework. There's multiple options for the smart contract implementation, but right now I'm favoring directly executing the contracts within Postgres itself, so smart contracts could be written in any of the languages directly supported by Postgres (python, sql, etc) and Postgres would act as the sandboxing system.
Oh I see, I remember discussion about modular hivemind, many dapps already run stripped down version to some extend, unified/standard approach would be beneficial for sure especially if it helps number of 2nd layers designed for different purpose.
From what I understand, Smart contract would work with specific dataset within Postgres and 2nd layer code/node would check validity of that data during execution, then update that data?!
I was asking this to know more of thought process on design of system. In chat, you mentioned token is necessary as incentive for 2nd layer nodes and what other things are there to consider, will it have unstructured or structured design, configurability, verifiability, security, speed.