Inspiration from the Mimo eContracts.
Currently, eContracts have their business logic within their store. This mimics custom logic within the store. Following SOLID design principles, it seems like this approach can be limiting, with the
Composition Inheritance over Composition
Therefore, code would not extend the store i.e. Inheritance. Code could be called I.E. Composed.
This follows how the current EVM works. As in, code gets called in clients to run, versus storing code in browser.
Most of the benefits of this approach would be to take advantage of:
- Decentralized Storage via IPFS
- Power of WASM
- Code Flexibility: Apps don't need to have custom logic per application, and can share modules / services. Upgradeability becomes easier via addressing based on docstore.
- Cross-Compatible: Code is not limited to Javascript, but any WASM compatible code. This WASM code can then be loaded in the browser. Contracts can not only become 'transactional' but can follow a redux / functional approach for state updates (can plugin nicely with State Channels)
- Decoupling via Adapter Pattern: Program in an Adapter to any type of store / underlying storage solution (e.g. IPFS, Storj, Dat)
Drawbacks:
- Standardization around auditability of contracts with different coding languages.
These contracts / documents can be pure WASM files, or, Vanilla Javascript. These files can be computer in the front end of the browser.
Ex: Each type of store is used for a certain purpose
eContract Virtual Machine (eVM) Components
+ Identity Management -->
+ CallCode / Run Functions --> DocStore (Has references to Storage References)
+ StorageReferences
+ Contract State --> KeyValue
+ Contract Events --> Feed