Kernel Deployment Workflow

beaker_deployment_workflow.md

Proposal

For now here's a primitive idea of the workflow a user would go through when deploying and instantiating a Beaker instance:

To deploy a new kernel instance a user needs:

• CLI: Beaker CLI
• Kernel: A Deployed Kernel Contract, with a designated Address
• EntryProcedure: A Deployed Entry Procedure Contract, with a designated Address and chosen Id
• Account: Any Ethereum Account with a the minimum required gas X
• Web3Provider: A local Web3 Provider available through an HTTP address

1. Setup Beaker Repo

In order to keep track of a instance, User uses the CLI to create a new project:

beaker-cli new <directory>

Which creates a default beaker.json file.

{
   "kernel": {
        "address": "..."
    },
    "account": {
          "provider": "http://localhost:8545"
     },
    "description": "My Contract Instance"
}

1. Entry Procedure

Before deployment, a User first needs to either choose an existing Entry Procedure or create one. The user can also verify that the entry procedure is valid with (if entry address is 0xdeadbeef on the main network)

beaker-cli verify --address 0xdeadbeef --network main

Assuming he chooses to use an existing entry procedure, he adds an #entry#address property to the beaker.json file:

{
   "entry": { "address": "0xdeadbeef", "id": "admin" }
}

2. Instance Deployment

beaker-cli deploy

User uses a local Web3Provider with an Account to deploy an instance by calling Kernel#new_instance from the Kernel. Which takes:

• An EntryProc address
• An EntryProc Id

We get:

1. An address to the new Instance. As #location in beaker.json.

{ "location": "..." }

2. A list of procedures. As #procedures in beaker.json. This starts with the entry.

{ 
   "procedures": {
       "admin" : {
           "clist": "...", 
           "location": "0xdeadbeef",
        }
    }
}

3. State Initialization

Once the User has an deployed Instance the user should be able to make a call to the Instance

# Raw payload
beaker-cli call "setOwner"