Introduce lite-mode

[lordshashank]

Usage related changes

Would implement lite node that can be used with "--lite-node" tag which would skip blockhash calculation by replacing it with block_number hashes.

Development related changes

• Resolves test the impact of "lite" mode on devnet performance and potentially introduce it #343
• Added a lite_mode option in the configuration.
• Modified the generate_new_block function to skip block hash calculation when lite_mode is enabled.
• Added relevant docs for lite-mode.

Benchmark Results

I performed benchmark testing using [mint_benchmark[(./scripts/benchmark/mint to compare the performance of the application in lite_mode and regular mode. Here are the results:

Mode	Command	Number of Mints	Time (ms)
Lite Mode	cargo run -- --lite-mode	200	11.172
Regular Mode	cargo run	200	13.447
Lite Mode (Release)	cargo run --release -- --lite-mode	1000	14.703
Regular Mode (Release)	cargo run --release	1000	15.058

As expected, enabling lite_mode improves the performance of the application.

Checklist:

• Checked the relevant parts of development docs
• Applied formatting - ./scripts/format.sh
• No linter errors - ./scripts/clippy_check.sh
• No unused dependencies - ./scripts/check_unused_deps.sh
• Performed code self-review
• Rebased to the latest commit of the target branch (or merged it into my branch)
• Updated the docs if needed, including the TODO section
• Linked the issues which this PR resolves
• Updated the tests if needed; all passing (execution info)

[lordshashank]

@ivpavici I have implemented lite mode by skipping blockhash calculation here and replacing it with hash of block_number.

Could you please see if the implementation is correct, I am not sure of few things like would calculating block_number before initializing header cause problem?, validity of initializing hash with from_prefixed_hex_string(block_number_hex) to reduce computation than generate_hex(), or if I have went completely wrong way here.

Also let me know if hash calculation has to be skipped somewhere else as well, thanks.

[FabijanC]

Have you done any benchmarking? What is the time impact of skipping block hash calculation?

[lordshashank]

Not yet, I just implemented the functionality as per devnet-py, if its required let me know how I can do that?

[FabijanC]

Not yet, I just implemented the functionality as per devnet-py, if its required let me know how I can do that?

Think of something, be creative :D

But one test could look like this, let's call the script mint_benchmark.sh:

#!/bin/bash

set -eu

N=$1

for _ in $(seq 1 $N); do
    curl -w "\n" -sSf localhost:5050/mint --json '{
        "amount": 1,
        "address": "0x1"
    }'
done

And you could run:

$ chmod +x mint_benchmark.sh
$ time ./mint_benchmark.sh 1000

Or replace 1000 with any number you wish to test. Of course, this assumes that somewhere on your computer you have Devnet running at port 5050. I'd recommend testing both cargo run and cargo run --release, both in lite and regular mode.

[ivpavici]

yeah, please @lordshashank we would be very grateful for this test and report afterwards :)

[lordshashank]

@FabijanC @ivpavici I have added benchmark report and test file as well, let me know if something else is needed.

[ivpavici]

thanks!
Seems like the speedup is negligible in --release mode... I will let @FabijanC decide about the merging. But either way this was helpful for us so you will definitely get a reward regardless if we merge or not!

[FabijanC]

Thanks for the table report in the PR description! How did you accumulate the times? I mean - are you reporting what you got on the first run? Or did you run it multiple times?

Also, I'm having doubts about DX and UX and if --lite-mode is the best approach. Perhaps we should have multiple CLI options like --block-hash <REAL|DUMMY>. We should consider what else can be skipped (other than block hash generation).

[lordshashank]

Times reported are of first run only.

For UX I suppose that best way could be to include --lite-mode which would include all the optimizations that we would be including in future and individual flags for each optimizations as well. But as currently there's just one, we can go with current flow ig, and change when we include new optimizations on future prs.

@FabijanC I have implemented the nits you suggested, let me know if anything else is to be done.

[FabijanC]

Thanks!

[FabijanC]

@lordshashank Please, in the future, execute the tests to ensure the CI workflow passes. I will fix the failure coming from the merge of this PR.

[lordshashank]

Really really sorry, I was thinking to do that after all the issues in pr were resolved, just forgot it at the end. Would surely keep in mind from next time.