feat: Access chainid, block number, timestamp and version from noir

[LHerskind]

Both public and private functions should be able to read:

• version
• chainid
  From their context.

Only the public functions should be able to read:

• timestamp
• blocknumber

---

Timestamp and block number might bring more trouble than good if accessible from the private domain as users will expect them to be "current", which is an unknown at the time of proof generation by the user, and only available by the sequencer when executing public functions.

Note:
For the cases where blocknumber or timestamp is used as a deadline, it is possible to build a generic TimeStampContract that has public function constraining these values which a private function could call to enforce a deadline. It will leak the deadline, but making it enforceable.

Meaning that you have A calling B::afterDeadline(deadline) where afterDeadline is a public function that will make the entire tx revert if block.timestamp < deadline.

[iAmMichaelConnor]

For the cases where blocknumber or timestamp is used as a deadline, it is possible to build a generic TimeStampContract that has public function constraining these values which a private function could call to enforce a deadline. It will leak the deadline, but making it enforceable.

I wonder if this use case is common enough to warrant global variables:

• max_timestamp
• max_blocknumber
• min_timestamp
• min_blocknumber

There would need to be a standardisation effort around a user-deployed TimeStampContract contract. For apps to have strong 'function hiding' guarantees, most / all apps would need to call a single TimeStampContract instance, and it's unclear to me whether that would happen. Baking these globals into the protocol would ensure a larger 'anonymity set' for apps which want to use this functionality.

[LHerskind]

I wonder if this use case is common enough to warrant global variables.

I think it is unclear what these variables would mean. What is max_timestamp and what stops me from manipulating it wildly in private calls by referring to older historic roots.

I would say no to having them as global variables, but yes to create a small library that people could use for some of the time functions. Essentially it will be different reads of historic data, so seems fine to put in app level.

@iAmMichaelConnor, can you try giving some descriptions of what max_timestamp is, like, what is the actual value, e.g., block[n].timestamp where n is the newest block in the historic root that user proved with etc.

[iAmMichaelConnor]

max_timestamp would be "the greatest timestamp, after which this tx would be invalid". An alternative name would be assert_timestamp_less_than or include_this_tx_before_timestamp.

min_timestamp would be the "smallest timestamp, before which this tx would be invalid". An alternative name would be assert_timestamp_greater_than or include_this_tx_after_timestamp.

These might allow private contracts to make time-based assertions. max_timestamp would be used to assert deadlines are met, whilst min_timestamp would be used to assert that enough time has elapsed.

[LHerskind]

If you are doing it in private, then I don't see how this would be enforceable, you mean private with a public call?

Also, what stops the sequencer from including the tx and getting the fee with it reverting anyway?

[iAmMichaelConnor]

I mean private with an assertion at the protocol level (in the kernel or rollup circuit, or on L1; basically wherever the block.timestamp check will be happening).

what stops the sequencer from including the tx and getting the fee with it reverting anyway

I guess the failing check would need to revert the whole rollup (and so the tx shouldn't be included by a sequencer unless they're confident that the timestamp check will succeed).

[LHerskind]

I mean private with an assertion at the protocol level

Think you could handle that in the base rollup. The rollup constants will have the current timestamp, and base can assert that min < block.timestamp < max.

One would need to account for the time constraints applied in #830, as there is some "slack".

It is quite different from most blockchains to have such a thing at the protocol level. Not sure if I like it or not.

[iAmMichaelConnor]

I thought I'd sent this last week, but just found it (unsent) as I was closing tabs:

I mean private with an assertion at the protocol level (in the kernel or rollup circuit, or on L1; basically the same place as wherever the block.timestamp check will be happening).

what stops the sequencer from including the tx and getting the fee with it reverting anyway

I guess the failing check would need to revert the whole rollup (and so the tx shouldn't be included by a sequencer unless they're confident that the timestamp check will succeed).