-
Notifications
You must be signed in to change notification settings - Fork 292
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
feat!: implement FillSquare
method for the testnode
#866
Conversation
Codecov Report
@@ Coverage Diff @@
## main #866 +/- ##
==========================================
+ Coverage 25.59% 25.75% +0.16%
==========================================
Files 75 75
Lines 9273 9287 +14
==========================================
+ Hits 2373 2392 +19
+ Misses 6677 6675 -2
+ Partials 223 220 -3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
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.
LGTM, only lefts comments to understand more
} | ||
maxShareCount := squareSize * squareSize | ||
// we use a formula to guarantee that the tx is the exact size needed to force a specific square size. | ||
msgSize := (maxShareCount - (2 * squareSize)) * appconsts.SparseShareContentSize |
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.
[Non Blocking][Question]
The (2 * squareSize)
refers to the size that the transaction will take, aside from the message?
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.
Assume squareSize=16
so maxShareCount=256
:
msgSize := (maxShareCount - (2 * squareSize)) * appconsts.SparseShareContentSize
msgSize := (256 - (2 * 16)) * appconsts.SparseShareContentSize
msgSize := (256 - 32) * appconsts.SparseShareContentSize
msgSize := (224) * appconsts.SparseShareContentSize
I don't think the transaction is guaranteed to take (2 * squareSize)
but I think it is an approximation for the other shares in the square (transactions, intermediate state roots, evidence).
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.
yeah, what Rootul said. In order to get the square size we want, we just have to make sure that we're using some number of share in between maxShareCount
and minShareCount
maxShareCount := squareSize * squareSize
minShareCount := maxShareCount / 2
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.
Thanks a lot for your help 🙏
I think it is an approximation for the other shares in the square (transactions, intermediate state roots, evidence).
Another question, are ISRs and evidence currently added to blocks?
minShareCount := maxShareCount / 2
Why is that? is it to accommodate ISRs and evidence?
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.
🚀 you're a beast, great work!
|
||
// FillBlock creates and submits a single transaction that is large enough to | ||
// create a square of the desired size. broadcast mode indicates if the tx | ||
// should be submitted async, sync, or block. (see flags.BroadcastModeSync). If |
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.
[question] should this be flags.BroadcastMode
per https://github.com/cosmos/cosmos-sdk/blob/7781cdb3d20bc7ebac017452897ce1e6ab3903ef/client/flags/flags.go#L114
// should be submitted async, sync, or block. (see flags.BroadcastModeSync). If | |
// should be submitted async, sync, or block (see flags.BroadcastMode). If |
Note: block
mode was removed in cosmos/cosmos-sdk#12659. Since celestia-app currently uses cosmos-sdk v0.46.0 we can still use block
here but note to future selves that we'll need to remove it when we upgrade cosmos-sdk to a release with that change
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.
yeah, blocking is just convenient atm and we will have to fix this in the future across the board.
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.
} | ||
maxShareCount := squareSize * squareSize | ||
// we use a formula to guarantee that the tx is the exact size needed to force a specific square size. | ||
msgSize := (maxShareCount - (2 * squareSize)) * appconsts.SparseShareContentSize |
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.
Assume squareSize=16
so maxShareCount=256
:
msgSize := (maxShareCount - (2 * squareSize)) * appconsts.SparseShareContentSize
msgSize := (256 - (2 * 16)) * appconsts.SparseShareContentSize
msgSize := (256 - 32) * appconsts.SparseShareContentSize
msgSize := (224) * appconsts.SparseShareContentSize
I don't think the transaction is guaranteed to take (2 * squareSize)
but I think it is an approximation for the other shares in the square (transactions, intermediate state roots, evidence).
testutil/testnode/full_node_test.go
Outdated
func (s *IntegrationTestSuite) Test_FillBlock() { | ||
require := s.Require() | ||
|
||
for squareSize := 16; squareSize < appconsts.MaxSquareSize; squareSize *= 2 { |
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.
[question] out of curiosity, why start squareSize at 16? My guess is that the estimation logic for non message-shares may break for squareSizes < 16
.
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.
good catch, that was a remnant of the old implementation.
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.
also #867
Co-authored-by: CHAMI Rachid <chamirachid1@gmail.com>
Co-authored-by: Rootul P <rootulp@gmail.com>
…ledger-app into evan/implement-fillnode
we should cut a release for v0.7.0 after merging this imo |
This PR - adds a modified FillSquare method for the testnode that only submits a single large message - modifies the default configs for a testnode's mempool to accept large transactions - modifies the `PostData` method to accept a flag that determines if the process blocks The issue with the old approach was that it was submitting too many transactions for a block with such short block times. The testnode was unlikely to get all of the transactions included in a single block, particularly when waiting to submit each transaction until the previous one was accepted into the mempool. Co-authored-by: CHAMI Rachid <chamirachid1@gmail.com> Co-authored-by: Rootul P <rootulp@gmail.com>
This PR
PostData
method to accept a flag that determines if the process blocksThe issue with the old approach was that it was submitting too many transactions for a block with such short block times. The testnode was unlikely to get all of the transactions included in a single block, particularly when waiting to submit each transaction until the previous one was accepted into the mempool.