Skip to content
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: use square size params #1126

Closed

Conversation

rahulghangas
Copy link
Contributor

@rahulghangas rahulghangas commented Dec 15, 2022

Removes dependence of appconsts.DefaultMinSquareSize and appconsts.DefaultMaxSquareSize and instead fetches the relevant params from the blob keeper during process proposal

  • remove usage of default values
  • testing

app/prepare_proposal.go Show resolved Hide resolved
app/prepare_proposal.go Show resolved Hide resolved
@evan-forbes evan-forbes added block validity rule consensus breaking modifies block validity rules in a way that will break consensus unless all nodes update their rules labels Dec 15, 2022
@evan-forbes evan-forbes added this to the Incentivized Testnet milestone Dec 15, 2022
Copy link
Contributor

@cmwaters cmwaters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Just have a few trivial comments.

A slightly adjacent question I have with these upper and lower square size bounds is how are they initially calculated and how do we know when it's time to change them?

app/prepare_proposal.go Show resolved Hide resolved
Comment on lines 47 to 56
func ExtendShares(squareSize uint64, shares [][]byte, minSquareSize, maxSquareSize uint64) (*rsmt2d.ExtendedDataSquare, error) {
// Check that square size is with range
if squareSize < appconsts.DefaultMinSquareSize || squareSize > appconsts.DefaultMaxSquareSize {
if squareSize < minSquareSize || squareSize > maxSquareSize {
return nil, fmt.Errorf(
"invalid square size: min %d max %d provided %d",
appconsts.DefaultMinSquareSize,
appconsts.DefaultMaxSquareSize,
minSquareSize,
maxSquareSize,
squareSize,
)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a thought here, but I feel like verification of the square size and extending the shares should be two separate functions. In PrepareProposal, estimateSquareSize already guarantees that the square size is within the expected range.

Also the comparison of squareSize*squareSize == len(shares) should probably be done in ComputeExtendedDataSquare.

pkg/da/data_availability_header.go Outdated Show resolved Hide resolved
Copy link
Collaborator

@rootulp rootulp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[question] why aren't unit tests running on CI for this PR? I checked it out locally and I'm observing a test failure

--- FAIL: TestBlobInclusionCheck (0.03s)
    /Users/rootulp/git/rootulp/celestia/celestia-app/app/test/process_proposal_test.go:124: 
        	Error Trace:	/Users/rootulp/git/rootulp/celestia/celestia-app/app/test/process_proposal_test.go:124
        	Error:      	Not equal: 
        	            	expected: 1
        	            	actual  : 2
        	Test:       	TestBlobInclusionCheck
        	Messages:   	valid untouched data
FAIL
FAIL	github.com/celestiaorg/celestia-app/app/test	0.534s
FAIL

app/estimate_square_size.go Outdated Show resolved Hide resolved
app/estimate_square_size.go Outdated Show resolved Hide resolved
app/process_proposal.go Show resolved Hide resolved
Copy link
Collaborator

@rootulp rootulp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have any blocking feedback but there is one unresolved blocking question on this PR: https://github.com/celestiaorg/celestia-app/pull/1126/files#r1049690184 so holding off on approval

app/test/process_proposal_test.go Show resolved Hide resolved
Comment on lines +25 to +27
if ctx.BlockHeader().Height < 1 {
return appconsts.DefaultMinSquareSize
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[non blocking question] sorry I'm not familiar with defining genesis params. Is there a way to define the DefaultMinSquareSize param at chain genesis time so that we don't need this conditional?

If it isn't possible, why is a similar conditional not needed for the GasPerBlobByte param later in this file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We ran into this today. Apparently the genesis params aren't set until the first block is committed. We added this check to min/max square size only because those two are queried in prepare/process proposal.

p.s. surprisingly it wasn't panicking (at the first block) on being unable to unmarshal nil byte slices to relevant values, but rather just blocking forever

Copy link
Member

@evan-forbes evan-forbes Dec 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to document this at least in the code, and then we might even want to document it elsewhere (but am unsure where)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible for someone to include a payForBlob in the first block of the chain? It seems unlikely but if yes, would GasPerBlobByte also need to be initialized?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's a good point, I don't think so, as the params are used in many places, but I'm not sure of what is done to make that the case! perhaps we can do that process a bit earlier, so that it works for processproposal, which would almost certainly be a better solution

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently the genesis params aren't set until the first block is committed

This seems odd. You should be able to set params in genesis that can be used for the first block.

@codecov-commenter
Copy link

codecov-commenter commented Dec 20, 2022

Codecov Report

Merging #1126 (0a296c1) into main (c16d6e7) will decrease coverage by 0.08%.
The diff coverage is 54.38%.

@@            Coverage Diff             @@
##             main    #1126      +/-   ##
==========================================
- Coverage   47.98%   47.90%   -0.09%     
==========================================
  Files          71       71              
  Lines        3995     4025      +30     
==========================================
+ Hits         1917     1928      +11     
- Misses       1909     1927      +18     
- Partials      169      170       +1     
Impacted Files Coverage Δ
app/prepare_proposal.go 0.00% <0.00%> (ø)
app/process_proposal.go 0.00% <0.00%> (ø)
app/estimate_square_size.go 90.00% <62.50%> (-5.75%) ⬇️
pkg/da/data_availability_header.go 78.50% <100.00%> (-1.15%) ⬇️
pkg/shares/share_splitting.go 73.56% <100.00%> (+13.33%) ⬆️
x/blob/keeper/params.go 85.18% <100.00%> (-14.82%) ⬇️
x/blob/types/payforblob.go 80.35% <100.00%> (ø)
pkg/shares/parse_sparse_shares.go 68.96% <0.00%> (-14.12%) ⬇️
pkg/shares/shares.go 87.83% <0.00%> (-9.09%) ⬇️
... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@rahulghangas
Copy link
Contributor Author

I'm going to create an issue on the cosmos-sdk repository to get their opinion

@rahulghangas rahulghangas enabled auto-merge (squash) December 21, 2022 07:25
Comment on lines +25 to +27
if ctx.BlockHeader().Height < 1 {
return appconsts.DefaultMinSquareSize
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently the genesis params aren't set until the first block is committed

This seems odd. You should be able to set params in genesis that can be used for the first block.

@@ -21,12 +22,22 @@ func (k Keeper) SetParams(ctx sdk.Context, params types.Params) {

// MinSquareSize returns the MinSquareSize param
func (k Keeper) MinSquareSize(ctx sdk.Context) (res uint32) {
// use the default size for the first block so that we return a value on the
// first block in PrepareProposal
if ctx.BlockHeader().Height < 1 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure the first block is at height 1 not 0. Also we should be using something like InitialHeight as it's possible with Tendermint chains to start at any height.

Most importantly, I'm still not sure if this logic is necessary. At least I haven't seen this in other SDK modules.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure either. However, with this logic removed, prepare proposal (where the params are fetched for the first time) blocks and using the cli to query the params panics with an error

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

chain logs

5:47PM INF Timed out dur=10000 height=1 module=consensus round=0 step=3
5:47PM INF Ensure peers module=pex numDialing=0 numInPeers=0 numOutPeers=0 numToDial=10
5:47PM INF No addresses to dial. Falling back to seeds module=pex
5:48PM INF Ensure peers module=pex numDialing=0 numInPeers=0 numOutPeers=0 numToDial=10
5:48PM INF No addresses to dial. Falling back to seeds module=pex

using celestia-appd query blob params results in

Error: rpc error: code = Unknown desc = UnmarshalJSON cannot decode empty bytes: panic

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. Maybe you're right. I'd have thought the genesis params would be set at InitChain which comes before PrepareProposal but maybe I'm wrong.

What you could also do is add a log for when the params first get set in the Keeper and we can see if that comes before the first block gets proposed. Also wouldn't this panic you're seeing also happen in PrepareProposal?

@evan-forbes
Copy link
Member

it looks like others have ran into this issue as well
cosmos/cosmos-sdk#14446

@facundomedica
Copy link

facundomedica commented Jan 5, 2023

This might be a fix for this: cosmos/cosmos-sdk#14505 would love to get some more eyes on it.

  • The height in PrepareProposal was always currentHeight-1. Now that's fixed, PrepareProposal can't be called with height < 1.
  • The state from InitChain/Genesis wasn't accesible by PrepareProposal/ProcessProposal. That's also fixed, so you should be able to get params safely.

EDIT: Didn't mean "this" as the PR but as the problems pointed out in the comments. Feel free to ping me

@cmwaters
Copy link
Contributor

Is there any update on this PR?

Can we either use the hack where we use the default size for the first block or we cherry-pick the commit that facundo did.

@evan-forbes
Copy link
Member

I think the decision was to not pursue this change, so I think we can close this issue and PR.

IIRC, the reasoning was that while we want something like BlockSize (determined in MB), we don't want to expose square sizes as those are more complex internal params. We'd also still have a "HardMaxSquareSize", that we'd have to hardfork to change, so it seems a bit extra to have a blocksize param along with a max square size param along with a hard max square size

@cmwaters
Copy link
Contributor

In that case can we look to either increase the current max square size from 128 to 256 i.e. 32MB square size or reduce DefaultMaxBlockBytes to 4MB. What I'm trying to get at is that the ceiling in terms of size should be something we control (i.e. MaxBlockBytes) and not something we don't (i.e. MaxSquareSize)

@evan-forbes
Copy link
Member

closing since we're simply using the existing block size limits in tendermint

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consensus breaking modifies block validity rules in a way that will break consensus unless all nodes update their rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants