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

Update pallet-relayer to use Contraints V2 #433

Merged
merged 17 commits into from
Oct 24, 2023

Conversation

HCastano
Copy link
Collaborator

@HCastano HCastano commented Oct 17, 2023

This updates the Relayer pallet to use the new Contraints API.

I split this PR out from #428 since I figured it would be better to ensure
that the new flow was working first and then we could go ahead and get
rid of the old code.

@vercel
Copy link

vercel bot commented Oct 17, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
entropy-core ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 20, 2023 5:52pm

pallets/relayer/src/lib.rs Outdated Show resolved Hide resolved
/// Storage: Constraints AllowedToModifyConstraints (r:0 w:1)
/// Proof Skipped: Constraints AllowedToModifyConstraints (max_values: None, max_size: None, mode: Measured)
/// The range of component `c` is `[0, 2]`.
fn confirm_register_registered(_c: u32, ) -> Weight {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Don't know why c isn't used here anymore...I didn't touch these benches 🤔

@@ -59,13 +60,15 @@ impl<T: frame_system::Config> pallet_relayer::WeightInfo for WeightInfo<T> {
/// Storage: StakingExtension SigningGroups (r:1 w:0)
/// Proof Skipped: StakingExtension SigningGroups (max_values: None, max_size: None, mode: Measured)
/// The range of component `c` is `[0, 2]`.
fn confirm_register_registering(_c: u32, ) -> Weight {
fn confirm_register_registering(c: u32, ) -> Weight {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hmm but c is used in this bench...ya not sure what's going on here

Jesse suggested this hack...
@@ -461,7 +461,7 @@ async fn test_store_share() {
let alice_account_id: <EntropyConfig as Config>::AccountId = alice.to_account_id().into();
let registered_query = entropy::storage().relayer().registered(alice_account_id);
for _ in 0..10 {
std::thread::sleep(std::time::Duration::from_millis(500));
std::thread::sleep(std::time::Duration::from_millis(1000));
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@JesseAbram lol this actually fixed the CI 🙈

@HCastano HCastano marked this pull request as ready for review October 19, 2023 19:32
@HCastano HCastano requested a review from JesseAbram October 19, 2023 19:32
HCastano added a commit that referenced this pull request Oct 19, 2023
@HCastano HCastano requested a review from ameba23 October 19, 2023 20:51
HCastano added a commit that referenced this pull request Oct 20, 2023
* Remove `is_swapping` field from registration details

* Remove related benchmarking code

* Update node metadata

* Apply same sleep hack as in #433 🙈
(evm_acl_len, btc_acl_len) = ConstraintsPallet::<T>::constraint_weight_values(constraints);
}
<T as Config>::WeightInfo::register(evm_acl_len, btc_acl_len)
<T as Config>::WeightInfo::register(initial_program.len() as u32)
})]
pub fn register(
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
Contributor

Choose a reason for hiding this comment

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

this requires we pass an initial program at registration?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe (pending the discussion below), but mostly that there's a change in field names and the type of a program (Option vs. Vec<u8>).

Copy link
Contributor

@ameba23 ameba23 left a comment

Choose a reason for hiding this comment

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

This is perfect in a that it achieves exactly what it set out to do, replacing constraints v1 with program bytecode in the relayer pallet.

But it brings up a design decision which we need to be clear on. Is setting a program optional or required?

Previously we allowed Option<Constraints> and now we require a Vec<u8> but it may be invalid bytecode, eg: empty vector.

At the point of signing, a valid program is currently required. Our tests pass here even though we set an empty program when registering, because we update it with a valid one before signing.

Personally i think setting a program should be optional, but that we should be explicit and use Option<Vec<u8>>. If given, it should be a valid program.

I think we should merge this as it is for now though. Maybe i can make an issue about optional vs. required programs.

Copy link
Member

@JesseAbram JesseAbram left a comment

Choose a reason for hiding this comment

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

looks good just the one comment

&constraints,
);
}
ConstraintsPallet::<T>::set_program_unchecked(
Copy link
Member

Choose a reason for hiding this comment

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

I don't like using set unchecked, as in set program we charge a deposit for length of program, here I believe people can post an arbitrary sized program for free

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

From what I can tell this doesn't change the previous deposit/weight behaviour for this extrinsic.

So the user calling the register extrinsic does get charged by program length (before that was being done with the evm_acl and btc_alc related functions).

The validators never got charged this deposit since Constraints::set_constraints_unchecked() doesn't require a deposit, and the confirm_* weight functions don't account for this either.

If we do want to charge for this some questions come up:

  • Who pays for this?
    • In the current workflow it would seem like the validators would, although maybe want the sig_req_account to
  • Which pallet should handle this?
    • It should be the Constraints pallet imo, but it might make the workflow a bit trickier

And technically the wouldn't be arbitrarily length program, they can only go up to T::MaxV2BytecodeLength 😛

Copy link
Member

Choose a reason for hiding this comment

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

hmmmm ya that does need to be solved, but we can charge them the deposit in the register extrinsic and then ya do set unchecked later on

@HCastano
Copy link
Collaborator Author

But it brings up a design decision which we need to be clear on. Is setting a program optional or required?

Previously we allowed Option<Constraints> and now we require a Vec<u8> but it may be invalid bytecode, eg: empty vector.

My understanding here was that an empty program would be equivalent to having a None previously. This makes sense to me since you can still "run" an empty program, but it would just end up being a no-op (said another way, we can just go straight to signature generation).

At the point of signing, a valid program is currently required. Our tests pass here even though we set an empty program when registering, because we update it with a valid one before signing.

Can you point me to the checks were we validate a program? Like is an empty program considered invalid?

Personally i think setting a program should be optional, but that we should be explicit and use Option<Vec<u8>>. If given, it should be a valid program.

I thought about changing the type to an Option<Vec<u8>>, but then what would the difference between None and a Some(vec![]) be in this case?

I think we should merge this as it is for now though. Maybe i can make an issue about optional vs. required programs.

I'm okay discussing it here or in an issue. Maybe we can also get some feedback from @jakehemmerle.

@JesseAbram
Copy link
Member

I thought about changing the type to an Option<Vec<u8>>, but then what would the difference between None and a Some(vec![]) be in this case?

When reviewing I thought the same as first, but then I thought about it and you write can do the empty program is the same thing makes sense.

@ameba23
Copy link
Contributor

ameba23 commented Oct 23, 2023

I thought about changing the type to an Option<Vec<u8>>, but then what would the difference between None and a Some(vec![]) be in this case?

When reviewing I thought the same as first, but then I thought about it and you write can do the empty program is the same thing makes sense.

I just tried running the test with an empty program, and it is not a noop. runtime.evaluate returns an error InvalidByteCode. But we could make it that we only attempt to evaluate the program if the length is greater than zero.

@HCastano
Copy link
Collaborator Author

@ameba23 can you tell me what test you're trying to run specifically?

Maybe this is something that needs to be accounted for upstream in the constraints crate

@ameba23
Copy link
Contributor

ameba23 commented Oct 23, 2023

@ameba23 can you tell me what test you're trying to run specifically?

Maybe this is something that needs to be accounted for upstream in the constraints crate

async fn test_sign_tx_no_chain() {

@jakehemmerle
Copy link
Contributor

@HCastano

Programs can be optional; I think it's fine if users can register without requiring one.

@HCastano
Copy link
Collaborator Author

HCastano commented Oct 24, 2023

@JesseAbram do you mind if we merge this? I have another PR coming for the storage deposit fixes which I think would be better off standalone instead of being added here.

I'll also create an issue about running empty programs (edit: made entropyxyz/programs#36).

@HCastano HCastano merged commit 6c507dd into master Oct 24, 2023
5 checks passed
@HCastano HCastano deleted the hc-swap-relayer-to-constraints-v2 branch October 24, 2023 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants