RFC: Native DNS

[damip]

RFC: Native DNS

Intro

Currently, because the identifier of an account in the ledger (the Address) is tightly linked to its authentication method (the private/public key), we have several limitations:

• it is not possible to update the cryptography algorithms of an account: it requires switching to a new account
• it is not possible to change the private key of an account: it requires switching to a new account
• we always need to use a long number as an address (32 bytes) to identify accounts, thus increasing the size of transactions, smart contracts, rolls ledger, as well as the length of the string to copy, type, or encode as QRCode to identify the person we want to send coins to.

This proposal consists in separating the concept of account from the concept of authentication by having accounts in the ledger be identified by a user-chosen string, and storing the corresponding public key (if any) as part of their ledger entry.

Another effect of this proposal is to encourage creating as few accounts per person as possible and keeping them.

Account format

Address format

Addresses are of two possible variants:

• Hash addresses are composed of a hash of 32 bytes or more
  • format: 20sdsqdd89SDQ9SQ9D8DSQdd.massa (at least 32 bytes)
• Name addresses
  • composed of an 1 to 31-byte UTF8 string (by definition it is shorter than hash addresses and therefore doesn't collide)
  • address text representation: myaddress.massa so that it matches the decentralized web domain name system.
  • allowed characters in name addresses, inspired by DNS:
    • anything alphanumeric https://doc.rust-lang.org/std/primitive.char.html#method.is_alphanumeric
    • hyphen "-"

Ledger entry

In the ledger, an entry is identified by address and associated to:

• an optional public key
• a "public key is immutable" bit
• a balance
• a bytecode
• a datastore

Optional public key in each ledger entry

The public keys of an account can be:

• empty so that nobody has control over the account, which is useful for immutable smart contracts or burn accounts
• be set to a given public key to behave like a normal externally owned account

Creating a new account

CreateAccount operation

To create a new account, an existing account needs to emit the CreateAccount operation with the following fields:

• sender address
• sender public key
• target address to create (can be hash or name, but it it is a hash it needs to match the public key)
• optional target public key to assign to the newly created account
• validity end period (varint u64)
• gas price
• signature of the sender account

If the target address already exists in the ledger, the call fails.

Smart contract ABI

We also allow smart contracts to create an account through a create_account ABI:

create_account(
    address: Option<Address>,
    public_key: Option<PublicKey>
) -> returns the created address

Note that if address is None, an automatically generated address is assigned.
Also note that this ABI can only create accounts that don't have an associated public key.

As of before, the execution context retains write access to the created account until its end.

Costs

Creating an account consumes a constant amount of gas, and storage costs linked to storing a new account in the ledger can also be accounted for.

Changing the auth parameters of an account

The optional public key can be changed by the owner of the account, or by smart contracts with temporary write access to it.

Note that to prevent fee funds disappearance, this operation simply marks the account for deferred update. The account is effectively updated 1 period later.

SetAccountAuth operation

This operation allows changing the public key list of an account and has the fields:

• sender address
• validity end period (varint u64)
• new public key (or None)
• gas price
• signature of the sender account using its current credentials

Smart contract ABI

We also allow smart contracts to change account public keys through a set_account_auth ABI:

set_account_auth(
    account: Address,
    new_public_key: Option<PublicKey>
)

Deleting an account

Accounts can be deleted by their owner(s) or by smart contracts with write access to them.

Note that to prevent fee funds disappearance, this operation simply marks the account for deferred update. The account is effectively deleted 1 period later.

DeleteAccount operation

This operation allows marking an an account for deletion and has the fields:

• account address
• validity end period (varint u64)
• transfer account address
• gas price
• signature of the sender account

When an account is effectively deleted, the "transfer account address" is credited with the remaining coins if it exists, as well as the reimbursed coins coming from the freed ledger space.

Smart contract ABI

We also allow smart contracts to mark accounts they have write access to for deletion using the delete_account ABI:

delete_account(
    account: Address,
    transfer_account: Address
)

Transaction format

The format of normal transactions changes. Here are the fields it would have:

• sender address
• target address
• amount: Amount (TODO to/from parallel/sequential)
• gas price: Amount
• signature of the sender account

Implications on the proof-of-stake system

Rolls ledger

The rolls ledger will be indexed by address. Its size does not change.

Staker accounts must be locked

While an account is staking, this account existence and auth are locked: no deletion, and no auth changes are allowed during the whole staking + lock time.

This ensures that:

• we can verify block/endorsement signatures without the risk of the auth method changing in parallel due to SC calls for example
• we don't need the execution cursor to reach the block's slot to verify block/endorsement signatures
• we can credit block rewards without having the target account disappear in the meantime
• we can burn rolls/coins etc... from the account as penalty without it disappearing just before we do so

Other implications on the architecture

Sharding

Operation sharding can be achieved by taking first_5_bits(hash(address)) as the thread index.

Importance of finality

Until finality, the account is speculative.
So it is a good practice to wait for finality to ensure your newly created account is indeed yours.

Use cases

• soul-bound tokens thanks to public key immutability
• offline account creation thanks to hash addresses
• having an "address" easy to remember by heart
• seamlessly integrate with the decentralized web and have a de-facto DNS system
• rotating my passphrase on a regular basis or if I suspect it has been compromised, without changing my "address"
• allow smart contracts to know with which key a call operation was signed so that they can take different actions based on the public key that was used
• manually setup a smart contract account, then provably lose control over it
• allow smart contracts to create new accounts on which a physical user has control
• allow smart contracts to give a physical person control over an existing restricted account under certain conditions (eg. time lock)
• allow users to update their cryptographic primitives version without losing their accounts
• transfer the ownership of an account to someone else without revealing my private key
• creating a market of "pretty" addresses
• use the same private key for multiple accounts (single user, multi-account)

[jwmdev]

Great proposal and I generally support the proposal, it will significantly save space and provide flexibility in terms of changing the private/public keys.

A few points which may need further clarification:
-Description has covered the account creating process when you have an existing account. What if one does not have an existing account and wants to create a new account?

• The validity end period (varint u64) - is it the validity period of the transaction or the validity period of the created account? I presume it is the validity of the transaction?

Other suggestions:

• u64 bit account number is relatively big to memorize, but better than public and private keys. So, my suggestion is that the system could map the u64 bit account number with account name, eg. #massalab account shorthand could be system generated (a simple algorithm can be developed to generate friendly account names) or provided by user when creating account - in this case, the system will need to query for availability of the proposed account name. This will have a bit of an overhead to lookup for the account number when account name is provided + additional of storage space in the ledger, but it will extremely be user friendly. By the way, I have suggested '#' rather than the common '@' because '#' has four letter strokes as M for Massa :)
• Consider the possibility of having account categories if it may assist in internal account lookup. For example, the first few account bits could be reserved for account categories: e.g 0000xxx - for system accounts, 0001xxx - smart contract accounts, 0010xxx - normal accounts, 0011xxx - multi-signature accounts, and other bits could be reserved for future account categories.

[damip]

Description has covered the account creating process when you have an existing account. What if one does not have an existing account and wants to create a new account?

That doesn't change compared to most other non-UTXO PoS cryptos: accounts appear on-chain only when someone who already has an account with coins sends some coins for the first time to the new account. Here it would be the same but stated more explicitly: an existing account with coins is required to create a new account.

* The validity end period (varint u64) - is it the validity period of the transaction or the validity period of the created account? I presume it is the validity of the transaction?

yes, it's the end of the validity interval of the operation. This is already in place in the current testnet for operations.

* u64 bit account number is relatively big to memorize, but better than public and private keys. So, my suggestion is that the system could map the u64 bit account number with account name, eg. _#massalab_  account shorthand could be system generated (a simple algorithm can be developed to generate friendly account names) or provided by user when creating account - in this case, the system will need to query for availability of the proposed account name. This will have a bit of an overhead to lookup for the account number when account name is provided + additional of storage space in the ledger, but it will extremely be user friendly. By the way, I have suggested '#' rather than the common '@' because '#' has four letter strokes as M for Massa :)

Unless we are about to run out of 64bit numbers, which is unlikely, most people will have "low" account numbers. If there are 1M accounts, people will typically have account numbers with less than 7 digits, which is easy to remember.

Those numbers could further be mapped to words (like private keys are mapped to seed words) when shown to the user, but that is cosmetic and can be added afterwards.

As for real on-chain domain names translating to account numbers / addresses, we would be better off with something that resembles Ethereum Name Service. Note that we already have something like that in place in the current testnet.

* Consider the possibility of having account categories if it may assist in internal account lookup. For example, the first few account bits could be reserved for account categories: e.g  0000xxx - for system accounts, 0001xxx - smart contract accounts, 0010xxx - normal accounts, 0011xxx - multi-signature accounts, and other bits could be reserved for future account categories.

This is also an interesting idea, but why not allow an account to smoothly define its own limitations ? For example one could create a normal account, then drop all keys to turn it into a smart contract account - without changing the account number, but in an easily verifiable way.

[jwmdev]

That doesn't change compared to most other non-UTXO PoS cryptos: accounts appear on-chain only when someone who already has an account with coins sends some coins for the first time to the new account. Here it would be the same but stated more explicitly: an existing account with coins is required to create a new account.

OK, now it is clear, thanks for the clarifications.

`Unless we are about to run out of 64bit numbers, which is unlikely, most people will have "low" account numbers. If there are 1M accounts, people will typically have account numbers with less than 7 digits, which is easy to remember.

Those numbers could further be mapped to words (like private keys are mapped to seed words) when shown to the user, but that is cosmetic and can be added afterwards.

As for real on-chain domain names translating to account numbers / addresses, we would be better off with something that resembles Ethereum Name Service. Note that we already have something like that in place in the current testnet.`
Yeah, I have got your point. It is now good.

This is also an interesting idea, but why not allow an account to smoothly define its own limitations ? For example one could create a normal account, then drop all keys to turn it into a smart contract account - without changing the account number, but in an easily verifiable way.
Yeah, I think that makes sense and it is more natural.

[AurelienFT]

I like the proposal because accounts are more "normal" vocabulary for web and can help mass adoption even though I have multiple questions/remarks:

• Here it would be the same but stated more explicitly: an existing account with coins is required to create a new account.

I don't really understand. You will need to have another account creating your before sending funds to you ? So for example if I want to buy on a CEX I will have two options : 1 already have an account send coins to me, 2 create my account and send money to me ?

• Unless we are about to run out of 64bit numbers, which is unlikely

I'm not sure about that. Following this website Ethereum has currently 190M addresses created. If, as you said, there is storage costs : the freed ledger space then the number of addresses will be block by the number of MAS and can't be more than u64::MAX but it's not defined on your spec and there is a lot to discuss about it.

• Until finality, the account number is speculative.
  So it is a good practice to wait for finality to ensure your newly created account is indeed yours.

This can create a lot of collision in operations in my mind. If we have 2 accounts that are created in the same time on two nodes they will have the same number and it will make one fail ? Also if the first node know more operations and then give a higher number to the account created on the second node this can cause collision ? Maybe I misunderstood something in speculative execution but in my mind collision can happens a lot.

• verifying a signature will be heavier as it will require a ledger lookup

Since we are spending most of our time here don't you think it will be a too big overload ?

• as well as the reimbursed coins coming from the freed ledger space

If there is no owner the account can't be delete so the MAS for space ledger is lost forever right ?

• Use cases

I think in use cases we can add that it will be possible on a explorer to know that an address has no owner and therefore will be never accessed (to the funds or the bytecode) it could be useful information for safety for bridges or for burn address it will be like unhackable bridge because nobody has permissions on it.

Thanks for writing this it's a good idea !

[damip]

* > Here it would be the same but stated more explicitly: an existing account with coins is required to create a new account.

I don't really understand. You will need to have another account creating your before sending funds to you ? So for example if I want to buy on a CEX I will have two options : 1 already have an account send coins to me, 2 create my account and send money to me ?

If you want to create a new account from a CEX, then there are multiple options:

• provide your pubkey to the CEX, and let it transfer ownership of an existing account, and give you the acc number
• provide your pubkey to the CEX, and let it create an account for you with that pubkey, and give you the acc number

* > Unless we are about to run out of 64bit numbers, which is unlikely

I'm not sure about that. Following this website Ethereum has currently 190M addresses created. If, as you said, there is storage costs : the freed ledger space then the number of addresses will be block by the number of MAS and can't be more than u64::MAX but it's not defined on your spec and there is a lot to discuss about it.

190M is very far from u64::MAX (18_446_744_073_709_551_615) . To give you an idea, if you create a new account every millisecond for the next 500 million years, you won't reach the max yet. So I'm not scared of running out of IDs, or them being too long to remember for now.

There will be a separate spec on storage costs (that's why I was evasive here) and it will set a de-facto hard limit of 1TB for storage, which will naturally limit the number of accounts.

* > Until finality, the account number is speculative.
  > So it is a good practice to wait for finality to ensure your newly created account is indeed yours.

This can create a lot of collision in operations in my mind. If we have 2 accounts that are created in the same time on two nodes they will have the same number and it will make one fail ? Also if the first node know more operations and then give a higher number to the account created on the second node this can cause collision ? Maybe I misunderstood something in speculative execution but in my mind collision can happens a lot.

Account creation is deterministic and consensual (because operation ordering is deterministic and consensual). But block reorganizations can occur before finality, which might make your account number change or disappear.

* > verifying a signature will be heavier as it will require a ledger lookup

Since we are spending most of our time here don't you think it will be a too big overload ?

This needs to be evaluated through testing, because for every transaction we already read the datastore everytime (to execute the transaction, check balances etc...).

* > as well as the reimbursed coins coming from the freed ledger space

If there is no owner the account can't be delete so the MAS for space ledger is lost forever right ?

Yes like in other cryptos. We can also decide that there is an inactivity tax with deletion on zero balance etc... that can be discussed separately.

I think in use cases we can add that it will be possible on a explorer to know that an address has no owner and therefore will be never accessed (to the funds or the bytecode) it could be useful information for safety for bridges or for burn address it will be like unhackable bridge because nobody has permissions on it.

yes, that's a nice feature

[Kryptopaid]

When an account is deleted, the "transfer account number" is credited with the remaining coins, as well as the reimbursed coins coming from the freed ledger space.

Could you clarify this point? What do you mean by the reimbursed coins? Could you give an example?

have an extra supervising corporate account that needs to confirm every action of the employees

Doesn't it exists already with multisig approach and using smart contracts? I think Gnosis, Multis and others address this issue. It's interesting though if it can smooth the process / if it is a new approach.

manually setup a smart contract account, then provably lose control over it

Same here, I think you can already do that (at least on EVM) and renounce ownership in a provable way.

use the same private key for multiple accounts (single user, multi-account)

Doesn't it increase the risk for multi-account to be compromised?

From @jwmdev here

Consider the possibility of having account categories if it may assist in internal account lookup. For example, the first few account bits could be reserved for account categories: e.g 0000xxx - for system accounts, 0001xxx - smart contract accounts, 0010xxx - normal accounts, 0011xxx - multi-signature accounts, and other bits could be reserved for future account categories.

I was wondering, wouldn't it be nice also to have the thread in which the account is located also? I would like that very much. A bit the same as your address prefix on Cosmos states on which chain it is dedicated (secret0001, cosmos0001) for the same address. Also couldn't you then have the same account on the 32 threads and change the prefix (32, 01 etc...)? For example to interact faster with a SC or address on this thread. But you would need the account to be only accounted once but balance would be accounted in as many threads as there were balance put in.

That doesn't change compared to most other non-UTXO PoS cryptos: accounts appear on-chain only when someone who already has an account with coins sends some coins for the first time to the new account. Here it would be the same but stated more explicitly: an existing account with coins is required to create a new account.

How you state this could be scary from a UX perspective as opposed to the UX on other chains, where it looks like it is "free" to create as many accounts as possible and when you send coins to any new account there is only gas for a normal tx. Also if I create a new ETH address it will be shown on Etherscan, would it be a paper address, so then from a UX perspective even if it is not "on-chain" it should be stated as a valid address and appear in the explorers as soon as it fits the requirements to be an address.

[damip]

When an account is deleted, the "transfer account number" is credited with the remaining coins, as well as the reimbursed coins coming from the freed ledger space.

Could you clarify this point? What do you mean by the reimbursed coins? Could you give an example?

Example: I have an account with 100 coins-equivalent in terms of storage space it uses, as well as a balance of 1000 coins. Now I delete this account. Where do the coins from the balance go ? Where do the coins unlocked from the freed storage go ?
In this RFC I propose a "DeleteAccount" operation that will allow you to delete an account, and optionally send all the remaining+freed coins to a target wallet that you define in the DeleteAccount operation.

have an extra supervising corporate account that needs to confirm every action of the employees

Doesn't it exists already with multisig approach and using smart contracts? I think Gnosis, Multis and others address this issue. It's interesting though if it can smooth the process / if it is a new approach.

Multisig exists on ETH only through smart contracts and is much less practical to use than Bitcoin's native multisig (we tried).
But you're right, multisig is not the main added value here.

manually setup a smart contract account, then provably lose control over it

Same here, I think you can already do that (at least on EVM) and renounce ownership in a provable way.

To my knowledge, that can be done only through complicated SC machinery and has strong limits on what you can do. Do you have examples ?

use the same private key for multiple accounts (single user, multi-account)

Doesn't it increase the risk for multi-account to be compromised?

Not much more than if your seedphrase is compromised, but yes slightly.

From @jwmdev here

Consider the possibility of having account categories if it may assist in internal account lookup. For example, the first few account bits could be reserved for account categories: e.g 0000xxx - for system accounts, 0001xxx - smart contract accounts, 0010xxx - normal accounts, 0011xxx - multi-signature accounts, and other bits could be reserved for future account categories.

I was wondering, wouldn't it be nice also to have the thread in which the account is located also? I would like that very much. A bit the same as your address prefix on Cosmos states on which chain it is dedicated (secret0001, cosmos0001) for the same address. Also couldn't you then have the same account on the 32 threads and change the prefix (32, 01 etc...)? For example to interact faster with a SC or address on this thread. But you would need the account to be only accounted once but balance would be accounted in as many threads as there were balance put in.

In the current testnet 11, the thread can be deduced directly from the address with a simple code, so clients will be able to display it. Here is the computation used to deduce the thread from a known address: https://github.com/massalabs/massa/blob/main/massa-models/src/address.rs#L148-L152
In this RFC, it's even simpler: we have thread = account_number % 32.
That being said, knowing the thread should not be relevant to real applications.

That doesn't change compared to most other non-UTXO PoS cryptos: accounts appear on-chain only when someone who already has an account with coins sends some coins for the first time to the new account. Here it would be the same but stated more explicitly: an existing account with coins is required to create a new account.

How you state this could be scary from a UX perspective as opposed to the UX on other chains, where it looks like it is "free" to create as many accounts as possible and when you send coins to any new account there is only gas for a normal tx. Also if I create a new ETH address it will be shown on Etherscan, would it be a paper address, so then from a UX perspective even if it is not "on-chain" it should be stated as a valid address and appear in the explorers as soon as it fits the requirements to be an address.

Technically, either the UX embraces the "account creation" mechanism that is familiar to non-crypto users (eg normal banks), or it hides it to make things look and feel like other cryptos by pretending the account is created (but we only have the public key off-chain), and create the account on-the-fly when a first tx is processed. Of course, because it reserves space in the ledger, account creation will always use more gas than a normal transaction that doesn't consume extra ledger space.

[AurelienFT]

190M is very far from u64::MAX (18_446_744_073_709_551_615)

Oh yeah my bad was thinking of 2 billions which is for i32

Ok with all your answers. Thank you !

[jcbaillie]

Just an idea, reacting to this: "having an "address" short enough to remember by heart" => I'm pretty sure people will not remember but the most trivial numbers (still hard for most people to remember more than their own phone number!). I think the advent of a DNS service for account names will be pretty much inevitable. Since looking up this DNS in the ledger will be done frequently, why not simply taking a hash of the account name as a key? It will make the account creation process a bit more complex and slow (to avoid collisions), but it's rare so it doesn't matter that much. Then, people would be able to register very short account names at the beginning, similar to user logins, with no problem remembering it (it would most likely be their name + initials, in most of the cases).

[damip]

That's a good proposal. It is currently being done through Ethereum Name Service: https://ens.domains/ and is basically a separate smart contract. Your proposal would force everyone to use domain names natively, which is something we could discuss indeed. However, your proposal would also imply that you won't be able to change your domain name without breaking all the links with other smart contracts (contrary to ENS). Just like for other classical systems (amazon accounts, bank accounts etc...) in this RFC you have a unique ID number that doesn't change, but you can change your vanity display names at will without breaking anything.

[jcbaillie]

I didn't mean that the account name would necessarily be the vanity name. My suggestion here was merely a method to forge the ID number from a procedure that allows the user to remember it (which was one of the use cases you mentioned) and communicate it easily without a QRCode, instead of incrementing a counter and hoping the user will remember this number. But once the ID is set (by whatever method), we can indeed also add a layer on top of that to bind a vanity display name, potentially different and changing. I think it's a separate issue here.

[damip]

OK I understand better, and it's an interesting idea that we could discuss further. Note however that this approach negates the transaction size gains obtained from the account number approach, and significantly increases ledger space usage.

[sebastien-forestier]

I see two points in your proposal:

1- an opportunity for reduction of transaction size using integers instead of hashes, at the cost of a similar increase in the ledger size with pubkeys,
2- a wish to include more features in the core protocol around authentication

For the first point: I think why not, let's study the benefits / costs

For the second point: I think all the described use cases can be done at the smart contract level, so we should let them at the smart contract level for more safety, simplicity, generality and maintenance of the core. Otherwise why not adding ERC20 to the core ? NFTs ? etc.

So a good question is how we set the limit of core features, considering the improvements in perfomance and user experience, and the costs in safety, simplicity, generality, maintenance.

I agree that for more performance, we added transactions at the core level instead of letting them in smart contracts like Ethereum, but I really think this is one of the main use cases of blockchain (to transfer value in the native token), with maybe half of the operation volume in the future, and a big performance improvement.

[damip]

I see two points in your proposal:

1- an opportunity for reduction of transaction size using integers instead of hashes, at the cost of a similar increase in the ledger size with pubkeys, 2- a wish to include more features in the core protocol around authentication

For the first point: I think why not, let's study the benefits / costs

For the second point: I think all the described use cases can be done at the smart contract level, so we should let them at the smart contract level for more safety, simplicity, generality and maintenance of the core. Otherwise why not adding ERC20 to the core ? NFTs ? etc.

So a good question is how we set the limit of core features, considering the improvements in perfomance and user experience, and the costs in safety, simplicity, generality, maintenance.

I agree that for more performance, we added transactions at the core level instead of letting them in smart contracts like Ethereum, but I really think this is one of the main use cases of blockchain (to transfer value in the native token), with maybe half of the operation volume in the future, and a big performance improvement.

This proposal does not revolve around hardcoding extra auth features in the core. I left the auth variations part away from the RFC because it's not the focus, we could even say that for now the number of pubkeys is either 0 or 1 so that there are no hardcoded multisig features. We can also forget about the SetAccountAuth op and we will be pretty much feature-equal with the current system: no hardcoded features.

It also doesn't revolve that much around performance since most ops will be larger SC ops eventually.

The main goal of this RFC is to separate concerns: account identification VS account authentication. This will make the codebase less coupled (and therefore more modular and simple), and allow for more flexibility in future applications and updates. The extra applications I listed are just (nice) side-effects of this separation, they are not hardcoded features.

[sebastien-forestier]

The main goal of this RFC is to separate concerns: account identification VS account authentication. This will make the codebase less coupled (and therefore more modular and simple)

I think this concept is currently implemented by users through smart contracts, and implementing it in the core will make the core more complex/less maintainable and the implementation won't be able to evolve easily through a change of smart contract, so it's not a straightforward decision

[damip]

The main goal of this RFC is to separate concerns: account identification VS account authentication. This will make the codebase less coupled (and therefore more modular and simple)

I think this concept is currently implemented by users through smart contracts, and implementing it in the core will make the core more complex/less maintainable and the implementation won't be able to evolve easily through a change of smart contract, so it's not a straightforward decision

I disagree it would make the core more complex. Less coupling usually means better maintainability and easier evolution.

It is also why I insisted so much on the fact that there are no extra hardcoded features in my previous message, just a decoupling of two concepts that don't need to be coupled in order to simplify the code and make it more modular. Again, the goal here is not to hardcode the list of use cases into the core, those are just side-effects of the decoupling.

But I feel like we are in an infinite misunderstanding loop here :p

[sebastien-forestier]

Let's take examples:

• https://ens.domains/ The ENS smart contracts solve the first 2 and the last 2 use cases, with no added decoupling code/complexity to the core
• https://gnosis-safe.io/ Gnosis Safe solves the next 2 use cases, again with no added decoupling code/complexity to the core
• other uses of smart contracts solve the other use cases, with no added decoupling code/complexity to the core

[damip]

I guess we need to discuss this orally a bit more

[LucasRoorda]

As I understand the main advantages are to 1) shorten the address format in transactions for optimization and ease of use/extra possibilities and 2) implement certain functions natively that smart-contracts would otherwise carry out (multisig, timelocks).

