This is accordace to the described document.

https://github.com/icon-project/ibc-planning/blob/main/adr/XCall_centralized_connection.md

What needs to be done

Develop the core logic for the centralized relay

Why it needs to be done

Describe why it needs to be done here.
Ex: "Reduces the amount of time for the relay to synchronize to the latest block"

Acceptance Criteria

Message passing relayer for xcall

Additional Information

Describe anything relevant that hasn't been mentioned yet.

• KMS Setup
• Checklist for Mainnet deployment

Create a centralized relay and xcall integration that can be used to connect to any chain.

If relay is running we cannot access db which is locked by running relayer.

Implementations:
Use IPC to communicate with running relayer.
If relayer is not running we simply connect the existing db.

Issue:
Currently, at each block notification, the messages are pushed to the in-memory message cache, and the messages are processed for relaying. Now let's assume the state where the total number of messages in the message cache is 100(50 from block height suppose 23 and the remaining 50 messages from block height 24). Now, let's also assume that only 20 messages are relayed and 21st message is being processed and suddenly the app crashes. Now when the application is restarted, the message cache will be cleared but the relay starts processing the message from the last saved block height which is 24. Clearly, 30 messages from block 23 are not processed in the relay.

Solution:
To prevent this scenario of message loss, it is crucial to save the message in the database before pushing it to the message cache.

Describe the bug
Event log condition check for icon has false positive behaviour resulting message processing error

Preferably use Apache License 2.0

Centralised Relay deployment and testing on testnet for ICON and Avalanche.

expose cli cmd for revertmessage function

Gas estimation for evm module

Test Modules using the centralised relay and xcall for different chains

Java Module integration for Avalanche with centralised relay

What needs to be done

Enable command handing for the relay to be able to submit messages

Why it needs to be done

Describe why it needs to be done here.
Ex: "Reduces the amount of time for the relay to synchronize to the latest block"

Acceptance Criteria

Describe how we can know whether the task is done.
Ex: When restarting the relay, synchronization picks up from the most recently stored block

Additional Information

Describe anything relevant that hasn't been mentioned yet.

Rust Module integration for Avalanche with centralised relay

Solidity Module integration for Avalanche with centralised relay

This keystore cmd will add the following feature:

1. Abilty to encrypt/decrypt the wallets on the go.
2. Abilty switch between wallets.
3. Secure wallet storage
4. Extra wallets creation dependencies.

Deployment Checklist

Follow these steps to deploy your centralized relay:

1. Machine Setup

• Create EC2 instance

  • Ubuntu 20.04
  • t2.medium
  • 10 GB
  • 1 GB swap space
  • 1 GB RAM
  • 2 vCPUs
  • 1 static IP
  • sudo apt update && sudo apt upgrade -y

• Install the necessary software:

  • GO
    • sudo apt install go
  • Git
    • sudo apt install git
  • Make
    • sudo apt install make

• Clone the repository.

  • git clone [email protected]:icon-project/centralised-relay.git

• Build the application.

  • make install

• Create a systemd service file.

  • sudo nano /etc/systemd/system/centralized-rly.service

  • Add the following:

    [Unit]
    Description=Centralized Relay
    After=network.target
    
    [Service]
    Type=simple
    Restart=always
    RestartSec=5s
    ExecStart=/usr/bin/centralized-rly start
    
    [Install]
    WantedBy=multi-user.target
    

2. Configuring Config Files

• Update the application config file with the correct settings.
  • centralized-rly config init
  • RPC urls
  • Chain NIDs
• Set the environment variables.
• Check the database connection.

3. Wallets and Funds

• Create or import a wallet.

  • centralized-rly keystore create --chain icon --password <password>
  • centralized-rly keystore create --chain avalanche --password <password>

• Ensure the wallet has sufficient funds.

  • centralized-rly keys list --chain icon
  • centralized-rly keys list --chain avalanche
  • Check balances on explorer.

• Set the wallet address in the config file.

  • centralized-rly keystore use --chain icon --address <address>
  • centralized-rly keystore use --chain avalanche --address <address>

4. AWS KMS Related Auth

• Set up an IAM EC2 role with the necessary permissions.
  • aws iam create-role --role-name <role-name> --assume-role-policy-document file://assume-role.json
    file contents:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "",
        "Effect": "Allow",
        "Principal": {
          "Service": "ec2.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }
  

  • aws iam create-policy --policy-name <policy-name> --policy-document file://kms-policy.json
    file contents:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "Stmt1234567890",
        "Effect": "Allow",
        "Action": [
          "kms:Decrypt",
          "kms:Encrypt",
          "kms:GenerateDataKey",
          "kms:DescribeKey",
          "kms:ListKeys",
          "kms:ReEncrypt*",
          "kms:CreateGrant",
          "kms:ListGrants",
          "kms:RevokeGrant",
          "kms:GenerateRandom"
        ],
        "Resource": "*"
      }
    ]
  }
  

  • aws iam attach-role-policy --role-name <role-name> --policy-arn <policy-arn>
  • centralized-rly keystore init
• Create a KMS key.
  • centralized-rly keystore init
• Assign the necessary IAM roles and policies.

5. Final Checks

• Run the application in a test environment.
• Check the logs for any errors.
• If everything is working as expected, deploy the application to the production environment.

          I believe, since the sn is always 0 for one-way xcall messages, using this criterion for identifying duplicate messages is not feasible.

@AntonAndell

Originally posted by @redlarva in icon-project/xcall-multi#196 (comment)

Internal Security Review Audit

The db subcommand should support the following features.

1. Ability to prune database
2. Ability to list unsent packets in a chain(s)
3. Actions to stored messages, delete, retry, etc.

• Pagination issue on DB

Abilty retry failed messages on certain duration and times.

Flush message logic for failed delivery packets.

On Avalanche and other ethereum chains, need to implement a check for block finality for sending and receiving packets.

We could check status of transaction instead of trying for new packet delivery.

Monitor xcall message and filter for execution

Second RPC client will be used for verifying packets messages.

This could possibly led retry of failed messages.

E2E testing setup for a centralized relay:

• The testing environment should be configured to support end-to-end (E2E) testing.
• The setup should be capable of executing E2E tests specifically designed for the xcall-multi scenario.

Describe the bug
Dest chain from config is not found due to network id is present on message but network address is ignored on centralized code base.

To Reproduce
Steps to reproduce the behavior:

1. Send Message from source chain to icon chain and vise-versa

Expected behavior
Should properly parse network id and find chain.

Additional context
Chain nid received on relay: "0x2.icon"/"0x13881.mumbai"