near / nearcore

Reference client for NEAR Protocol
https://near.org
GNU General Public License v3.0
2.32k stars 619 forks source link

Problem with creating a top level account on a localnet after 1.22.0 #5045

Open EquilateralDelta opened 3 years ago

EquilateralDelta commented 3 years ago

Describe the bug I'm running a local Near node for local development using Rustup. Currently, I have a problem with creating a top-level account there. I'm creating an account named 'local' from a 'node0' account and I'm getting "CreateAccountOnlyByRegistrar" error. That worked fine not so long ago and the setup on my part had no major changes lately, so I suspect that Rustup has implicitly updated to 1.22.0 and that is what causes an issue. Additionally, inside a genesis.json file, the value of min_allowed_top_level_account_length is 0, which implies that there shouldn't be a restriction I'm facing.

To Reproduce 1. Run nearprotocol/nearup:1.2.1 Docker container with 'run localnet --verbose' command 2. Execute a transaction to create a short-named top-level account from the 'node0' account or any other preexisting one.

Expected behavior The account is created successfully.

Version (please complete the following information):

Additional context I suspect that the issue can be caused by this pull request: https://github.com/near/nearcore/pull/4779, but I'm not sure. @Longarithm

Longarithm commented 3 years ago

Hey @NarkomDe!

Yeah, it happened because of update of the protocol. We decided to have the same runtime configuration for all chains, including local ones, because at some point we observed unexpected differences in betanet, testnet and mainnet, which also were hard to track. The expected behaviour is that regular users except registrar shouldn't be able to create top-level accounts with length < 32.

When we fully roll this out, runtime config from genesis.json shouldn't be actually used for new protocol versions. We plan to remove it from here, but the current state may be confusing, sorry for that. See https://github.com/near/nearcore/issues/4649 for more details.

The source of truth now is this folder: https://github.com/near/nearcore/tree/master/nearcore/res/runtime_configs For protocol version 48, the configuration includes:

  "account_creation_config": {
    "min_allowed_top_level_account_length": 32,
    "registrar_account_id": "registrar"
  }
EquilateralDelta commented 3 years ago

@Longarithm Thanks for the explanation. Do I understand correctly that what I'm facing is expected behavior from now on? If so, I have a problem with that account 'registrar' at a local configuration isn't created by default. So I can't call any transactions from it and I can't create it because it is also a top-level account. Is there are any way currently to create a top-level account on a local chain that I don't see?

Longarithm commented 3 years ago

Do I understand correctly that what I'm facing is expected behavior from now on?

Yes.

Is there are any way currently to create a top-level account on a local chain that I don't see?

There shouldn't be an other way.

account 'registrar' at a local configuration isn't created by default

Hm, that's a good point! From the first sight, it looks like a bug. We may consider adding it to the configuration. How crucial is it for you to work with top-level accounts, and are accounts like xyz.node0 acceptable for you, which you should be able to create?

EquilateralDelta commented 3 years ago

I'm already moving to .node0 as a top-level account because it's a blocking issue for me. And it isn't a trivial switch for the system I'm working on. I wanted to make sure there isn't any easier way. On a side note, I find xyz.local accounts more expressive during local development compared to xyz.node0 the same way as xyz.testnet or xyz.near express chains they are on. So I would like to save the possibility to use it if it's possible. But thanks for the clarifications anyway! I would appreciate any updates on this topic in the future.

bowenwang1996 commented 3 years ago

From the first sight, it looks like a bug. We may consider adding it to the configuration.

@Longarithm do you mind creating an issue for this?

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.