For this example I will be using Virtuoso, a quad-store written in C++ language. This RDF database has a class disk.c which implements a file access manager on xyz.db, which persists the database state. I propose swapping the xyz.db file for a named pipe, e.g. a FIFO special file, and have a script (an “eos adaptor”) on the other end of the pipe that serves as Virtuoso’s proxy to the eos smart contract. This minimizes the level-of-effort required for the existing quad-stores to interface with the blockchain. There may be a better way to abstract the persistence layer (e.g. extract an interface from disk.c, then implement a eos_disk.c) but the above seemed to me to be the path of least resistance.
As an example of how a disk write will work for the eos adaptor, the buffer used by disk.c will pass the write onset and the total_bytes to the eos blockchain and this transaction (and nothing more) will be recorded on the blockchain, respecting its index in the sequence of i/o transactions. On a read request, the buffer will pass the read onset and length to eos. To derive the current state of the file inside that char window, the smart contract will do the equivalent of running the transaction history from beginning to end. For optimization, as it runs each transaction/state transition, it will only consider (i.e. read and record) the bytes passing through the requested window. It will then return the state/content in the window back to the adaptor which passes the content back to the file buffer. In this way, the state machine (the blockchain) could model an xyz.db file of indefinite length and manage access to that file for an indefinite number of Virtuoso instances.
Interoperability and Data Access Control
If all the data in this blockchain-backed database was public data (e.g. DBPedia), then data access control is not an issue. But if we wish to store private data on this blockchain, then role-based access control would be needed to manage which transactions are allowed to be considered when deriving the file state. Those parts of the requested window which are not authorized are simply “redacted”.
Semantic interop between clients is built into the language the CRUD operations are written in, so we will get this requirement for free.
Simple Use Case
A service provider will then subscribe to services requests and she will view lists of requests in the manner described above, meaning the list will be a structured document which is transformed into viewer code by the blockchain. Her subscription likewise is a record (more specifically, a SPARQL query that is triggered to execute each time someone inserts a record on the blockchain involving properties and/or subjects appearing in the query) registered to the blockchain by the service provider. The blockchain will push her query result sets to the eos account of her choice. This means she can push the result set to another smart contract of her own authoring (an “agent”), perhaps to provide automated services for the event’s creator. In this way, human-to-machine and machine-to-machine service requests are mixed in with human-to-human service requests.
Another consideration is that blocks are created every 3 seconds, and create/insert/delete DB transactions are encapsulated as blocks in this model. The latency will need to be on par with file i/o operations. Some delay would perhaps be tolerable as a tradeoff for the confederated querying, but a few seconds or less for average query response time should be the goal.
I am eager to know your thoughts.