Specification: Aleph message format to run code in VM

[hoh]

This issue discusses the specification of the Aleph messages that instruct nodes to run code in virtual machines.

The content that need to be specified:

• [x] Code to run
• [x] Entrypoint in the code
• [x] Format of the code: plaintext, zipped or gzipped directory
• [x] Location of the code: inline or in an other message
• [x] When to run the code: on HTTP requests, on Aleph message published, on a timer (cron)
• [x] Runtime to use (ex: Aleph Alpine Linux with Python). This contains the rootfs and should be updatable (security updates).
• [x] Initial state to use
• [x] What to do with the output state.
• [x] Should the function be reproducible
• [x] Output state format and signature of the node that executed the VM.
• [x] IO access: Access to internet, access to an Aleph node for queries
• [x] Resources allocated: cores, memory, max expected execution time

Here is a first proposal:

{
  "type": "vm-function",
  "address": "0x99eC8dc3831F67359a18420449fb028D5dCAa60f",
  "content": {
    "code": {
      "encoding": "plain" | "zip" | "tar.gzip",
      "entrypoint": "application",

      either "content":  "async def application(scope, receive, send):\n    await send({'output': 'hola!'})"
      or "address": "0xED9d5B040386F394B9ABd34fD59152756b126710"
    },
    "on": {
      "http": true,
      "cron": "5 4 * * *",
      "aleph": [
        {"type": "POST", "channel": "FOUNDATION", "content": {"type": "calculation"}}
      ]
    },
    "environment":{
      "reproducible": true,
      "internet": false,
      "aleph_api": false
    },
    "resources": {
      "vcpus": 1,
      "memory": 128,
      "seconds": 1
    },
    "runtime": {
      "address": "0x4cB66fDf10971De5c7598072024FFd33482907a5",
      "comment": "Aleph Alpine Linux with Python 3.8"
    },
    "data": {
      "encoding": "tar.gzip",
      "mount": "/mnt",
      "address": "0xED9d5B040386F394B9ABd34fD59152756b126710"
    },
    "export": {
      "encoding": "tar.gzip",
      "mount": "/mnt"
    }
  },
  "time": 1618386753.856,
  "ref": "695d63ff4d5a1d1f2d0b10523bdb903d407b7270e9c7b5c37e956fe57d43b2e3"
}

[hoh]

Question: Should the mount point for the initial state (data) and final state (export) be enforced to be identical ?

[hoh]

Since Aleph messages can be ammended, it would make more sense to reference the code using the root _itemhash than the address of the emitter. Same for the runtime and the data.

The format therefore changes to contain a ref to the _itemhash and a field _latestamend that specifies whether the latest amend to the message should be used or only the original message.

This would give:

{
  "type": "vm-function",
  "address": "0x99eC8dc3831F67359a18420449fb028D5dCAa60f",
  "content": {
    "code": {
      "encoding": "plain" | "zip" | "tar.gzip",
      "entrypoint": "application",

      either "content":  "async def application(scope, receive, send):\n    await send({'output': 'hola!'})",
      or "ref": "c5e40cd89103d3c57327a514f465b83cd193d1331f307bc5a4c38bfec36ab37d",
      "latest_amend": true
    },
    "on": {
      "http": true,
      "cron": "5 4 * * *",
      "aleph": [
        {"type": "POST", "channel": "FOUNDATION", "content": {"type": "calculation"}}
      ]
    },
    "environment":{
      "reproducible": true,
      "internet": false,
      "aleph_api": false
    },
    "resources": {
      "vcpus": 1,
      "memory": 128,
      "seconds": 1
    },
    "runtime": {
      "ref": "c5e40cd89103d3c57327a514f465b83cd193d1331f307bc5a4c38bfec36ab37d",
      "latest_amend": true,
      "comment": "Aleph Alpine Linux with Python 3.8"
    },
    "data": {
      "encoding": "tar.gzip",
      "mount": "/mnt",
      "ref": "c5e40cd89103d3c57327a514f465b83cd193d1331f307bc5a4c38bfec36ab37d",
      "latest_amend": true
    },
    "export": {
      "encoding": "tar.gzip",
      "mount": "/mnt",
    }
  },
  "time": 1618386753.856,
}

[moshemalawach]

Current proposal makes the content accessible as message.content.content... As discussed we would need to change this so that it's accessed as message.content.

In the optics of using the first hash of a vm creation as its address we need to ensure there is enough "unique" parts in the content to make it really unique (as in no further creation will get the same hash).

[hoh]

The specification was further defined and accepted here: https://github.com/aleph-im/aleph-message/pull/2