"Storage root must match that calculated" , 2.0.0-alpha.4

[ghost]

when i start my private block-chain , the err arise:

Thread 'import-queue-worker-0' panicked at 'Storage root must match that calculated.', <::std::macros::panic macros>:2

This is a bug. Please report it at:

        https://github.com/paritytech/substrate/issues/new

2020-05-02 21:51:30 Block prepare storage changes error:
Execution(RuntimePanicked("Storage root must match that calculated."))
2020-05-02 21:51:30 Error importing block 0xfc94f0a2b3b22db02e03197dd19536b07959582c2b8124f3fa6caee8e3580344: Err(Other(ClientImport("Import failed: Execution: Runtime panicked: Storage root must match
that calculated.")))

my command for example: ./substrate --base-path ./db/node1 --chain dev --port 30340 --ws-port 9911 --rpc-port 30339 --telemetry-url ws://telemetry.polkadot.io:1024 --validator --name node1 --bob

./substrate --base-path ./db/node2 --chain dev --port 30338 --ws-port 9922 --rpc-port 30337 --telemetry-url ws://telemetry.polkadot.io:1024 --validator --name node2 --ev

[shawntabrizi]

Sounds like you might need to purge chain to start:

./substrate purge-chain --base-path ./db/node1 --chain dev

./substrate purge-chain --base-path ./db/node2 --chain dev

[ghost]

Sounds like you might need to purge chain to start:

./substrate purge-chain --base-path ./db/node1 --chain dev

./substrate purge-chain --base-path ./db/node2 --chain dev

i have already remove the db every time

[kianenigma]

which version?

[ghost]

which version?

alpha4

[ghost]

which version?

Why did this error occur

[ghost]

which version?

i pull the substarete code abount on February 30th, and start my project.

[arkpar]

@shawntabrizi @kianenigma We need to bump runtime version @wjy19990622 use --execution=wasm as a workaround for now

[ghost]

which version?

@shawntabrizi @kianenigma We need to bump runtime version @wjy19990622 use --execution=wasm as a workaround for now

thanks very much, when i use --execution=wasm, it's ok.

[ghost]

which version?

@shawntabrizi @kianenigma We need to bump runtime version @wjy19990622 use --execution=wasm as a workaround for now

thanks very much, when i use --execution=wasm, it's ok.

however， produce the block become slowly,. " Timeout fired waiting for transaction pool to be ready. Proceeding to block production anyway."

[NikVolf]

however， produce the block become slowly,. " Timeout fired waiting for transaction pool to be ready. Proceeding to block production anyway."

This cannot make block production slower unless you have full blocks always, block time is fixed

And it is also fixed in the latest master.

[rakanalh]

I've hit this issue as well when trying to launch a custom chain using node-template.

• Using the latest commit: 8c2ff6954597ff2377c664ca8b45a2312619e74c
• Made sure the base-paths are fresh
• Following the instructions of this tutorial where a custom-spec is generated. I replaced the aura and grandpa authorities and nothing other than those.

I can reproduce locally, so i can provide any further information needed for debugging.

[NikVolf]

Ok, seems that this issue due to aura not sending block import notification.

In regular node babe is used, so I couldn't reproduce.

Thanks!

[bkchr]

I can not reproduce this. @rakanalh please upload your custom chain spec and post the secret uris you have used to reproduce this.

Ok, seems that this issue due to aura not sending block import notification.

Not sure what you mean and how that should be related to the storage root.

[ghost]

from threading import Thread

# 向外透露的端口 alice 9944
def node1():
    os.system(
        r"./substrate --base-path ./db/node1 --chain customspec.json  --port 30334 --ws-port 9944 --rpc-port " +
        r"30339  --name node1 --alice" + r" --ws-external --rpc-external  --rpc-cors=all --execution=wasm")

# 向外透露接口
def node2():
    os.system(
        r"./substrate --base-path ./db/node4 --chain customspec.json  --port 9951 --ws-port 9945 --rpc-port " +
        r"9952 --name node4 --bob" + r" --ws-external --rpc-external  --rpc-cors=all --execution=wasm")

# 不向外透露的端口 9911
def node3():
    os.system(
        r"./substrate --base-path ./db/node2 --chain customspec.json  --port 30335 --ws-port 9911 --rpc-port 30338 "
        r" --validator --name node2 --eve --execution=wasm")

# 不向外透露的端口
def node4():
    os.system(
        r"./substrate --base-path ./db/node3 --chain customspec.json  --port 30336 --ws-port 9922 --rpc-port 30337 "
        r" --validator --name node3 --dave --execution=wasm")

# 不向外透露的端口
def node5():
    os.system(
        r"./substrate --base-path ./db/node5 --chain customspec.json  --port 9953 --ws-port 9946 --rpc-port 9954 "
        r" --validator --name node5 --ferdie --execution=wasm")

# 不向外透露的端口
def node6():
    os.system(
        r"./substrate --base-path ./db/node6 --chain customspec.json --port 9955 --ws-port 9957 --rpc-port 9956 "
        r" --validator --name node6 --charlie --execution=wasm")
if __name__ == "__main__":

    queue = []

    queue.append(Thread(target=node1, args=()))
    queue.append(Thread(target=node2, args=()))
    queue.append(Thread(target=node3, args=()))
    queue.append(Thread(target=node4, args=()))
    queue.append(Thread(target=node5, args=()))
    queue.append(Thread(target=node6, args=()))

    os.system("rm localspec.json")
    os.system("rm customspec.json")

    os.system(r"./substrate build-spec --chain=dev > localspec.json")
    os.system(r"./substrate build-spec --chain localspec.json --raw > customspec.json")
    os.system(r"rm -rf ./db/*")

    for i in queue:
        i.start()
    for i in queue:
        i.join()

there are my code for starting multi-node.

[bkchr]

@wjy19990622 your script works for me without any problem. (I removed --execution wasm). Could you please try latest master?

[ghost]

it take time to merging my runtime to latest master. but in my project, The average block time was significantly higher than 3 seconds. there is my project linkhttps://github.com/TransactionX/TransX

[rakanalh]

@bkchr here's my chain-spec: customSpec.txt customSpecRaw.txt

The keys generated where as follows:

Node1 sr25519 for AURA:

Secret phrase 'march garbage kidney adult where never clown again jump excite animal mansion' is account:
  Network ID/version: substrate
  Secret seed:        0x59d4bc30e2aca2dc0a833e280a0b4a6b045e0a32175848df93907e90296d8878
  Public key (hex):   0xc2f5694a31bd292a64382254808b9dcf0cfbb11939c2376f488650696126ee47
  Account ID:         0xc2f5694a31bd292a64382254808b9dcf0cfbb11939c2376f488650696126ee47
  SS58 Address:       5GUL3ofydtV4HoL2pLTatcu4joYCdWgj4cGEUxd9jrHeJRKS

Node1 ed25519 for Grandpa:

Secret phrase `agent walk grain shoe liberty october trash flush diesel nut combine intact` is account:
  Network ID/version: substrate
  Secret seed:        0xff81080172a5b69f352b16e23072a0b94372a83d07171eaa51e53eb55911259a
  Public key (hex):   0x63c8c319ad17e5d9f21a1fe251f0ee109c248eb7a0c4d771a575ff27cc64325a
  Account ID:         0x63c8c319ad17e5d9f21a1fe251f0ee109c248eb7a0c4d771a575ff27cc64325a
  SS58 Address:       5EKYEg1SGagQLVFoptHw5oZEZZM77fDMBDgDStrnPcacRGyW

Node2 Sr525519 for AURA:

Secret phrase `argue fetch educate match arm cousin hold orchard moment strike sister video` is account:
  Network ID/version: substrate
  Secret seed:        0x42d5a633ccb1c4f3391ceab4701e2bc192153f842276bd115b3b65aaf549ff5d
  Public key (hex):   0xd47e90f1ca358a52dcc9a539d4a56b54cc946553f1ecce6beffee17182763055
  Account ID:         0xd47e90f1ca358a52dcc9a539d4a56b54cc946553f1ecce6beffee17182763055
  SS58 Address:       5GsKc9HquLZUzgeVxVsjYVAEZDtMNUpTGvirwT3V1xuU85AS

Node 2 ed25519 for Grandpa:

Secret phrase `island regret sorry sad polar owner into comic property slow boost noise` is account:
  Network ID/version: substrate
  Secret seed:        0xf0ca7b2e9913a6738c32a3bb2b3470ea5c4dc4d04adb7be8e107692d0e357d3e
  Public key (hex):   0xc5dbd7575417ff06a56b208123db16d5f083e5e5e3fe810065a6b35a5d75abbd
  Account ID:         0xc5dbd7575417ff06a56b208123db16d5f083e5e5e3fe810065a6b35a5d75abbd
  SS58 Address:       5GY8baHSmjfCFCA1jKRubbwiSoj3fXoABik4ApMMBrFNbjCV

Steps to reproduce:

1. Run 2 nodes with chain-spec
2. Register node1's sr25519 key into keystore via author.insertKey which triggers the block authoring.
3. As soon as the key is stored, node 2 will start showing the error.

[bkchr]

it take time to merging my runtime to latest master. but in my project, The average block time was significantly higher than 3 seconds. there is my project linkhttps://github.com/TransactionX/TransX

You have that many modifications, the bug can by anywhere. Just make sure that your native and wasm runtime use the same code! We will not be able to provide further support for this.

[bkchr]

@rakanalh how did you generate this chain spec?

[rakanalh]

Following this tutorial: https://www.substrate.io/tutorials/start-a-private-network/v2.0.0-alpha.6/customspec

Basically:

$ ./target/release/node-template build-spec --disable-default-bootnode --chain local > customSpec.json

update the authorities using my generated keys and then:

./target/release/node-template build-spec --chain=customSpec.json --raw --disable-default-bootnode > customSpecRaw.json

[bkchr]

@rakanalh so I can reproduce this, but I suspect that you have changed something in your runtime? Can you please try again with latest master, use node-template build-spec and set your keys. Just use the json config.

[bkchr]

Did you change anything after building the spec?

[rakanalh]

As mentioned in my comment: https://github.com/paritytech/substrate/issues/5871#issuecomment-623539400 i was on latest master at the time and had no changes on master.

I will pull again and try to reproduce tomorrow morning as requested.

[bkchr]

Ty.

[ghost]

Did you change anything after building the spec?

i use the command "./substrate build-spec --chain=dev > localspec.json" replace " ./target/release/node-template build-spec --disable-default-bootnode --chain local > customSpec.json" to start my network. change nothing. i don't use "--bootnodes " , because of there are default bootnodes in my localspec.json

[NikVolf]

Not sure what you mean and how that should be related to the storage root.

Was answering this from @wjy19990622:

Timeout fired waiting for transaction pool to be ready. Proceeding to block production anyway.

[bkchr]

But Aura is also sending a block import notification. I have seen this transaction pool warning as well, but only for the first block.

[NikVolf]

But Aura is also sending a block import notification. I have seen this transaction pool warning as well, but only for the first block.

I know it should send and generally does. But I think it is possible when there are constant reorgs, it misses some of those notifications. Was trying to reproduce locally but with no luck.

[bkchr]

There are no reorgs on an Aura chain, as you always have a fixed validator assigned per slot (which is not the case for Babe and thus the reason we have reorgs/forks).

[rakanalh]

@bkchr tested on latest master (c0ccc24d02080ab4fbb2c65440327fc72acb6c42) and the problem is still there.

Will try to re-generated the chain-spec as you suggested

[rakanalh]

Repeating all steps from latest master:

1. Generate chain-spec:

   > ./target/debug/node-template build-spec --disable-default-bootnode --chain local > customSpec.json
   2020-05-05 11:06:00 Building chain spec
   > vi customSpec.json # Add keys posted above
   > ./target/debug/node-template build-spec --chain=customSpec.json --raw --disable-default-bootnode > customSpecRaw.json
   2020-05-05 11:08:08 Building chain spec

2. Start 2 nodes:

   • Node 1:

     ./target/debug/node-template --base-path /tmp/node01 --chain=./customSpecRaw.json --port 30333 --ws-port 9944 --rpc-port 9933 --telemetry-url 'ws://telemetry.polkadot.io:1024 0' --validator --name MyNode01 --unsafe-rpc-expose

• Node 2:

  ./target/debug/node-template --base-path /tmp/node02 --chain ./customSpecRaw.json --port 30334 --ws-port 9945 --rpc-port 9934 --telemetry-url 'ws://telemetry.polkadot.io:1024 0' --validator --name MyNode02 --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/<Node1 ID> --unsafe-rpc-expose

3. Try to register the key on node 1

Now i can see that node1 is starting to author blocks without node 2 crashing. So all good now!