Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove minimal spec #1119

Merged
merged 26 commits into from
Jan 23, 2024
Merged

Remove minimal spec #1119

merged 26 commits into from
Jan 23, 2024

Conversation

claravanstaden
Copy link
Contributor

@claravanstaden claravanstaden commented Jan 17, 2024

  • remove beacon-minimal-spec feature
  • update lodestar to use mainnet spec when running the local net
  • test smoke tests work
  • investigate error: thread 'tests::submit_update_execution_headers_too_far_behind' has overflowed its stack
  • update test fixture/benchmark data
  • adds script to generate test data for inbound message queue tests (will aid Adds runtime tests #1114)
  • generate next sync committee update
  • check benchmarks work
  • check beefy relayer starting

Polkadot-sdk companion: Snowfork/polkadot-sdk#100

@yrong
Copy link
Contributor

yrong commented Jan 18, 2024

investigate error: thread 'tests::submit_update_execution_headers_too_far_behind' has overflowed its stack

Maybe you can try this env setup first

RUST_MIN_STACK: 8388608

# if were are running locally speed up the seconds per slot from 12 seconds to 2 seconds. if we are not
# running locally, revert
if [ "$eth_network" == "localhost" ]; then
set_slot_time 12 2
Copy link
Contributor

@yrong yrong Jan 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe slot time can be further decreased to 1 second, then a sync period will be 2.27 hours.
Anyway, it seems still a bit challenging to test the switchover process.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be careful being too aggressive, as it may mean the beacon-light-client could struggle to import headers at such a fast rate. May need relayer updates too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like 1 second per slot is fine for our local setup. The bridge hub parachain sometimes drops imports but then recovers. I think that's okay, for the sake of faster tests? Otherwise we can change the SECONDS_PER_SLOT back to 2 seconds.

@claravanstaden
Copy link
Contributor Author

investigate error: thread 'tests::submit_update_execution_headers_too_far_behind' has overflowed its stack

Maybe you can try this env setup first

RUST_MIN_STACK: 8388608

Thanks! This did the trick. It will be a problem when running the test in polkadot-sdk, perhaps. It is maybe worthwhile to change the test to fit in the stack size, maybe use heap-allocation instead.

Copy link

codecov bot commented Jan 18, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d65afb4) 75.09% compared to head (79b8a30) 76.04%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1119      +/-   ##
==========================================
+ Coverage   75.09%   76.04%   +0.95%     
==========================================
  Files          58       58              
  Lines        2461     2455       -6     
  Branches       72       72              
==========================================
+ Hits         1848     1867      +19     
+ Misses        596      571      -25     
  Partials       17       17              
Flag Coverage Δ
rust 75.15% <100.00%> (+1.13%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Comment on lines 1 to 11
// Generated, do not edit!
// See ethereum client README.md for instructions to generate
use hex_literal::hex;
use snowbridge_beacon_primitives::CompactExecutionHeader;
use snowbridge_core::inbound::{Log, Message, Proof};
use sp_std::vec;

pub struct InboundQueueTest {
pub execution_header: CompactExecutionHeader,
pub message: Message,
pub execution_header: CompactExecutionHeader,
pub message: Message,
}
Copy link
Contributor

@yrong yrong Jan 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool! IIUC now the InboundQueueFixture is also auto-generated based on a template file.

I would like it's not limited to benchmark tests and also apply to unit/integration tests, more context in #1115 (comment).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I think we can use these fixtures in more tests. I thought about moving these tests fixtures into a separate crate so we can easily reference them.

Comment on lines -128 to -134
# Run tests for fast-runtime feature
- name: Tests for fast-runtime
working-directory: parachain
run: >
cargo test
--workspace
--features fast-runtime
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fast runtime isn't necessary for the ethereum client anymore, since the runtime is sped up outside of the spec.

@@ -95,5 +95,3 @@ try-runtime = [
"pallet-timestamp?/try-runtime",
"sp-runtime/try-runtime",
]
beacon-spec-minimal = []
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No more this annoying feature...

Comment on lines 2 to 11
"execution_header": {
"parent_hash": "0x088df21dc48b1ef18b6df9ef35dc3b21eda78f943813436d5059fb3b8248c74a",
"state_root": "0xc1e042d99f2e5d21f4be14cca504ce8bd961db18084a1908431686ef918900bd",
"receipts_root": "0x7b1f61b9714c080ef0be014e01657a15f45f0304b477beebc7ca5596c8033095",
"block_number": 210
},
"message": {
"event_log": {
"address": "0xeda338e4dc46038493b885327842fd3e301cab39",
"topics": [
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added generating the inbound message test fixture to the beacon data fixture generation, since it is kinda of related. This message was generated on the same run as the beacon test fixture data so we can now write a test in #1114 that:

  • sets the beacon checkpoint
  • submit a sync committee update
  • submit a finalized header
  • submit an execution header containing a message
  • verify the message

Comment on lines 1 to 11
// Generated, do not edit!
// See ethereum client README.md for instructions to generate
use hex_literal::hex;
use snowbridge_beacon_primitives::CompactExecutionHeader;
use snowbridge_core::inbound::{Log, Message, Proof};
use sp_std::vec;

pub struct InboundQueueTest {
pub execution_header: CompactExecutionHeader,
pub message: Message,
pub execution_header: CompactExecutionHeader,
pub message: Message,
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I think we can use these fixtures in more tests. I thought about moving these tests fixtures into a separate crate so we can easily reference them.

fi
yarn install && yarn run build
popd
pushd $root_dir/lodestar
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to build lodestar on every run because it won't rebuild if there are no changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, it did rebuild even no changes and cost almost 13s on my laptop.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe that 13 seconds is OK? The reason why I would rather rebuild is, if you change fast runtime from true to false, lodestar won't rebuild.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a problem. Maybe we can add a bool flag/env in the script to control whether to force rebuild or not. But it's very nit-picky so leave it up to you.

@@ -52,6 +52,8 @@ start_lodestar() {
timestamp=$(date -d'+10second' +%s)
fi

export LODESTAR_PRESET="mainnet"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use the "mainnet" spec for local tests.

@@ -37,9 +37,10 @@
ps

# typescript
python3
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Python is necessary to build lodestar.

Comment on lines +42 to +43
nodejs_20
(yarn.override { nodejs = nodejs_20; })
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yarn comes with node 18 so we need to override it here. Lodestar 1.12.0 doesn't build with 18.16.1

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw the lodestar in our repo is the forked branch https://github.com/Snowfork/lodestar/tree/snowbridge which is based on 1.14.0 with a hack to work with node 18.16.

Anyway, the hack here is necessary for working with node 20 so happy to see it.

@claravanstaden claravanstaden marked this pull request as ready for review January 21, 2024 20:38
Copy link
Contributor

@yrong yrong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

Copy link
Collaborator

@vgeddes vgeddes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, looks great 🚀

@claravanstaden claravanstaden merged commit 53a5522 into main Jan 23, 2024
9 checks passed
@claravanstaden claravanstaden deleted the remove-minimal-spec branch January 23, 2024 11:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants