Excited to see this get in! Very important for onchain DAOs!
The current version of the EIP doesnât give sufficient information to determine what kind of clock is being used. clock()
returns the current timepoint, but more than that is necessary for basic tasks like measuring spans of time, which users have to do when configuring Governor parameters like voting period.
Two examples that could be useful to consider are timestamps with lower granularity:
function clock1() returns (uint) {
return (block.timestamp / 1000) * 1000;
}
function clock2() returns (uint) {
return block.timestamp / 1000;
}
The first one is interesting because every 1000 seconds it would appear equivalent to block.timestamp
, but it isnât exactly that and in some cases the difference might lead to errors. The second one doesnât present the same potential for confusion, but a user or an application wouldnât know (unless they inspect the source code) how to measure a span of time in this clock.
The EIP should define a standard way to identify the clock function. This is difficult because we are allowing arbitrary monotonic functions, but I think we will agree that the user needs to know more properties about the clock than that. The simplest thing would be to add a function returning an enum with options a) block number, b) timestamp, and c) other. The two examples above would be classified as âotherâ, so if we think itâs valuable to express those we will need something more complex.
Another thing that I would consider is defining timepoints as 64 bit values, and making uint64
the return type of clock()
. This would allow timepoints to be be packed in storage, otherwise we can make no assumptions about their size. Timepoints as large as uint256
have way too much granularity that will never be needed.
Iâd rather do none of these /1000
conversions and just return raw value and leaving the conversion to caller.
function clock() returns (uint) {
return block.timestamp;
}
In addition, from a standardization scoping perspective, I think the representation of time shall be solved in a separate EIP, something like
EIP-XXX Time Scheme
Specification
enum TimeSchemeOption {
blocknum = 0;
timestamp = 1;
};
interface ERCTimeScheme {
function defaultTimeScheme() external pure returns(TimeSchemeOption);
}
Ref Impl
contract Foo is ERCTimeScheme, ERC1202, ERC5805, ERC5732 {
function defaultTimeScheme() external pure returns(TimeSchemeOption) {
return TimeSchemeOption.blocknum;
}
}
This help ensuring whenever a time is being used, the scheme is acquirable and shall be consistent across different functions.
Complying contracts of EIP-1202 probably need to align with the same sense of time too. The EIP-5007: Time NFT, EIP-721 Time Extension however choose to use int64 for unix stamp.
(posted as EIP-XXX Time Scheme to see if there is interest to consolidate)
The EIP as currently written allows arbitrary monotic functions for the clock, so I was giving examples that are valid according to the spec.