Dumb Contracts
To keep things simple, I chose to not have smart contracts; rather the opposite: dumb contracts. The main reason is that people don't understand complicated contracts in legalese, and much less so in Forth or JavaScript. For most financial transactions, you don't need a smart contract, anyways. The basics of a contract is that you offer something and want something else in exchange. We assume for simplicity that all things offered or asked for are recorded in the same BlockChain.
Assets and Obligations
To allow arbitrary real world goods to be represented by a token on the BlockChain, we allow people to create those as future assets. When the future expires, the creator has an obliation to deliver that asset to the current owner; it will be removed from the BlockChain afterwards. Verification of actual delivery of that asset may be up to some notary or other arbiter, usually complaint-based (i.e. the arbiter is only there to resolve conflicts; conflicts should be public and lower the score of an asset creator). Future assets have the same form as credits, they create two tokens, an asset and an obligation. Both can be traded, and when the obligation is fulfilled, asset and obligation meet each other again, and are annihilated.
Legal tenders inserted into the BlockChain are handled that way, too: A bank issues a pair of assets and obligations, the obligation stays at the bank, the asset is sold for that legal tender to the purchaser (the legal tender is transmitted by normal bank transfer). The purchaser can trade that legal tender with others, and if you want to leave the BlockChain, you sell it (for normal bank transfer) to one of those banks that have obligations in that currency; they are now free to annihilate those obligations, as they have fulfilled them.
Mortgages and loans with interest rates are too complicated for a dumb contract, which is a good thing.
State of an Asset Account
An asset account contains the following state:
- A hash of the contract that last changed the state
- A table of assets and their values (how many)
- A timestamped signature of all that in canonical form
An asset account is addressed by its pubkey. Contracts are addressed by their hashes.
A wallet has a securely created random number as seed to create a sequence of secret keys and their corresponding pubkeys.
The merkle tree to calculate the hashes of a block starts with the signatures only; the R and S values of the ed25519 signature are xored to compress one signature to a 256 bit value (enough for the security guarantee of the signature).
A chain also contains metadata (e.g. asset types, permission rules, granularities of assets), metadata is stored in a DVCS repository, and the current revision's hash represents that metadata. Updates can only be checked in by consensus, i.e. if a new version is available, signers who accept the new version of the metadata first try to sign and check in the new version, and if that doesn't reach a consensus, try again with the old version.
What's a Dumb Contract?
A dumb contract represents the state transition of the active data in the BlockChain to fulfill that contract. A contract is valid if it preserves all the transacted goods (allows creation and annihilation of assets+obligations, all other values have to be preserved). Obligations are just another name for an asset with a negative value.
Contracts are stored as shortened forms of the state transitions, only those values that change are recorded in a form that is by design valid, and only needs checking of the sources. The new states need a valid signature of the respective owner. To execute a contract, all sources are fetched, the transitions (assets moved from one account to the other) are performed, and the signatures (destinations) of the new states are checked.
Contracts can be offered in open form, where parts of the transaction are left open to be filled in, e.g. source or destination addresses. If the open form contains a destination, and the relevant information to update it is completed by then, it can be appended by further informations without needing a signature of the contract again.
To formalize a contract, Sources are written as S (timestamp), destinations as D (new timestamp + signature), obligations as O, assets as A, delta amounts as + or - (give or take), and numbers to select the correct source if unclear (the last source is always the active one). B is a shortcut for balancing an asset, and can be used instead of the last value on that asset type. Also, previously used assets can be selected by number.
All sources specify the date of the source state, so that a contract can be performed only once — the destination date must be later than the source date.
- Claimed money cheque (anybody who has the transaction can claim the money; requires trust to the ledger node that accepts the cheque): SA-DSA+D
- Money transfer (only the designated recipient can claim the money): SA-SA+D1D
- Creation of asset and obligation: SA+OBD
- Two party purchase: SA¹+A²-S¹B²B1D2D
- Two party purchase delivery: SA-SOB1D2D (annihilates the asset)
- Bid/Ask in an exchange: SA¹+A²-D, finalized by SA¹+A²-DS¹B²BD. Note that bids/asks in an exchange can be more complicated when they are only partly fulfilled; the splitting requires action by the bidder; and also note that this kind of bid requires, like the cheque, trust in the ledger node; but less than: The ledger node can only buy for the same price, not steal the money. Better finalize the contract with the other side.
- Auction offer: SA¹-, auction bid: SA¹-S¹BA²-D, auction conclusion: SA¹-S¹BA²-D1²BD. Auction offers are signed with an end-of-auction beginning to indicate the timeout, and the offering party can select the best match, allowing other algorithms as maximum price, too, or other timeout algorithms than the fixed deadline; e.g. 15 minutes after last bid or so.
The evaluation of a dumb contract is rather easy: All sources and destinations must balance (i.e. the sums of all sources with their respective units must be equal to the sums of all sinks with their units) and all destinations must have a signature for their state. The contract must have signatures of all destinations inside, but the signature is allowed to cover only part of the contract. As and Os can be created in pairs or annihilated in pairs, permission who is allowed to create depend on the type of asset and obligation (everybody is allowed to annihilate).
Sources are seen as selector (a source is a pk+timestamp), assets select the asset value in the source, values operate on that asset. Destinations are signatures and refer to the corresponding source by number of occurance — the sources are never reordered. Sources are written as pk+timestamp, but hashed in as their signature, so you can only verify the destination signature if you actually have checked for the source state in the corresponding ledger.
Mixer
Note that there can be an arbitrary amount of participants in one contract, so it is possible to merge contracts with the consent of all participants. If you want to anonymize your account, you need to distribute the value into difficult to track coins (e.g. powers of two), and to do so without being tracked, many other people have to do the same thing, and do it in the same big merged contract.
Size of a transaction
- Opcodes are one byte (there aren't that many); literals are bytewise encoded and strings have a length preceeding the raw data — see commands
- Sources are 8+32=40 bytes strings
- Assets are an integer (index into the set of assets), an optional describing string (not needed for a currency)
- Values are 64 bit integers. For a legal tender, the scale is in cents, for deflationary coins the scale can be considerably larger. Sums are always kept in 128 bits, so for really large transactions, you can use double values (two 64 bit integers).
- Destinations are signatures with timestamp and expiration, i.e. 80 bytes strings.
A minimal transaction is somewhat less than 300 bytes, and that's already non-emtpy to non-empty account.
Descriptive Assets
Monetary assets are just units of a currency; interchangeable, summable, and it is irrelevant who's obligation will be used to fulfill the contract.
Real world assets may need a description. The description however reveals a lot about the transaction, and therefore must be encrypted. Real-world assets have two-party transfers (you can't split real world assets), so a DHE between the sender and receiver vault key is sufficient. The DHE is mixed with an IV generated from the contract so far, and the description string has a 128 bit HMAC to check that the decryption was likely correct.