Failed to read rollup configuration

[DSHIVAAY-23]

After adding the transaction to batch when i try to sumbit the transaction through this command cargo run rpc submit-batch by-address sov15vspj48hpttzyvxu8kzq5klhvaczcpyxn6z6k0hwpwtzs4a6wkvqwr57gc

i got Failed to read rollup configuration error

[preston-evans98]

@DSHIVAAY-23 it looks like your second command is trying to use the cli to submit transactions, but is invoking the cargo run instead of ./target/debug/sov-cli. Does ./target/debug/sov-cli rpc submit-batch by-address work?

[preston-evans98]

On closer inspection, the root cause of this issue is a bad bash snippet in demo-rollup/README.md. The snippet contains the bad command which OP reproduced here. #815 fixes the README.

@DSHIVAAY-23 I tested locally and ./target/debug/sov-cli rpc submit-batch ... seemed to work - but please let me know if you have any more issues.

[DSHIVAAY-23]

again i have tried it with different given addresses but....

[DSHIVAAY-23]

@preston-evans98 i am getting this much tps is it true ? and when will we see the Sovereign testnet launch?

[preston-evans98]

again i have tried it with different given addresses but....

@DSHIVAAY-23, it looks like you're manually specifying that the CLI should use the address from the demo. If you want to use your own address, you can drop by-address sov... from the command and the CLI will choose an address for you. Alternately, you can import the private key from the demo address using make import-keys and then the command should work.

Looks like another bug in our tutorial - we should add the make import-keys step.

[preston-evans98]

i am getting this much tps is it true ?

It looks like we're doing integer division to get the TPS number, so it's overstating things slightly. If you check the division on a calculator you get roughly 427,220 TPS for your first run, not the even 500k shown in the table. I'll put up a PR to switch to float division shortly.

Aside from that, I think these numbers should be "real" - we are checking all of the transaction signatures and computing state-root updates, as well as committing the results to the DB. But, the benchmark differs from reality in some important ways. Since we spin up a clean chain state is almost definitely small enough that it fits into memory. In addition, we're using a mock DA layer - so we're not fetching the transaction data over the network, and we're not doing any checks to guarantee data availability.

And, last but not least, this is just the performance of the full node. The prover runs separately, but certainly can't handle half a million TPS on a single machine

cc @dubbelosix is there anything I'm missing here?

and when will we see the Sovereign testnet launch?

Hopefully soon™️ 😂. In all seriousness, though, we're hoping to have something stable enough for a long-running testnet in the next couple of months.

[DSHIVAAY-23]

@preston-evans98 and one more thing like i have not seen any contribution guide.. through this repo what if i want to contribute some Risc-zero Code examples so that users can understand the main Zk-tech behind this repo Easily

[preston-evans98]

Aside from that, I think these numbers should be "real" - we are checking all of the transaction signatures and computing state-root updates, as well as committing the results to the DB. But, the benchmark differs from reality in some important ways. Since we spin up a clean chain state is almost definitely small enough that it fits into memory. In addition, we're using a mock DA layer - so we're not fetching the transaction data over the network, and we're not doing any checks to guarantee data availability.

I chatted with @dubbelosix, and these numbers seem fishier on second glance. Last time we checked, we were clocking no more than 10k tps on a developer laptop. He's digging in now.

[preston-evans98]

@preston-evans98 and one more thing like i have not seen any contribution guide.. through this repo what if i want to contribute some Risc-zero Code examples so that users can understand the main Zk-tech behind this repo Easily

PRs are welcome! We don't have formal contributing guidelines yet - so if you have something you want to tackle, feel free to just open a PR. The only other thing I should mention is that we recommend using the top-level Makefile to help get through CI. make lint-fix is super useful.

[DSHIVAAY-23]

@preston-evans98 like a have check it many times on my thinkpad

Aside from that, I think these numbers should be "real" - we are checking all of the transaction signatures and computing state-root updates, as well as committing the results to the DB. But, the benchmark differs from reality in some important ways. Since we spin up a clean chain state is almost definitely small enough that it fits into memory. In addition, we're using a mock DA layer - so we're not fetching the transaction data over the network, and we're not doing any checks to guarantee data availability.

I chatted with @dubbelosix, and these numbers seem fishier on second glance. Last time we checked, we were clocking no more than 10k tps on a developer laptop. He's digging in now.

@preston-evans98 i have check it for 10 to 15 times and i got exactly same tps i.e 500k.

[DSHIVAAY-23]

@preston-evans98

i am getting this much tps is it true ?

It looks like we're doing integer division to get the TPS number, so it's overstating things slightly. If you check the division on a calculator you get roughly 427,220 TPS for your first run, not the even 500k shown in the table. I'll put up a PR to switch to float division shortly.

Aside from that, I think these numbers should be "real" - we are checking all of the transaction signatures and computing state-root updates, as well as committing the results to the DB. But, the benchmark differs from reality in some important ways. Since we spin up a clean chain state is almost definitely small enough that it fits into memory. In addition, we're using a mock DA layer - so we're not fetching the transaction data over the network, and we're not doing any checks to guarantee data availability.

And, last but not least, this is just the performance of the full node. The prover runs separately, but certainly can't handle half a million TPS on a single machine

