Hi @Giulio2002, good work 👏👏 👏 👏 .

Below is the feedback:
0) General considerations are:

• Do we allow the same public key to be used in multiple wallets
• Do we allow contracts with the same address to exist on many networks

If the first is true then the second is true as well. If the second is true then we have to mitigate the transaction reply attack.

If we don't want to allow first or second we have to have a strategy to prevent it.

I would propose to tackle that one before moving forward.

1. Configuration - overall looks good, but one consideration:
   Should we add onRampProviders to a network? I don't expect to have the same set of providers and configurations for different networks.

2. Message - I would propose to add a new field to message:

• networkId
  The field would need to be eventually verified on-chain via hash, we can start with verification on the relayer side only.
  An example message would look like this:

const message = {
  to: '0x...',
  value: 1
  networkId: ...
};

Regarding the initialization, I would propose to use pass dictionary of providers. We could have a default for simpler initialization.

Alternative

The more we analyze what would need to be done, we realized a multi-chain relayer is quite a big project. Perhaps we can simply run two relayers on one machine to simplify? And focus on having two contracts with the same ens name?

from unilogin.

Alternative

The more we analyze what would need to be done, we realized a multi-chain relayer is quite a big
project. Perhaps we can simply run two relayers on one machine to simplify? And focus on having
two contracts with the same ens name?

@marekkirejczyk let's try to build upon your alternative proposal that sounds very good to me

The multi-chain support could be better referred to as multi-chain UL account: it shall allow any user to create and operate its own UL account within a subset of the networks supported by the UL relayers she is connected to. How the multi-chain UL relayer itself is realized is an implementation matter.

The solution proposed by @Giulio2002, referred as native multi-chain relayer hereafter, adds the multi-chain concept into the relayer itself but requires changes to the current implementation.

Another solution named multi-chain relayer pool is based on the idea of having a bunch of N relayers, one for each chain (e.g. Ethereum, POA, xDAI...), configured with the same ENS domains. Such relayers are completely independent from each other, can be executed on one machine [different JSON RPC end-points] or more, each of them has its own database. In the UL SDK the provisioning of the multi-chain relayer pool will be similar to the native multi-chain relayer and the SDK itself will be responsible for sending each meta-tx with the new networkId field to the correct relayer in the pool. Please note that the networkId field is still required in the UL SDK API exposed to the dapps

Multi-chain relayer pool

Pros

• backward compatibility: the current relayer implementation does not require big changes in this architecture
• multi-chain scalability: the number of networks can be increased/decreased by simply starting/stopping relayers on the same machine or on different machines

Cons

• ENS name availability problem: this is due to the lack of atomicity in reserving the same ENS name on different chains using different relayers in the pool, it is always possible to have a clash if dapps trigger the same UL account creation on different independent relayers. In the native multi-chain relayer this problem can be solved by serializing access to some sort of ENS name reservation within the unique relayer database

Open Points

1) Public key / contract address allocation

• Do we allow the same public key to be used in multiple wallets
• Do we allow contracts with the same address to exist on many networks

We have two options here:

1A) Same public key / contract address

Pros

• this allows the same device public key registered on UL wallets on different networks
• this solution simplifies the dapp bridge protocols, e.g. dapps using the POA Arbirary Message Bridge (AMB) can choose to rely on their own contracts and UL accounts having the same address (it becomes straightforward to check the message sender in the incoming chain)

Cons

• it suffers from transaction replay attack. This is mitigated by the presence of the nonce field in the UL meta-tx (it is unlikely equal on different networks... or am I missing something here?)
• the counterfactual deployment of contracts with the same address on different networks requires that all relayers have the same EOA paying transaction gas and use the same salt for the same contract, so sharing the salt becomes an issue (no idea how to solve this)

1B) Different public key / contract address

Pros

• no transaction replay attack
• no need to obtain the same counterfactual deployment address

Cons

• multiple key pair associated to different networks should be used on each device
• this solution moves the burden of bridge protocols on the dapp side because no assumption can be made on key/address mirroring

Option 1A is apparently nice and clean, but option 1B seems to be better.

2) ENS name availability

It seems a real concern to me, but no idea on this at the moment

from unilogin.

On ENS name availability

This is a crucial architectural problem

1- I think we need to keep in mind that Universal Login is a synonym of Login with Ethereum and not Login with POA or Login with Rootstock (or Login with any ethereum like sidechain).

2- If I understand how UL works, in the creation of the user on the relayer the availability of the ENS related to the mainchain is checked otherwise that ENS is not available. However, the check is made on the ENS "booked" on the relayer but not yet deployed on the mainchain via Create2.

Starting from these 2 assumptions a possible solution could be the following:

A- In a multichain scenario, anyone who wants to participate in the UL network with his relayer, even if he does not foresee the immediate use of the mainchain but only a sidechain, must "book" the ENS on the mainchain at the relayer level with Create2 precalculating the relative address.

B- the mainchain relayer (that is always mandatory) is the master relayer and any other relayer on the same ENS domain cannot deploy on the sidechain a name already booked for the mainchain.

This means that each sidechain relayer references and / or duplicates the "reserved" name database on the master relayer (on ethereum / mainchain)

A problem remains open: suppose there are two entities that participate in the UL network with their relayers and therefore their ENS domains.

The two units are called Facebook and Google and their domain is:
facebook.eth
google.eth

facebook.eth allows deployment on Ethereum and POA
google.eth allows deployment on Ethereum and Rootstock

How does the user alice.facebook.eth use a dapp that uses Rootstock as a sidechain?

There are two answers:

1. can not unless google.eth also voluntarily activates a relay on Rootstock
2. it can always because the blockchains authorized by UL are decided by UL inc. in subsequent releases and are mandatory, whoever uses UL must update and "reserve" and pre-calculate with CREATE2 the user on every single chain authorized by UL. inc.

from unilogin.

Adding interesting link for reference:
https://eips.ethereum.org/EIPS/eip-2304

from unilogin.

Multichain sdk

Quick summary

A new direction was proposed in yesterday's discussion with @PaoloRebuffo and @canepat.
We call it multichain sdk.

The idea is to build a new sdk in top of existing sdk, without need for modifying relayer or smart contracts.

ENS hierarchy

In this approach, there is a hierarchy of ENS deployments, let's say ENS on mainnet is called master ENS and ENS on sidechain is called slave ENS.

Multichain Resolution

To resolve in ENS name MutlichainSDK first try to resolve the name with master ENS and if that fails, try to resolve with slave ENS.

User path

1. A typical user path would start on the sidechain, where first ENS registration would happen. The name registered on the slave ENS, we call weak name
2. If users want to move to mainchain - he needs to register same name on master ens. If the name is already taken user needs to pick a new name. Name register on mainchain we call strong name.

To reduce the probability of collision, multichain SDK checks the availability of a strong name, when registering a weak name.

Mitigating potential attack

A malicious actor could on purpose register strong names based on observation of weak names. To mitigate that, user needs to store the proof in strong ENS record that he owns a weak ENS name. That can be simply a phrase signed with on of the user's keys.

Other notes

Multichain sdk could also include auxiliary functions to support bridge operations.

from unilogin.