Predefined & documented ENS name ownership condition

[theref]

No description provided.

[arjunhassard]

• Use existing RPC conditions to build off-the-shelf condition set for decryptor to control ENS name(s)
• Write up walkthrough tutorial and add to Advanced Usage Guides or Conditions
• Edit tutorial (@arjunhassard)

[derekpierre]

Is the idea for this issue only to address name resolution on the client-side (i.e. at encryption time, just use the resolved wallet address in place of the ens name), or is there an associated server-side change that is expected.

If the idea is only to do name resolution at the client side (i.e. at encryption time), then one limitation is that it would prevent any updating of the ens domain to point to a different wallet address after the fact.

Obviously, changes on the server side require updates across the network, but aside from that, the actual code change is probably not that difficult - https://web3py.readthedocs.io/en/stable/ens_overview.html#ethereum-name-service-ens.

[piotr-roslaniec]

I think there are two different functionalities, that we may or may not want to bundle together:

• ENS-to-address resolution on the client side. "When I input bob.eth, I actually mean 0xb0b..."
• ENS address-ownership condition. "Whoever owns bob.eth should be able to decrypt".

Edit: I think we can do both as long as we communicate that EnsAddressOwnershipCondition is different than putting an ENS address into ownerAddressOrEnsAddress variable somewhere.

[derekpierre]

I think there are two different functionalities, that we may or may not want to bundle together:

• ENS-to-address resolution on the client side. "When I input bob.eth, I actually mean 0xb0b..."
• ENS address-ownership condition. "Whoever owns bob.eth should be able to decrypt".

Indeed.

And for the first one i.e. on client-side replace bob.eth with the actual address and use the actual address in the condition, this has the limitation that the intended address can't really change - less flexibility.

Unless, we make server-side changes to actually handle ens addresse so that they can be allowed in the condition and properly processed by the node i.e. the second one.

[manumonti]

ENS address-ownership condition. "Whoever owns bob.eth should be able to decrypt".

AFAIK this is the goal of this issue.

I have created a new issue for the other idea: #512

[manumonti]

After a chat about this with @piotr-roslaniec, we came to some conclusions:

There are different use cases:

As Piotr realized, there are at least two different use cases that will require ENS:

• The "only if your address resolves to this ENS name" use case: we want to encrypt some information so the decryptor will be able to decrypt only if their address resolves to a specific ENS name. I.e. if anything changes about this ENS address ownership, I no longer want to share this information.

• The "lottery winner" use case: we want to encrypt some information so only the lottery winner can decrypt it. The lottery is celebrated every day and, as a result, the winner's address is automatically registered as "lotterywinner.eth" during this day. So, the condition is "only the address which the domain lotterywinner.eth resolves to will be able to decrypt the information". As we can see, this address will be different every day.

We cannot use the current TACo conditions, but there are some alternatives

The first attempt was to use a contract condition to check for the ENS ownership. Something like calling an ENS contract method passing the Ethereum address and the contract returning the ENS name. But this doesn't work so easy.

To make an ENS lookup (nick.eth -> 0x241df23...) we have to do two calls to two different contracts:

1. A call to the ENS registry that will return the resolver contract address which has the information about this ENS name.
2. A call to this resolver contract to know the address of this ENS name.

This is not straightforward to do with the current conditions on taco-web.

But there are several alternatives:

1. To deploy a contract for ENS lookup: we can deploy a contract that will do these two steps. The main method ensLookup will have as an argument the ENS domain and will return the Ethereum address.

2. To create a new condition class. As with the other conditions, the taco-web client will ask the nodes for the lookup and the Ursulas will use web3.py to get the information. The calls to the ENS protocol can be done easily using web3.py: https://web3py.readthedocs.io/en/stable/ens_overview.html#usage.

3. Extending the use of taco-web conditions: using compound conditions, the parameter of the second condition is resolved in the first condition at evaluation time:

(@piotr-roslaniec pseudo-code)

// We have these two conditions that must be true at the same time
(EnsResolverCondition("john.eth") == :unknown-value) && (ResolvedAddressCondition(:unknown_value) == "real-address-of-the-user")
:unknown-value -> Condition author still doesn't know the value at the time of writing the condition, but they want to replace it at the evaluation time

// Currently, we are unable to resolve them because of how context parameters work.
// Today we support two types of context parameters:
:user-address -> An example of a context parameter that automatically gets replaced
:any-custom-param -> any user can bring their parameter value at decryption time 

So, to fix this we may need to introduce a new, "blank" context parameter that will be substituted by contract return value during condition evaluation:

:special-paramer-that-is-actually-an-output-of-another-condition -> :_output -> the special new parameter for conditions 

// So now, our condition can be evaluated as
(EnsResolverCondition("john.eth") == :_output1) && (ResolvedAddressCondition(:_output1) == ":user-address")

The last one can be useful not only for the ENS integration but for further use cases in which we need to ask for some data in the blockchain before checking the condition.