cc @dubbelosix is there anything I'm missing here?

and when will we see the Sovereign testnet launch?

Hopefully soon™️ 😂. In all seriousness, though, we're hoping to have something stable enough for a long-running testnet in the next couple of months.

If we get these huge numbers then we can expect 50k+ tps whlie Running it with DA layer OR if we will do transaction on layer 2 i.e from one wallet to another wallet both on Sovereign network we could Expect the good speed.

[preston-evans98]

@DSHIVAAY-23, we found the source of the suspicious TPS numbers - the benchmark code was configured to require sequencers to register with the rollup before submitting transactions, but the registration transaction was never being sent. So, the rollup was seeing all of the bundles but choosing not to apply them. The fix landed in #829 , we're seeing the correct numbers again.

[preston-evans98]

@DSHIVAAY-23 unfortunately, it's pretty hard to know what the production numbers will be at this point. On the one hand, in prod you'll incur overhead from DA and from having more state than you can fit in memory. On the other hand we haven't started optimising the native performance at all yet because we expect proving to be the bottleneck - so there's a bunch of relatively low-hanging fruit to improve native performance. Do you have a particular application in mind that needs certain performance from the fullnode and/or sequencer?

[parveenkaushikmajra]

@DSHIVAAY-23, we found the source of the suspicious TPS numbers - the benchmark code was configured to require sequencers to register with the rollup before submitting transactions, but the registration transaction was never being sent. So, the rollup was seeing all of the bundles but choosing not to apply them. The fix landed in #829 , we're seeing the correct numbers again. @preston-evans98 i am @DSHIVAAY-23 my github is not working btw your changes in benches are not working and however we wait for 1 hr for results we didnt get anything plz share Screenshot if you have run these benches

[parveenkaushikmajra]

@DSHIVAAY-23 unfortunately, it's pretty hard to know what the production numbers will be at this point. On the one hand, in prod you'll incur overhead from DA and from having more state than you can fit in memory. On the other hand we haven't started optimising the native performance at all yet because we expect proving to be the bottleneck - so there's a bunch of relatively low-hanging fruit to improve native performance. Do you have a particular application in mind that needs certain performance from the fullnode and/or sequencer?

I am doing R&D on this update you soon

[DSHIVAAY-23]

@preston-evans98 And i have seen that You all are using Zk-Snark in this too how you all are uing that thing . is stark-recursive is not a option how polygon has implemented that very well

[preston-evans98]

benches are not working and however we wait for 1 hr for results we didnt get anything plz share Screenshot if you have run these benches

@DSHIVAAY-23, hmm that's very odd. We've seen an issue on some of our dev machines where the RocksDB crate can slow down by a factor of 100 or more when linked against a system-wide installation. But yeah, here are benchmarks on my machine:

[preston-evans98]

And i have seen that You all are using Zk-Snark in this too how you all are uing that thing . is stark-recursive is not a option how polygon has implemented that very well

We allow people to use a variety of proof systems, but for now it looks like Risc0 offers the best performance and they're also using recursive SNARKs.

[preston-evans98]

See also: https://github.com/Sovereign-Labs/sovereign-sdk/issues/857

[DSHIVAAY-23]

again i have tried it with different given addresses but....

and any update on this ?

[DSHIVAAY-23]

@preston-evans98 can we run sovereign-sdk with local calestia node that we see the transactions on light-node exlplorer locally

[DSHIVAAY-23]

@preston-evans98 I think chain Validity is not implemented here . thats why we are getting error in demo-prover host

[preston-evans98]

again i have tried it with different given addresses but....

and any update on this ?

Hmm, it's possible your wallet got into a bad state during an upgrade. Does removing the ~/.sov_cli_wallet directory help?

I'd also recommend just using cargo run --bin sov-cli rpc submit-batch without the by-address flag and letting the wallet pick the address for you.

[preston-evans98]

@preston-evans98 I think chain Validity is not implemented here . thats why we are getting error in demo-prover host

Hmm, I'm not able to reproduce this on the latest nightly? Are you able to switch? If not, send me a commit hash and I'm happy to help debug

[preston-evans98]

@preston-evans98 can we run sovereign-sdk with local calestia node that we see the transactions on light-node exlplorer locally

We haven't been using Celestia block explorers, but you might be able to get something like this up and running against the local devnet. If not, we should have explorer support once we upgrade to the newer Celestia version (coming in a few weeks)

[DSHIVAAY-23]

@preston-evans98 plz see #857 can you make some changs there ?

[DSHIVAAY-23]

@preston-evans98 I think chain Validity is not implemented here . thats why we are getting error in demo-prover host

Hmm, I'm not able to reproduce this on the latest nightly? Are you able to switch? If not, send me a commit hash and I'm happy to help debug

this is the commit history

[DSHIVAAY-23]

I have tried to clone the repo again facing this error

[DSHIVAAY-23]

@preston-evans98 and i am curious to know what will be your maximum tps destination as cosmos itself claim 10k tps on their chains ?

[preston-evans98]

Ah, looks like you might be using a compiler version that Risc0 doesn't support. I'd recommend updating to the latest nightly version of Sovereign, and then running cargo install cargo-risczero and cargo risczero install