Some thoughts:

1. Does the sender of funds who has to use the CreateAccount function pay more gas fees as when he simply would have to send a simple transaction? Is this a big difference, or is it negligible? I’m thinking about CEXes who might be paying more in fees if this is the case, but would potentially overcharge users if they charge everyone as if they would have to use the CreateAccount function.

2. 'The public key list length must be limited by a protocol constant.’

—> Are there any technical objections against having huge lists of public keys connected to an account number?
—> Can an account be created without sending coins to it?

3. DeleteAccount operation

—> Can limitations/rights be set on pubkeys for specific functions? Sort of like different admin rights for different public keys

4. How do gas costs compare for:

(1.) Adjusting the public keys linked to an account
(2.) Creating a new account
(3.) Transfering the coins to a secondary existing account

Would be good if 1 is cheaper than 2 and 3 combined.

5. Can some sort of naming service be implemented natively to the account number? So besides simply remembering the account number, people could have their nickname? You’d still have smart-contracts use the account number, while the name of the account could be changed to people’s liking whenever they simply want to receive transactions.

Not sure what security considerations are here.

[damip]

Thanks for your review Lucas !
Here are some answers:

As I understand the main advantages are to 1) shorten the address format in transactions for optimization and ease of use/extra possibilities and 2) implement certain functions natively that smart-contracts would otherwise carry out (multisig, timelocks).

