You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is this task and why do we need to work on it?
We plan to enforce a base fee per byte. To do this, we need to know the size of the proposed payload during validation (also in Header::new where the fee info gets proposed). So we need to pass VidCommon into the block trait functions. This means that in the consensus task, we can't call validate_and_apply_header until we have received the VID dispersal, so that call would have to get moved into vote_if_able, which is a pretty significant logic change.
After the voting dependancies are collected we'll know that we have the VID information and can do all our validation. Also it will mean we won't be running the validated_and_apply_header logic which is blocking on the main consensus task.
As part of the refactoring efforts to the vote_if_able function, we need to support the ability to make this data available for calculation purposes.
What work will need to be done to complete this task?
No response
Are there any other details to include?
No response
What are the acceptance criteria to close this issue?
Tests to ensure that the requisite information is indeed available.
Branch work will be merged to (if not the default branch)
No response
The text was updated successfully, but these errors were encountered:
Ugh. I don't fully understand this issue but wonder whether it's related to EspressoSystems/jellyfish#561 (comment). Seems there are a few places where we need things like payload_byte_len or num_storage_nodes before we have a VidCommon to tell us these things.
What is this task and why do we need to work on it?
We plan to enforce a base fee per byte. To do this, we need to know the size of the proposed payload during validation (also in
Header::new
where the fee info gets proposed). So we need to passVidCommon
into the block trait functions. This means that in the consensus task, we can't callvalidate_and_apply_header
until we have received the VID dispersal, so that call would have to get moved intovote_if_able
, which is a pretty significant logic change.After the voting dependancies are collected we'll know that we have the VID information and can do all our validation. Also it will mean we won't be running the
validated_and_apply_header
logic which is blocking on the main consensus task.As part of the refactoring efforts to the
vote_if_able
function, we need to support the ability to make this data available for calculation purposes.What work will need to be done to complete this task?
No response
Are there any other details to include?
No response
What are the acceptance criteria to close this issue?
Tests to ensure that the requisite information is indeed available.
Branch work will be merged to (if not the default branch)
No response
The text was updated successfully, but these errors were encountered: