Having a blockchain with smart contracts, like in Ethereum/RSK, opens a can of possibilities, new use cases, and new ways to give value to business. I’m not sure it is needed, but one possibility to explore is to have a simple relational database associated with an account, using the account storage.
An account can have code (maybe precompiled), balance, nonce, and storage. Storage is composed by storage cell, each having an address (32 bytes), and a content (a big integer represented in 32 bytes). The account storage has a hash value associated: if its content change, the hash changes.
At @RSKSmart, we are experimenting having storage cells with arbitrary binary data (byte arrays of any length). The hash calculation is the same, and the cell persistence does not change: internally, it uses a key-value store, where key is a byte array, and value is a byte array.
Then, I could implement a precompiled contract, with:
– Method execute(sql) to execute a simple SQL statement (create table, insert, ….)
– Method query(sql) to retrieve an array of rows
Internally, each table could have an ID (short number), and each row has an ID (20 bytes address, maybe). The description of the database (one database per account) resides in system tables. The storage cell for a row should be located at TableID + RowID, in the account storage.
In this way, each state of world hash has an snapshot of the account databases, as now they have the account states.
But I insist: maybe there are few use cases where such arrangement add values. Usually, the value comes from contract logic, and more directly exposed state, in contract variables.
I hope to write some demo code.
Another approach is to use the contract as a lightweight wrapper around an industrial-strength distributed database. But it is not clear how to keep the snapshots by world state (and if those snapshots are needed or not).
Angel “Java” Lopez