RFC: Native DNS on top of pubkey-hash addresses #3454
Replies: 4 comments 19 replies
-
|
Caveat: what happens if I'm logged in damir.massa and while being logged in, I change the owner/target or delete the domain damir.massa ? |
Beta Was this translation helpful? Give feedback.
-
|
It logs you out |
Beta Was this translation helpful? Give feedback.
-
|
Open question: what about the reverse lookup ? |
Beta Was this translation helpful? Give feedback.
-
|
In this proposition there is no need for (address -> domain name) lookup nor for limiting to 1 domain name per address |
Beta Was this translation helpful? Give feedback.
-
|
It's not mandatory but it could maybe be useful to add this feature. |
Beta Was this translation helpful? Give feedback.
-
|
This index+ABI/API could be useful in some situations, e.g. I forgot which domains I booked and I want to ask my node / ask inside a smart contract, but the tradeoff is that it doubles the DNS space usage and so the cost of registration. I don't know what's best |
Beta Was this translation helpful? Give feedback.
-
|
I like the proposal. I didn't understand the Personal thoughts about the comments :
I don't see a real usage as soon as the address has been transferred we don't need to have the owner informations. It would take some storage space and so cost more coins to create a DNS address for no real value. Maybe worth implementing it in a v2 but I'm not a fan of paying more for something in the future.
What would be the use cases ? It could add a lot of computation power no ? I don't have real opinions right now |
Beta Was this translation helpful? Give feedback.
-
|
The developer of the ERC20 / NFT / soulbound token decides, but the idea is to link ERC20 and NFTs to the domain name, it makes sense to link it to the underlying address only for soulbound tokens (the developer will use |
Beta Was this translation helpful? Give feedback.
-
|
Now, we could also decide to allow domain name keys in the native ledger to allow account abstraction of native coins, but I'm not sure we need this as the most interesting stuff is happening on smart contracts |
Beta Was this translation helpful? Give feedback.
-
This would create a lot of side-effects. Let's keep it simple |
Beta Was this translation helpful? Give feedback.
-
For the end user it means that he can have fungible tokens on his domain name but not massa coins. Seems strange to have a different behavior between fungible tokens and massa on this no ? Do you have a non-exhaustive list of the problems it may cause ? |
Beta Was this translation helpful? Give feedback.
-
|
Same for me, I don't see the side-effects yet, let's discuss them |
Beta Was this translation helpful? Give feedback.
-
|
Here is a possible V1 allowing Massa Station to proxy .massa addresses, everything else is removed and can be added later: StateWe add a new table The first field Booking a domain nameA new transaction type
As there is no transfer/free possibility, storage cost can be interpreted as a burn. Resolving a domain name with the APIResolution is done only with the API. Storage CostsWorks exactly as for other state tables, paying storage costs when increasing state size. |
Beta Was this translation helpful? Give feedback.
-
|
V2: add resolving ability: a coin transfer (in a transaction or smart contract) to a .massa address sends coins to the resolved pubkey-hash address or fails. Optional: A RESOLVE(address) ABI allows to resolve an address from a smart contract. Returns the pubkey-hash or fails. |
Beta Was this translation helpful? Give feedback.
-
|
If the storage is immutable and there is no way to "free" an address, assuming some vulnerability is discovered in some frontend/smart contract/DAO. How could users be alerted of the vulnerability? |
Beta Was this translation helpful? Give feedback.
-
Introduction
We need a native DNS, instead of a smart contract DNS so that you can simply send coins to myaddress.massa without specifying to which DNS contract you refer to. We could hardcode only the DNS smart contract address natively to achieve this, but it's probably a good idea to implement the full DNS natively to save gas as those are a few simple functions used very frequently.
@damip proposed a native DNS (#2646) replacing pubkey-hash addresses with ".massa" chosen addresses, where ".massa" chosen addresses are associated to pubkeys (not pubkey hash), with no P2PK (pay to pubkey) possibility.
There are several downsides with this approach:
Here I instead propose building the native DNS on top of pubkey-hash addresses.
This is a general description, not a detailed specification.
Note: With both approaches we gain a small amount of Account Abstraction (AA), but the full AA can only be achieved with smart contract accounts, for which I think the simplest approach for Massa would be to follow EIP-2938 with a new type of transaction and a PAYGAS opcode (cf #3456 discussion).
Address
A domain name is a
.massa string.Now, an
addresscan be either apubkey-hashor a.massa stringdomain name.State
We add a new table
DNSto the state.The
DNStable is composed of(.massa string, address, is_immutable)rows, indexed by the first field (whose items appear at most once).The first field
.massa stringis the domain name that was booked, and which points to the second field, theaddress.The
is_immutablefield specifies ifaddresscan change in the future.Caller and Login
A new ABI call
LOGIN(dn)allows to login to a domain namedn, changing the current identity/account/caller address todnandLOGOUTreverts the caller address to the previous one.LOGIN(dn)succeeds only if the current caller is the address associated todnin the DNS.A pubkey-hash address can login to a domain name address which can login to another domain name address etc.
Booking/Transferring/Freezing/Freeing a domain name
A new transaction type
DNS_TXallows to book, transfer, freeze or free a domain name.DNS_TX(BOOK, dn, address)books the domain namednand assigns it to any addressaddress. Succeeds only ifdnis not already booked.DNS_TX(TRANSFER, dn, address)transfers the domain namednand assigns it to any addressaddress. Succeeds only if the transaction caller is the address associated todnin the DNS and theis_immutablefield isFalse.DNS_TX(FREEZE, dn)freezes the domain namednby setting theis_immutablefield toTrue. Succeeds only if the transaction caller is the address associated todnin the DNS and theis_immutablefield isFalse.DNS_TX(FREE, dn)frees the domain namedn. Succeeds only if the transaction caller is the address associated todnin the DNS and theis_immutablefield isFalse.New ABI calls allow to do the same operations from smart contracts.
Resolving a domain name
When a normal transaction sends coins to an address that is not a pubkey-hash, then the address is resolved with the DNS (recursively if needed), and the coins are transfered to the pubkey-hash. Succeeds only if a pubkey-hash was resolved, fails if detecting a cycle or if there is no address associated.
A
RESOLVE(address)ABI allows to resolve an address from a smart contract. Returns the pubkey-hash or fails.Storage Costs
Works exactly as for other state tables, paying storage costs when increasing state size, getting back storage costs when decreasing state size.
Staking
Only pubkey-hash addresses can buy rolls and stake.
Example Use Case: ERC-20
An ERC-20 contract stores how much coins a given address has.
Now the address can be either a
pubkey-hashor a.massa stringdomain name.In order to spend the ERC-20 of a domain name address, one has to
LOGINbefore.Comments:
DNStable with(.massa string, owner_address, resolved_address)to cover more use cases ?.massaaddresses to be a key in the ledger to cover more use cases ?Beta Was this translation helpful? Give feedback.
All reactions