-
Notifications
You must be signed in to change notification settings - Fork 10
feat: pass powertable to blobs actor #263
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
base: main
Are you sure you want to change the base?
Conversation
| let proposer = state.validator_id().map(|id| id.to_string()); | ||
| let proposer_ref = proposer.as_deref(); | ||
|
|
||
| let (_configuration_number, powers) = self.gateway_caller.current_power_table(&mut state)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it an okay place to call the actor?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, this is the right spot...
I wonder though, instead of re-fetching the full table, can you just send the validator_changes to the blob actor? they look like,
pub struct StakingChangeRequest {
pub configuration_number: ConfigurationNumber,
pub change: StakingChange,
}
I don't think we care about configuration_number in this context.
where StakingChange is,
pub struct StakingChange {
pub op: StakingOperation,
pub payload: Vec<u8>,
pub validator: Address,
}
payload can be ignored, which is the pubkey.
and StakingOperation is,
pub enum StakingOperation {
Deposit = 0,
Withdraw = 1,
SetMetadata = 2,
SetFederatedPower = 3,
}
I don't think we care about SetMetadata or SetFederatedPower. so you could filter those out of the changes.
The logic in the actor would reconcile the changes into an "accumulated" power table.
|
@sanderpick Please, have a look at this attempt to pass power table to the blobs actor. It is dirty, but should (probably) work. The biggest uncertainty is where to invoke the call. You definitely know better if "deliver" of |
sanderpick
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, left some comments
| let proposer = state.validator_id().map(|id| id.to_string()); | ||
| let proposer_ref = proposer.as_deref(); | ||
|
|
||
| let (_configuration_number, powers) = self.gateway_caller.current_power_table(&mut state)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, this is the right spot...
I wonder though, instead of re-fetching the full table, can you just send the validator_changes to the blob actor? they look like,
pub struct StakingChangeRequest {
pub configuration_number: ConfigurationNumber,
pub change: StakingChange,
}
I don't think we care about configuration_number in this context.
where StakingChange is,
pub struct StakingChange {
pub op: StakingOperation,
pub payload: Vec<u8>,
pub validator: Address,
}
payload can be ignored, which is the pubkey.
and StakingOperation is,
pub enum StakingOperation {
Deposit = 0,
Withdraw = 1,
SetMetadata = 2,
SetFederatedPower = 3,
}
I don't think we care about SetMetadata or SetFederatedPower. so you could filter those out of the changes.
The logic in the actor would reconcile the changes into an "accumulated" power table.
| let (mut state, out) = self.inner.end(state).await?; | ||
|
|
||
| // TODO SU Wrong | ||
| let a = self.gateway_caller.current_power_table(&mut state); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, not needed here
| }) | ||
| .await; | ||
|
|
||
| // TODO Continue update power table in blobs actor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not needed if doing in the txn deliver handler. this end block is where you'd update any off-chain components, like env.parent_finality_votes.
3b8a119 to
f5a3616
Compare
| .iter() | ||
| .filter_map(|validator| { | ||
| let public_key = validator.public_key.0.serialize(); | ||
| let address = Address::new_secp256k1(&public_key); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this address is going to be of the f1-style. the validators will be f410 style with a delegated ethereum addresses. ie, i don't think this format is what we want on-chain because we won't be able to allow claims using this address format. this is one reason why i was suggesting using the power table updates that come from top down messages, because they already include the correct validator address. that being said, I haven't had a chance to really look at this... I got sucked into CI fixes today. i'll take another look tomorrow... I think you could continue with next steps on top of this though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oop, I saw your slack thread with the IPC team... sounds like you're more informed than me on how to do this now. btw, we just merged the gas market actor to develop, so you could mimic / piggy back on that. though i don't see where the power table is stored in the new actor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I figured. There are few layers of indirection between a pub key and the address.
8ed1261 to
50f8498
Compare
|
I think I figured the addresses. Assumption: a validator uses the same (public) key for CometBFT consensus and for interaction with the chain. If the assumption is true, then we convert the CometBFT public key to ETH address, and then convert it into delegated address through EAM actor (i.e. actor id of the address manager who converts between the "external" address and an address internal to FVM, see FIP-48), where "payload" is eth address bytes. |
bfd316b to
f05c620
Compare
| checkpoint::maybe_create_checkpoint(&self.gateway, &mut state) | ||
| .context("failed to create checkpoint")? | ||
| { | ||
| let power_table = prepare_blobs_power_table(&updates); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a particular reason to execute this transaction in ExecInterpreter instead of ChainMessageInterpreter? I am asking because we have been generally putting all such changes where we have to execute implicit transaction in ChainMessageInterpreter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is just a place where updates are readily available. Other than that, no reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is, I am all right to move it there, according to the tradition, unless I find any insurmountable resistance on the code level. And, I'll tell you if that happens :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the clue!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good. i think, it would be easier to track changes that we have made in fendermint if they are all in the same place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@avichalp I believe now it belongs to the right place.
|
Oh, and converting to the draft, as it is not urgently needed. |
95f5b70 to
4031262
Compare
UPD after the comments and discussion with Will from IPC:
endblock ofExecInterpreter for FvmMessageInterpreter,StakingChangeorStakingOperation.