This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Add members

Excellent, we now have the necessary schema to create the Wine type subject. However, on reflection, we realize that there is no one authorized to create and issue events related to this new schema. Therefore, we need to add a new participant to our network responsible for this task.

Let’s start by configuring the corresponding node:

{
    "kore": {
      "network": {
          "listen_addresses": ["/ip4/0.0.0.0/tcp/50000"],
          "routing": {
            "boot_nodes": ["/ip4/172.17.0.1/tcp/50000/p2p/{{PEER-ID}}"]
          }
      }
    }
  }

We map port 3001 to make requests from our machine and indicate the peer-id of node 1.

docker run -p 3001:3000 -p 50001:50000 -e KORE_PASSWORD=polopo -e KORE_FILE_PATH=./config.json -v ./config2.json:/config.json koreadmin/kore-http:0.5-leveldb-prometheus

We will then proceed to update the governance to include this new member and allow him/her to create Wine type issues.

Let’s verify the changes we want to make in the governance properties. At this point, our governance should look like the following:

{
    "members": [
        {
            "id": "{{CONTROLLER-ID}}",
            "name": "WPO"
        }
    ],
    "roles": [
        {
            "namespace": "",
            "role": "WITNESS",
            "schema": {
            "ID": "governance"
            },
            "who": "MEMBERS"
        },
        {
            "namespace": "",
            "role": "APPROVER",
            "schema": {
            "ID": "governance"
            },
            "who": {
            "NAME": "WPO"
            }
        }
    ]
}

Now, we need to incorporate the mentioned changes:

{
    "members": [
        
        ...

        {
            "id": "{{CONTROLLER-ID}}",
            "name": "PremiumWines"
        }
    ],
    "roles": [

        ...

        {
            "namespace": "",
            "role": "CREATOR",
            "schema": {
                "ID": "Wine"
            },
            "who": {
                "NAME": "PremiumWines"
            }
        }
    ]
}

We’ll use our Kore-Patch tool to generate these changes, following the procedure below:

kore-patch '{"members":[{"id":"{{CONTROLLER-ID}}","name":"WPO"}],"roles":[{"namespace":"","role":"WITNESS","schema":{"ID":"governance"},"who":"MEMBERS"},{"namespace":"","role":"APPROVER","schema":{"ID":"governance"},"who":{"NAME":"WPO"}}]}' '{"members":[{"id":"{{CONTROLLER-ID}}","name":"WPO"},{"id":"{{CONTROLLER-ID}}","name":"PremiumWines"}],"roles":[{"namespace":"","role":"WITNESS","schema":{"ID":"governance"},"who":"MEMBERS"},{"namespace":"","role":"APPROVER","schema":{"ID":"governance"},"who":{"NAME":"WPO"}},{"namespace":"","role":"CREATOR","schema":{"ID":"Wine"},"who":{"NAME":"PremiumWines"}}]}'

The result obtained will be as follows:

[
  {
    "op": "add",
    "path": "/members/1",
    "value": {
      "id": "{{CONTROLLER-ID}}",
      "name": "PremiumWines"
    }
  },
  {
    "op": "add",
    "path": "/roles/2",
    "value": {
      "namespace": "",
      "role": "CREATOR",
      "schema": {
        "ID": "Wine"
      },
      "who": {
        "NAME": "PremiumWines"
      }
    }
  }
]

Now, it’s time to call the method of the governance contract responsible for updating its properties. To do this, we’ll execute the following:

Once the event is emitted, we need to obtain the new update request. To do this, we run the following:

curl --request GET 'http://localhost:3000/approval-requests?status=Pending'

We copy the value of the id field and accept the governance update request:

curl --request PATCH 'http://localhost:3000/approval-requests/{{PREVIUS-ID}}' \
--header 'Content-Type: application/json' \
--data-raw '{"state": "RespondedAccepted"}'

We query the governance from the new node:

curl --request GET 'http://localhost:3001/subjects/{{GOVERNANCE-ID}}'

And we will get:

[]

An error? But didn’t we just include the new node in the governance, and it’s a witness of it?

While the last statement is true, we must consider the following: for security reasons, the kore node rejects all subjects that have not been explicitly sent, unless one of the following two conditions is met: the governance is configured to consider it a witness, or we explicitly authorize the subject. In the case of the governance, it’s special since there’s no prior governance to authorize it, so the only way to access it is by explicitly authorizing it.

Therefore, we need to execute the following to receive governance information:

curl --request PUT 'http://localhost:3001/allowed-subjects/{{GOVERNANCE-ID}}' \
--header 'Content-Type: application/json' \
--data-raw '{
    "providers": []
}'

Now, when trying to query the governance from the new node, we will get the expected information:

curl --request GET 'http://localhost:3001/subjects/{{GOVERNANCE-ID}}'

World Food Organization

Currently, WPO is the only owner of the governance and has the exclusive power to approve changes to it. However, this poses a problem since its power is absolute, and, for example, it lacks representation or influence from around the world on the changes made to this governance. Therefore, there is a need to add a new member to the governance, World Food Organization (WFO), which will act as the second validator and prevent the existing monopoly by WPO.

To achieve this, we’ll allow WFO to take on the roles of an approver, validator, and evaluator of the governance. Furthermore, it will be allowed to act as a witness to Wine type subjects since it’s interested in collecting consumption statistics.

Let’s start by setting up the WFO node:

docker run -p 3002:3000 -p 50002:50000 -e KORE_PASSWORD=polopo -e KORE_FILE_PATH=./config.json -v ./config2.json:/config.json koreadmin/kore-http:0.5-leveldb-prometheus

Next, we’ll proceed to update the governance to grant it the mentioned properties:

Once this command is executed, we should obtain the update request again. To do this, we run:

curl --request GET 'http://localhost:3000/approval-requests?status=Pending'

We copy the value of the id field and accept the governance update request:

curl --request PATCH 'http://localhost:3000/approval-requests/{{PREVIUS-ID}}' \
--header 'Content-Type: application/json' \
--data-raw '{"state": "RespondedAccepted"}'

At this point, we’ll find ourselves in a situation similar to the one described in the previous section. Although the new node is part of the governance, it’s not able to receive its information, so we need to perform its pre-authorization. To do this, we’ll execute the following command:

curl --request PUT 'http://localhost:3002/allowed-subjects/{{GOVERNANCE-ID}}' \
--header 'Content-Type: application/json' \
--data-raw '{
    "providers": []
}'

If everything has gone as expected, we can now query the governance from the new node, and it should now have an sn value of 4, as well as the change made in members and roles.

curl --request GET 'http://localhost:3002/subjects/{{GOVERNANCE-ID}}'