Yes that, and to decouple two things that don't need to be coupled (identification vs authentication) for higher code flexibility.

Some thoughts:

1. Does the sender of funds who has to use the CreateAccount function pay more gas fees as when he simply would have to send a simple transaction? Is this a big difference, or is it negligible? I’m thinking about CEXes who might be paying more in fees if this is the case, but would potentially overcharge users if they charge everyone as if they would have to use the CreateAccount function.

He will pay a extra storage fee when creating the account because adding the new account occupies extra space in the ledger.
Storage fees are still being discussed here: #2746

2. 'The public key list length must be limited by a protocol constant.’

—> Are there any technical objections against having huge lists of public keys connected to an account number? —> Can an account be created without sending coins to it?

Having an arbitrarily complicated authentication method (eg. many keys) will impact the performance of the protocol. Signature verification is already the main source of CPU usage in Massa.

You can create an account with 0 balance but you need to pay for the storage fees as mentioned above.

3. DeleteAccount operation

—> Can limitations/rights be set on pubkeys for specific functions? Sort of like different admin rights for different public keys

In theory yes. It is left for future spec, but this RFC paves the way towards that.
That being said, since the smart contracts are allowed to know which pubkeys were used for authentication, they can implement that kind of functions as well.

4. How do gas costs compare for:

