-
Notifications
You must be signed in to change notification settings - Fork 85
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
multi fees per block (versioned) #1659
Conversation
This will make it easier to keep a somewhat consistent Rust API even as we add or change various fields in the underlying representation of the header.
@@ -592,6 +604,7 @@ impl ExplorerHeader<SeqTypes> for Header { | |||
type ProposerId = FeeAccount; | |||
type NamespaceId = NamespaceId; | |||
|
|||
// TODO what are these expected values w/ multiple Fees |
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.
How do we determine proposer_id
w/ multiple Fees? Can this be resolved in block explorer by propagating the Vec
upward?
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.
@Ayiga for your reference.
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.
What is the proposer id currently? Is it the HotShot leader id or the builder id?
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.
Here they are taking the account field of FeeInfo
(builder account) for use as proposer id. Which I think makes sense in the case of the single fee (since that is the account paying the fee). With multiple fees not sure how this would work.
types/src/v0/header.rs
Outdated
fee_info: vec![fee_info], | ||
builder_signature: vec![builder_signature], |
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.
Since we now have multiple builders, would it make sense to make the builder signature part of the fee info type?
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.
There is discussion around this on zulip: https://espresso.zulipchat.com/#narrow/stream/440749-Marketplace/topic/Multiple.20fees.20per.20block/near/448326448
pub fn fee_info(&self) -> Vec<FeeInfo> { | ||
match self { | ||
Self::V1(fields) => vec![fields.fee_info], | ||
Self::V2(fields) => vec![fields.fee_info], | ||
Self::V3(fields) => fields.fee_info.clone(), | ||
} |
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.
We need some way to distinguish bid fees from sequencing fees, likely using an enum. I'm not sure where the best place to put this information is, but it needs to go somewhere :)
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 discussion addresses this.
@@ -592,6 +604,7 @@ impl ExplorerHeader<SeqTypes> for Header { | |||
type ProposerId = FeeAccount; | |||
type NamespaceId = NamespaceId; | |||
|
|||
// TODO what are these expected values w/ multiple Fees |
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.
What is the proposer id currently? Is it the HotShot leader id or the builder id?
still need to update logic where FeeInfo is used in validation
revert the iterable `FeeInfo`. Currently the compiler is unaware of header version in `validate_builder_fee` causing compile errors.
Note that upstream changes to BuilderSignature trait are required in order for this to compile. Or, we *could* simply bypass the trait.
ec7f564
to
0867660
Compare
`Vec<FeeInfo>::amount()` will return `None` if any FeeAmount is out of range or if the sum total of the amounts is out of range. So this commit updates varient name and `Display` impl to better reflect that.
As yet un tested
Except arguments passed to builder signature (waiting on hotshot). Also move `IterableFeeInfo` trait to types.
some lints
The absence of a builder signature can be represented as an empty array.
Superseded by #1696 |
Re-working multi-fees-per block to account for versioning (#1637).