Closed tuxcanfly closed 9 months ago
The update introduces new constants for commit sizes and block encoding overhead in celestia.go
, refining the calculation of DefaultMaxBytes
and thus the MaxBlobSize
. This adjustment ensures more accurate data handling capacities. Correspondingly, celestia_test.go
sees a modification where a test now directly references DefaultMaxBytes
instead of an outdated constant, aligning the test assertions with the updated data size calculations.
Files | Change Summary |
---|---|
celestia/celestia.go ,celestia/.../celestia_test.go |
Added constants for commit sizes and block encoding overhead. Updated DefaultMaxBytes calculation.Updated test assertion to use DefaultMaxBytes directly, removing outdated constant reference. |
"In the realm of code, where bytes do flow,
A rabbit hopped, making changes glow.
Constants new, and sizes true,
🌟 In Celestia's skies, data anew."
- 🐰 CodeRabbit
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
6afe388
) 74.05% compared to head (8aa63af
) 74.05%.:exclamation: Current head 8aa63af differs from pull request most recent head 1a20032. Consider uploading reports for the commit 1a20032 to get more accurate results
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
OK, I dug pretty deep into this. I believe this is not the right fix because we're doing tx accounting overhead to the blob limit.
With some debugging I found instead that the issue is that transactions are accepted into the mempool, but they're not added to the block because of improper validation, I added some trace fmts to prepare_proposal.go
:
app.App.PrepareProposal: FilterTxs len(txs): 1
app.App.PrepareProposal: square.Build len(txs): 0
It seems that square.Build
has stricter conditions that everything else. It also silently ignores transactions it deems invalid. This causes the tx to stay in mempool and times out the DA submit transaction, leading to a cascade of errors. I believe the proper fix is in celestia-app/go-square
, but until then we can mitigate this by hardcoding the blob limit that it accepts.
Some more logging indicates that there is a worst case padding which might be missing from mempool inclusion checks:
7:00PM DBG inserted new (maybe) valid transaction height=3 num_txs=1 priority=2000 size=1962824 tx=DB4489C41BDFA0F3C47CC5F0354BD4B9CC62AF52EE13D9E17D99880E54F35411
in mempool.v1.TxMempool.ReapMaxBytesMaxGas
(maxGas: -1 >= 0 && totalGas: 0 + w.gasWanted: 16754612 > maxGas: -1) || (maxBytes: 1973430 >= 0 && totalBytes: 0 + txBytes: 1962828 > maxBytes: 1973430
state.BlockExecutor.CreateProposalBlock: ReapMaxBytesMaxGas txs: 1
in app.App.PrepareProposal
app.App.PrepareProposal: FilterTxs txs: 1
in square.newElement: len(blob.Data): 1962441; numShares: 4072
in square.Builder.AppendBlobTX loop: blobElements[idx].NumShares: 4072; blobElements[idx].PfbIndex: 0, blobElements[idx].BlobIndex: 0; blobElements[idx].MaxPadding: 63
in square.Builder.AppendBlobTx: pfbShareDiff: 1; maxBlobShareCount: 4135
in square.Builder.canFit: b.currentSize: 0; shareNum: 4136; b.maxCapacity: 4096
app.App.PrepareProposal: square.Build txs: 0
Overview
This PR fixes an issue with the
MaxBlobSize
API call. The current size doesn't account for padding shares.Checklist
Summary by CodeRabbit