-
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] merge constant size account registers in account status #2799
Conversation
…thub.com:onflow/flow-go into ramtin/fvm-remove-legacy-controller-from-storage
…thub.com:onflow/flow-go into ramtin/fvm-remove-legacy-controller-from-storage
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 great! 👍 Just some minor comments.
fvm/state/accounts_status.go
Outdated
|
||
const ( | ||
maskExist byte = 0b0000_0001 | ||
maskFrozen byte = 0b1000_0000 | ||
) | ||
|
||
// NewAccountStatus sets exist flag and return an AccountStatus |
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 we can remove exist flag from the comment because it isn't used anymore.
// NewAccountStatus sets exist flag and return an AccountStatus | |
// NewAccountStatus returns a new AccountStatus |
fvm/state/accounts_status.go
Outdated
|
||
// SetStorageUsed updates the storage used by the account | ||
func (a AccountStatus) SetStorageUsed(used uint64) { | ||
binary.BigEndian.PutUint64(a[storageUsedStartIndex:storageIndexStartIndex], used) |
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.
Maybe something like this could be less dependent on element sequence.
binary.BigEndian.PutUint64(a[storageUsedStartIndex:storageIndexStartIndex], used) | |
binary.BigEndian.PutUint64(a[storageUsedStartIndex:storageUsedStartIndex+storageUsedSize], used) |
fvm/state/accounts_status.go
Outdated
} | ||
return AccountStatus(uint8(inp) & (0xFF - maskFrozen)) | ||
a[0] = a[0] & (0xFF - maskFrozen) |
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.
See comment above.
a[0] = a[0] & (0xFF - maskFrozen) | |
a[flagIndex] = a[flagIndex] & (0xFF - maskFrozen) |
@ramtinms after you mentioned slice vs array idea today, I looked into trade-off between The performance and allocations are similar if:
The benefit of using array is to prevent creating
To be safer, I think we can use array as |
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 to me (besides the things that Faye mentioned).
I am slightly concerned with the introduction of a MaxPublicKeyCount
. Its definitely nice to have this control if we need it, but if we choose to use it we should be aware that keys cannot currently be removed, only revoked, which means that we need to know how we are going to help accounts that have Max-1 revoked keys, 1 good key and they want to switch that last key with a different one.
Codecov Report
@@ Coverage Diff @@
## master #2799 +/- ##
==========================================
- Coverage 56.32% 56.24% -0.09%
==========================================
Files 684 690 +6
Lines 63047 63587 +540
==========================================
+ Hits 35512 35762 +250
- Misses 24520 24800 +280
- Partials 3015 3025 +10
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
@janezpodhostnik I kept MaxPublicKeyCount and set it to maxUint64 to prevent overflowing for now and added to the TPM agenda if we want to have any lower value or concerns we have about it. |
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 work! Just a couple more minor comments.
copy(as[:], inp) | ||
return &as, nil |
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.
Maybe we can avoid making a copy by using input's underlying array. And we don't need as
created earlier.
copy(as[:], inp) | |
return &as, nil | |
return (*AccountStatusArray)(inp), nil |
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 not sure, I was worried we might update the registers directly in this case and if we get rid of deep copy feature of ledger we might have some issues? what do you think ? or we could reuse but copy on updates
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 worried we might update the registers directly in this case
I think it's OK if AccountStatusFromBytes
is only called to create account status by reading:
- payload value from mtrie, or
- cached payload value, previously retrieved from mtrie.
Because a copy of payload value is returned from mtrie, I think we update the copy.
if we get rid of deep copy feature of DB we might have some issues
Yes but getting rid of deep copy of the payload value can be problematic even without this change. I think it would be safer to get rid of deep copy of the payload key.
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.
Another case I'm still not sure, is the case we rollback, we drop the delta but the underlying read cache on view is invalid.
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.
let's keep this optimization for another PR when we revisit all allocations and possible ways to not copy or deep copy.
…onflow/flow-go into ramtin/fvm-merge-account-meta-registers
This PR
storage_used
,storage_index
, andpublic_key_count
into the account status register, which reduces about 30M registers from the Mainnet and reduces proof sizes accordinglyfrozen
andexists
registers