Objects on chain

Blockchain is like bare metal, it is efficient, cold and monotonous. Let's enliven it with evolving objects. This is an introduction, for formal definitions see the protocol.

##Versions Blockchain is immutable, so for the objects to evolve they need versions. New objects point to a prior version of themselves, which points to the version before that, recursively all the way to the first version of this object. The blockchain uses hashes for such pointers. So do we, i.e. a pointer to a previous version of the object is a hash of that object.

##Types Objects are differentiated by their types. Types are special kinds of objects that let us understand what objects mean. Types allow objects to have many attributes/properties, and for us to understand the meaning of these attributes, e.g. name, location, creator, price, etc.

##Identity One special type of object is Identity. We have the Identity to denote who changes other objects. The Identity is important in decentralized markets and in Enterprise applications, and especially in financial settings where the law requires money handlers to verify user's identity.

##Links Objects point to other objects and these links are like the URLs on the Web.

##Storage Objects are fat and do not fit on chain, thus the chain itself only keeps secure references to object bodies, which are kept in a scalable trust-reduced immutable storage.

##Scripts Objects change state and this change needs to be governed. We have scripts that govern this change. Some scripts are executed on-chain by miners and others off-chain by the client nodes. The reasoning for this divide is the privacy. If the transaction is encrypted, the script (often called contract) must be executed off-chain. Running scripts off-chain challenges the notion of consensus.

##Chains The blockchain uses a couple of simple methods to make its data structures immutable. We follow the suit.

In the blockchain a block header contains a hash of a previous block. Similarly transactions are chained. In Tradle the versions of objects form chains.

Another chain pattern used in blockchains is merkle trees. Bitcoin uses it to represent in one hash a list of all the transactions contained in a block. Anyone can hash all the transactions in a block into a merkle tree root hash to verify that block was not tempered with. But merkle tree is even cooler than the simple hash of hashes, as it allows to construct very small and a very efficient to verify proof that a hash belongs to a certain branch in a merkle tree. This makes merkle trees very popular. For example, there is a design cooking now that will create a merkle tree of all unspent bitcoins, which will allow to scale blockchain nodes storage 100 times. Merkle trees are also proposed in SIN Identity design.

We plan to use Merkle trees for all objects created by a person. This will make it extremely hard for attackers to introduce an alternative history. Any ideas where else we should use merkle trees in Tradle objects? Please open a github issue on this repository or ask us anything in the chat room for this repo.

Protocol versioning

Objects contain a version of the protocol they comply to. This way upgrade to a new protocol becomes possible.