Open nventuro opened 6 months ago
Note that with https://github.com/AztecProtocol/aztec-packages/issues/5757 this would be a time of change, not block.
While nice (and necessary?) this makes the API a bit more involved (since users need to pass one extra param), so I think we can afford to not have this for now.
The introduction of SharedMutable in https://github.com/AztecProtocol/aztec-packages/pull/5490 does not alow to specify a block number when scheduling; it is automatically set to the current block number plus the delay. This is simpler and results in the lowest latency for the changes to go through, but there are very good reasons why applications may want to configure their block of change. Note that a configurable block of change would always have to be larger than the minimum one, which is the current plus delay.
When users interact with contracts that have scheduled changes, they leak some privacy by using the
max_block_number
property of their transaction. Recall that scheduled changes are public, so if e.g. only one contract has a scheduled value change at block X, then any transactions with amax_block_number
of X - 1 would be presumed to be interacting with said contract.In order to avoid this, applications may want to increase their privacy set by 'sharing' blocks of change, so that all applications would have scheduled value changes at the same block. There are some side effects to this, such as the fact that the network as a whole may see reduced activity right before the 'global' block of change, since people may not submit transactions out of worry that they won't get included in time. It is also possible that users that don't require a block of change parameter would choose to use this 'global' one to be part of this anonimity set.