EIP-5805 Voting with delegation

EIPs
,
1
2 Likes
2

Excited to see this get in! Very important for onchain DAOs!

1 Like
3

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.

1 Like
4

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)

5

The EIP as currently written allows arbitrary monotic functions for the clock, so I was giving examples that are valid according to the spec.

1 Like