1

So basically i want to ask that how can we programmatically get the accurate, exact and current time in a DApp, without relying on the system's time or a centralized time server ?

Is there a decentralized serivce which keeps track of time, so it would be easier to query time from there without having to rely on centralized, single point of failure and potentially vulnerable time servers ?

Maybe a decentralized timestamping service can help here, but i am not aware of any.

please let me know !

  • Hi and welcome to Stack Exchange! I'm voting to close this question as "off-topic" as it's not related to Ethereum - you are asking about a decentralized time service and Ethereum does not provide such. – Lauri Peltonen Aug 8 at 10:50
  • Check Google's Roughtime for something similar new.blog.cloudflare.com/roughtime – Ismael Aug 8 at 17:13
  • It's not off-topic, and Google's Roughtime has nothing to do with the question. As Oleg Kondrakhanov's says in his answer, one could use the now keyword to get the current block timestamp in a Dapp. – Carlos Fuentes Aug 8 at 20:38
0

I guess you need now keyword in Solidity. That is a current block timestamp.

Check the official docs:

https://solidity.readthedocs.io/en/develop/units-and-global-variables.html#block-and-transaction-properties

Example

function f(uint start, uint daysAfter) public {
    if (now >= start + daysAfter * 1 days) {
      // ...
    }
}

Is it the thing you are talking about?

  • I don't know if this satisfies OP's request about "accurate, exact and current time", but it is the best way to get the current time in a Dapp. – Carlos Fuentes Aug 8 at 20:40
  • The problem with now (= block.timestamp) is that it is easy to manipulate by the miner (within certain margins) so it is not thrustworthy if you need precise timestamps. – Ismael Aug 9 at 17:14
  • hey there Oleg ! so how reliable is the 'current block timestamp' ? is it truly immutable and resistant to any changes / attacks ? Just to add to what was said by @Ismael , I am asking because i read on this very stackexchange that some miner could change this timestamp by 900s. please let me know how reliable this timestamp actually is. – Muhammad Yasir Aug 9 at 18:50
  • Miner indeed can manipulate it. So sometimes it might be better to use not now (timestamp), but block number instead and an average time between blocks. But this method is not very precise. You can check here hackernoon.com/… (Search for '12. Block Timestamp Manipulation' text) – Oleg Kondrakhanov Aug 10 at 4:35
0

The Solidity keyword now does return the underlying node's system time, but this could be manipulated by that particular node (e.g. to do miner frontrunning). One possibility is you could have a smart contract that participants can regularly submit a time for the current block, which would be correct plus or minus a few blocks (called a FUDGE_FACTOR_IN_BLOCKS below).

On Ethereum, each block is found after roughly 15 seconds, so you could write a smart contract that looks roughly like (this might not compile but gives the idea)

contract TimeServer {

  uint256 FUDGE_FACTOR_IN_BLOCKS = 2;
  uint256 public lastBlockNumber;
  uint256 public lastBlockTime;

  constructor(uint256 firstBlockNumber) {
    require(abs(firstBlockNumber - block.number) < FUDGE_FACTOR_IN_BLOCKS));
    lastBlockNumber = block.number;
    lastBlockTime = now;
  }

  function submitNewTime(uint256 newBlockNumber, uint256 newBlockTime) public {
    uint blockDiff = newBlockNumber - lastBlockNumber;
    require(blockDiff > 0, `New block number must be later than last block')'
    uint timeDiff = newBlockTime - lastBlockTime;
    require(abs(timeDiff / 15) - blockDiff) < FUDGE_FACTOR_IN_BLOCKS,
            'Submitted block time is off by more than +/- fudge factor.') )
    lastBlockNumber = newBlockNumber;
    lastBlockTime = newBlockTime;
  }

}

I'm not sure if now is in milliseconds or seconds, so check first. As long as the contract is constructed correctly (given within two blocks of the actual block number, on an honest node), then every other call to submitNewTime will also be within two blocks of the correct time and block number.

Participants could call this submitNewTime periodically as a public service (since it costs gas), perhaps every few blocks to adjust for drift. Consumers can access the lastBlockTime and lastBlockNumber members as a lower bound on time (it's as stale as the last time anyone called submitNewTime)

  • An interesting solution but I doubt any participants want to pay gas to adjust the "system clock". – Lauri Peltonen Aug 9 at 12:04
  • this could be a public service that large companies could participate in, if they required accurate block time in their contracts (e.g. government or military applications). The U.S. government runs an atomic clock which we all benefit from, even though most private citizens wouldn't want to or know how to operate it. – Paul Pham Aug 10 at 13:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.