Commit 366cf8208f4cd25c7c689fd76120241482ec7989
Update design.md
wanderer authored on 11/22/2016, 5:28:30 PMGitHub committed on 11/22/2016, 5:28:30 PM
Parent: 29b4a4a60e83eef1ed70225dae7e9514764a25bf
Files changed
| docs/design.md | changed |
| docs/design.md | ||
|---|---|---|
| @@ -1,53 +1,25 @@ | ||
| 1 | 1 | # Architecture |
| 2 | 2 | |
| 3 | -This prototype attempts to model Ethereum as three seperate but interlocking | |
| 4 | -layers. Environment, Kernel, and VM. | |
| 5 | 3 | ``` |
| 6 | - +------------------+ | |
| 7 | - | | | |
| 8 | - | Environment | | |
| 9 | - | | | |
| 10 | - +------------------+ | |
| 11 | - | | |
| 12 | - +------------------+ | |
| 13 | - | | | |
| 14 | - | Kernal | | |
| 15 | - | | | |
| 16 | - +------------------+ | |
| 17 | - | | |
| 18 | - interfaces | |
| 19 | - | | |
| 20 | - +------------------+ | |
| 21 | - | | | |
| 22 | - | VM | | |
| 23 | - | | | |
| 24 | - +------------------+ | |
| 4 | + +--------------+ | |
| 5 | + | | | |
| 6 | + | Environment | | |
| 7 | + | | | |
| 8 | + +--------------+ +--------------------+ | |
| 9 | + | | +--+ | |
| 10 | + | +----+ Imports | | | |
| 11 | + | | +--------------------+ | | |
| 12 | + +------------+ +------------+ | | +--------------------------+ | |
| 13 | + | | | | | +--------------------+ | | | | |
| 14 | + | Kernel +-------+VM Container+---------+ +------+ Sandboxed VM instance | | |
| 15 | + | | | | | | Imports | | | | | |
| 16 | + +------------+ +------------+ | +--------------------+ | +--------------------------+ | |
| 17 | + | | | |
| 18 | + | +--------------------+ | | |
| 19 | + | | | | | |
| 20 | + +----+ Imports +--+ | |
| 21 | + +--------------------+ | |
| 22 | + | |
| 25 | 23 | ``` |
| 26 | -## VM | |
| 27 | - | |
| 28 | -The VM implements [webassembly](https://github.com/WebAssembly/design). Two | |
| 29 | -sets of intefaces are exposed to it by the kernal. The Kernal Interface and | |
| 30 | -The Environment Interface. | |
| 31 | - | |
| 32 | -## Kernel Interface | |
| 33 | - | |
| 34 | -The kernel handles the following | |
| 35 | - * Interprocess communication | |
| 36 | - * Intializing the VM and exposes ROM containing code to the VM (codeHandler) | |
| 37 | - * Exposing the namespace and Intializes the Environment which VM instance exists | |
| 38 | - (callHandler) | |
| 39 | - * Provides some built in contracts that facilitates different run levels | |
| 40 | - (runTx, runBlock) | |
| 41 | - * Provides resource sharing and limiting via gas | |
| 42 | - | |
| 43 | -The kernel Interface expose kernal primitives to VM which contain | |
| 44 | - * IPC (calls) | |
| 45 | - * Namespace Interface | |
| 46 | - * GET/PUT/DELETE/ROOT/NEXT - currently implemented as a `Map` | |
| 47 | - | |
| 48 | -## Environment Interface | |
| 49 | - | |
| 50 | -The Environment Interface expose the following | |
| 51 | -* blockchain infromation | |
| 52 | -* current block infromation | |
| 53 | -* transaction infromation | |
| 24 | +# Overview | |
| 25 | +The `Kernel` is modeled to be somewhat like [actors](https://en.wikipedia.org/wiki/Actor_model). Each Kernel/Actor is bound to a segment of code and a state tree on startup. The Kernel provides the top level API. When the kernel recieves a message from another kernel or an external source (signal) it may run that code in a VM container. The container just provides a uniform way to interact with VMs. The container is given an instance of `Evironment`. The `Evironment` contains all the ephemeral state that need for the VM container and instance. Lastly the VM container start and manages the VM instance which is assumed to be sandboxed. The Sandbox communicates to VM container via `Imports` that are exposed to it on the time of creation. | |
Built with git-ssb-web