On this week there was a nice document about Blockchain project and I would like to continue writing about it in a more detailed form, so people could comment on it.
Small introduction: on initial phase of development (week #1-5) I focused too much on persistence and mapping to normal SQL database thinking about large queries and importance for the client to get straight access to DB. To be honest that was a mistake and now I could feel it after second phase of refactoring is finished (week #6-10). The main issue that Blockchain is a database and it requires that all data access is governed by Blockchain where SQL/noSQL/files will be used only internally for Blockchain.
We plan to store all information in blockchain i.e. in blocks. In the beginning the system will be centralized i.e. only 1 party will produce blocks. It is wrong to assume that blockchain system will not scale to many parties. There is no significant impact of consensus algorithm on the underlying technologies. For example, right now we already support such basic operations as : 1) replicate 2) revert and operations to the queue 3) rebase blockchain on top of another blockchain 4) delete specific operations from the queue. By defining consensus algorithm all these operations will be invoked if certain conditions are met. So, technically for distributed it will require to define only type of network to communicate between nodes and define consensus algorithm itself (longest chain for example).
There are 3 main conceptual objects in OpenDB blockchain:
- Object is a structured json object which has an id represented as string array and type inherited from encapsulated operation.
- Operation is a type (mandatory) structure that defines newly created objects of same type, deleted objects and referenced objects. Deleted objects are referenced by operation_hash and index number where they where created. Referenced objects are referenced by named id.
- Block is a structure that consists of several meta data fields (date, blockId, merkleTreeHash) and sequence of operations.
We can compare it with Bitcoin structure:
- Object - unspent output / input (UTXO)
- Operation - transaction
- Block - block
Blockchain is a chain of blocks and it is centric on validation, so the validation makes it consistent, transparent and trustable.
Hash computation (builtin).
There is a definite procedure how operation hash is calculated and how block hash is calculated. Operation hash is calculated based on json serialization of all objects and it is using SHA-256. The system is dynamic cause operation hash describes algorithm it is using i.e. “hash”:“json:sha256:89b6e3…”. So in future we could change hash algorithm or serialization method. Block hash is computed using merkle tree hash of operations and adding metadata fields such as date, previous block hash.
Signature validation (builtin).
Each operation must be signed by at least one user of the system. Each user should be registered with a signup key (exception OAuth) and that key should be used only to create / withdraw login key/pair. Login key/pair could sign all other operation. Key/pair algorithm is defined in login operation and now it is using EC. Blockchain doesn’t store any kind of private key and only stores public key and signature, so everybody could validate that operation was actually
Objects uniqueness validation (builtin).
- Object can not be deleted twice. In bitcoin none of output could be spent twice
- Object can not be created with the existing id. If deleted and created object has same id, it is called editing operation.
- All referenced and deleted objects should be existing in the blockchain before operation is added to the block
User defined validation.
Blockchain has objects of type sys.validate which defines whether operation could be added to blockchain or not. It has own expression language and function library which already has some basic number, set, string operations and extra operation validating signature, roles
Role based validation (user defined).
Some system objects could have a role and system functions such as “auth:has_sig_roles” could validate that operation was signed by somebody that has a role access. Roles form hierarchy and they are defined by “sys.role” object. Each role could be granted to any user login or signup by “sys.grant” object. Roles for login operation are taken precedence fi they exist, so user could define some logins to have a restricted access comparing to other logins.
Other validation (builtin)
Other validation include the maximum size of the block, maximum size of operation and extra validations that expressions are compilable and roles doesn’t form circular references loop.
OpenDB builtin object types
We came up with 6 builtin object types and the mechanism to create new operation / object types.
- sys.login, sys.signup - manages user credentials
- sys.role, sys.grant - manager blockchain roles and user permissions
- sys.operation - describes blockchain operations
- sys.validate - defines validation for all possible operations add to blockchain. Validation is considered to fail if at least 1 validation doesn’t pass.
- sys.limit [planning] - defines limits for certain type operation in order to prevent ddos or limit blockchain throughput for less-valuable operations
You can read detailed description from blockchain itself(https://dev.openplacereviews.org/api/admin). Each operation needs to be registered in blockchain by creating an object “sys.operation”.
You can already explore all objects / operations / blocks in the system and we plan to continue writing about blockchain details further.