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.
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.
@Ayiga for your reference.
There was a problem hiding this comment.
What is the proposer id currently? Is it the HotShot leader id or the builder id?
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
tbro
force-pushed
the
tb/ver/multi-fees-per-block
branch
from
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).