-
Notifications
You must be signed in to change notification settings - Fork 180
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
[FVM] reducing register touches #2502
Conversation
FVM Benchstat comparisonThis branch with compared with the base branch onflow:master commit dc85e89 The command Bench tests were run a total of 7 times on each branch. Collapsed results for better readability
|
@@ -34,7 +34,7 @@ type Context struct { | |||
CadenceLoggingEnabled bool | |||
EventCollectionEnabled bool | |||
ServiceEventCollectionEnabled bool | |||
AccountFreezeAvailable bool | |||
AccountFreezeEnabled bool |
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.
renamed it to match other ones.
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 good, I just have some questions.
// all accounts provides enoguh weights | ||
// | ||
// if KeyWeightThreshold is set to a negative number, signature verification is skipped | ||
type TransactionVerifier struct { |
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.
Whats the benefit of merging all the checks into one processor?
I was thinking that the frozen checker could actually be run for all transactions in a block(chunk?) in parallel before any transaction invocation. This would only change the behaviour of the freeze so that it is valid only from the next block on, which I think would be acceptable.
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 think checking frozen accounts should happen at the time of the register reads, for example, we do have extra checks when a contract is going to load from an account that is not the authorizer of the tx but should still block that call, etc ...
maskExist byte = 0b0000_0001 | ||
maskFrozen byte = 0b1000_0000 |
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.
Instead of using enum style I did it mask style, cause if something gets frozen and unfrozen we can maintain future states for accounts, while maintaining frozen state
func keyPublicKey(index uint64) string { | ||
return fmt.Sprintf("public_key_%d", index) | ||
} | ||
|
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.
moved it to the end of file
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! I focused on changes with exists
and frozen
registers, and have one minor comment.
for _, authorizer := range tx.Authorizers { | ||
err := accounts.CheckAccountNotFrozen(authorizer) | ||
if err != nil { | ||
return fmt.Errorf("checking frozen account failed: %w", err) | ||
} | ||
} | ||
|
||
err := accounts.CheckAccountNotFrozen(tx.ProposalKey.Address) | ||
if err != nil { | ||
return fmt.Errorf("checking frozen account failed: %w", err) | ||
} | ||
|
||
err = accounts.CheckAccountNotFrozen(tx.Payer) | ||
if err != nil { | ||
return fmt.Errorf("checking frozen account failed: %w", err) | ||
} |
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.
Not sure if it's feasible, maybe we can batch read account status registers for multiple addresses and then check frozen status for all read registers.
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.
nice idea, though it requires way more changes as I don't think we can read batch of registers yet from inside the fvm yet. going to create a follow up PR to batch read in places that are possible.
bors merge |
2502: [FVM] reducing register touches r=ramtinms a=ramtinms This PR - merges `frozen` and `exists` register keys into a new register (AccountStatus) - adds a migration for ^ change - removes frozen enabling step as it's already covered inside transaction ENV dynamically. - moves remaining frozen checks into the tx verifier process (less allocation) - optimized getContract method call for happy path, so we don't need to load `contract_names` registers by default (this saves at least 4-5 register reads per tx) - removes old migration codes Co-authored-by: ramtinms <ramtin@axiomzen.co> Co-authored-by: Ramtin M. Seraj <ramtinms@users.noreply.github.com>
bors cancel |
Canceled. |
This PR
frozen
andexists
register keys into a new register (AccountStatus)contract_names
registers by default (this saves at least 4-5 register reads per tx)