Smart contract programming has been largely written by developers with primarily a traditional web background. Tooling and perspective is often limited to a classic single-application mindset, not taking stock of the unique trade-offs of running on a global system.

While most smart contracts use cases today are written totally bespoke, effectively carving up the shared word computer into discrete fiefdoms, we the microcontract/interlock design pattern

Status Codes

CQRS: Command / Query Separation

• Queries can run locally for free / gas-less

State Reuse

NB these diagrams are conceptual, and actual implementation may combine layers into a single smart contract As is becoming imncreasingly common, splitting state from behaviour encourages reuse, behaviour upgradability, &c. This pattern is not unlike a networked database in a traditional microservice architecture.

       State
         ^
         |
         v
   Access Control
    ^         ^
    |         |
    v         v
Client A    Client B

This Access Control layer may communicate over subcalls using the same protocol (ERC-902), which may in turn depend on state provided by other third parties (e.g. read only access, principle of least access, &c).

+---------Database----------+
|                           |
|         State A           |
|            ^              |
|            |              |
|            v              |
| +----Access Control-----+ |
| |                       | |
| | [✓] ACL B <-----------------erc902----> Auth Server A (Read Only)
| |                       | |
| | [✓] ACL B <-----------------erc902----> Auth Server B (Read Only)
| |                       | |
| | [✓] ACL C (Stateless) | |
| |                       | |
| +-----------------------+ |
|                           |
+---------------------------+

Call Recursion

Ad Hoc Composition / "Anonymous Contracts"

Combinators

Use Cases

Authorization & Access Control