Skip to content

Multiple Blockchains

Jump to bottom
dabooz edited this page Jul 27, 2017 · 2 revisions

Multiple Blockchains

Agreements between producers and consumers using the "Citizen Scientist" protocol include agreement on the blockchain type and name to be used by both parties. This means that either party could have more than 1 blockchain client container running concurrently. Producers and consumers can specify which blockchains they want to use. Producers indicate their choice(s) by configuring it through the Edge Device API on the agreementprotocol attribute (either a global attribute or an attribute specific to a service). Consumers indicate their choice(s) by specifying it in the agreementProtocols section of their policy file(s). Blockchain clients MUST be registered in the exchange by the same type and name as referenced by the producer and consumer.

The producer and consumer choices MUST have a non-empty intersection for an agreement to be made. Intersection is done on blockchain type and name. If one party doesnt specify either, then it is assumed that the party doesnt care. When specifying blockchain type and name, it is important to know that the only blockchain type supported is "ethereum", and it is also the default. The default blockchain name is "bluehorizon". If both parties specify neither type nor name, "bluehorizon" will be chosen.

Specifying a Producer Blockchain

On an Edge Device, when using the "Citizen Scientist" agreement protocol, a specific blockchain client can be specified. The agreementprotocol attribute can be specified as a global attribute (using the /service/attribute Edge Device API) or as a service specific attribute as shown below. The following attribute indicates that the device wants to use a blockchain registered in the Horizon Exchange as type "ethereum" (the default) with name "myblockchain". This attribute is set as a service specific attribute using a POST to the /service Edge Device API. More than one name can be specified. If so, the order in which they are specified indicates preference. Specifying no names indicates that the Edge Device doesnt care which client is used.

    "attributes": [
    ...
        {
          "id": "agreementprotocol",
          "short_type": "agreementprotocol",
          "label": "Agreement Protocol",
          "publishable": true,
          "mappings": {
            "protocols": [
              {"Citizen Scientist":
                [
                  {"name":"myblockchain"}
                ]
              }
            ]
          }
        },
    ...
    ]

Specifying a Consumer Blockchain

In the policy file of an agreement bot, the agreement protocol choice is specified in the agreementProtocols section. The blockchain choice(s) is specified in the "blockchains" array. Both type and name can be specified, but type is redundant since only "ethereum" is supported right now. More than one name can be specified. If so, the order in which they are specified indicates preference. Specifying no names indicates that the agreement bot doesnt care which client is used. However, in the agreement protocol process, the Edge Device is given the opportunity to choose the blockchain name if there is more than 1 choice, and it will use its own precedence order. Therefore, the precedence order specified by the consumer is consulted within the context of the Edge Device's precedence order.

    "agreementProtocols": [
      {
        "name": "Citizen Scientist",
        "blockchains": [
          {"name": "myblockchain"}
        ]
      }
    ]

Timing Considerations

  1. Starting an ethereum container client on an edge device can take a handful of mins to download, load, start and bootstrap itself into the ethereum network. In fact, in some cases, 10 mins might be normal. Therefore it is important that the Edge Device and agreement bot configuration field "AgreementTimeoutS" should be set long enough for all of this to happen plus the time it takes to write the agreement into the blockchain and then verify that it was written successfully (which could be several more minutes). A total of 15 mins might not be out of the question for the first agreement using that blockchain client.

Operational Considerations

  1. If a blockchain client container is stopped manually (e.g. docker stop xxxx), Anax (Edge devices and agreement bots) will automatically restart the container ONLY IF IT IS STILL NEEDED. Anax never automatically removes running blockchain client containers, but they do track whether or not a specific client is still needed. A client container is deemed to be NEEDED if (a) there is at least one agreement that is using that client container, or (b) condition (a) was true up to 5 minutes ago. Therefore, if a client container is manually stopped more than 5 mins AFTER the last agreement using it was cancelled, then the client container will not be restarted.
  2. For blockchain client containers that Anax has started, it will periodically check the exchange to see if the metadata for the container has changed since the container was started. If a change is detected, Anax will restart the container.
  3. When Anax restarts, it will ensure that there is a blockchain client container running for every agreement that needs one. Therefore, when Anax is stopped so that it can be upgraded, the blockchain client containers can also be stopped, because they will be restarted when Anax restarts.
Clone this wiki locally