Skip to content

Use StakeTableV2 and new events in the GCL #3289

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

Merged
merged 38 commits into from
May 28, 2025
Merged

Conversation

sveitser
Copy link
Collaborator

@sveitser sveitser commented May 19, 2025

  • Verify signatures on new events in GCL.
  • Deploy StakeTableV2
  • Allow CLI to register and update keys with both versions of the contract for backwards compat.
  • Run all stake table CLI tests against the V1 and V2 contract.

What's not done

There's currently no E2E test where we start on the original stake table and move to V2 and generate all the events for that. I think we can consider adding it but we are missing good testing infra for doing all of this, so I think it's better to work on this as a separate PR since this one is already much bigger than anticipated.


Base automatically changed from 3267-stake-table-v2 to main May 19, 2025 16:34
Using current jellyfish APIs it's not possible to construct the type
currently used. Since the contract doesn't need it we can send a bytes
type instead.
@sveitser sveitser force-pushed the ma/staking-cli-signatures branch from 7a67542 to c789fc2 Compare May 20, 2025 14:38

let stake_table_key: BLSPubKey = blsVK.clone().into();
let state_ver_key: SchnorrPubKey = schnorrVK.clone().into();
// TODO(MA): The stake table contract currently enforces that each bls key is only used once. We will
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Need to update this comment

Comment on lines +262 to +263
impl Serialize for ValidatorRegisteredV2 {
fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
Copy link
Contributor

Choose a reason for hiding this comment

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

why are we adding on this? so .abi_encode() is not sufficient?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We store the events locally in the DB for that I think they are wrapped into an enum.

#[derive(Clone, derive_more::From, PartialEq, serde::Serialize, serde::Deserialize)]
pub enum StakeTableEvent {
Register(ValidatorRegistered),
RegisterV2(ValidatorRegisteredV2),
Deregister(ValidatorExit),
Delegate(Delegated),
Undelegate(Undelegated),
KeyUpdate(ConsensusKeysUpdated),
KeyUpdateV2(ConsensusKeysUpdatedV2),
}

It would probably also work with abi_encode / decode but to change now we could have to migrate storage of any nodes that have this deployed already. We would still have to implement serde I think to work with our storage code.

Correct me if I'm wrong @imabdulbasit .

sveitser added 12 commits May 23, 2025 10:51
Foundry has a workaround for the lack of function overloading in rust
that leads to confusing function names in the bindings. Avoiding the
function name collison makes the workaround unnecessary.
- Add tests with V2 register and key update events.
- Fix bug where update keys does not check for key-reuse, with
  regression test.
- Make types a bit more convenient with From and Copy impls.
@sveitser sveitser changed the title WIP: use StakeTableV2 Use StakeTableV2 and new events in the GCL May 27, 2025
@sveitser sveitser marked this pull request as ready for review May 27, 2025 13:56
if bls_keys.contains(&stake_table_key) {
bail!("bls key {} already used", stake_table_key.to_string());
bail!("bls key already used: {}", stake_table_key.to_string());
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The diff is a bit misleading here. For the V1 there shouldn't be any changes other than doing the formatting for errors differently and removing some clones because some types are Copy now. I guess since the two branches for v1 and v2 are so similar the diff got cut in half.

Copy link
Contributor

@alysiahuggins alysiahuggins left a comment

Choose a reason for hiding this comment

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

lgtm with a few clarifying qs

BN254.G2Point blsVk,
EdOnBN254.EdOnBN254Point schnorrVk,
BN254.G2Point blsVK,
EdOnBN254.EdOnBN254Point schnorrVK,
uint16 commission,
BN254.G1Point blsSig,
Copy link
Contributor

Choose a reason for hiding this comment

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

since we made schnorrSig bytes, any chance it makes sense to do so for blsSig too? cc @alxiong

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I actually don't like to use Bytes (anymore) if we have a type of known size because it means we can't make the type Copy in rust.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

But IIRC we are missing some code so if we don't use bytes things would have gotten more complicated.

Copy link
Contributor

Choose a reason for hiding this comment

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

personally I like bytes because it's more future proof. but whenever we want to do something with these objects in the contract, we should consider giving them a concrete types.

In this case, we do verify the BLS signature, thus giving it a type is better IMO.

I hear Mathis's complain about no Copy for bytes, but my personal tolerance for Clone is higher and I can live with lots of .clone() everywhere, (clippy will inform us about unnecessary clone once alloy bindings decide to add Copy on them)

impl Copy for crate::sol_types::G1PointSol {}
impl Copy for crate::sol_types::G2PointSol {}
impl Copy for crate::sol_types::EdOnBN254PointSol {}
impl Copy for crate::sol_types::StakeTableV2::ValidatorRegistered {}
Copy link
Contributor

Choose a reason for hiding this comment

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

not totally sure but would this also need to be called ValidatorRegisteredV2?

Copy link
Collaborator Author

@sveitser sveitser May 27, 2025

Choose a reason for hiding this comment

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

No this is the the V1 event defined in the V2 abi. The rust code is now written to always use the V2 ABI/bindings (except for when deploying the original StakeTable contract) because the V2 ABI it's a superset of the V1 ABI. I think I left some comments about this in the stake table contract.

sigma: sigma_affine.into_group(),
}
};
if !bls_vk.validate(&sig, &msg) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I might have missed it but do we have a test for bls vk validation against its sigs?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

You mean unittests? I didn't add them because @alxiong wrote it, so it should be correct 😂 added some unittests here: 985ce8d

@@ -14,6 +14,7 @@ derive_more = { workspace = true }
espresso-types = { path = "../../../types" }
hotshot-contract-adapter = { workspace = true }
hotshot-types = { workspace = true }
sequencer-utils = { version = "0.1.0", path = "../../../utils" }
Copy link
Contributor

Choose a reason for hiding this comment

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

Only test-utils? So dev-dependency?

Comment on lines 20 to 21
#[case::v1(StakeTableContractVersion::V1)]
#[case::v2(StakeTableContractVersion::V1)]
Copy link
Contributor

Choose a reason for hiding this comment

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

Are they supposed to be the same?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

uff, no, thanks

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I haven't found a way to sort of "inherit" the test name from the struct. The test function name is more explicit if #[values] are used such as here:

#[rstest::rstest]
#[tokio::test]
async fn stake_for_demo_delegation_config_helper(
#[values(StakeTableContractVersion::V1, StakeTableContractVersion::V2)]
version: StakeTableContractVersion,
#[values(
DelegationConfig::EqualAmounts,
DelegationConfig::VariableAmounts,
DelegationConfig::MultipleDelegators
)]
config: DelegationConfig,
) -> Result<()> {

test stake_for_demo_delegation_config_helper::version_2_StakeTableContractVersion__V2::config_1_DelegationConfig__EqualAmounts ... ok
test stake_for_demo_delegation_config_helper::version_2_StakeTableContractVersion__V2::config_2_DelegationConfig__VariableAmounts ... ok
test stake_for_demo_delegation_config_helper::version_1_StakeTableContractVersion__V1::config_1_DelegationConfig__EqualAmounts ... ok
test stake_for_demo_delegation_config_helper::version_1_StakeTableContractVersion__V1::config_3_DelegationConfig__MultipleDelegators ... ok
test stake_for_demo_delegation_config_helper::version_2_StakeTableContractVersion__V2::config_3_DelegationConfig__MultipleDelegators ... ok

But for the applied template it just uses case_1 and case_2 by default.

@sveitser sveitser merged commit 21ff7c0 into main May 28, 2025
102 checks passed
@sveitser sveitser deleted the ma/staking-cli-signatures branch May 28, 2025 12:52
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