Access Node Instantiation and Compliance Guide

• 1. Registration validation: DOME
• 2. Issuance Validation: LEAR Credential Machine
• 3. Data validation: DLT
• 4. AN Configuration: Secrets
• 5. AN Configuration: Chart.yaml
• 6. AN Configuration: Values.yaml
• 7. Registering the node in the Trusted Lists
• 8. AN preparing the synchronization tests
• Tests to Perform

1. Registration validation: DOME

The first step in the setup process is to confirm that our company is registered in DOME and therefore we have a LEAR Credential Employee with Onboarding permissions available so that we can issue our credentials. 

If you are not registered or there is any problem with the credential’s permissions, consult this guide: Onboarding Guide

2. Issuance Validation: LEAR Credential Machine

The second step is to validate that we currently have a LEAR Credential Machine at our disposal. To do this, we must confirm that we have access to the Wallet and see if our credential has been downloaded. 

If you do not have access or do not have the required credentials, please review the credential issuance guide . 

Once we have our issued credentials, we will need to consult the next 3 points:  

• Private key > This is the key generated during the LEAR Credential Machine issuance process . It is important to save it, as we will need it later. 

       Image when we issued a new LEAR Credential Machine

• DID key > Auto-generated key at the time of creation that identifies the machine. 

         After downloaded your credential, you can view your info

• LEAR Credential > Auto-generated token that identifies your credential. You could find it at the bottom of your machine info.

3. Data validation: DLT

Once we have the issued credential, we need to generate our machine's addresses using this tool: Dome Access Node  Keys Generator 

To do that, we need our machine's DID key, obtained previously. 

 The generated addresses will be as follows: 

 

4. AN Configuration: Secrets

Check this guide if you will work with secrets: Github sealed secrets guide

5. AN Configuration: Chart.yaml

This is how your chart.yaml should look. All necessary dependencies are included in the AN configuration. 

Check the last version here: 

6. AN Configuration: Values.yaml

First, we need to consider whether we've decided to work with secrets (remember rename the file to values.yaml), or not, as the file format may vary slightly. 

Values with secrets.yaml

Values without secrets.yaml

 

First of all, we will check that the file header starts as shown in the image: 

 

Now let’s configure all the blocks.

Ingress

Modify the ingress hots and ensure your domain is properly exposed.

For example this is our domain:  desmos.dome-marketplace-lcl.org

App 

The next thing to check is that we have specified your DID key in the following field: 

 

 

Next, we will need to review the configured domains: 

We will need to configure your protocol (in this case it was http but usually it would be https) and the domain of our machine, the URL with which it will be identified. 

 

The next step is to configure the private key, which, if we are working with secrets, will look like this: 

 

 

Or without secrets: 

 

DB 

The next step will be to configure our databases. 

Here we need to configure our database host; this example uses an embedded database. We'll also need to specify our database details and whether or not we're using secrets. 

As you can see, without secrets, we will need to specify our database password and disable secrets.

DLT-adapter 

The next block is the DLT block; here we will need to configure the data obtained with the dome key generator: 

 

In case of working without secrets: 

Postgresql 

For the configuration of our Postgres, we must take into account the configuration of the secrets. 

 

And for the case of no secrets: 

Scorpio 

For the Scorpio configuration: 

 

 

 

And for the configuration without secrets, we would only have to configure the password as shown in the image: 

 

Postgis

The same procedure applies to secrets;. 

And without secrets: 

 

 

This would be all the configuration to take into account to prepare our AN to be able to perform the synchronization tests. 

Logically, there are more blocks in the file that we haven't mentioned, but we suggest not editing them without having the necessary knowledge.

7. Registering the node in the Trusted Lists

In order for your AN node to communicate and connect with ours, it must be registered on the following two lists. 

Trusted Access node list 

Trusted Access Node list file 

The format to follow is as follows: 

Trusted Services list 

Trusted services list file 

The format to follow is as follows: 

8. AN preparing the synchronization tests

These are the steps that will be taken before the tests: 

8.1. Backup before testing 

Perform a dump backup of the Scorpio data so we can restore it afterwards and delete the data of your DB. Remember to put it out of your docker or it will disappear if you restart your AN. 

How you could delete the data

kubectl get pvc -n <namespace> kubectl delete pvc postgris-0 kubectl delete pod postgis-0 -n <namespace> --grace-period=0 --force

If you change any of your settings, be careful with the PVC's; they could interfere negatively. It's advisable to remove them whenever there's a major change.

8.2. Configuration for testing

Add the externalAccessNodesUrls configuration inside the APP block as shown on the image below, which should be adapted for these tests. (It will be reconfigured later to point to the correct location.)

How it should looks

8.3. Review the values configuration and Trusted Lists registry

Verify that you complete all the steps above and your machine is correctly registered in the Trusted lists

Trusted Lists github 

8.4. Install AN 

After doing the previous steps, be sure that you installed your AN correctly. I'm leaving these commands here in case they're helpful. Remember that you need to throw these commands inside your values.yaml directory.

If you already have the current AN installed, uninstall it to prevent any mixing between the new and old configurations.

helm uninstall myaccessnode

8.5. Desmos running without errors

Confirm that your desmos pod is working correctly. You could check it with 

kubectl logs desmos-648bdbc988-pl2ft -n <your-namespace> -c desmos

8.6. Send an email

Send an email to domesupport@in2.es informing them that everything is ready to perform the integration tests.

Tests to Perform

We will perform two tests:

• Synchronization with the blockchain 
• P2P verification

We will create a temporary entity, one on your node and another on ours, and see if it synchronizes via the blockchain. 

We can do it using Postman or using the curl command by postforwarding to Scorpio: 

 

Or if we have access to the bae marketplace, from there; For example, this is our configured site: Bae marketplace local 

And we will validate that it has been created correctly using curl 

For P2P validation, we first need to create a Request Point (RP) by removing our node from the Trusted Access Nodes List. Create a new entity as shown above, and we will validate that we have NOT processed that entity.

Run the following command on the node where the entity was created and validate that this time, we have received it.

kubectl port-forward svc/desmos 8080:8080 -n <your namespace>

curl --location 'http://localhost:8080/backoffice/v2/actions/sync' \ --header 'Authorization: Bearer eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6IkVDIiwidXNlIjoic2lnIiwiY3J2IjoiUC0yNTYiLCJ4IjoiTlJMbXBVTjE3VGsxWUd3WHNuVVlkbG9qTFpxZHhqRVhqNHlTSnZKZWRJMCIsInkiOiJwV2ozVEdPeGRvTGpzRU1rbDFJQ3RPYmRENm12bzZXaDJTMjdKelNweEZRIn19.eyJodG0iOiJQT1NUIiwiaHR1IjoiaHR0cHM6Ly9kZW1vcy5kb21lLW1hcmtldHBsYWNlLWxjbC5vcmcvYXBpL3YxL2VudGl0aWVzLzEyMzQ1Njc4IiwiaWF0IjoxNzM1ODI4MjI2LCJqdGkiOiJkZDQyNzVmYi00MjhmLTQ2NjMtOGI4ZS0zMTUxMDVkZmQ2ZjIifQ.vZ33bJ2rYFEki5rM6uFmE46t4Ot4BCAIrnQXd-GWNnVwXWPtdhmP9gWa7u5xJS-ZrNJAkbj4Wh_tjxiSQyRt5Q'