Replies: 6 comments
-
There is good reason to also separately bound the number of shares available to use for paying for messages, and all other requests with a reserved namespace ID: it avoids the two sharing a fee market. |
Beta Was this translation helpful? Give feedback.
-
This was implemented when we added a max square size, and will be turned into a configurable parameter when we do #183 |
Beta Was this translation helpful? Give feedback.
-
I think I read this too quickly when closing, we still need to implement this |
Beta Was this translation helpful? Give feedback.
-
If transactions have a different fee market then we may consider adopting a sparse share scheme for transaction shares (initially proposed in #1040). The rationale is that it isn't possible to determine exactly how many shares a PFB will occupy when using a compact share scheme. In order to meter a PFB for the number of shares they occupy, we would have to round up to the worst case number of shares. If transaction shares used a sparse share scheme, they could be metered based on the exact number of shares they occupy (similar to how blob shares are metered after #431). Note: we could still have a separate fee market and meter transactions based on number of bytes rather than number of shares. |
Beta Was this translation helpful? Give feedback.
-
Hmmm. Fee markets don't necessarily have to be played out entirely in-protocol. Ultimately, it's up to the block producers how they calculate priority. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
The number of shares used for transactions, intermediate state roots, evidence, etc. should be bounded by some parameter. Otherwise, a malicious validator could create a maximum-size block filled with only transactions, and all full node would be required to fully download and process the block to compute the state.
Beta Was this translation helpful? Give feedback.
All reactions