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
Copy file name to clipboardExpand all lines: docs/docs/developers/guides/smart_contracts/how_to_define_storage.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -415,7 +415,7 @@ While `DelayedPublicMutable` state variables are much less leaky than the assert
415
415
416
416
### Choosing Delays
417
417
418
-
The `include_by_timestamp` transaction property will be set to a value close to the current timestamp plus the duration of the delay in seconds. The exact value depends on the historical block over which the private proof is constructed. For example, if current timestamp is `X` and a `DelayedPublicMutable` state variable has a delay of 3000 seconds, then transactions that read this value privately will set `include_by_timestamp` to a value close to 'X + 3000' (clients building proofs on older state will select a lower `include_by_timestamp`).
418
+
The `include_by_timestamp` transaction property will be set to a value close to the current timestamp plus the duration of the delay in seconds. The exact value depends on the anchor block over which the private proof is constructed. For example, if current timestamp is `X` and a `DelayedPublicMutable` state variable has a delay of 3000 seconds, then transactions that read this value privately will set `include_by_timestamp` to a value close to 'X + 3000' (clients building proofs on older state will select a lower `include_by_timestamp`).
419
419
420
420
These delays can be changed during the contract lifetime as the application's needs evolve.
Copy file name to clipboardExpand all lines: docs/docs/migration_notes.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,6 +49,16 @@ As we prepare for a bigger `Wallet` interface refactor and the upcoming `WalletS
49
49
50
50
## [Aztec.nr]
51
51
52
+
### Historical block renamed as anchor block
53
+
54
+
A historical block term has been used as a term that denotes the block against which a private part of a tx has been executed.
55
+
This name is ambiguous and for this reason we've introduce "anchor block".
56
+
This naming change resulted in quite a few changes and if you've access private context's or utility context's block header you will need to update your code:
Copy file name to clipboardExpand all lines: docs/docs/protocol-specs/transactions/validity.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ Mike review: If we have written definitions for the various kinds of "`data`" de
13
13
-**Proof is valid**: The `proof` for the given public `data` should be valid according to a protocol-wide verification key for the final private kernel circuit.
14
14
-**No duplicate nullifiers**: No `nullifier` in the transaction `data` should be already present in the nullifier tree.
15
15
-**No pending private function calls**: The `data` private call stack should be empty.
16
-
-**Valid historic data**: The tree roots in the block header of `data` must match the tree roots of a historical block in the chain.
16
+
-**Valid anchor data**: The tree roots in the block header of `data` must match the tree roots of an anchor block in the chain.
17
17
-**Maximum block number not exceeded**: The transaction must be included in a block with height no greater than the value specified in `maxBlockNum` within the transaction's `data`.
18
18
-**Preimages must match commitments in `data`**: The expanded fields in the transaction object should match the commitments (hashes) to them in the public `data`.
19
19
- The `encryptedLogs` should match the `encryptedLogsHash` and `encryptedLogPreimagesLength` in the transaction `data`.
0 commit comments