Einstein predicted more than a century ago that clocks at higher altitudes tick faster than those at sea level. This theory, stated in Einstein’s brilliant and accessible manner, made people worry that those who lived up in the mountains would age faster than their friends by the sea.
In 2010, experiments with atomic clocks — the most accurate time measurement instruments on earth — validated Einstein’s theory by showing that if an atomic clock is raised physically by a mere 12 inches, the slightly weaker gravitational field at this higher altitude will stretch time, theoretically adding 90 nanoseconds to a human lifespan of 79 years. Such a tiny addition may not be enough to encourage you to stop smoking, but these experiments marked the moment in history when non-Einsteinian humans began to realize that “time” as a notion was not absolute.
A decade after this realization, data scientists working with time-series data that includes blockchain timestamps need to understand the relativity of those stamps. Blockchain architecture is decentralized; every participant has its own computing installation that generates “proposed” blocks, which compete for final status in the chain. Each of those installations has its own clock.
Aside from a multiplicity of confusing formats (e.g., Unix Timestamp, Unix Epoch, ISO 8601, SQL), timestamps in blockchains differ from each other by tiny amounts because they are generated by different systems. In addition, timestamps have differing levels of precision.
Participants in most blockchain networks use Unix Time stamp, which has a precision level of one second, to mark the moment a proposed block is generated. Some networks use Unix Epoch, which has millisecond level precision. Atomic clocks are accurate down to approximately one nanosecond per day. Thus, with precision of only one second, blockchain timestamps are inappropriate for storing ultra precise measurements.
The lack of a centralized time clock can lead to ambiguous situations. For example, time sequences of blocks could appear to go backward or stay the same.
To make things even more complicated, the timestamp of the block that both the Singapore and the Norway node will write in their copies of the blockchain is likely to be based on a third-party clock: that of the proposer. Since every block can have a different proposer, their timestamps will all reflect the small variances of the different machine clocks. Each stamp will introduce to the chain the slight inconsistency of its proposer’s clock.
In many cases, these inconsistencies don’t matter. If a blockchain is used by a logistical system to follow inventory in transit, accuracy down to a few seconds is probably sufficient. But as blockchain performance increases — in older systems, it takes 10 minutes to confirm a new block; in newer ones, only five seconds or less — its application to things like trading networks become feasible. And trading networks are highly sensitive to slight time variances. In another example, many enterprise applications are currently executed “off-chain,” as insiders say, but today’s faster blockchain networks will let enterprise applications write directly to the blockchain.
Real-time applications such as these will need, if not accurate timestamps, then at least a way to arbitrate among discrepant ones.
Although all nodes have the exact same copy of the blockchain, the timestamps on blocks may be different, depending on the proposer of the block and its machine clock. This misalignment can lead to a situation in which, as noted earlier, two or more consecutive blocks have the same Unix timestamp.
Before, when blockchain was used for only non-time-critical applications, these small differences might not have mattered much, but increasingly they will, as more-time-sensitive applications come on stream.
Blockchain provides a greater degree of security to people transacting without a trusted central authority, but — because of its decentralized nature — blockchain networks come with a structural weakness: inconsistent and unknowable timestamp accuracy. Some blockchain implementations handle time discrepancy explicitly and transparently, via either a mechanism for clock syncing or a rule that requires timestamp sequences to always increase. Each has benefits and imperfections. Allowing clocks to sync across blockchain participants introduces a door that bad actors can use to fool nodes into accepting incorrect times. But from a practical perspective, time syncing cannot become part of the consensus mechanism (how the blockchain system awards a particular block to a participant) because, as of this writing, its precision level is measured in seconds, which is too slow. So, most blockchain operators have decided not to deal with the overhead of universal time and have left it to their clients to bring their own timestamps when they need them.
In a world where timing accuracy is increasingly important — and available from atomic clocks and even Apple Watches — data scientists and other interested parties must find a way to deal with the inherent inaccuracies of blockchain networks.
Here are a few suggestions for data scientists dealing with the issue of timing accuracy in blockchains. Analysts should:
a. educate themselves on the nature of timestamps in blockchains and be prepared to learn the origin of particular timestamps
b. be aware of potential timestamp misalignment and varying levels of accuracy, and be ready to account for these discrepancies in their analyses
c. in cases where order is important but actual time less so, align datasets based on block numbers rather than simply on timestamps (i.e., since all nodes working on same blockchain share a set of common block numbers, an application can start with time, convert to block numbers, finish the work in block numbers, and at the end of the process convert back to time again in whatever domain is most relevant), and
d. consider, in cases that need precise time, an architecture that bundles data going into a block with its own local timestamp to the desired level of precision.
As more time-sensitive applications are moved to blockchain networks, data scientists will increasingly be confronted by timestamp issues, not only with respect to reconciling multiple complex time formats, but also in the area of unknown variability of timestamp accuracy. In blockchain networks, timestamps cannot be trusted as absolute truth.
In some cases, that relativity will matter, and it is up to the data scientist involved to understand the nature of blockchain timing variances and learn ways to mitigate their effects.
Nikos Andrikogiannopoulos is the founder and CEO of a Cambridge-based startup providing solutions to leading edge blockchain 3.0 vendors. He has more than 10 years’ experience working for and with large telecommunications providers on strategy and big-data analytics. Andrikogiannopoulos holds two degrees from the Massachusetts Institute of Technology (MIT): an MBA from the Sloan School of Management and a master’s degree from the Electrical Engineering and Computer Science department.