Attributed execution

[Maelkum]

This PR makes changes to the node to add support for attributed execution. If the node is instructed to do so (by using the --attributes true CLI flag, it will try to load its attributes from IPFS/IPNS. The location where the node searches its data is determined by its public key.

On boot, the node will try to download the attributes.bin file from the relevant path. The code uses the Cloudflare IPFS gateways. Not sure if it's a transient thing, but the past week or so whenever I tested, that gateway was pretty solid in catching new IPNS names, while other gateways didn't sync.

Node caches those attributes in memory, so if the attributes need to be reloaded - the process has to be restarted.

Execution requests

Execution requests requesting specific attributes have the following form:

{
    "function_id": "{{hello-world-cid}}",
    "method": "{{hello-world-wasm}}",
    "config": {
        "number_of_nodes": 1,
        "attributes": { }
    }
}

The attributes file is optional. If needed, it can take the following format:

• attestation_required (boolean) - the node has at least one attestor, whichever it is
• attestors - object, with the following fields:
  • each (peer.ID) - each of the listed attestors should be found
  • one_of (peer.ID) - any one attestor from the list will suffice
• values - list of objects with name and value pairs, specifying attributes that the node should have. at the moment we support exact matches only

Example:

{
    "function_id": "{{hello-world-cid}}",
    "method": "{{hello-world-wasm}}",
    "config": {
        "number_of_nodes": 1,
        "attributes": {
            "attestation_required": true,
            "attestors": {
                "each": [
                    "{{important-attestor-id}}"
                ],
                "one_of": [
                    "{{first-attestor-id}}",
                    "{{second-attestor-id}}"
                ]
            },
            "values": [
                { "name": "CPU", "value": "4"} ,
                { "name": "RAM", "value": "16GB"} ,
                { "name": "PublicIP", "value": "Yes"} ,
                { "name": "StorageType", "value": "SSD"} ,
                { "name": "Storage", "value": "100GB" }
            ]
        }
    }
}

All of these values can be combines and used independently from each other, so e.g. only attestation_required can be set, or only the wanted attributes.

Roll Call

Head node passes along the attributes value on roll call to worker nodes. Worker nodes check by themselves if they fulfill the criteria and ignore the roll call if they do not (logging the condition which eliminated them from contention).

Head node does not double-check the reporting peers. It may be a good idea for robustness to have also workers send their attributes to the head node which could double-check them, to make sure none of them are filthy liars.