-
Notifications
You must be signed in to change notification settings - Fork 493
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
V31 consensus upgrade #3553
V31 consensus upgrade #3553
Conversation
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.
Four more requests here:
- Don't forget to update ConsensusCurrentVersion to ConsensusV30
- Add v30.ApprovedUpgrades[protocol.ConsensusV31] = 140000
- Add v31.RewardsCalculationFix to true ( and remove from vFuture )
- Add v31.MaxProposedExpiredOnlineAccounts to 32 ( and remove from vFuture )
Codecov Report
@@ Coverage Diff @@
## master #3553 +/- ##
==========================================
+ Coverage 47.74% 47.77% +0.02%
==========================================
Files 370 370
Lines 60262 60266 +4
==========================================
+ Hits 28773 28790 +17
+ Misses 28183 28170 -13
Partials 3306 3306
Continue to review full report at Codecov.
|
Co-authored-by: Pavel Zbitskiy <[email protected]>
looks good, thanks for the changes.
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.
Looks ok from AVM 1.1 perspective. My other comments are very minor.
@@ -76,7 +76,7 @@ func testExpirationAccounts(t *testing.T, fixture *fixtures.RestClientFixture, f | |||
_, currentRound := fixture.GetBalanceAndRound(richAccount) | |||
// account adds part key | |||
partKeyFirstValid := uint64(0) | |||
partKeyValidityPeriod := uint64(150) | |||
partKeyValidityPeriod := uint64(150) // TODO: maybe increase? |
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.
What are the units? I would have guessed rounds, but that would be very short.
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.
Yes they are rounds and it is very short, maybe we should put 1000-3000 there instead, as no State Proof keys will be generated for such a short interval.
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.
I've added some minor fixes here: id-ms#15
@@ -76,7 +76,7 @@ func testExpirationAccounts(t *testing.T, fixture *fixtures.RestClientFixture, f | |||
_, currentRound := fixture.GetBalanceAndRound(richAccount) | |||
// account adds part key | |||
partKeyFirstValid := uint64(0) | |||
partKeyValidityPeriod := uint64(150) | |||
partKeyValidityPeriod := uint64(150) // TODO: maybe increase? |
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.
Yes they are rounds and it is very short, maybe we should put 1000-3000 there instead, as no State Proof keys will be generated for such a short interval.
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 FYI, didn't update a few references to ConsensusFuture - quick find in IDE will turn some up.
participationRegistry_test.go
accountdb_test.go
I'm opening an issue for the general case - we should have a single approach to referencing the ConsensusParams protocol inclusive of current+future that does not have to change when we bump the version.
v31.EnableStateProofKeyregCheck = true | ||
|
||
// Maximum validity period for key registration, to prevent generating too many StateProof keys | ||
v31.MaxKeyregValidPeriod = 256*(1<<16) - 1 |
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.
I was about to ask some questions about the numbers going into this formula, seems like intent is to address this in a follow on issue: #3257 cc @algonautshant
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.
The assumption is that the source of the truth is here: v31.MaxKeyregValidPeriod = 256*(1<<16) - 1
Anywhere else should be referencing this parameter.
The issue in #3257 is to make sure this variable is used for testing (instead of hardcoding the same value elsewhere), and fix the package dependency issue.
This is not a blocking issue.
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.
MaxKeyregValidPeriod
combines 256 and 16, which are based on two different limits.
for example:
merklearray/merkle.go: MaxEncodedTreeDepth = 16
@@ -590,6 +594,7 @@ func TestAccountParticipationInfo(t *testing.T) { | |||
a.Equal(uint64(firstRound), account.Participation.VoteFirst, "API must print correct first participation round") | |||
a.Equal(uint64(lastRound), account.Participation.VoteLast, "API must print correct last participation round") | |||
a.Equal(dilution, account.Participation.VoteKeyDilution, "API must print correct key dilution") | |||
// TODO: should we update the v1 API to support state proof? Currently it does not return this field. |
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.
@tsachiherman did we already address this?
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.
I copied this comment from @Aharonee 's PR, but I believe that the answer is no, and I think it's fine. We want to avoid updating the v1 endpoint any further.
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.
agreed, if we are using v1 somewhere internally that needs it, we should just convert it to using v2 instead
@gmalouf If you're referring to data/account/participationRegistry_test.go:45 then it should remain In ledger/accountdb_test.go:293 the |
@Aharonee I agree with @gmalouf here; the proper way to test this before the protocol is created is to take an existing protocol version, and "add" the needed flags to its parameters in order to test using a custom protocol. I know that this might mean slightly more work, but it's the "cleaner" way to accomplish that. It also means that there won't be any changes when we apply new protocol version. |
Right, I was suggesting a reference to constants articulating what those
limits source from would be ideal.
…On Thu, Feb 10, 2022 at 4:10 PM Shant Karakashian ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In config/consensus.go
<#3553 (comment)>:
> + v31 := v30
+ v31.ApprovedUpgrades = map[protocol.ConsensusVersion]uint64{}
+ v31.EnableBatchVerification = true
+ v31.RewardsCalculationFix = true
+ v31.MaxProposedExpiredOnlineAccounts = 32
+
+ // Enable TEAL 6 / AVM 1.1
+ v31.LogicSigVersion = 6
+ v31.EnableInnerTransactionPooling = true
+ v31.IsolateClearState = true
+
+ // stat proof key registration
+ v31.EnableStateProofKeyregCheck = true
+
+ // Maximum validity period for key registration, to prevent generating too many StateProof keys
+ v31.MaxKeyregValidPeriod = 256*(1<<16) - 1
MaxKeyregValidPeriod combines 256 and 16, which are based on two
different limits.
for example:
merklearray/merkle.go: MaxEncodedTreeDepth = 16
—
Reply to this email directly, view it on GitHub
<#3553 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHP3U7U4DCVPZZOHKXIDI3U2QSTHANCNFSM5NMQONXQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Summary
Create an update path that would enable the following features:
NextRewardsState()
#3403)Test Plan
Unit tests added.