Deploying to mainnet

[nugaon]

The smart contract that we use intensively in our stack is only the ENS at the moment.
We planned to deploy it to the Gnosis blockchain originally as it does not have an official deployment and since the Ethereum Swarm Bee nodes operate on that currently.

Nevertheless, it is worthwhile to discuss what would be the upsides of using the official ENS on the Ethereum mainnet since the merge will happen soon and other L2 solutions are spreading to sort out the problems with high transaction fees and scalability.

[nugaon]

Among the upsides of using official ENS are definitely

• the usage of ENS Manager App and
• the Bee client can resolve ENS name with bzz:// record, thereby FDS accounts will have support of setting personal page/dApp site on Swarm out-of-the-box.

For that, we need to register/buy a short and fitting label under .eth that also requires additional implementation of an NFT compatible subdomain registrar (since we prepared with TLD solution so far).

There is also another approach that we can do is that we deploy our own ENS to have .fds TLD.

The source code still have to be upgraded to use price oracle and else like in the official ENSRegistry. It also requires action from the Bee team to support name resolutions for this contract as well if we want to support personal sites for FDS users. Additionally, the ENS Manager App cannot be used with this solution, but we want to provide tools to maintain the ENS nodes anyway.

And there is a mixed and not that pretty solution: buy any label on the official ENS, create the registrar as above mentioned and use .fds references in applications that we transfer to the corresponding ENS subdomain in the fdp-contracts JS library. With that we still don't have Bee support for personal pages, moreover, it can make confusion among users what are their real ens domain on the chain.

The 4th solution is that we just use the labels under .eth. By that there is no listing of FDS users/dApps and we cannot bring any additional logic into the name resolution that we may require for our stack in the future.

[molekilla]

Let's reuse, we don't have the manpower to do chainops, as we have seen, with ENS, even if the API surface is easy, maintaing proper chain ops is daunting

[crtahlin]

I will try to recap the meeting we had this week:
Let's use the option 1, using ENS directly. It leverages existing tech, also users of ENS and lets us focus on our core things instead of developing a "custom" ENS solution.

[tfius]

Overview of tasks in preparation for mainnet release:

• create Goerli multisig
• create Goerli ENS name
• register ENS name
• verify PublicResolver.sol from fdp-contracts is compliant with ENS
• deploy PublicResolver from fdp-contracts
• create FDPController contract

FDPController functionality
On subdomain register tasks to be completed by FDPControler

1. setSubnodeOwner
2. setResolver
3. set public key

• implement function createUserSubnode(fdpNodeHash, userNameHash, publicResolverAddress, timeToLive)
• call setSubnodeRecord(node,label,owner,resolver, ttl)
• call resolver.setPubkey(node, x,y)

FDPController MUST implement

• FDPController must have ownership control,
• implement function transfer ownership to address (EOA account)

When ready and tested

• assign FDPController as owner to ENS name

FDP storage CHANGES

• fdp-storage MUST call FDPController.createUserSubnode
  where
• userNameHash, is nameHash of userName
• fdpNodeHash is constant
• publicResolverAddress is constant
• timeToLive TBD, i suggest 4 years

UPDATE create-account-app

• update with new fdp-storage
• add external signer support

changes should go to goerli first
goerli ENS: deployed https://goerli.etherscan.io/address/0x112234455c3a32fd11230c42e7bccd4a84e02010

[tfius]

We could skip multisig, if we keep ownership on EOA, do stuff there, and then transfer back to multisig

[tfius]

Lets take into consideration @nugaon suggestion that Controller is also an NFT minter, that allows the user to 'mint' subNode of ENS name.

[molekilla]

Forking chains @nugaon https://www.quicknode.com/guides/ethereum-development/how-to-fork-ethereum-blockchain-with-ganache

…

On Mon, Sep 26, 2022 at 8:09 AM Tadej Fius ***@***.***> wrote: Lets take into consideration @nugaon <https://github.com/nugaon> suggestion that Controller is also an NFT minter, that allows the user to 'mint' subNode of ENS name. — Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQWR426SW5U7EVUWX7U4DWAGOA7ANCNFSM6AAAAAAQFT3BTE> . You are receiving this because you commented.Message ID: ***@***.***>

[nugaon]

Forking chains @nugaon

yeah, well I think we should keep our blockchain environment light for now and IMO forking the whole Ethereum blockchain in order to test out multisig is like shooting a bird with a cannon.

[nugaon]

the requirements that we need to have:

• the users can set their own personal page on swarm by setting bzz link reference in ENS for which we should avoid from require any changes in the Bee client
• provide NFT minting along with the registered usernames mainly for the potential migrations to another label in the future.

[plur9]

It seems to me that ENS on mainnet will only grow in importance. Many people also are using it already and have NFTs linked as avatars. While the costs of using it are high atm, with EIP4844 they should be lower. So, all in all, this seems as best bet.