(1.) Adjusting the public keys linked to an account (2.) Creating a new account (3.) Transfering the coins to a secondary existing account

Would be good if 1 is cheaper than 2 and 3 combined.

I think the main source of fees would be linked to the extra storage space the operation would use.
For example if it adds 20 keys, you'll pay more because you'll use more space (TBD, see above).
If it's just changing 1 public key to another, the cost will be the same as transferring coins as there is no extra storage involved.
Creating an account always involves extra storage tho.
So with 1 key: (1) = (3) < (2) => in that case, (1) is indeed cheaper than (2) and (3) combined

5. Can some sort of naming service be implemented natively to the account number? So besides simply remembering the account number, people could have their nickname? You’d still have smart-contracts use the account number, while the name of the account could be changed to people’s liking whenever they simply want to receive transactions., but this RFC does not detail them.

That can be achieved through an ENS-like smart contract, but some blockchains implement it natively (eg. EOS: https://medium.com/hackernoon/the-ultimate-guide-to-understanding-eos-accounts-a44b58ba5601 ). This is up to debate.

Not sure what security considerations are here.

The public key is revealed

[damip]

Updated with chosen-account-name

[qdrn]

I like the idea. And I think it makes sense to implement this in the core of the protocol since we want user to be able to browser decentralized websites.

One thing that I don't like with this proposition is that once I buy a name domain, I hold it forever. It will probably lead to people buying "interesting" name domains right from the start of the network to make a profit later. Also, if someone buys "interesting" name domains and then forget his private key then those domains are lost forever. In the case of ENS name domains are rented so it will eventually become available again.

[damip]

I like the idea. And I think it makes sense to implement this in the core of the protocol since we want user to be able to browser decentralized websites.

One thing that I don't like with this proposition is that once I buy a name domain, I hold it forever. It will probably lead to people buying "interesting" name domains right from the start of the network to make a profit later. Also, if someone buys "interesting" name domains and then forget his private key then those domains are lost forever. In the case of ENS name domains are rented so it will eventually become available again.

Basically, all of your concerns are absorbed inside the general idea "an address occupying space inside the ledger needs to pay a time-proportional fee or be deleted". This is a separate problem that requires its own RFC.
All the remaining problems are also present on the normal DNS system.

[qdrn]

Not really.

I don't think there is any problem with addresses as it is. Mostly people will stick to one address as it cost more coins to have more (storage cost). In the case of DNS there are other things that come into play that will make people want to buy more than one address to speculate etc...

I agree that it's also present on the normal DNS but if the DNS becomes part of the core then this should be addressed in the core. Maybe it can be discussed in another discussion.

[damip]

I'm not sure I agree that holding on to N domain names in time is any different than holding on to N megabytes in the ledger in time. Both are costly to setup, both hog ressources, both can be used for speculation, both could be charged per unit of time and freed on lack of payment. Also with this RFC, 1 domain name = 1 ledger entry, and therefore ledger space in use. Deleting a domain name implies deleting its ledger entry and vice versa.

It is possible to define a cost on account creation, as well as a cost per unit of time that is [ a constant plus a factor proportional to occupied ledger space ]. By adjusting those factors, basic incentives can be created.

Note that domain squatting, hoarding, speculation etc... is commonplace in the traditional DNS system, despite initial costs and monthly fees

[qdrn]

I'm not sure I agree that holding on to N domain names in time is any different than holding on to N megabytes in the ledger in time. Both are costly to setup, both hog ressources, both can be used for speculation, both could be charged per unit of time and freed on lack of payment. Also with this RFC, 1 domain name = 1 ledger entry, and therefore ledger space in use. Deleting a domain name implies deleting its ledger entry and vice versa.

Not saying everything is different. As you said, this part (storage) is similar in both cases.

It is possible to define a cost on account creation, as well as a cost per unit of time that is [ a constant plus a factor proportional to occupied ledger space ]. By adjusting those factors, basic incentives can be created.

Yes. That's something that can be put in place for instance.

Note that domain squatting, hoarding, speculation etc... is commonplace in the traditional DNS system, despite initial costs and monthly fees

I think this point is just further proof that we need to think about the consequences of putting a DNS system.

[damip]

TODO: choose an economic model to unlock this discussion.

• allow one person to sell to another

• tax on allocation:

  • free
  • constant (like we do for storage) with coins being freed when the name is deallocated

• time tax:

  • none (like we do for storage)
  • free but need for "sign of life" signalling from time to time to prove it's not abandonned
  • constant with possible length dependnecy (like ENS)
  • Harberger tax
  • what happens when the tax is not paid ? do we implicitly rename the entry to the hash of its pubkey ?

[damip]

Idea towards which we are converging after discussions:

• auction domains at mainnet launch
• after launch, let people freely transfer domains
• when reserving a new domain from scratch, let people do it for free if the domain is more than 20 chars long, otherwise, require a burn of 100 coins. When freeing the domain, reimburse 50% of that amount, burn the rest

[damip]

@sebastien-forestier @qdrn

[SlnPons]

Once you've made a decision, please ping me so I can start - eventually - to implement needed features to our current DNS "object" (putting quotes as I don't think it's the best word...but I'm sure you know what I'm talking about ;) )

[sebastien-forestier]

Alternative: #3454