Every single change set will be relatively small and self contained.
In this commit on a branch I implemented a new smart contract, a payment splitter.
https://github.com/cryptonomex/graphene/commit/c6b848ef18ed80607bfa4e0fde6fbcf38c0f6862The payment splitter is an object that accumulates payments and once a threshold has been accumulated it divides the proceeds up among several different destinations:
1. another account
2. a market order
3. another splitter (future work)
The code is divided into `operations`, `evaluators`, `objects`, and `indexes`
1. an `evaluator` performs mutations on the blockchain state for a particular `operation`
2. the blockchain state consists of a set of `indexes` on `objects` which can be though of like "tables" and "rows"
So a typical "smart contract" can be thought of as a class
Abstract Example
```
class MySmartContract
{
/// maps to the *_operation structs
variant some_operation( op_field1, op_field2, ... )
/// maps to the *_object data
string persistant_data1
int persistant_data2
}
/// maps to the *_evaluator
variant MySmartContract::some_operation( op_field1, op_field2, ... )
{
}
```
Operations are "decorated" with some meta data such as:
1. required fees
2. required authorities (must be derivable from data in the operation)
3. static validation (independent of chain state)
4. relevant accounts (any account that may have an interest in the operation)
Evaluator's are divided into TWO stages:
1. evaluate - performs invariant and pre-condition checks and ensures the operation is properly formed in light of current blockchain state
2. apply - performs the minimal work to transition the database state and assumes all preconditions are met.
This division between eval and apply allows the blockchain to SKIP evaluate while reindexing and simply apply the state transition.