You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
pub enum Strategy {
EveryBlock,
Never,
/// Only writes for linked blocks - does a few more reads to save some writes.
/// Probably uses more gas, but less total disk usage.
///
/// Note that you need a trusted source (eg. own contract) to set/remove checkpoints.
/// Useful when the checkpoint setting happens in the same contract as the snapshotting.
Selected,
}
For the generic design, it was very unclear how to handle auth, so we just used EveryBlock, which is always correct even if less efficient.
As we have many voting contracts and sets in tgrade, it would make sense to looking into optimizing this. What do we need to use selected?
There are two functions add_checkpoint and remove_checkpoint which need to be exposed with some auth control. The voting contract should always call add_checkpoint at the current height when opening a vote. The voting_contract may also call remove_checkpoint when executing/closing a proposal... if no other proposals are on the same height (some sort of rc).
As we get a large space savings even if we never cleanup checkpoints (and even more if we do), we can look at registering the voting contract on the respective groups somehow on init. And later just all AddCheckpoint on proposal creation. That would be a good first step and verifying everything works (fuzzing it?) in odd conditions (multiple proposals on block, multiple closing in one transaction, etc)
The text was updated successfully, but these errors were encountered:
ethanfrey
changed the title
Only snapshot needed blocks for voting contracts
Only checkpoint required blocks for voting contracts
Feb 2, 2022
In SnapshotMap, we provide:
For the generic design, it was very unclear how to handle auth, so we just used EveryBlock, which is always correct even if less efficient.
As we have many voting contracts and sets in tgrade, it would make sense to looking into optimizing this. What do we need to use selected?
There are two functions
add_checkpoint
andremove_checkpoint
which need to be exposed with some auth control. The voting contract should always calladd_checkpoint
at the current height when opening a vote. The voting_contract may also callremove_checkpoint
when executing/closing a proposal... if no other proposals are on the same height (some sort of rc).As we get a large space savings even if we never cleanup checkpoints (and even more if we do), we can look at registering the voting contract on the respective groups somehow on init. And later just all
AddCheckpoint
on proposal creation. That would be a good first step and verifying everything works (fuzzing it?) in odd conditions (multiple proposals on block, multiple closing in one transaction, etc)The text was updated successfully, but these errors were encountered: