Skip to content

Conversation

@ukstv
Copy link
Contributor

@ukstv ukstv commented Oct 16, 2024

UPD after the comments and discussion with Will from IPC:

  • send a tx to Blobs actor in the end block of ExecInterpreter for FvmMessageInterpreter,
  • send updates already prepared by the existing code (higher level than StakingChange or StakingOperation.

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)?;
Copy link
Contributor Author

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?

Copy link
Contributor

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.

@ukstv
Copy link
Contributor Author

ukstv commented Oct 16, 2024

@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 ExecInterpreter the right place.

Copy link
Contributor

@sanderpick sanderpick left a 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)?;
Copy link
Contributor

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);
Copy link
Contributor

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
Copy link
Contributor

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.

@ukstv ukstv force-pushed the su/pass-powertable-to-blobs-actor branch from 3b8a119 to f5a3616 Compare October 21, 2024 06:24
@ukstv ukstv changed the title Su/pass powertable to blobs actor feat: pass powertable to blobs actor Oct 21, 2024
@ukstv ukstv requested a review from sanderpick October 21, 2024 17:43
@ukstv ukstv marked this pull request as ready for review October 21, 2024 17:46
.iter()
.filter_map(|validator| {
let public_key = validator.public_key.0.serialize();
let address = Address::new_secp256k1(&public_key);
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@ukstv ukstv force-pushed the su/pass-powertable-to-blobs-actor branch from 8ed1261 to 50f8498 Compare October 25, 2024 16:15
@ukstv
Copy link
Contributor Author

ukstv commented Oct 28, 2024

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.

@ukstv ukstv force-pushed the su/pass-powertable-to-blobs-actor branch from bfd316b to f05c620 Compare October 29, 2024 12:14
checkpoint::maybe_create_checkpoint(&self.gateway, &mut state)
.context("failed to create checkpoint")?
{
let power_table = prepare_blobs_power_table(&updates);
Copy link
Collaborator

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.

Copy link
Contributor Author

@ukstv ukstv Oct 31, 2024

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.

Copy link
Contributor Author

@ukstv ukstv Oct 31, 2024

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 :)

Copy link
Contributor Author

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!

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

@ukstv ukstv marked this pull request as draft October 31, 2024 16:37
@ukstv
Copy link
Contributor Author

ukstv commented Oct 31, 2024

Oh, and converting to the draft, as it is not urgently needed.

@ukstv ukstv force-pushed the su/pass-powertable-to-blobs-actor branch from 95f5b70 to 4031262 Compare November 4, 2024 09:49
@sanderpick sanderpick added the archived Archived for now label Mar 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

archived Archived for now

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants