This tracking issue lays out the high-level overview of the solution,
but redirects more detailed views to its individual issues if required.
Originally discussed in https://hackmd.io/_UnW4qCUTlSQh5RBkRHY4Q
Smart contracts have access to several global functions that reflect the state of the blockchain (like what is the current block or chain ID) or give additional context about the current transaction (like who is the transaction sender).
This doc takes inspiration from Etheruem to discuss what global methods Aztec should support from Noir and if both in public and private functions.
The issue lists each of Ethereum’s global variables/functions relating to a block or the current transaction and discuss why they are useful and if it is required for Aztec. The individual issues will expand on how it can be supported, especially in the context of private execution which only have access to historic data. You can read more on the restrictuion here but the TL;DR is this prevents race conditions for private transactions, where the user generates proofs locally on their browser, much before the time of inclusion, and therefore doesn’t know about the current chain.
For structure, we will list the short term first, before extending on the longer term variables.
Short Term
- chainid
- version
- block number
- block timestamp
chainid
Exists in Ethereum: 👍
Description: Reading the L1 chainid for the current block.
Uses: Generally used for replay protection between chains, exposed in evm to protect against replays for meta transactions, EIP-712, etc. Also used widely for cross-chain messaging for sender and recipient domain identifier.
Public support: 👍
Private support: 👍
version
Exists in Ethereum: 👎
Description: Essentially the l2 chainid for the current block. Using version to clearly distinct between chainid and it from Noir.
Uses: Generally used for replay protection in Aztec, and part of cross-chain message authentication. Similar to chainid.
Public support: 👍
Private support: 👍
block.number
Exists in Ethereum: 👍
Description: Reading the current block number for L2.
Uses: Often used as a proxy for time, see compound V2 or curve locking contracts. Certain system use the discrete coarse units to make accounting easier.
Public support: 👍
Private support: 👎 (see #832)
block.timestamp
Exists in Ethereum: 👍
Description: Reading the timestamp of current block for L2.
What it is used for: Used widely for deadlines and interest computations.
Public support: 👍
Private support: 👎 (see #832)
The values can be added to the ConstantRollupData and must match throughout the full tree building and finally against public inputs from the contract, that will also constrain the variables to meaningful values.
### Short Term Taks
- [ ] https://github.com/AztecProtocol/aztec-packages/issues/826
- [ ] https://github.com/AztecProtocol/aztec-packages/issues/827
- [ ] https://github.com/AztecProtocol/aztec-packages/issues/828
- [ ] https://github.com/AztecProtocol/aztec-packages/issues/831
- [ ] https://github.com/AztecProtocol/aztec-packages/issues/912
- [ ] https://github.com/AztecProtocol/aztec-packages/issues/832
- [ ] https://github.com/AztecProtocol/aztec-packages/issues/830
- [ ] https://github.com/AztecProtocol/aztec-packages/issues/359
Access to historic values should be supported through #849 and will not be handled as part of this issue.
Smart contracts have access to several global functions that reflect the state of the blockchain (like what is the current block or chain ID) or give additional context about the current transaction (like who is the transaction sender).
This doc takes inspiration from Etheruem to discuss what global methods Aztec should support from Noir and if both in public and private functions.
The issue lists each of Ethereum’s global variables/functions relating to a block or the current transaction and discuss why they are useful and if it is required for Aztec. The individual issues will expand on how it can be supported, especially in the context of private execution which only have access to historic data. You can read more on the restrictuion here but the TL;DR is this prevents race conditions for private transactions, where the user generates proofs locally on their browser, much before the time of inclusion, and therefore doesn’t know about the current chain.
For structure, we will list the short term first, before extending on the longer term variables.
Short Term
chainidExists in Ethereum: 👍
Description: Reading the L1 chainid for the current block.
Uses: Generally used for replay protection between chains, exposed in evm to protect against replays for meta transactions, EIP-712, etc. Also used widely for cross-chain messaging for sender and recipient domain identifier.
Public support: 👍
Private support: 👍
versionExists in Ethereum: 👎
Description: Essentially the l2 chainid for the current block. Using version to clearly distinct between chainid and it from Noir.
Uses: Generally used for replay protection in Aztec, and part of cross-chain message authentication. Similar to
chainid.Public support: 👍
Private support: 👍
block.numberExists in Ethereum: 👍
Description: Reading the current block number for L2.
Uses: Often used as a proxy for time, see compound V2 or curve locking contracts. Certain system use the discrete coarse units to make accounting easier.
Public support: 👍
Private support: 👎 (see #832)
block.timestampExists in Ethereum: 👍
Description: Reading the timestamp of current block for L2.
What it is used for: Used widely for deadlines and interest computations.
Public support: 👍
Private support: 👎 (see #832)
The values can be added to the
ConstantRollupDataand must match throughout the full tree building and finally against public inputs from the contract, that will also constrain the variables to meaningful values.Access to historic values should be supported through #849 and will not be handled as part of this issue.