Accurate and Decentralized Timestamping Using Smart Contracts On The Ethereum Blockchain

Information Processing and Management 58 (2021) 102471
Contents lists available at ScienceDirect
Information Processing and Management

journal homepage: www.elsevier.com/locate/ipm
Accurate and decentralized timestamping using smart contracts on

the Ethereum blockchain
Gabriel Estevam a ,∗, Lucas M. Palma a , Luan R. Silva b , Jean E. Martina a , Martín Vigil b
a Programa de Pós-Graduação em Ciência da Computação, Universidade Federal de Santa Catarina, Campus Florianópolis, Brazil
b Departamento de Computação, Universidade Federal de Santa Catarina, Campus Araranguá, Brazil
ARTICLE INFO ABSTRACT
Keywords: Timestamps allow us to identify a date and time when a piece of data existed or an event
Ethereum took place. For example, we use timestamps to establish the date when we grant a patent.
Timestamp Services that offer trusted timestamps on the blockchain exist, where one creates a timestamp
Trusted timestamping
on a value by sending the blockchain a transaction containing the value, which is eventually
Blockchain
confirmed in a block a miner creates and timestamps. Our work focuses on the accuracy of
Accuracy
Smart contract
such timestamps created on the Ethereum blockchain. We estimate that their mean accuracy is
half of the average time between consecutive blocks. However, Ethereum clients geth and parity
allow accuracy to vary in up to a few tens of seconds. Surprisingly, we found out empirically
that miners can backdate data using the timestamp on a block, which is a serious flaw in
timestamping services. To address this problem, we propose a new decentralized timestamping
service that combines smart contracts and distinct time providers. The service offers timestamps
with higher accuracy of milliseconds. We conduct a cost analysis of our service, which shows
that Ethereum transaction fees drive our timestamps costs when the service scales up. Finally,
we discuss alternatives to cut costs.
1. Introduction
It is often necessary to identify when a piece of data existed or when an event occurred. Such evidence is called proof of existence
in the literature (Vigil, Buchmann, Cabarcas, Weinert, & Wiesmaier, 2015) and is needed in distinct scenarios. For instance, patent
offices should publicize the date when an inventor filled an application on a new idea so that future public disclosures cannot form
prior art. Another example is accounting records, which often require audit trails tracing financial transactions chronologically. After
the accounting scandals involving companies listed on the New York Stock Exchange, such as the Enron case (Kershner, 2020), the
U.S. Congress passed the Sarbanes-Oxley Act of 2002 that requires U.S. companies to provide secure audit trails (Connel, 2017).
The accuracy of proof of existence matters, i.e., how close it is to the actual moment when data or events were indeed witnessed.
Proof of existence should not be earlier than the actual witnessing moment, otherwise backdating issues may arise, such as those seen
in stock options scandals (Daines, McQueen, & Schonlau, 2018). Conversely, proof of existence can be later than the actual witnessing
moment to some extent, depending on the scenarios needing proof of existence. For example, we can see a degree certificate as proof
of existence that a student has completed a degree. Since the procedure a university follows in issuing certificates may consist of
several steps (Palma, Vigil, Pereira, & Martina, 2019), it is acceptable that the date the certificate is issued can be some days later
than the moment the student completed all courses for that degree.
∗ Corresponding author.
E-mail addresses: [email protected] (G. Estevam), [email protected] (L.M. Palma), [email protected] (L.R. Silva),
[email protected] (J.E. Martina), [email protected] (M. Vigil).
https://doi.org/10.1016/j.ipm.2020.102471
Received 15 May 2020; Received in revised form 9 December 2020; Accepted 11 December 2020
Available online 6 January 2021
0306-4573/© 2020 Published by Elsevier Ltd.
G. Estevam et al. Information Processing and Management 58 (2021) 102471
A way to realize proof of existence for digital data is trusted timestamps. A trusted timestamp consists of a digital signature
by a trusted third party on the information together with a date and time (Buchmann, Karatsiolis, & Wiesmaier, 2013). This party
is usually called timestamp authority and is trusted to sign the date and time when it makes a digital signature (viz., the present
time). Trusted timestamps have been standardized in RFC3161 (Zuccherato, Cain, Adams, & Pinkas, 2001) and sold by distinct
vendors (BRyTecnologia, 2020; Surety, 2020).
The advent of the cryptocurrency Bitcoin (Nakamoto, 2008) brought about the disruptive blockchain technology. It allows us to
realize a distributed, append-only ledger which logs the history of Bitcoin transactions in the form of a sequence of cryptographically
linked blocks such that blocks contain disjoint sets of transactions and the immutability of the blocks and contained transactions
is guaranteed (Palma et al., 2019). Moreover, maintaining the ledger requires no trusted parties but rather the consensus of a
peer-to-peer network of volunteers nodes. A subset of such volunteers, which is usually called miners, validates transactions and
creates blocks. Miners are rewarded for their work by minting new Bitcoins or collecting fees from transactions.
Other cryptocurrencies came up augmenting the blockchain technology with new features. For instance, in addition to securely
logging transactions in a distributed manner, the Ethereum blockchain (Wood et al., 2014) made smart contracts possible. A smart
contract is a script stored in a blockchain and is executed independently and automatically in a prescribed manner by every volunteer
in the blockchain (Christidis & Devetsikiotis, 2016).
In contrast to RFC3161 timestamps, Hepp, Schoenhals, Gondek, and Gipp (2018) and Zhang, Xu, Cheng et al. (2019), Zhang,
Xu, Li, Yang and Shen (2019) propose using blockchains instead of timestamp authorities to create trusted timestamps. The authors
take advantage of the fact that a blockchain guarantees the relative and absolute order of blocks and contained transactions to some
extent without relying on trusted parties. Relative order is established by cryptographically linking every block but the first to the
previous block. Absolute order is established by the timestamps miners apply on the blocks they mine. Such relative and absolute
order that blockchains implement by combining cryptography and consensus has drawn the attention of further researchers. Swan
(2016) defines block time as a ‘‘chain of time’’ by which we add blocks to a blockchain. She advocates using block time as a secondary
time framework to reinforce time recorded outside of blockchains.
However, there exist concerns whether the above blockchain-based timestamps are accurate. Although the peer-to-peer network
of volunteers verifies the cryptographic link of every new block to the previous block, they may not firmly check the time stamped
on it. Loop (2019) and the Bitcoin Wiki (Wiki, 2019) alert that a Bitcoin volunteer validates the timestamp of a new block if it
is greater than the median timestamp of the previous 11 blocks and less than two hours into the future. The so-called time warp
attack has exploited such loose verification against the Bitcoin blockchain (Davidson & Diamond, 2020). According to Zhang, Xu, Li
et al. (2019), similar issues affect the Ethereum blockchain but contradicting research (Luu, Chu, Olickel, Saxena, & Hobor, 2016;
McCorry, Shahandashti, & Hao, 2017) claims Ethereum-based timestamps can suffer from only some seconds of error.
This work investigates how to create more accurate timestamps using the Ethereum blockchain. We refer to timestamp accuracy
as the closeness of the time claimed by a timestamp to the moment one requests the timestamp. We analyze the accuracy of Ethereum
state-of-the-art timestamping solutions analytically by examining the Ethereum specification (Ethereum, 2019; Wood et al., 2014)
and the source code of Ethereum most popular clients geth and parity. We estimate that the mean accuracy is half of the average
time between consecutive blocks, but it can vary in up to a few tens of seconds. Since this analysis simplifies unpredictable aspects
of the peer-to-peer network of volunteers, we evaluate accuracy empirically and found out it is 28.53 s on average when we pay
entirely the fees that miners ask. Nonetheless, our experiments reveal that accuracy varies significantly, and we could even spot a
non-negligible number of backdated timestamps, which is a severe flaw in timestamping solutions. We provide evidence suggesting
that backdated timestamps occur because miners can add new transactions to a block being mined without refreshing the timestamp
of the block.
We design a new protocol to create more accurate timestamps in the Ethereum blockchain. We claim that such timestamps are
decentralized since we combine smart contracts with distinct time sources instead of relying on block timestamps. More precisely,
one can ask a smart contract to timestamp a value by addressing the smart contract a transaction containing the value. Volunteers
provide the timestamps of the moments when they learn that particular transaction to the smart contract. The smart contract filters
discrepant timestamps out and selects the earliest timestamp to answer the timestamp request. The average accuracy of the selected
timestamps turned out to be 121.10 ms, which is by far higher than the accuracy of the state-of-the-art solutions.
We conduct a cost analysis to approximate how much the above timestamps should cost, so that our approach is financially
viable in the Ethereum blockchain. It turns out that the cost of our timestamps is significantly higher than RFC3161 timestamps
due to the Ethereum transaction fees. We discuss ways of off-loading parts of our approach from the Ethereum blockchain in order
to cut costs.
We organize the remainder of this article as follows. Section 2 introduces the background needed for this work. Section 3
compares the related work with the new protocol we propose. In Section 4, we analyze the accuracy of state-of-the-art timestamping
solutions that run on the Ethereum blockchain. Section 5 describes our proposal. Section 6 brings experiments and corresponding
results on the protocol we design. Section 7 sheds some light on backdated timestamps and provides some evidence suggesting
why they may occur. In Section 8, we conduct a comprehensive cost evaluation of our proposal. Section 9 presents some extended
discussion on costs and project decisions. Finally, we draw our conclusions in Section 10.
2. Background
In this section, we present the fundamental concepts and technologies that we use to build our proposal. In Section 2.1, we briefly
present some cryptographic primitives and digital certificates. Section 2.2 defines a hash-based commitment scheme. Section 2.3
introduces RFC3161 trusted timestamps. Finally, Section 2.4 brings the definitions of blockchains and smart contracts.
2
2.1. Cryptographic hash functions, digital signatures & digital certificates
A cryptographic hash function 𝐻 ∶ {0, 1}∗ → {0, 1}𝑛 maps the set {0, 1}∗ of arbitrary-length bit strings to the set {0, 1}𝑛 of n-bit
strings. We refer to cryptographic hash functions as hash functions. Hash functions are the building block of many cryptographic
protocols. For the protocols presented in the following sections, a hash function should fulfill two requirements. The first is called
collision resistance and requires that it should be computationally infeasible to find two bit strings 𝑥 ≠ 𝑥′ such that 𝐻(𝑥) = 𝐻(𝑥′ ). The
second is called preimage resistance and says it should be hard to find 𝑥 from 𝐻(𝑥). For further details on hash functions, we refer
the reader to the textbook of Hoffstein, Pipher, and Silverman (2008). A common choice for a hash function is SHA-256 (National
Institute of Standards and Technology, 2002) or Keccak-256 (Bertoni, Daemen, Peeters, Assche, & Keer, 2018), which set 𝑛 = 256.
Classic digital signature schemes rely on three algorithms. Namely, GenerateKeys(), Sign( 𝑑, 𝑆𝑘 ), and Verify( 𝜎, 𝑃𝑘 ). The first
algorithm creates a public key and a private key (𝑆𝑘 , 𝑃𝑘 ) for encryption and decryption of data. The Sign algorithm accepts a data
𝑑 and the signer’s 𝑆𝑘 as parameters. The original data 𝑑 is input to a cryptographic hash function 𝐻() and the result ℎ = 𝐻(𝑑)
is encrypted using an encryption algorithm 𝐸, where 𝑒 = 𝐸(ℎ). Therefore, the output 𝑒 is concatenated with the original data 𝑑
generating the signature 𝜎 = (𝑒 ∥ 𝑑). In order to verify if 𝜎 is valid, one should execute the Verify algorithm, which accepts as
parameters 𝜎 and the signer’s 𝑃𝑘 and outputs true if the signature is valid, false otherwise.
Digital signatures provide data integrity, that is, means to verify if the original data has been changed. They also allow one
to identify who signed that data (authenticity) and to prevent the signer from denying it (non-repudiation). Examples of digital
signature schemes are RSA and ECDSA. For detailed descriptions of these two signature schemes, we refer the reader to the text-book
of Stallings (1995).
Digital certificates bring about the means to distribute trustworthy public keys as follows. A trusted party called certification
authority signs a certificate attesting that a given public key belongs to a particular subject. One can trust a digital certificate unless
it has expired or the issuing certificate authority has been compromised.
2.2. A hash-based commitment scheme
A hash-based or string commitment scheme is an electronic way to temporarily hide a value that cannot be changed (Halevi &
Micali, 1996). Such a scheme consists of two phases. In the first phase, a sender sends a value locked within a box to a receiver. In
the second phase, the sender provides the key for the receiver to open the box and learn the value.
A simple construction for a commitment scheme is as follows. Let 𝐻() be a collision-resistant cryptographic hash function. In the
first phase, the sender sends the receiver a commitment 𝑐 = 𝐻(𝑣 ∥ 𝑟) to a value 𝑣, where 𝑟 is a sufficient-long sequence of random
bits and 𝑣 ∥ 𝑟 denotes the binary concatenation of 𝑣 and 𝑟. In the second phase, the sender reveals 𝑣 and 𝑟 to the receiver. The
receiver verifies that the sender has not changed the committed value by computing 𝑐 ′ = 𝐻(𝑣 ∥ 𝑟) and checking that 𝑐 ′ equals 𝑐.
For further information about commitment schemes, we refer the reader to the work of Halevi and Micali (1996).
2.3. Trusted timestamps
We can use timestamps to identify a date and time when a piece of data existed. Trusted timestamps can be construct as a
triple 𝐻(𝑣), 𝑡, 𝜎, where 𝐻() is a collision-resistant hash function, 𝐻(𝑣) is the hash of a value 𝑣 to be timestamped, 𝑡 is a date and
time when 𝑣 existed, and 𝜎 is a signature on the concatenation 𝐻(𝑣) ∥ 𝑡. The date and time 𝑡, as well as the signature 𝜎, are
given by a trusted party called timestamp authority (TSA). A TSA is trusted to have a clock synchronized to an official time source
(e.g., the National Institute of Standards and Technology (National Institute of Standards and Technology, 2020)), and to use 𝑡 as
date and time when the TSA signs the timestamp. It follows that any timestamp issued by a compromised TSA should not be trusted.
The reason is that one cannot distinguish between (a) a valid timestamp that the TSA has created before being compromised and
(b) a backdated timestamp the TSA issued after being compromised. RFC3161 (Zuccherato et al., 2001) is the de facto standard for
trusted timestamps, which further trusted timestamping protocols such as (Blazic, Gondrom, & Saljic, 2011; Vigil, Weinert, Demirel,
& Buchmann, 2014) build on.
2.4. Blockchain, smart contracts, & fees
A blockchain is a distributed data structure composed of chained blocks of data. Every block can include a pointer to the previous
block in the chain, a timestamp, and a digital content compilation. Fig. 1 depicts a simplified blockchain structure. This technology
gained attention with Bitcoin (Nakamoto, 2008), where it works as a distributed ledger to store digital currency transactions
(i.e., Bitcoin transactions).
To create the link between two consecutive blocks 𝐵𝑖 and 𝐵𝑖−1 , where 𝑖 >= 1, every block, except the first one (the genesis block),
stores the cryptographic hash from the previous block, which is called a hash pointer. To tamper with any block in the middle of the
chain (i.e., any block except the most recent block in the chain), one needs to update subsequent blocks to maintain the consistency
of the links. In other words, for each block 𝐵𝑖 in the chain, one can verify the data integrity of 𝐵𝑖−1 . Furthermore, the timestamp
stored in every block associated with the hash pointers helps to establish a total order between the different blocks. We further
discuss blockchain timestamps in Section 4.
In Nakamoto (2008)’s proposal, the blockchain is shared and replicated among all nodes in a peer-to-peer network, where we
connect each node to a set of randomly chosen peers (usually called neighbors). Every block in their chains stores a compilation of
3
Fig. 1. The simplified blockchain structure. The block header is composed of at least two elements. Namely, the cryptographic hash pointer of the previous
block and the timestamp of the actual block.
digital content called transactions. These transactions consist of transferring Bitcoins from one node in the network to another. We
identify each node by an address derived from a public key and controlled by the corresponding private key. Nodes are allowed to
have multiple addresses, i.e., different key pairs. The set of all private keys of a node is called a Bitcoin wallet, and it virtually holds
the node’s funds.
Moreover, the blockchain stores only validated transactions, that is, transactions confirmed by the majority of the nodes. To
store a new transaction in the chain, the sender (the one node that desires to transfer funds to another) broadcasts a request to
its peers, informing the receiver address and the number of Bitcoins to be transferred. Next, the peers proceed with the validation
process. More precisely, they verify that (a) the sender owns enough funds to afford the transaction, and (b) the sender’s signature
on the transaction using his or her private key is valid.
Once the transaction passes these verifications, a miner can add it to a new block. However, in this system, we can have
inconsistencies between the blockchain replicas. Since every node stores a local copy of the blockchain, it is required a mechanism
in which all nodes agree on what blocks and transactions are valid.
Nodes participate in a consensus algorithm to keep the replicas consistent. In Bitcoin, the nodes who want to create a new block
are called miners. Miners assemble a compilation of broadcast transactions in a new block and run the consensus mechanism called
Proof of Work (PoW). It consists of a cryptographic puzzle, where miners apply computational power to set the new block. Fees are
applied to compensate miners. Every time a miner correctly creates a new block, he or she receives some Bitcoins. One can interpret
this consensus algorithm as a round-based competition. Every time a new block is to be created, miners engage in a new round.
During each round, miners will collect and verify new transactions, set the timestamp of the next block they will mine, and try to
solve the cryptographic puzzle. When a miner solves the cryptographic puzzle, it broadcasts its newly crafted block to its peers and
starts a new round of mining. Upon learning the new crafted block, the other miners start a new round of mining too. However,
please note that miners may not be synchronized. That is, a miner 𝐴 may be in a different round than miner 𝐵. For example, miner
𝐴 may be trying to create a new block in a non-updated chain. In this case, the consensus algorithm recommends peers accepting
the longest chain, or in other words, the chain in the most recent round.
This mechanism also works as a countermeasure to the so-called Sybil attacks and Byzantine failures. Douceur (2002) explains
that a Sybil attack consists of one malicious entity performing redundant operations in a system where no trusted authority vouches
for a one-to-one correspondence between entity and identity (e.g., using distinct identities to vote multiple times in a voting-based
consensus protocol). Mostéfaoui and Raynal (2016) describe a Byzantine failure as the loss of a system due to one of its components
that arbitrarily deviates from the intended behavior (e.g., a malicious participant in a peer-to-peer system who sends conflicting
messages to prevent other participants from reaching consensus). For more information on different consensus algorithms, we refer
the reader to the survey of Alsunaidi and Alhaidari (2019).
Bitcoin went rapidly popular after its network launched in 2009 (Bitcoin Community, 2020), which generated dozens of new
blockchain-based cryptocurrencies in the following years (Mukhopadhyay, Skjellum, Hambolu, Oakley, Yu, & Brooks, 2016). In
particular, the Ethereum blockchain platform (Wood et al., 2014). Similar to Bitcoin, Ethereum also provides means for nodes to
transfer digital funds, but in its case, the cryptocurrency is called Ether. Nonetheless, the central concept that differs Ethereum from
Bitcoin is the adoption of smart contracts.
One of the first definitions of smart contracts was presented by Szabo (1996) as contractual clauses embedded in pieces of
software. Ethereum extended this idea with generic decentralized applications (DApps) running in the blockchain. In this context,
any node in the Ethereum network is allowed to create a smart contract. The high-level instructions of a smart contract are translated
to byte-codes and stored as a transaction in the Ethereum blockchain. An address in the network also identifies smart contracts.
To execute a smart contract, one needs to broadcast a transaction addressing a specific contract defining the desired function and
the set of inputs. Next, miners collect these transactions and execute them in a local virtual environment called Ethereum Virtual
Machine (EVM).
We represent every smart contract function in Ethereum as a collection of operation codes. For instance, according to Appendix
G in the Ethereum Yellow Paper (Wood et al., 2014), to set a variable from zero to non-zero, one should call the EVM operation code
4
Table 1
How the related work compares to our work.
Accuracy Properties
Improved RFC3161 Timestamps Seconds Minutes Hours TSA Platform
Stavrou and Voas (2017) ✓ ✓ ✓ Bitcoin*
Blockchain Timestamps Seconds Minutes Hours TSA Platform
Hepp et al. (2018) ✓ ✓ Bitcoin*
Gipp, Meuschke, and Gernandt (2015) ✓ ✓ Bitcoin
Gipp, Breitinger, Meuschke, and Beel (2017) ✓ ✓ Bitcoin*
Tierion and Inc. (2020) ✓ ✓ Bitcoin
Factom (2019) ✓ Bitcoin
Tomescu and Devadas (2017) ✓ ✓ Bitcoin
Ali, Nelson, Shea, and Freedman (2016) ✓ ✓ Bitcoin*
Clark and Essex (2012) ✓ ✓ Bitcoin
Zhang, Xu, Li et al. (2019) ✓ ✓ Ethereum
Zhang, Xu, Cheng et al. (2019) ✓ ✓ Ethereum
Blockchain Improved Timestamps Seconds Minutes Hours TSA Platform
Landerreche et al. (2018) – – – –
Szalachowski (2018) ✓ ✓ Bitcoin*
Ours ✓ * Ethereum*
𝐺𝑠𝑠𝑒𝑡 . Moreover, every operation code has an associated cost in terms of the so-called 𝑔𝑎𝑠. The 𝐺𝑠𝑠𝑒𝑡 operation code costs 20,000
𝑔𝑎𝑠 to be executed. In this way, one can use an Ethereum compiler to calculate the total cost of its smart contract’s functions as the
sum of all required operation codes costs. Additionally, 𝑔𝑎𝑠 can be later on translated to Ether and finally converted to fiat money,
for example, the U.S. dollar (U$).
Both Bitcoin and Ethereum work in a public permissionless network, where any node can integrate the network, read data
stored in the blocks, and propose new transactions. However, different blockchain platforms such as Hyperledger Fabric (Cachin
et al., 2016) introduce a different environment. More precisely, one can deploy a new blockchain instance in a private permissioned
network. Therefore, read and write permissions can be regulated by a node or a consortium of nodes. For more information on
blockchain architectures, we refer the reader to Xu et al. (2017).
Blockchain has made possible not only decentralized financial services. Researchers have proposed the application of blockchain
in different areas such as education (Palma et al., 2019), the combat of fake media (Chen, Srivastava, Parizi, Aloqaily, & Ridhawi,
2020), cloud storage (Li, Wu, Jiang, & Srikanthan, 2020), fog computing (Baniata, Anaqreh, & Kertesz, 2021), smart vehicles (Oham,
Michelin, Jurdak, Kanhere, & Jha, 2021), and the Internet of Things (IoT) (Zhao, Chen, Liu, Baker, & Zhang, 2020).
3. Related work
In this section, we compare the related work with our proposal as follows. Table 1 classifies the related work into three main
categories: (1) improved RFC3161 timestamps: blockchain-based solutions that add or improve security properties of RFC3161
timestamps; (2) blockchain timestamps: solutions that provide timestamps based on the time miners allegedly create blocks; and
(3) blockchain improved timestamps: solutions that address the lack of accuracy and security of blockchain-based timestamps. Also,
Table 1 shows the expected timestamp accuracy for every listed proposal, which strongly depends on the chosen blockchain platform.
For instance, proposals that use the Bitcoin blockchain have a timestamp accuracy of minutes (m) or even hours (h). On the other
hand, in the Ethereum blockchain, one can have timestamps with an accuracy of seconds (s) in the best-case scenario or even
minutes, depending on factors such as the fees we offer miners to confirm our transactions and network latency.
Moreover, we inform proposals that consider TSAs’ participation and which blockchain platform authors recommend using. In
the latter, we use an asterisk (*) if authors discuss the use of different platforms in addition to the one used as the basis for their
proposals.
The work of Landerreche, Schaffner, and Stevens (2018) is an exception in our classification since they propose a generic
timestamping protocol that theoretically can be used as an external service by any blockchain platform.
We rule out works dealing with clock synchronization of blockchain participants (e.g., Badertscher, Gazi, Kiayias, Russell, &
Zikas, 2019; Fan et al., 2018, 2019; Hartl, Zseby, & Fabini, 2019) because this topic is out of the focus of our work. Note please that
although synchronized clocks are necessary to create accurate timestamps, they may not be sufficient. For example, a miner, who
has synchronized his or her clock, can apply a timestamp earlier than the present time on a fresh block he or she has just created.
Stavrou and Voas (2017) discuss the problems of relying on a single TSA. For instance, they highlight potential abuses that may
be committed by this private or governmental entity and wonder about the validity of timestamps issued by a compromised TSA. As
an alternative, they propose a secure timestamping system combining the trustworthiness and accuracy of a centralized TSA with the
decentralized nature of blockchains. In their proposal, a TSA issues an RFC3161 timestamp 𝑡 and concatenates 𝑡 to the hash of the
block 𝐵𝑖−1 , which the authors assume to be the most recent block of the blockchain. Next, the TSA publishes this concatenation in
the blockchain by creating a new transaction 𝑇𝑖 , which is expected to be confirmed in the next block 𝐵𝑖 . The produced concatenation
is registered in the blockchain and can be publicly verified. In this way, one can infer that 𝑡 must be later than the timestamp of
5
the block 𝐵𝑖−1 and earlier than the timestamp of 𝐵𝑖 . However, if the authors’ assumption on which blocks to use, viz., 𝐵𝑖−1 and 𝐵𝑖 ,
does not hold true, then there exist possibilities of attacks. For example, the TSA could intentionally use an older block 𝐵𝑗 , where
𝑗 < (𝑖 − 1) as the most recent block to backdate 𝑡. Moreover, since it is hard to guarantee that the transaction 𝑇𝑖 containing 𝑡 is
accepted in the next block 𝐵𝑖 due to network latency and fees, 𝑇𝑖 could be accepted in a future block 𝐵𝑘 , where 𝑘 > 𝑖. Therefore,
the TSA could use any time value between 𝐵𝑖−1 and 𝐵𝑘 to create 𝑡.
Furthermore, the authors discuss the scenario where a TSA is compromised (e.g., its private key has been stolen). In this case,
one could find a tamper-proof proof of the existence of the timestamps created before the incident in the blockchain, and could
easily distinguish them from the timestamps created after the incident.
We now present works that deal with blockchain-based timestamps, i.e., timestamps that use the time miners claim they mined a
block. For instance, OriginStamp (Gipp et al., 2015; Hepp et al., 2018) is a technical solution that brings to light a blockchain-based
alternative to RFC3161 timestamps. The system works on top of the Bitcoin protocol as follows. To create a timestamp, users send
a request to the OriginStamp service with the desired document. Next, the service computes the hash of the sent document. The
service collects all the requests created in the last 24 h and sends them together to reduce costs and the number of transactions
in the network. More precisely, they store the collected hashes in a balanced Merkle tree (Merkle, 1989). The root of the tree is
then embedded in a new transaction 𝑇𝑖 that is eventually confirmed in block 𝐵𝑖 . Also, users are allowed to request an individual
timestamp on a document that is issued as soon as the service receives the request if they are not willing to wait 24 h. In this
case, the service embeds a single hash in the blockchain. In this proposal, the accuracy of the generated timestamps depends on (a)
whether the service creates a timestamp upon each request or accumulates requests for 24 h before issuing a timestamp; and (b)
the time between two consecutive blocks in the Bitcoin blockchain.
Furthermore, users, who verify timestamps, trust the service to send transactions to the blockchain as soon as it receives a
timestamp request or no longer than 24 h after the request. One example of the OriginStamp application is CryptSubmit (Gipp
et al., 2017), which brings traceability to manuscript submission systems. The idea is to help researchers to mitigate potential data
leakage or reviewer fraud during a peer-review process. Authors propose to store the hash of manuscripts in the blockchain to prove
that the document already existed at a certain point in time.
Further technical solutions offering blockchain-based timestamp exist, which take the same approach as OriginStamp. For exam-
ple Tierion and Inc. (2020) and Factom (2019). Moreover, one can use blockchain-based storage schemes (e.g., Catena (Tomescu &
Devadas, 2017), Blockstack (Ali et al., 2016), and CommitCoin (Clark & Essex, 2012)) to achieve a similar result.
Chronos (Zhang, Xu, Li et al., 2019) is a timestamping protocol that promises to handle the lack of accuracy in blockchain-based
timestamping schemes. The proposal works on the Ethereum blockchain and focuses on cloud storage services, where the system
timestamps outsourced data once they are recorded in the cloud. There are three participants in this proposal:
1. User: he or she creates files and requests timestamps.

2. Chronos Log Server: it is subject to cloud service providers and provides timestamping and storage services.
3. Authenticated Auditor: he or she can access data stored in the Chronos Log Server and outputs timestamps for specific data.
There are four distinct phases in the Chronos protocol: Setup, Store, TimeStamp, and CheckStamp. In the Setup phase, security
parameters such as the user’s key pair are determined. Next, in the Store phase, the user generates and sends a new file concatenated
with its digital signature to the Chronos Log Server. In TimeStamp, the Chronos Log Server applies a hash function on the
concatenation of the file, the signature, and the last 𝜙 > 0 consecutive blocks of the Ethereum blockchain (the authors recommend
𝜙 = 12 in the Ethereum network). Then, Chronos generates a new transaction in the blockchain to store the computed hash in a
future block 𝐵𝑖 . In this way, the authors claim that Chronos can indicate both the earliest creation time and the latest creation time
of the outsourced data. That is, it is possible to infer that the timestamp of the outsourced data is later than the most recent block
in the 𝜙 last blocks (earliest creation time) and earlier than the timestamp of block 𝐵𝑖 . Moreover, the authors propose a time limit
of a few minutes to accept this interval.
In the final step, that is, CheckStamp, upon request, the authenticated auditor checks the time when the file was generated
and informs its timestamp. The authors extended this proposal with the so-called Chronos+ (Zhang, Xu, Cheng et al., 2019) to
support batch timestamping, where multiple requests from different users are handled all together by the service. Also, the authors
analyze the characteristics of cloud services’ data to determine a Window of Timestamping (WoT), which measures the practicality of
timestamping schemes in a cloud scenario. In both proposals, the timestamps’ accuracy strongly depends on the time spent between
the most recent block in 𝜙 and the blockchain timestamp of 𝐵𝑖 . Moreover, users who request timestamps need to trust the Chronos
services.
On the other hand, some researchers try to improve blockchain timestamps. Landerreche et al. (2018) propose an external
timestamping service based on proofs of sequential work that theoretically can be used by any blockchain platform in order to
create a cryptographically verifiable proof of the age of its records. Another example is Szalachowski (2018), in which they propose
a Timestamp Protocol (Zuccherato et al., 2001) (TSP) compliant mechanism to increase the reliability of Bitcoin timestamps. The
proposal requires no changes in the original Bitcoin protocol and works as follows. There are two types of participants, a regular
TSA and a Verifier. The latter is an entity that wants to verify the time of an upcoming (future) block 𝐵𝑖 . Every participant in the
peer-to-peer network can act as a Verifier.
First, the Verifier observes the blockchain and selects the most recent block, 𝐵𝑖−1 . The header 𝐻𝑖−1 of this block is extracted and
sent to a TSA to generate a timestamp 𝑡𝑖−1 . Next, the Verifier publishes 𝑡𝑖−1 by sending a transaction which contains 𝑡𝑖−1 and will
be confirmed in the next block 𝐵𝑖 . In this way, one can verify that 𝐵𝑖 is earlier than 𝑡𝑖−1 . Then, the verifier repeats the procedure
6
generating a timestamp 𝑡𝑖 for the block 𝐵𝑖 and publishes 𝑡𝑖 in the next block 𝐵𝑖+1 , creating evidence that 𝐵𝑖 was created between
the timestamps 𝑡𝑖−1 and 𝑡𝑖 . The author claims that this proposal is extendable to support multiple TSAs, where the Verifier could
select a different TSA to generate each timestamp. The accuracy of this proposal depends on the number of blocks between 𝑡𝑖−1 and
𝑡𝑖 . In the best-case scenario, the Verifier publishes 𝑡𝑖−1 in the next block 𝐵𝑖 and the same must occur for 𝑡𝑖 . However, one cannot
guarantee this accuracy in such an environment since a block’s content depends on the transactions the miner packs into the block,
usually those rewarding the highest fees. Furthermore, we cannot say anything about the time when transactions in 𝐵𝑖 were created
or seen for the first time.
Our proposal also aims to improve blockchain-based timestamps. However, it differs from the related work presented above by
not relying on the time miners claim they mine a block. Instead, we propose to combine a smart contract with distinct time sources
to timestamp a single piece of data.
4. The accuracy of Ethereum-based timestamps
As seen in Section 3, blockchains have been used as an immutable, timestamping medium. In general, to timestamp a value, one
sends a transaction containing the value to the blockchain, which is eventually confirmed and packed into the next block added to
the blockchain. The timestamp of the block works as a timestamp on the value.
The accuracy of such timestamps created with the help of the Ethereum blockchain is of interest here. We use the definition
of accuracy found in Physics, which refers to ‘‘how close the result of a measurement is to the true value’’ (Loyd, 2007). Based on
that, we define the accuracy of a timestamp for a block or transaction. For a block, accuracy is the closeness of the timestamp to
the moment the block was created. For a transaction, accuracy is the difference between the timestamp and the moment we send
the transaction to the blockchain.
Zhang, Xu, Li et al. (2019) affirm that timestamps on blocks in Ethereum are not accurate because nodes do not check for
accuracy. Moreover, the authors claim that a timestamp would suffer from up to 900-second errors. Luu et al. (2016) make the same
claim, but later McCorry et al. (2017) say that this claim is no longer valid because of the Ethereum light client protocol (Ethereum,
2018). However, we have found no mention of timestamps in Ethereum (2018), from which we could not figure out whether
900-second errors are still possible.
One could verify the accuracy of a timestamp on a block by comparing the timestamp with the time read from a synchronized
clock as soon as the block is mined. However, this is no easy task because we cannot predict which miner mines the next block.
Otherwise, we could establish a direct connection to such a miner, receive quickly the next block mined, and analyze the timestamp.
Neither can we guess the route the next block takes on the peer-to-peer network until it reaches us. Otherwise, we could approximate
the time the block takes to reach us, and from that estimate, the moment the block should have been mined. It turns out that the
closer a node is to the next block’s miner in terms of hops in the peer-to-peer network, the better the chance to learn the next block
faster, and the better the node can verify accuracy. Neighbors of the miner that mines the next block are likely to conduct the best
verification for accuracy.
There exist at least two verification that nodes should conduct on a timestamp when they learn a new block. First, the Ethereum
Yellow Paper requires nodes to check that the timestamp of a new block is greater than the timestamp of the previous block. Second,
the Ethereum White Paper (Ethereum, 2019) requires the timestamp of the new block to be less than 900 s into the future. Nodes are
supposed to reject a block whose timestamp fails any of the two verifications. Ethereum clients geth and parity have implemented
both verifications but changed the second to 15 s (Ethereum, 2020; Open Ethereum, 2020).
From the above verifications, we can approximate timestamp accuracy as to transactions. Assume a transaction pays the fees
miners ask so that miners pack it into the next block. Moreover, assume that the time for blocks and transactions to propagate in
the network is negligible and that miners collect new transactions with the same probability. Thus, the mean difference between
the time of sending a transaction and its confirmation within the next block (i.e., the timestamp accuracy) is supposed to be half of
the mean time between blocks. Specifically, around 6.50 s since, as of this writing, the mean time between two consecutive blocks
is approximately 13 s (Etherscan, 2020a). However, because miners may drift a timestamp as long as it is greater than the previous
block timestamp and not more than 15 s into the future, the accuracy can be:
1. reduced to zero if the miner puts its clock backward 6.50 s, or

2. expanded to 21.50 s if the miner puts its clock forward 15 s.
This is illustrated in Fig. 2, where 𝐵𝑖−1 and 𝐵𝑖 are the last block created and next block that will be created at the expected times
𝑡𝐵𝑖−1 < 𝑡𝐵𝑖 , respectively. Miners learn new transactions at any time 𝑡 ∈ (𝑡𝐵𝑖−1 ; 𝑡𝐵𝑖 ). As soon as 𝐵𝑖 is created, nodes learn it at time
𝑡𝑣 ≈ 𝑡𝐵𝑖 . They accept 𝐵𝑖 if 𝑡𝐵𝑖 ∈ [𝑡𝐵𝑖−1 + 1; 𝑡𝑣 + 15]. This is why nodes also accept 𝐵𝑖 containing an inaccurate timestamp 𝑡′𝐵 < 𝑡𝐵𝑖 or
𝑖
𝑡′′
𝐵𝑖
> 𝑡𝐵𝑖 .
In practice, however, estimating the accuracy of timestamps for transactions in an analytic way is more complicated. The reason
is that the time for mining a block can deviate from the average of 13 s. Moreover, transactions should take some time to reach
miners and compete with each other for being packed into the next block. Consequently, accuracy can vary with the peer-to-peer
network usage and the demand for transaction confirmation. Because of this, we evaluate accuracy empirically in Section 6.
7
Fig. 2. Block timestamps over time. Blocks 𝐵𝑖−1 and 𝐵𝑖 are expected to be created and timestamped at 𝑡𝐵𝑖−1 and 𝑡𝐵𝑖 respectively. As of this writing, blocks are
created every 13 s in average. However, nodes would accept block 𝐵𝑖 if it contained an inaccurate timestamp 𝑡′𝐵 or 𝑡′′𝐵 , being 𝑡𝐵𝑖−1 < 𝑡′𝐵 < 𝑡𝐵𝑖 and 𝑡𝐵𝑖 < 𝑡′′𝐵 ≤ 𝑡𝑣 +15,
𝑖 𝑖 𝑖 𝑖
where 𝑡𝑣 is the moment nodes learn 𝐵𝑖 .
Fig. 3. A smart contract intermediates between requesters and providers of timestamps in the blockchain.
5. A new decentralized timestamping service
In this section, we present our proposal as follows. First, in Section 5.1, we present an overview of our proposal’s participants
and protocol. Section 5.2 brings a detailed explanation on how we propose to timestamp transactions in the Ethereum blockchain.
In Section 5.3, we discuss a mechanism to select the best timestamp for a piece of data. Finally, in Section 5.4, we briefly discuss
a prototypical implementation.
5.1. Overview
Our goal is to issue blockchain-based timestamps with higher accuracy than existing solutions. To this end, we propose that
one interested to timestamp a piece of data sends it within a transaction into the Ethereum network and that this transaction is
timestamped individually rather than collectively in blocks. We detail this approach in the following.
We start by introducing three participants in our proposal. The first participant consists of individuals requesting timestamps on
pieces of data in the blockchain. We refer to them as requesters. The second participant comprises a set of nodes of the blockchain
network, which are programmed to provide timestamps. We call those nodes providers. The third participant is a smart contract,
which intermediates between requesters and providers.
We now explain the process that creates timestamps, which is illustrated in Fig. 3. First, a requester sends the smart contract a
blockchain transaction containing the piece of data he or she wants to timestamp together with fees to reward miners for confirming
transactions and providers for providing timestamps (❶ in Fig. 3). Next, the providers send the smart contract a transaction
containing a timestamp, which states the moment when they saw the requester’s transaction for the first time (❷). Then, the smart
contract selects the best timestamp from the timestamps received according to some selection strategy (❸). The smart contract keeps
a record containing the piece of data timestamped and the selected timestamp. Finally, the smart contract shares the fees among
the providers according to some strategy (❹).
Note that one provider can learn the timestamps from other providers before sending its timestamp to the smart contract. It
follows that a dishonest provider may use advanced information from others to manipulate its timestamp such that it has higher
chances of being selected by the smart contract. In addition to that, a dishonest entity controlling several providers can carry out
a Sybil attack. More precisely, he or she can abuse the smart contract by providing the majority of timestamps in order to increase
his or her chances of having a timestamp selected. We address these issues in the following section.
5.2. Protocol
As seen before, the protocol should prevent dishonest entities from taking advantage of foreknowledge of his or her competitors’
timestamps or from conducting Sybil attacks. To address these issues, the protocol uses commitments and requires providers to
register for the smart contract. We detail the protocol in the following.
8
We start with registering providers for the smart contract. The smart contract selects timestamps only from registered providers.
To register for the smart contract, a provider should pay a deposit 𝑁 > 0 to the smart contract. We refer to the set of registered
providers as 𝑃 .
Recall please that Ethereum smart contracts are scripts that only execute when triggered by a transaction. Therefore, the requester
or providers must initiate each step of the protocol. It follows that the protocol execution can halt indefinitely when the requester
and providers take no action. The protocol establishes deadlines and can apply penalties to participants to mitigate this issue.
Next, we present the protocol. The participants engaging the protocol were introduced in Section 5.1. Namely, a requester, a
smart contract, and a set 𝑃 of registered providers. We assume |𝑃 | > 0. The protocol is as follows.
1. A requester sends the smart contract a transaction 𝑇 containing the value 𝑣 to be timestamped and the minimum number
0 < 𝐼 ≤ |𝑃 | of timestamps expected. Transaction 𝑇 should pay 𝑀 + 𝑆 + 𝑅 on fees, where 𝑀, 𝑆 > 0 reward miners and
providers, respectively, and 𝑅 > 0 is a guarantee deposit. Fees 𝑆 + 𝑅 are to be held by the smart contract.
2. Transaction 𝑇 triggers the execution of the smart contract, which sets public, future deadlines 𝐷𝑐 < 𝐷𝑑 < 𝐷𝑠 .
3. Before deadline 𝐷𝑐 , each provider in a subset 𝑃 ′ ⊆ 𝑃 sends the smart contract a commitment 𝑐 = 𝐻(𝑣‖𝑡‖𝑟), where 𝐻 is a
collision-resistant hash function, 𝑡 is the timestamp of the moment when the provider learned transaction 𝑇 containing 𝑣, and
𝑟 is a sufficiently-long sequence of random bits.
4. At any time in (𝐷𝑐 , 𝐷𝑑 ], each provider in 𝑃 ′ ⊆ 𝑃 sends the smart contract the corresponding decommitment {𝑣, 𝑡, 𝑟}.
5. At any time in (𝐷𝑑 , 𝐷𝑠 ], only the requester can ask the smart contract to select the best timestamp on 𝑣 and to pay him or
her the deposit 𝑅 back. After 𝐷𝑠 , anyone in the blockchain can do the same (e.g., a provider) and receive 𝑅.
6. Upon request, the smart contract collects timestamps 𝑡1 , … , 𝑡|𝑃 ′ | on 𝑣 whose commitments can be verified with the corre-
sponding decommitments. Moreover, the smart contract returns 𝑅. The smart contract ignores any following request asking
again to select the best timestamp on 𝑣 and to return 𝑅.
7. In case |𝑃 ′ | < 𝐼, the smart contract refunds the requester the fees 𝑀 + 𝑆 using providers’ registration deposits 𝑁 and the
protocol aborts.
8. The smart contract selects the best timestamp from 𝑡1 , … , 𝑡|𝑃 ′ | and stores it together with value 𝑣 in the blockchain.
9. The smart contract shares fee 𝑆 among providers 𝑃 ′ that provided timestamps 𝑡1 , … , 𝑡|𝑃 ′ | . Their share is added to their
registration deposits 𝑁.
A Sybil attack is mitigated by requiring providers to pay a deposit 𝑁 to the smart contract in order for them to participate in
the protocol. Please note that the smart contract cannot prevent a provider controlling multiple identities from submitting several
timestamps in order to increase his or her chance of receiving a larger fee share. However, paying a deposit discourages him or her
from doing so.
The use of commitments and decommitments in steps 3 and 4 prevents front-running attacks. Namely, it prevents a provider
from first learning his or her competitors’ timestamps and then submitting a timestamp tailored to be selected as the best timestamp
in step 8.
The choice for deadlines 𝐷𝑐 , 𝐷𝑑 , and 𝐷𝑠 in step 2 is a trade-off between the time providers need to complete the protocol and the
fees the requester pays. On the one hand, the shorter the deadlines, the faster providers should have their transactions confirmed, and
the higher the fees, the providers should pay miners to do so. Recall that the requester covers the costs of providers on transaction
fees. On the other hand, longer deadlines allow to reduce confirmation fees but increase the time the requester should wait for the
timestamping service to attend his or her request. We estimate values to deadline in Section 6.1 empirically.
As described in step 7, if the number |𝑃 ′ | of timestamps the smart contract collects is fewer than the number 𝐼 of timestamps
the requester expects, then his or her costs of interacting with the smart contract should be reimbursed. The smart contract pays
the reimbursements debiting from the registration deposits owned by registered providers that provided faulty or no pairs of
commitments and decommitments. In this way, we incentivize registered providers to engage the protocol whenever requesters
ask a timestamp correctly.
Conversely, the requester should cover the costs of the 𝑃 ′ providers when they interact with the smart contract as expected, and
the systems reach the minimum number 𝐼 of expected timestamps. Moreover, the reward 𝑆 the requester pays the providers should
be higher than the costs of interacting with the smart contract so that providers can profit from joining the timestamping service.
Otherwise, they may ask for their registration deposits back and quit. We leave the discussion about 𝑆 and further fees or deposits
mentioned for Section 8. In the next section, we explain how to select timestamps and share rewards among providers.
5.3. Selecting timestamps and sharing rewards
In this section, we discuss strategies for selecting the best timestamp among the timestamps providers offer and for sharing fees
among these providers.
We start with the timestamp selection, which refers to step 8 of the protocol in Section 5.2. Please recall that the smart contract
selects a timestamp from the set of timestamps the providers offer. Moreover, the closer the timestamps are to the moment the
requester asks for a timestamp, the more accurate is the timestamping service. Thus, the best timestamp the smart contract can
select is that closer to the time of the request. Fig. 4 depicts an example. At 𝑡𝑅 , the requester asks the smart contract a timestamp.
Providers 𝑃1 , … , 𝑃5 offer their respective timestamps 𝑡𝑃1 , … , 𝑡𝑃5 . Timestamp 𝑡𝑃1 is the best timestamp.
However, one should bear in mind that such a set can contain discrepant timestamps. They can happen because a transaction
propagates non-uniformly in the blockchain network, and the time providers learn the transaction can differ significantly. Moreover,
9
Fig. 4. Timestamps over the timeline. Time 𝑡𝑅 is the moment when a requester requests a timestamp. Timestamps 𝑡𝑃1 , … , 𝑡𝑃5 are the times when providers
𝑃1 , … , 𝑃5 learned the request, respectively. Timestamps beyond the boundaries of the 𝑙-sized time window (dashed rectangle) are considered discrepancies.
providers may use unsynchronized clocks or deliberately lie about the time they learn a transaction. For the service to work properly,
we assume that the majority of timestamp providers are reliable and the majority of timestamps they provide is non-discrepant. We
argue that it is acceptable to assume that the majority of providers is reliable since several blockchain platforms (e.g., Ethereum)
assume that most of their participants are reliable. Since the smart contract can collect few discrepant timestamps into the set of
timestamps (step 6 of the protocol in Section 5.2), a strategy consists of selecting the median of the set. For example, timestamp
𝑡𝑃3 in Fig. 4. Although simple, this strategy falls short of selecting the best timestamp or any earlier timestamps closer to when
requesters ask for a timestamp.
Therefore, we propose a compromise between selecting earlier timestamps and avoiding discrepant timestamps as follows. Let
a time window be a range of size 𝑙 > 0 which is centered at the median of the set of the timestamps the smart contract collected
for a request. Let the subset that falls into the time window contain only non-discrepant timestamps. From this subset, the smart
contract selects the earliest timestamp as the best timestamp. Fig. 4 illustrates the window as a dashed rectangle centered at 𝑡𝑃3 .
Timestamp 𝑡𝑃2 is to be selected as the best timestamp, whereas 𝑡𝑃1 and 𝑡𝑃5 are considered discrepancies. In this way, the earliest,
non-discrepant timestamp is selected, thereby providing a more accurate timestamp.
For this selection strategy to work, we suggest that the smart contract should select the best timestamp from a set whose the
number of elements is greater than one and is odd. Greater than one because the service is intended to be decentralized rather
than relying on a single timestamp provider. An odd number of elements guarantees that at least one timestamp falls into the time
window (namely, the median timestamp) and the smart contract will select one timestamp as the best timestamp. Conversely, if
the number of timestamps is even, then the time window is not centered at any timestamp and it may happen that no timestamps
fall into the window. For example, if they are further than 𝑙∕2 from the median. It follows that the minimum size of the set of
timestamps is three.
We now turn to the sharing of rewards among providers (step 9 of the protocol in Section 5.2) based on the window-based
selection strategy. We propose to share the rewards evenly among the providers who offered timestamps falling into the selection
window. Otherwise, paying the provider whose timestamp was selected, the total rewards could tempt providers to fabricate their
timestamps in order to guess the earliest timestamp in the selection window.
A variant approach takes the providers offering discrepant timestamps also into account. More precisely, we pay just enough to
cover the full or part of the costs of interacting with the smart contract. This approach trades off between fairness and quality of
service. As of fairness, we avoid punishing the honest providers who learned transactions far earlier or later than others because of
the blockchain network’s anomalies. As of quality of service, we encourage providers to keep as many connections as possible with
blockchain neighbors so that they learn the transactions faster.
A key point left is estimating the size of 𝑙 of the time window. On the one hand, the wider the window, the higher the chance of
selecting discrepant values. On the other hand, the narrower the window, the higher the chance of selecting fewer non-discrepant
timestamps. We select empirically a size for the time window in Section 6.
5.4. Prototype
We developed a prototypical implementation for the protocol presented in Section 5.2. The implementation consists of one smart
contract and two scripts.
The smart contract contains a set of functions that participants call in order to interact with the smart contract as they engage
the protocol in Section 5.2. More precisely, a requester asks the smart contract a timestamp on a value (step 1 of the protocol) by
calling function requestTimestamp passing the value as a parameter. This function also takes care of step 2, where we set deadlines.
A provider sends a commitment (step 3) and decommitment (steps 4) to the smart contract by calling functions addCommitment and
addDecommitment, respectively. Depending on the deadlines set, either a requester or provider can ask the smart contract to select
a timestamp, store the selected timestamp together with the timestamped value, return deposits, and share rewards (step 5–9) by
calling function selectTimestamp. Table 2 summarizes these functions and the respective steps in the protocol they execute.
As of storing the selected timestamp together with the timestamped value (step 8), function selectTimestamp uses non-volatile
memory so that anyone can find them in the future. The function stores the timestamps in a dictionary to make searches efficient,
which maps the timestamped value to the corresponding selected timestamp.
The two scripts are to be used by requesters and providers, respectively. The scripts allow us to connect to the Ethereum Main
Network and send the transactions needed to trigger the execution of the above functions. Additionally, the script we created for
10
Table 2
The functions implemented in the prototype and the
respective steps of the protocol the functions execute.
Function Protocol steps executed
requestTimestamp 1–2
addCommitment 3
addDecommiment 4
selectTimestamp 5–9
providers allows them to monitor the Ethereum Main Network for transactions requesters send to call the requestTimestamp function.
Thus, providers can provide a timestamp at the moment they see the transaction for the first time.
As of programming languages, we wrote the smart contract in Solidity (Ethereum Foundation, 2017a) and the two scripts in
JavaScript. The scripts use the library web3j (Ethereum Foundation, 2017b) to access the blockchain network and run in the
NodeJS (OpenJS Foundation, 2020) runtime environment.
Our prototypical implementation is used in the next sections to conduct experiments and estimate the costs of running the
proposed protocol in the Ethereum Main Network.
6. Experiments
This section describes two experiments we conducted to evaluate our proposal as follows. First, Section 6.1 presents experiments
to find how fast transactions are propagated and eventually confirmed. We use these findings to configure the prototype to run in
the Ethereum Main Network. Then, Section 6.2 presents the evaluation of the configured prototype.
6.1. Finding transaction propagation & confirmation times
Our goal is to find how fast new transactions propagate and how long it takes for a miner to confirm them. We use nodes
connected to the Ethereum Main Network to compare the time we send a new transaction to the time Ethereum learns or confirms
it. We detail the way these times are obtained and compared in the following.
6.1.1. Experimental set-up

We use six Ethereum nodes connected to the Main Network as follows. Regularly, one node sends a new transaction to an
arbitrary address and logs the exact moment it sends it. We refer to this node as the sending node. The other nodes listen for the
new transactions sent to the arbitrary address and log the moment they see such transactions for the first time. We refer to these
nodes as the listening nodes.
The sending node broadcasts 395 new transactions for seven days. Transactions are scheduled for every 25 min from the first to
the seventh day. However, we can delay the next transaction as follows. Before broadcasting a new transaction, the sending node
queries the so-called Gas Station (Concourse Open Community, 2020) what fees miners are asking. This tool calculates average fees
for miners to confirm a transaction in up to 2, 5, and 30 min. We use 5-minute fees but apply an upper limit of 6 Gwei because
fees fluctuate widely, and our experiment was on a budget. More precisely, if 5-minute fees are over 6 Gwei, the sending node halts
for 10 s before it checks for the fees again; otherwise, the node broadcasts the transaction paying the current 5-minute fees. The
sending node can wait up to five minutes for fees to decrease to avoid indefinite delays. After that, the node broadcasts the new
transaction paying no more than 6 Gwei worth in fees. Moreover, for the experiment to last seven days, a delayed transaction does
not change the schedule of the next transactions.
As to software, nodes run go-ethereum 1.9.7 stable and parity 2.5.10 stable clients on Amazon Linux 2. The sending node needs
no copy of the Ethereum blockchain. Moreover, it should deliver the new transactions to as many neighbors as possible so that the
transaction propagates at maximum
√ speed. Kim et al. (2018) show that go-ethereum broadcasts transactions to all of its neighbors
whereas parity sends to only 𝑛 neighbors. Therefore, the sending node runs go-ethereum in the light mode (i.e., without a copy of
the blockchain). By contrast, to listen for transactions, both go-ethereum and parity require nodes to keep a copy of the blockchain.
Because parity usually demands fewer storage space than go-ethereum according to Etherscan (2020b), parity in full mode is the
choice for listening nodes. For sending and listening transactions in the Ethereum Main Network, nodes run the scripts mentioned
in Section 5.4.
We host each of the six nodes on a distinct Amazon EC2 instance. Two hardware profiles are selected as follows. For the EC2
instance where the sending node is, we select the lowest-cost t2.small profile. Namely, one virtual processor, 2GB RAM, and low
to moderate network performance. For the other instances where listing nodes need to download the blockchain and listen to the
whole traffic in the Ethereum Main Network, we choose the higher performance m4.large profile. Namely, two virtual processors,
8GB RAM, and high network performance.
We placed the EC2 instances in different geographical locations to mimic node distribution in the Ethereum Main Network. The
instance hosting the sending node sits in Ohio (United States). The other instances hosting listening nodes are in Northern Virginia
(United States), São Paulo (Brazil), Frankfurt (Germany), Seoul (South Korea), and Sidney (Australia). We place two nodes in the
United States because, as of the time of this experiment, it is the country where most of the known nodes of the Ethereum Main
Network concentrate (Gmbh, 2020). Moreover, nodes select their neighbors randomly (Kim et al., 2018). Therefore, geographically
close nodes may not be neighbors.
11
Table 3
The number of neighbors of each node.
Node location Avg Std Dev Min Max
Ohio 18.19 3.12 12 27
Northern Virginia 37.81 1.72 34 42
São Paulo 37.08 1.24 34 41
Frankfurt 38.38 1.39 35 42
Seoul 39.17 1.43 36 43
Sidney 39.24 1.01 36 43
Table 4
The time nodes needed to learn transactions. The rightmost column
shows the percentage of transactions one node learned faster than the
other nodes.
Node location Avg (ms) Std dev Tx Learned faster (%)
Frankfurt 151.36 71.45 56.63
Northern Virginia 157.52 78.45 34.18
Seoul 198.84 70.23 7.91
São Paulo 206.17 76.40 0.77
Sidney 228.99 63.95 0.51
All locations 188.35 78.06 –
6.1.2. Results
We experimented with 23 to 30th of November 2019. Next, we present collected data on the number of neighbors, the time
nodes need to learn transactions, and how fast miners confirm transactions. Because nodes we connect in a peer-to-peer network,
where data propagation is non-uniform, discrepant samples may occur. When this is the case, we identify them as outliers according
to the Interquartile Range Method (Forsyth, 2018).
Nodes should connect to at least one other node in the Ethereum Main Network to send or receive transactions. Also, the more
connections nodes establish, the faster they propagate and learn transactions. Table 3 shows the number of neighbors the nodes kept.
As can be seen, no node was isolated from the network during the experiment. However, the node in Ohio, which runs go-ethereum
client and sends new transactions, slightly differs from the others. More precisely, the average of neighbors was lower and varied
more.
The time that listening nodes need to learn transactions allows us to understand how fast transactions propagate. We computed
these times as the difference between the time a listening node learns the transactions and the time the sending node sends the
transactions. These times are in milliseconds, which is the standard precision NodeJS runtime provides. We first present the times
computed, considering no outliers. Table 4 summarizes our findings. The rightmost column shows the percentage of transactions
one node learned faster than the other nodes.
As can be seen in Table 4, nodes needed 188.35 ms on average to learn a transaction in the Ethereum Main Network. However,
these times vary significantly due to the non-uniform propagation of transactions in the peer-to-peer network. Namely, the standard
deviation corresponds to more than 40% of the average. The observed variance in the speed which transactions propagate prevents us
from estimating precisely how long it takes from the moment one requests a timestamp to a timestamping service in the blockchain
and the moment the service attends the request. Therefore, we can assume that an average network latency of 188.35 ms and
deviation of 40% on propagation times impose a lower bound to the accuracy of the timestamps these services provide.
Table 4 also shows that being geographically closer to the place where a transaction originates is no guarantee of learning
transactions faster. On the one hand, the node in Frankfurt, which is further away from Ohio than Northern Virginia is, needed
the shortest mean time to learn transactions and was the first node to spot more than half of all transactions. On the other hand,
the node in Northern Virginia learned transactions faster than Seoul, São Paulo, and Sidney, which are further away from Ohio
than Northern Virginia is. Nevertheless, three transactions reached Northern Virginia and Frankfurt simultaneously before being
delivered to the other nodes. We ruled out these three transactions in the rightmost column in Table 4.
As of outliers, discrepant values occur due to the non-uniform propagation in peer-to-peer networks. Outliers add up to 9.72%
of the computed times to learn a transaction. Moreover, the maximum time to learn a transaction was 32.6 min, which is more than
10.000 times as large as the mean time when dropping outliers. By contrast, the minimum time was 39 ms.
To better understand how outliers affect the time listening nodes learn a transaction, we present the times a transaction takes to
reach one, two, three, four, and five listening nodes. Fig. 5 reveals, around 98% of the transactions took up to one second to reach
the first node, which is more than five times as larger as the mean time of 188.35 ms.
We now compare the moments the listening nodes learned the transactions. More precisely, we compute the difference between
the moments when the first and the last nodes learn a transaction. We refer to this difference as time window. Outliers are time
windows greater than 222.25 ms and add up to 17.47% of the computed windows. Fig. 6 illustrates the frequency distribution of
time windows. As can be seen, around 90% of the windows are not greater than 1 s.
For the times presented above, we do not distinguish between the fees the sending node paid miners to confirm transactions.
Please recall that the sending node pays no more than 6 Gwei for miners to confirm a transaction in up to 5 min. Since fees fluctuate,
12
Fig. 5. The time transactions take to reach listening nodes.
Fig. 6. The difference between the times when the first and the last node learn transactions.
Table 5
The time miners use to confirm transactions. Transactions pay
either full or partial fees miners ask to confirm transaction in up
to 5 min.
Fees Avg (s) Std dev Min (s) Max (s)
Full 28.53 37.22 −33.15 1942.81
Partial 39.46 44.14 −6.64 6422.10
and this experiment was in a budget, not all transactions rewarded miners with full fees. It turns out that 71.65% of all transactions
paid full fees while the remaining paid partial fees. As of the mean speed, partial-fees transactions were 48.89% slower, and the
corresponding standard deviation was 9.48% higher. We expect such a mean since high transaction fees indicate that the network is
overloaded with transactions to be confirmed. As such, one can expect transactions to propagate slower. Conversely, we have found
no evidence in the source code of parity and geth that nodes prioritize propagating full-fees transactions over partial-fee transactions.
Next, we turn to the time miners used to confirm the transactions the sending node issues. We compute such a confirmation
time as the difference between the timestamp of the block confirming the transaction and the time the sending node issued the
transaction. Again we need to take transactions paying partial or full fees into account. Table 5 presents confirmations times in
seconds (s) and distinguishes them between transactions paying full and partial fees. Outliers are confirmations times smaller than
−101.00 s or higher than 187.00 s, and they add up to 13.67% of the transactions the sending node issued.
As Table 5 shows, confirmation time varies significantly. Namely, the average confirmation time can vary more than 100%.
Recall that partial-fees transactions paid 6 Gwei to miners while they were asking higher fees for confirming transactions in up
to 5 min, probably due to the network was overloaded. Because miners should have prioritized higher-fees transactions and the
network should have been overloaded, the partial-fees transactions took longer to be confirmed on average but far less than the
5 min expected.
Interestingly, we found an anomaly. Namely, 12.41% of the confirmation times were negative. More precisely, the timestamp
of the block is earlier than the moment when the sending node created the transaction. Such occurrence suggests that miners may
13
Fig. 7. The time miners took to confirm transactions paying full or partial 5-minute confirmation fees.
not refresh the timestamp of a block if they learn a new transaction after they started mining the block. Section 7 provides some
evidence supporting this claim. It follows that the timestamp miners assign to a block may be used to backdate a transaction packed
in that block.
The confirmation time encompasses the time to learn a transaction and the time to mine a block. However, since the times
to learn and confirm transactions are in terms of milliseconds and seconds, respectively, the time to learn transactions ends up a
negligible fraction of the confirmation time.
We illustrate the distribution of confirmation times in Fig. 7. As can be seen, 91% of transactions paying full 5-minute
confirmation fees were confirmed in no more than 180 s, which is less than 5 min. By contrast, we saw only 80% of transactions
paying partial 5-minute fees confirmed in up to 5 min. Note, however, that these times should be analyzed with caution because
the time a transaction was confirmed may have been backdated some tens of seconds, as we pointed out before. Because of this and
since most of the transactions paying full fees were confirmed within the expected time, we use only transactions paying full fees
in the next experiment in Section 6.2.
6.2. Evaluating the prototype
In this section, we evaluate the prototypical implementation of our proposal presented in Section 5.1 in the Ethereum Main
Network.
6.2.1. Experimental set-up

The set-up is similar to that in Section 6.1. The difference is that the sending and listening nodes engage the protocol described
in Section 5.2 together with the prototypical implementation of the smart contract. More precisely
1. the sending node issues transactions requesting timestamps to the smart contract;
2. upon noticing such a transaction, the listening nodes submit a commitment to the times when they noticed the transaction;
3. the listening nodes reveal their times; and
4. the sending node asks the smart contract to select a timestamp using the time window approach presented in Section 5.3.
To set up the parameters of the smart contract, we use the results in Section 6.1.2. Namely, we set the period between consecutive
steps 3, 4, and 5 of the protocol in Section 5.2 to 180 s, which is the time 91% of the transactions took to be confirmed. As of the
selection of the best timestamp revealed by the listening nodes, we set the time window to 1 s, which is greater or equal to 90% of
the time windows found in Section 6.1.2.
We experimented on the 3rd of December 2019 for 24 h. The sending node was programmed to issue one transaction per hour,
requesting a timestamp to the smart contract. As of fees, we set the sending node to pay the full fees miners asked for confirming the
transaction in up to five minutes as long as the sending node has enough funds to pay. If it has no enough funds, then the sending
node waits up to five minutes for fees to decrease. If they do not, the sending node calls off the scheduled transaction. Note please
that, in contrast with the previous experiment, the sending node issues no transaction paying fees partially.
6.2.2. Results
The sending node was programmed to issue 24 transactions requesting a timestamp to the smart contract. Nonetheless, the
sending node issued 21 transactions successfully and aborted issuing three transactions because of the amount of fees miners asked
were higher than the funds the sending node had. For the 21 transactions issued, all nodes and the smart contract completed the
protocol described in Section 5.2. That is, the five listening nodes successfully provided the timestamps when they noticed the
14
Fig. 8. The frequency distribution of the timestamps that fitted in the 1-second time window.
transactions issued by the sending node. This behavior shows that the 180-second period for listening nodes to commit to or to
reveal a timestamp is suitable.
Next, we present the number of timestamps the smart contract collected for each transaction the sending node issued. Please
recall that for each transaction, we provide five timestamps by the listening nodes, and the smart contract collects the provided
timestamps that fit in the time window. Fig. 8 shows that at least three timestamps fitted in the time window for 20 out of 21
issued transactions. For only a single issued transaction, some timestamps the listening nodes provided were discrepant and only two
timestamps fitted in the time window. This difference corroborates that a 1-second time window was adequate to select the majority
of offered timestamps in most of the times. Nonetheless, please recall that we derived the time window size from observations of
the Ethereum Main Network in the last week of November 2019 and we tested whether the time window size was adequate in the
following week. If the network activity were significantly higher in the following week (e.g., due to an ICO), the 1-second time
window might have been inadequate because the listening nodes could take longer to learn the requests and would provide times
that would not fit the time window. By contrast, the time window size depends neither on the number of listening nodes nor on
transactions. Therefore, the 1-second time window should be adequate to a distinct service set-up. For instance, a greater number
of listening nodes or transactions in the experiment.
We now turn to the best timestamp among the collected timestamps. Recall that the best timestamp is the earliest timestamp
within the time window. We compare the time the sending node issued the transactions requesting a timestamp with the best
timestamps the smart contract selected. On average, we found that the best timestamp is 121.10 ± 37 ms later than when the sending
node requests a timestamp.
Finally, we count the number of timestamps that each listening node provided and that the smart contract selected as the best
timestamps. As Fig. 9 depicts, the listening nodes in Northern Virginia and Frankfurt provided most of the best timestamps. In
contrast with the previous results in Section 6.1.2, it follows that the node in Northern Virginia was the fastest node to spot most
of the transactions, thereby providing the earliest timestamps.
7. Investigating backdated transactions
Section 6.1 reports the unexpected fact that the timestamp of a block confirming a transaction can be earlier than the moment we
create this transaction. This happened for 12.41% of the transactions we created in the experiment and it allows us to backdate these
transactions if we use the block timestamp as a time reference. In this section, we provide some evidence supporting a possible reason
for that unexpected fact. First, we assume miners backdate transactions unintentionally. That is, they do not deliberately fabricate
the timestamp of blocks (e.g., by choosing any earlier timestamp provided that it is at least one second later than the previous block
timestamp), but rather they assign the current time to the timestamp. This assumption is plausible since the majority of miners is
supposed to be honest. As such, we claim that miners can inadvertently backdate transactions if they (a) add new transactions to a
block after they set up the timestamp and started mining the block, and (b) not necessarily update the timestamp when they add
new transactions to the block being mined. Next, we provide some data that supports our claim.
We start by distinguishing the backdated transactions observed in Section 6.1 by the fees they paid and the number of seconds
they were backdated. As Fig. 10 depicts, the majority of backdated transactions paid full fees. They amount to 87.76% of all
backdated transactions. Moreover, the difference between the moment they were created and the block timestamp is not greater
than 15 s, which is the average time for miners to come up with a new block. This finding suggests that miners add new transactions
to a block being mined not only before they start mining this block but also while they are mining it (especially if the full fees that
15
Fig. 9. The location which provided the best timestamps.
Fig. 10. The distribution of backdated transactions we observed in the experiment of Section 6.1. Most of these transactions paid full fees and were backdated
to not more than 15 s in the past.
the new transactions pay are an economic incentive). Otherwise, every transaction learned while the miner is mining a block, that
is, while the miner engages in a mining round, would have to wait until the miner stops mining (e.g., because it learned a fresh
block from a competitor or succeeded in mining its own block) and prepares a new block that will be mined in the next round and
that contains an up-to-date timestamp which is later than the moment the transactions were learned. If this were the case, we would
have observed no block timestamps which are earlier than the moment we created transactions.
Next, we turn to our claim that miners do not necessarily update the timestamp of the block being mined when they add a new
transaction to it. One could verify this claim by comparing the moment a miner learned a transaction to the timestamp of the block
where the miner put the transaction. Unfortunately, this is not feasible in a public blockchain such as Ethereum because one cannot
control the miner which mines the next block.
Instead, we take a distinct approach to verify our claim. More precisely, we compare the time we learn a new block to the
timestamp of the next block (i.e., a parent block and its child, respectively). Let us first assume that a fresh block needs negligible
time to travel from its miner to us or other miners, and that miners start over the mining process every time they learn any fresh
block. Thus, if the moment we learned a parent block turns out to be approximately the timestamp of its child block, then it means
that the miner of the child block set the timestamp to the moment when he or she learned the parent block and did not update that
timestamp while mining the child block.
Since we did not collect the times we learn blocks in the experiments of Section 6, we use data collected from a previous
experiment we conducted with a similar set-up from 16 to 22 July of 2019. We set up four light nodes running parity 2.5.5 stable in
distinct cities. Namely, Ohio (US), Frankfurt (Germany), Seoul (South Korea), and Florianópolis (Brazil). These nodes wrote down
16
Fig. 11. The difference between the moment our nodes learn a fresh block and the timestamp of the next fresh block. The short differences suggest that miners
take few seconds to learn a block because of network latency, and assign the time they learned a new block to the timestamp of the next block they will mine.
the time they learn a fresh block together with the block number and timestamp. The nodes learned the same set of blocks. This
set contained 37703 blocks.
Then, we compute the difference between the earliest moment when the nodes learn a block and the timestamp of the next block.
The reason to choose the earliest moment is to minimize the time nodes needed to learn blocks due to network latency. Fig. 11
illustrates a histogram of the computed differences.
We found out that 97.51% of the computed differences lie between −5 and 5 s. We argue that these differences are due to the
network latency and that they provide evidence supporting that miners do not update the timestamp of a block being mined. The
reason is that the latency is consistent with the time nodes took to learn transactions in the experiment of Section 6.1. Moreover, if
miners had updated block timestamps at any time, then we would have observed differences laying uniformly over the average time
of a mining round, which is 13 s in Ethereum. This indicates that miners set the timestamp of the next block to be mined before they
start mining but not while they are mining it. Thus, the moment miners set a timestamp and the fact that they can occasionally add
new transactions to the block in the middle of a round of mining can explain why backdated transaction occur even if the majority
of miners is honest.
8. Cost evaluation & comparison
This section presents a cost analysis of the protocol described in Section 5.2. Since requesters cover the timestamping service
costs, we estimate the price requesters should pay for a timestamp so that the service is financially viable. We intend to have a
simple financial analysis to derive a timestamp price that allows providers to profit. As such, the timestamp price should cover:
1. miners’ fees for confirming blockchain transactions;

2. the costs of hosting a provider in a data center; and
3. a reward paid to providers for offering timestamps.
We present the timestamp price in U$ as of this writing—namely, the 16th of April 2020.
We start with miners’ fees. Please recall that requesters and providers engage the protocol by interacting with the smart contract.
To this end, they address transactions to the smart contract identifying a function. Miners confirm such transactions and execute
the smart contract functions. Table 2 lists the functions which are available in our smart contract prototype and which we call in
each step of the protocol. We estimate miners’ fees by summing the cost of executing any function as the protocol is engaged. To do
so, we gauge the computational cost of each function for gas and then multiply the number of gas by the gasPrice miners ask. Since
the result is in terms of the Ethereum cryptocurrency Eth, we convert to U$. Note that miners’ fees can fluctuate widely depending
on mining demand and Eth/U$ exchange rate.
Gauging the computational costs requires summing the individual gas of each machine instruction found in the smart contract
functions. We use programming tools such as Remix to automate this complex, error-prone task. However, it cannot count specific
variable-cost instructions. For example, the instructions we use to map values to timestamps in non-volatile memory. For this reason,
we gauge the costs for each function by averaging the exact units gas miners used to confirm the function in the experiment described
in Section 6.2. Since the gas unit is indivisible, we round the cost to the nearest integer. Table 6 summarizes the average cost and
standard deviation in terms of gas for each function.
As of this writing, miners ask 12 × 10−9 Eth per gas unit, and Eth is U$ 170.10 worth. Table 6 presents the average price and
standard deviation in U$ for each function participants can call.
17
Table 6
The computational costs (Gas) and price (U$) of executing the smart
contract functions on the 16th April 2020 in the Ethereum Main Network.
Function Avg gas Std dev gas Avg U$ Std dev U$
requestTimestamp 135,366 23 0.23242 0.00003
addCommitment 83,872 10,763 0.14401 0.01848
addDecommitment 63,192 4,879 0.10849 0.00838
selectTimestamp 174,593 16,225 0.29978 0.02786
Table 7
An example of the price a requester pays for a timestamp as a function of timestamp sales.
Five providers are used as source of time for the timestamps. Providers use Amazon’s
m4.large hosting facility and pay a deposit of U$ 10,000 to the smart contract. As of 16
April 2020, their annual gross return rate is 17.86%.
Timestamp Cost distribution (% of price)
Sales/year Price (U$) Miners’ fees Hosting fees Providers reward
10 187.8541 0.9554% 3.9926% 95.0520%
100 20.4006 8.7973% 3.6765% 87.5263%
1,000 3.6553 49.0987% 2.0519% 48.8495%
10,000 1.9808 90.6067% 0.3787% 9.0147%
100,000 1.8133 98.9739% 0.0414% 0.9847%
1,000,000 1.7966 99.8964% 0.0042% 0.0994%
We now estimate the total fees miners ask by summing the cost of calling each function when a requester and providers
engage a protocol. Remember that the requester defines the minimum number 𝐼 > 2 of providers offering timestamps. For the
sake of simplicity, assume that exactly 𝐼 providers offer timestamps. Moreover, let us rule out the standard deviation to facilitate
understanding the math. (In a more detailed analysis, standard deviation should be considered to estimate upper and lower bounds
on costs.) It follows that functions addCommiment and addDecommitment are executed I times, whereas requestTimestamp and
selectTimestamp are called a single time. Therefore, miners’ fees add up to U$ 0.5322 + 𝐼0.2525.
Next, we turn to the costs of hosting a provider (i.e., a listening node) in a data center. As presented in Section 5.4, providers
use a script that allows them to listen for transactions in the blockchain and address the smart contract transactions containing the
offered timestamp. An Amazon EC m4.large instance is sufficient for such a service. Therefore, we assume the hosting costs to be
the costs of hiring an m4.large instance. As of this writing, m4.large instances in the same geographical locations we chose cost U$
420.042 per year on average.
The reward paid to providers refers to the profit they make from offering timestamps. Recall please that, in addition to paying
hosting costs, providers must pay the smart contract a deposit to get paid for offering timestamps. Therefore, we estimate the
providers’ reward so that it is higher than their opportunity cost. That is, the reward should compensate the gains providers lose by
investing in timestamping instead of other alternatives.
For a risk-free alternative, let us choose the 1-Year U.S. Treasury Bill. As of the writing, this bill pays investors an annual interest
rate of 0.19% before subtracting the taxes. To compensate providers for not choosing it, they should receive a risk premium. Namely,
the annual return rate for offering (i.e., selling) timestamps should be higher than the interest rate paid by the 1-Year U.S. Treasury
Bill after paying taxes. Let the risk premium be 15%. For the sake of simplicity, let us assume that a median marginal tax rate of
24% (Tuovila, 2020) and an average sales tax of 7% (Cammenga, 2019) apply on the income from U.S. Treasure’s interest and on
timestamp sales, respectively. Doing the math yields, the gross reward to be paid to providers should be 17.86% of the capital they
invested (namely, the hosting costs together with the deposit on the smart contract).
Recall please that providers must pay the smart contract a deposit in order to prevent Sybil attacks. Quantifying a reasonable
deposit 𝑁 that avoids Sybil attacks we leave for future work. Thus, we expect providers to pay a total of U$ 𝑁 + 420.042. It follows
the annual gross return of selling timestamp is U$ 0.1786𝑁 + 75.01950.
As of the final price requester pays for a timestamp, it also depends on the demand for timestamps. The more timestamps
providers sell, the lower the ratio between the gross reward and the number of timestamps, and the lower the timestamp price is.
For simplicity, we assume that all timestamps which providers offer fit in the time window such that the providers evenly share the
reward.
The price 𝑃 (𝐼, 𝑁, 𝐸) for a timestamp can be given as a function of the number of providers 𝐼 engaging the protocol, the deposit
𝑁 providers pay, and the expected number 𝐸 of timestamp sales combined with the computed values for miners’ fees, hosting fees,
and rewards such that
0.1786𝑁𝐼 + 75.01950𝐼
𝑃 (𝐼, 𝑁, 𝐸) = 0.5322 + 0.2525𝐼 + . (1)
𝐸
We next provide an example in Table 7. For this, we plug in 𝐼 = 5, 𝑁 = 𝑈 10, 000, and 𝐸 = 10, 100, … , 100000 in Eq. (1). Note
please that as sales increases over 10,000 timestamps/year, timestamp prices decrease slowly, and almost the total sales income is
to pay miners’ fees. We discuss the implications of miners in the price equation in the next section.
18
9. Discussion
We start by discussing the parameter values we plug into the smart contract to evaluate it in the Ethereum Main Network.
We obtained these values from observations of the network for one week. However, activity in that network may change in the
following weeks, as do the observed values. For example, we saw overload in the Ethereum Main Network due to online games and
initial coin offerings (Kharif, 2019). Therefore, regularly updating the smart contract parameters is suggested for a fine-tuning of
the timestamping service we propose.
The 180-second confirmation time, i.e., the time we chose for miners to confirm the transactions that participants send to the
smart contract as they engage the protocol, turned out to be appropriate. This appropriate time is because no transaction missed
the confirmation deadline. We could expand this time without harming the accuracy of timestamps concerning transactions. The
reason is that providers rather than miners provide timestamps, and they do so as soon as they learn transactions. However, by
expanding the confirmation time, timestamp requesters could trade-off lower miners’ fees for a longer time for the smart contract
to attend their requests.
By contrast, choosing the correct size for the time window is critical for timestamp accuracy. The window filters out discrepant
timestamps. However, there is a trade-off between the length of the window and the number of useful timestamps collected. On the
one hand, the larger the time window, the higher the chances of collecting discrepant timestamps. On the other hand, the narrower
the time window, the fewer timestamps are likely to be collected. At least one timestamp from a provider is always collected (viz.,
the median timestamp). However, since our goal is to provide a decentralized service, one expects the smart contract to select at
least three timestamps.
Moreover, we can expand the time window when we overload the Ethereum network since providers may learn transactions at
very distinct moments. Otherwise, most of the timestamps that providers offer is likely to be outside the window. In our experiment,
we set the smart contract to filter out discrepant timestamps using a 1-second time window. Similar to the first experiment in
Section 6.1, 91% of the offered timestamps fitted in the window. All the discrepant timestamps that the smart contract filtered out
were beyond the right boundary of the window. That is, all discrepant timestamps were given by the provider that took too long to
learn the timestamp request. It follows that the smart contract selected the earliest timestamp as the best timestamp, which is that
closer to the moment when the requester asked a timestamp.
The accuracy of the timestamps in our scheme is the difference between the best timestamp and the moment the requester
addresses the smart contract a transaction requesting a timestamp. The mean accuracy observed is 121.10 ± 37 ms. Compared to the
expected accuracy we estimate from the time between two consecutive blocks in Section 4, our proposal is at least 53 times more
accurate. This accuracy is a significant improvement, but it may not be accurate enough for some scenarios, such as stock market
timing. According to Broby, Basu, and Arulselvan (2019), the timestamps needed to avoid front-running attacks in the stock markets
should be subject to nanosecond stacking. The authors claim that this is possible using a distributed ledger that they do not identify.
In contrast, experiments reveal that the public peer-to-peer network rather than the blockchain platform imposes a lower
bound on the accuracy of timestamps. There may still be room to reduce this lower bound and corresponding variance if we use
permissioned peer-to-peer networks. In permissioned peer-to-peer networks, we can identify participants and establish connections
among them such that the routes that transactions take contain the minimum number of hops, and these hops do not change often.
Even though, we should not expect transactions to propagate on the order of nanoseconds. The reason is that the propagation
delays in wide-area networks are on milliseconds (Kurose, 2017), which is the same we observed for transactions in the Ethereum
Main Network. In addition to that, performing cryptographic operations on blockchain data may be a non-negligible obstacle to
nanosecond stacking. For example, Ethereum transactions should contain a 256-bit ECDSA signature, which requires around 350
nanoseconds to be computed by a 2.6 GHz dual-core Intel Core i5 processor according to the OpenSSL speed benchmark (OpenSSL
Software Foundation, 2018).
The experiments on Sections 6.1 and 6.2 indicate that the timestamps our proposal provides are potentially more reliable than
those miners apply on blocks. By comparing the time we create a transaction to the timestamp miners apply on the block confirming
the transaction, we observed that the block timestamp could be earlier. The reason seems to be that the miners may add new
transactions to a block after they have set the timestamp and started to mine the block (see Section 7). Thus, we may succeed
in backdating a transaction if we pay sufficient fees for the transaction to be confirmed in the next block being mined, which is
a severe flaw for a timestamping service. To avoid this issue, our smart contract-based service relies on no block timestamps that
miners provide, but rather on the timestamp of the moment when special nodes learn transactions. Moreover, a smart contract filters
discrepant timestamps out.
By contrast, block-based timestamping protocols have a lower overhead than our smart contract-based solution. More precisely,
whereas block-based protocols need only a single transaction for them to timestamp a value in a block, our protocol requires
additional two transactions per timestamp provider (viz., a commitment and the corresponding decommitment) and one transaction
asking the smart contract to select the best timestamp. Consequently, users of block-based timestamping protocols should wait
shorter and pay less for their timestamps to be issued.
The timestamps our proposal offers are more expensive than RFC3161 timestamps. In our proposal, the price per timestamp is
around U$ 1.79 when the number of timestamps to be sold is high, whereas RFC3161 timestamps can cost few cents (DigiStamp
& Inc, 2020) or even less than one cent (Solutions Notarius Inc., 2020). Although our proposal is decentralized and should reward
more participants than RFC3161 schemes do, Table 7 reveals that the significant part of the price of our timestamps is to cover
miners’ fees. To reduce fees, we should reduce the number of transactions participants issue while engaging the protocol. To this
end, at least two strategies where participants communicate data using off-chain means are possible.
19
In the first strategy, providers send decommitments to the timestamp requester rather than the smart contract (step 4 of the
protocol in Section 5.2). Then, the requester sends the smart contract a single transaction containing all decommitments. Since
Ethereum establishes a minimal cost of 21.000 gas for each transaction to prevent the network from being abused, this strategy
allows cutting fees. More precisely, empirical tests with five providers engaging the protocol revealed that we could reduce fees in
20%. Note that we can further reduce the fees if we apply the same procedure to commitments (step 3 of the protocol). However,
this would allow a timestamp requester to boycott providers by dropping commitments without arising suspicion.
A second strategy consists of using the so-called general state channel networks (Dziembowski, Faust, & Hostáková, 2018). In
this approach, participants engage the protocol in an off-chain way by executing a local copy of the smart contract and sharing the
smart contract states by exchanging digitally signed messages with other participants. At any time, the participants can register the
current state of their local smart contract in the original smart contract in the blockchain. In case they disagree on the local state,
the real smart contract can solve the dispute. Although the approach could reduce fees in our proposal significantly, we claim that
participants could collude without being noticed. More precisely, participants could run the protocol incorrectly and agree on an
inaccurate timestamp. While conducting this research, frameworks for implementing off-chain Ethereum-like smart contracts were
incipient and lacked comprehensive documentation. For instance, the Perun (Perun Network, 2020) framework.
A question that remains open is the initial deposit providers should pay in order to engage the protocol and profit from offering
timestamps. The deposit has a minor effect on the price of timestamps when compared to miners’ fees. Nonetheless, defining how
large this deposit should be in order to prevent Sybil attacks is not easy. One reason is that paying the deposit should impose a
dishonest provider a cost that is not less than the benefits from obtaining an inaccurate timestamp. Since we need timestamps in
several scenarios (e.g., patents registration and auction bids), it is hard to precisely identify what benefits a dishonest provider can
obtain in each scenario. Nonetheless, we can sort providers into distinct groups as to the size of the deposit they pay. Providers that
pay more significant deposits can be regarded as more reliable and could ask for higher rewards.
When it comes to security, our proposal excels at RFC3161 timestamps in two aspects. First, RFC3161 timestamps remain
secure provided that the used signature algorithm, keys length, and hash algorithm remain secure (Vigil et al., 2015). By contrast,
blockchain-based timestamps depend on the used hash algorithm only. Because key lengths are secure for fewer years than the
lifetime of hash algorithms, we expect blockchain-based timestamps to last longer than RFC3161 timestamps.
The second security aspect has to do with the resilience of timestamps. If an issuer of RFC3161 timestamps (i.e., a timestamp
authority) is compromised, any timestamps it has ever issued is not supposed to be trusted. This problem happens because one
cannot distinguish authentic timestamps issued before the issuer was compromised from false, backdated timestamp issued afterwards.
Nevertheless, a similar problem arises when the certification authority that provides a digital certificate to the timestamp authority is
compromised. It can issue a false certificate that one could use to sign backdated timestamps on behalf of the timestamp authority.
This situation is a well-known problem we mitigate by establishing the relative ordering of issued timestamps in a hash-based
linked list similar to a blockchain. More precisely, a timestamp authority adds to every timestamp the hash of the previous
timestamp (Haber & Stornetta, 1991). Also, we can publish some of the linked timestamps on a widely visible medium, e.g., a
newspaper (Surety, 2003). As such, although a timestamp authority is compromised, one could still trust its issued timestamps
because the relative ordering can help identify which timestamps have not been backdated. Maniatis and Baker (2002) propose that
two or more timestamp authorities interweave their hash-based linked lists so that the relative ordering of their timestamps holds if
at least one timestamp authority is not compromised. By contrast, the timestamps our proposal provides are not called into question
if a provider is compromised as long as the majority of providers are trustworthy when we issue timestamps. Moreover, please note
that our proposal needs no additional relative ordering guarantees or a widely visible medium since the blockchain itself provides
them. However, although we showed the timestamp on a block to be inaccurate, to some extent, it can be used to verify a timestamp
our proposal creates.
Finally, one could use our timestamping scheme on other blockchain systems as long as they provide a broadcast protocol and
supports smart contracts. A broadcast protocol is necessary to send a timestamp request to all providers such that they have the
same chance of attending it as soon as possible. Smart contract support is needed to decentralize the selection of timestamps.
More precisely, our scheme requires a shared memory, Turing-complete execution environment where multiple parties agree on
the execution of a script that selects timestamps. The script does not depend on any specific consensus algorithm the blockchain
system runs. Other blockchains that provide broadcast and smart contracts and could also run our scheme are Hyperledger
Fabric (Androulaki et al., 2018) and EOS (block.one, 2018). By contrast, we may need to significantly change our scheme in order
to run it on some blockchain systems. For example, R3 Corda (Brown, 2018) provides distinct broadcast and execution models.
By default, the Corda network does not broadcast data to all parties but sends it to the relevant parties only when they need to
see it. Therefore, our scheme should be changed such that a timestamp requester can discover the set of providers and sends a
request to each provider individually (Newton, 2019). On the one hand, this would allow the requester and a subset of providers
to collude without being noticed. On the other hand, since Corda secures one-to-one communication channels, providers would
learn no timestamps from its competitors, turning the commitment protocol no longer necessary. As of the execution model, Corda
smart contracts can only establish how transactions should consume inputs and produce outputs. Consequently, we would need to
change our scheme such that a timestamp requester rather than the smart contract selects the best timestamp from a set of collected
timestamps and proposes a transaction whose output is the best timestamp and input is the set of collected timestamps, while the
Corda smart contract only verifies that the transaction input and output are consistent with the selection strategy.
20
10. Conclusions & future work
Several timestamping services build on top of a blockchain by sending transactions containing the data to be timestamped to
the blockchain and using the time miners allegedly create blocks as a timestamp on the data. We showed that such block-based
timestamps might not be accurate because one cannot precisely predict how long a transaction will wait before miners pack it into
a new timestamped block. This problem is also real because nodes in the blockchain tolerate tens of seconds of deviation in the
new block’s timestamp. Experiments on the Ethereum blockchain revealed that such tolerance allowed to backdate a transaction in
33.15 s, which is a severe flaw in timestamping services.
Aiming at higher accuracy, we designed a decentralized timestamping service that combines smart contracts with external time
providers. A timestamp request is a transaction that contains a value we want to timestamp, and we address such transactions
to an Ethereum smart contract. Providers also send the smart contract the timestamp of the exact moment they learned such a
transaction. The smart contract filters out discrepant timestamps and selects the earliest timestamp. The mean accuracy of our
timestamps, i.e., the difference between the time we make a request and the timestamp the smart contract selects, is 121.10 ± 37 ms.
This accuracy is significantly higher than that found in block-based timestamps.
We conducted a cost analysis in order to approximate how much our decentralized timestamps should cost in order for our
proposal to be financially viable in the Ethereum blockchain. The analysis left open an exact deposit the providers should pay in
order to mitigate Sybil attacks. The results showed that our timestamps could be at least 90 times more expensive compared to
centralized timestamps sold in the market. The main reason for such a higher price is the fees miners ask.
The cost and network analysis suggest that our proposal could benefit from a permissioned blockchain, where we authenticate
providers. By doing so, we can not only prevent Sybil attacks but also rule out deposit payments and miners’ fees from the cost
equation for timestamps. Furthermore, we can establish direct and more stable connections than those found in the Ethereum peer-
to-peer network, which could improve accuracy. Investigating such an approach is in our roadmap for future work. Moreover, since
some use cases cannot give up the security that public blockchains provide, additional future work includes evaluating the accuracy
of timestamps in the forthcoming Ethereum 2.0.
CRediT authorship contribution statement
Gabriel Estevam: Conceptualization, Software, Investigation, Data curation, Formal analysis, Writing - review & editing. Lucas
M. Palma: Conceptualization, Software, Writing - original draft, Investigation. Luan R. Silva: Software, Investigation, Data curation.
Jean E. Martina: Writing - review & editing, Funding acquisition. Martín Vigil: Conceptualization, Writing - original draft, Project
administration, Supervision.
Acknowledgments
This work has been supported by BRy Tecnologia (BR) [Termo de Convênio 2019/007, Processo UFSC 23080.064150/2018-31]
and financed in part by the Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - Brasil (CAPES) - Finance Code 001.
References
Ali, M., Nelson, J., Shea, R., & Freedman, M. J. (2016). Blockstack: A global naming and storage system secured by blockchains. In 2016 USENIX annual
technical conference (pp. 181–194). Denver, CO: USENIX Association, ISBN: 978-1-931971-30-0, https://www.usenix.org/conference/atc16/technical-sessions/
presentation/ali.
Alsunaidi, S. J., & Alhaidari, F. A. (2019). A survey of consensus algorithms for blockchain technology. In 2019 international conference on computer and information
sciences (pp. 1–6). IEEE, http://dx.doi.org/10.1109/iccisci.2019.8716424.
Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., Caro, A. D., Enyeart, D., Ferris, C., Laventman, G., Manevich, Y., Muralidharan, S., Murthy, C.,
Nguyen, B., Sethi, M., Singh, G., Smith, K., Sorniotti, A., Stathakopoulou, C., Vukolic, M., Cocco, S. W., & Yellick, J. (2018). Hyperledger fabric: a distributed
operating system for permissioned blockchains. In R. Oliveira, P. Felber, & Y. C. Hu (Eds.), Proceedings of the thirteenth eurosys conference (pp. 30:1–30:15).
ACM.
Badertscher, C., Gazi, P., Kiayias, A., Russell, A., & Zikas, V. (2019). Ouroboros chronos: Permissionless clock synchronization via proof-of-stake: Tech. rep., Cryptology
ePrint Archive, Report 2019/838.
Baniata, H., Anaqreh, A., & Kertesz, A. (2021). PF-BTS: A privacy-aware fog-enhanced blockchain-assisted task scheduling. Information Processing & Management,
58(1), Article 102393. http://dx.doi.org/10.1016/j.ipm.2020.102393.
Bertoni, G., Daemen, J., Peeters, M., Assche, G. V., & Keer, R. V. (2018). Keccak team (online). https://keccak.team/index.html. (Accessed 17 April 2020).
Bitcoin Community (2020). Bitcoin core integration. Bitcoin (online). https://github.com/bitcoin/bitcoin. (Accessed 27 April 2020).
Blazic, A. J., Gondrom, T., & Saljic, S. (2011). Extensible markup language evidence record syntax (XMLERS). In Request for comments, (Vol. 6283), RFC Editor,
http://dx.doi.org/10.17487/RFC6283, https://rfc-editor.org/rfc/rfc6283.txt.
block. one (2018). EOS.IO technical white paper v2 (online). https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md. (Accessed 17
September 2020).
Broby, D., Basu, D., & Arulselvan, A. (2019). The role of precision timing in stock market price discovery when trading through distributed ledgers. Journal of
Business Thought, 10(1), 1–8. http://dx.doi.org/10.18311/jbt/2019/23355.
Brown, R. G. (2018). The corda platform: An introduction (online). https://www.corda.net/content/corda-platform-whitepaper.pdf. (Accessed 17 September 2020).
BRyTecnologia (2020). Carimbo do Tempo garante data e hora em documentos e transações (online). https://www.bry.com.br/carimbo-do-tempo/. (Accessed 4
May 2020).
Buchmann, J. A., Karatsiolis, E. G., & Wiesmaier, A. (2013). Introduction to public key infrastructures. Springer Science & Business Media, ISBN: 978-3-642-40656-0,
http://dx.doi.org/10.1007/978-3-642-40657-7.
Cachin, C., et al. (2016). Architecture of the hyperledger blockchain fabric. In Workshop on distributed cryptocurrencies and consensus ledgers: Vol. 310 (pp. 4).
21
Cammenga, J. (2019). State and local sales tax rates, 2019 (online). https://taxfoundation.org/sales-tax-rates-2019. (Accessed 17 April 2020).
Chen, Q., Srivastava, G., Parizi, R. M., Aloqaily, M., & Ridhawi, I. A. (2020). An incentive-aware blockchain-based solution for internet of fake media things.
Information Processing & Management, Article 102370. http://dx.doi.org/10.1016/j.ipm.2020.102370.
Christidis, K., & Devetsikiotis, M. (2016). Blockchains and smart contracts for the internet of things. IEEE Access, 4, 2292–2303. http://dx.doi.org/10.1109/
ACCESS.2016.2566339.
Clark, J., & Essex, A. (2012). CommitCoin: Carbon dating commitments with bitcoin. In Financial cryptography and data security (pp. 390–398). Springer Berlin
Heidelberg, http://dx.doi.org/10.1007/978-3-642-32946-3_28.
Concourse Open Community (2020). ETH Gas station | consumer oriented metrics for the ethereum gas market. (online). https://ethgasstation.info/. (Accessed
11 May 2020).
Connel, M. (2017). The fall of enron and the creation of the Sarbanes-Oxley act of 2002 (online). http://digitalcommons.lasalle.edu/honors_projects/19. (Accessed
20 April 2020).
Daines, R. M., McQueen, G. R., & Schonlau, R. J. (2018). Right on schedule: CEO option grants and opportunism. Journal of Financial and Quantitative Analysis,
53(3), 1025–1058. http://dx.doi.org/10.1017/S0022109017001259.
Davidson, M., & Diamond, T. (2020). On the profitability of selfish mining against multiple difficulty adjustment algorithms. IACR Cryptology ePrint Archive,
2020, 94.
DigiStamp, & Inc (2020). DigiStamp: PRice of digital timestamps from a trusted timestamp authority. (online). https://www.digistamp.com/subpage/price.
(Accessed 27 April 2020).
Douceur, J. R. (2002). The sybil attack. In Peer-to-peer systems (pp. 251–260). Springer Berlin Heidelberg, http://dx.doi.org/10.1007/3-540-45748-8_24.
Dziembowski, S., Faust, S., & Hostáková, K. (2018). General state channel networks. In D. Lie, M. Mannan, M. Backes, & X. Wang (Eds.), Proceedings of the 2018
ACM SIGSAC conference on computer and communications security (pp. 949–966). ACM, http://dx.doi.org/10.1145/3243734.3243856.
Ethereum (2018). Light-client-protocol. (online). https://github.com/ethereum/wiki/wiki/Light-client-protocol. (Accessed 28 April 2020).
Ethereum (2019). White paper. (online). https://github.com/ethereum/wiki/wiki/White-Paper. (Accessed 27 April 2020).
Ethereum (2020). go-ethereum/consensus/ethash/consensus.go. (online). https://github.com/ethereum/go-ethereum/blob/c49a4165d074c2d08c362cfe1dac835b6
a3e1251/consensus/ethash/consensus.go#L246. (Accessed 27 April 2020).
Ethereum Foundation (2017a). Solidity. (online). https://solidity.readthedocs.io/en/develop/. (Accessed 20 April 2020).
Ethereum Foundation (2017b). web3.js - Ethereum JavaScript API. (online). https://web3js.readthedocs.io. (Accessed 20 April 2020).
Etherscan (2020a). Ethereum average block time chart. (online). https://etherscan.io/chart/blocktime. (Accessed 28 April 2020).
Etherscan (2020b). Ethereum full node sync (default) chart (online). https://etherscan.io/chartsync/chaindefault. (Accessed 21 January 2020).
Factom (2019). Factom - a blockchain innovations company. (online). https://www.factom.com/. (Accessed 20 April 2020).
Fan, K., Ren, Y., Yan, Z., Wang, S., Li, H., & Yang, Y. (2018). Secure time synchronization scheme in IoT based on blockchain. In 2018 IEEE international
conference on internet of things (IThings) and IEEE green computing and communications (GreenCom) and IEEE cyber, physical and social computing (CPSCom) and
IEEE smart data (SmartData) (p. 1068). IEEE, http://dx.doi.org/10.1109/cybermatics_2018.2018.00196.
Fan, K., Sun, S., Yan, Z., Pan, Q., Li, H., & Yang, Y. (2019). A blockchain-based clock synchronization scheme in IoT. Future Generation Computer Systems, 101,
524–533. http://dx.doi.org/10.1016/j.future.2019.06.007.
Forsyth, D. (2018). Probability and statistics for computer science. Cham, Switzerland: Springer, ISBN: 978-3-319-64409-7.
Gipp, B., Breitinger, C., Meuschke, N., & Beel, J. (2017). Cryptsubmit: Introducing securely timestamped manuscript submission and peer review feedback using
the blockchain. In 2017 ACM/IEEE joint conference on digital libraries (pp. 1–4). IEEE, http://dx.doi.org/10.1109/jcdl.2017.7991588.
Gipp, B., Meuschke, N., & Gernandt, A. (2015). Decentralized trusted timestamping using the crypto currency bitcoin. ArXiv preprint arXiv:1502.04015.
Gmbh, B. (2020). Ethereum mainnet statistics (online). https://www.ethernodes.org/countries. (Accessed 20 April 2020).
Haber, S., & Stornetta, W. S. (1991). How to time-stamp a digital document. Journal of Cryptology, 3(2), 99–111. http://dx.doi.org/10.1007/bf00196791,
https://doi.org/10.1007/bf00196791.
Halevi, S., & Micali, S. (1996). Practical and provably-secure commitment schemes from collision-free hashing. In N. Koblitz (Ed.), Lecture notes in computer
science: Vol. 1109, Advances in cryptology - CRYPTO ’96, 16th annual international cryptology conference, Santa Barbara, California, USA, August 18-22, 1996,
Proceedings (pp. 201–215). Springer.
Hartl, A., Zseby, T., & Fabini, J. (2019). Beaconblocks: Augmenting proof-of-stake with on-chain time synchronization. In 2019 IEEE international conference on
blockchain (pp. 353–360). IEEE, http://dx.doi.org/10.1109/blockchain.2019.00055.
Hepp, T., Schoenhals, A., Gondek, C., & Gipp, B. (2018). OriginStamp: A blockchain-backed system for decentralized trusted timestamping. Information Technology,
60(5–6), 273–281. http://dx.doi.org/10.1515/itit-2018-0020.
Hoffstein, J., Pipher, J., & Silverman, J. (2008). An introduction to mathematical cryptography, (1st ed.). (p. 524). Springer New York.
Kershner, E. (2020). Companies that were caught cooking the books. WorldAtlas (online). worldatlas.com/articles/companies-that-were-caught-cooking-the-
books.html. (Accessed 7 May 2020).
Kharif, O. (2019). Ethereum ‘almost full’ as controversial coin gobbles up capacity (online). https://www.bloomberg.com/news/articles/2019-08-26/ethereum-
almost-full-as-controversial-coin-gobbles-up-capacity. (Accessed 27 April 2020).
Kim, S. K., Ma, Z., Murali, S., Mason, J., Miller, A., & Bailey, M. (2018). Measuring ethereum network peers. In Proceedings of the internet measurement conference
2018 (pp. 91–104).
Kurose, J. (2017). Computer networking : a top-down approach. Harlow, England Boston: Pearson, ISBN: 978-0133594140.
Landerreche, E., Schaffner, C., & Stevens, M. (2018). Cryptographic timestamping through sequential work. Tech. Rep, CWI Amsterdam.
Li, J., Wu, J., Jiang, G., & Srikanthan, T. (2020). Blockchain-based public auditing for big data in cloud storage. Information Processing & Management, Article
102382. http://dx.doi.org/10.1016/j.ipm.2020.102382.
Loop, J. (2019). Bitcoin timestamp security. (online). https://blog.lopp.net/bitcoin-timestamp-security/. (Accessed 20 April 2020).
Loyd, D. (2007). Physics lab manual. Cengage Learning, ISBN: 9780495114529, https://books.google.com.br/books?id=vPQg9p0XKd8C.
Luu, L., Chu, D., Olickel, H., Saxena, P., & Hobor, A. (2016). Making smart contracts smarter. In E. R. Weippl, S. Katzenbeisser, C. Kruegel, A. C. Myers, &
S. Halevi (Eds.), Proceedings of the 2016 ACM SIGSAC conference on computer and communications security (pp. 254–269). ACM, http://dx.doi.org/10.1145/
2976749.2978309.
Maniatis, P., & Baker, M. (2002). Secure history preservation through timeline entanglement. In D. Boneh (Ed.), Proceedings of the 11th USENIX security symposium
(pp. 297–312). USENIX.
McCorry, P., Shahandashti, S. F., & Hao, F. (2017). A smart contract for boardroom voting with maximum voter privacy. In A. Kiayias (Ed.), Lecture notes
in computer science: Vol. 10322, Financial cryptography and data security - 21st international conference (pp. 357–375). Springer International Publishing,
http://dx.doi.org/10.1007/978-3-319-70972-7_20.
Merkle, R. C. (1989). A certified digital signature. In G. Brassard (Ed.), Lecture notes in computer science: Vol. 435, Advances in cryptology - CRYPTO ’89, 9th Annual
International Cryptology conference, Santa Barbara, California, USA, August 20-24, 1989, Proceedings (pp. 218–238). Springer, http://dx.doi.org/10.1007/0-387-
34805-0_21.
Mostéfaoui, A., & Raynal, M. (2016). Intrusion-tolerant broadcast and agreement abstractions in the presence of byzantine processes. IEEE Transactions on Parallel
and Distributed Systems, 27(4), 1085–1098.
22
Mukhopadhyay, U., Skjellum, A., Hambolu, O., Oakley, J., Yu, L., & Brooks, R. (2016). A brief survey of cryptocurrency systems. In 2016 14th annual conference
on privacy, security and trust (pp. 745–752). IEEE, http://dx.doi.org/10.1109/PST.2016.7906988.
Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. Technical report, Manubot.
National Institute of Standards and Technology (2002). FIPS 180-2 (online). https://csrc.nist.gov/csrc/media/publications/fips/180/2/archive/2002-08-01/
documents/fips180-2.pdf. (Accessed 17 April 2020).
National Institute of Standards and Technology (2020). The official U.S. time (online). https://timegov.boulder.nist.gov/. (Accessed 13 May 2020).
Newton, D. (2019). Broadcasting a transaction to external organisations (online). https://www.corda.net/blog/broadcasting-a-transaction-to-external-
organisations. (Accessed 17 September 2020).
Oham, C., Michelin, R. A., Jurdak, R., Kanhere, S. S., & Jha, S. (2021). B-FERL: Blockchain based framework for securing smart vehicles. Information Processing
& Management, 58(1), Article 102426. http://dx.doi.org/10.1016/j.ipm.2020.102426.
Open Ethereum (2020). Openethereum/ethcore/verification/src/verification.rs. (online). https://github.com/openethereum/openethereum/blob/
5c3c9797985d86cfd8983e180575639cad735c11/ethcore/verification/src/verification.rs#L344. (Accessed 27 April 2020).
OpenJS Foundation (2020). Node.js. (online). https://nodejs.org/. (Accessed 20 April 2020).
OpenSSL Software Foundation (2018). /docs/man1.1.1/man1/openssl-speed.html (online). https://www.openssl.org/docs/man1.1.1/man1/openssl-speed.html.
(Accessed 11 May 2020).
Palma, L. M., Vigil, M. A. G., Pereira, F. L., & Martina, J. E. (2019). Blockchain and smart contracts for higher education registry in Brazil. International Journal
of Network Management, 29(3), http://dx.doi.org/10.1002/nem.2061.
Perun Network (2020). Perun. (online). https://www.perun.network. (Accessed 28 April 2020).
Solutions Notarius Inc. (2020). Trusted digital timestamps. (online). https://notarius.com/en/timestamp/. (Accessed 27 April 2020).
Stallings, W. (1995). Network and internetwork security: principles and practice. Englewood Cliffs, NJ: Prentice Hall [u.a.], ISBN: 9780131800502, OCLC: 263704709.
Stavrou, A., & Voas, J. (2017). Verified time. Computer, 50(3), 78–82. http://dx.doi.org/10.1109/mc.2017.63.
Surety, L. L. C. (2003). Ensuring record integrity with absolute proofSM . Technical whitepaper, Surety LLC.
Surety, L. L. C. (2020). Protect the integrity, defend the authenticity of your digital information (online). http://www.surety.com/. (Accessed 4 May 2020).
Swan, M. (2016). Blockchain temporality: Smart contract time specifiability with blocktime. In Rule technologies. Research, tools, and applications (pp. 184–196).
Springer International Publishing, http://dx.doi.org/10.1007/978-3-319-42019-6_12.
Szabo, N. (1996). Smart contracts: building blocks for digital markets. EXTROPY: The Journal of Transhumanist Thought, 18(16), 2.
Szalachowski, P. (2018). (Short paper) towards more reliable bitcoin timestamps. In 2018 crypto valley conference on blockchain technology (pp. 101–104). IEEE,
http://dx.doi.org/10.1109/cvcbt.2018.00018.
Tierion, & Inc. (2020). Tierion - blockchain proof engine. (online). https://tierion.com/. (Accessed 20 April 2020).
Tomescu, A., & Devadas, S. (2017). Catena: Efficient non-equivocation via bitcoin. In 2017 IEEE symposium on security and privacy (pp. 393–409). IEEE,
http://dx.doi.org/10.1109/sp.2017.19.
Tuovila, A. (2020). Marginal tax rate definition (online). https://www.investopedia.com/terms/m/marginaltaxrate.asp. (Accessed 18 April 2020).
Vigil, M. A. G., Buchmann, J. A., Cabarcas, D., Weinert, C., & Wiesmaier, A. (2015). Integrity, authenticity, non-repudiation, and proof of existence for long-term
archiving: A survey. Computers & Security, 50, 16–32.
Vigil, M. A. G., Weinert, C., Demirel, D., & Buchmann, J. A. (2014). An efficient time-stamping solution for long-term digital archiving. In IEEE 33rd international
performance computing and communications conference (pp. 1–8). IEEE Computer Society, http://dx.doi.org/10.1109/PCCC.2014.7017099.
Wiki, B. (2019). Block timestamp. (online). https://en.bitcoin.it/wiki/Block_timestamp. (Accessed 20 April 2020).
Wood, G., et al. (2014). Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper, 151(2014), 1–32.
Xu, X., Weber, I., Staples, M., Zhu, L., Bosch, J., Bass, L., Pautasso, C., & Rimba, P. (2017). A taxonomy of blockchain-based systems for architecture design. In
2017 IEEE international conference on software architecture (pp. 243–252). IEEE, http://dx.doi.org/10.1109/icsa.2017.33.
Zhang, Y., Xu, C., Cheng, N., Li, H., Yang, H., & Shen, X. S. (2019). Chronos+: An accurate blockchain-based time-stamping scheme for cloud storage. IEEE
Transactions on Services Computing, 1=. http://dx.doi.org/10.1109/tsc.2019.2947476.
Zhang, Y., Xu, C., Li, H., Yang, H., & Shen, X. (2019). Chronos: Secure and accurate time-stamping scheme for digital files via blockchain. In ICC 2019 - 2019
IEEE international conference on communications (pp. 1–6). IEEE, http://dx.doi.org/10.1109/icc.2019.8762071.
Zhao, Q., Chen, S., Liu, Z., Baker, T., & Zhang, Y. (2020). Blockchain-based privacy-preserving remote data integrity checking scheme for IoT information systems.
Information Processing & Management, 57(6), Article 102355. http://dx.doi.org/10.1016/j.ipm.2020.102355.
Zuccherato, R., Cain, P., Adams, D. C., & Pinkas, D. (2001). Internet X.509 public key infrastructure time-stamp protocol (TSP). In Request for Comments, (Vol.
3161), RFC Editor, http://dx.doi.org/10.17487/RFC3161 (online). https://rfc-editor.org/rfc/rfc3161.txt. (Accessed 4 May 2020).
23

Accurate and Decentralized Timestamping Using Smart Contracts On The Ethereum Blockchain

Uploaded by

Copyright:

Available Formats

Accurate and Decentralized Timestamping Using Smart Contracts On The Ethereum Blockchain

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Accurate and Decentralized Timestamping Using Smart Contracts On The Ethereum Blockchain

Uploaded by

Copyright:

Available Formats

Information Processing and Management 58 (2021) 102471

Contents lists available at ScienceDirect

Information Processing and Management

Accurate and decentralized timestamping using smart contracts on

ARTICLE INFO ABSTRACT

2.1. Cryptographic hash functions, digital signatures & digital certificates

2.2. A hash-based commitment scheme

2.3. Trusted timestamps

2.4. Blockchain, smart contracts, & fees

1. User: he or she creates files and requests timestamps.

4. The accuracy of Ethereum-based timestamps

1. reduced to zero if the miner puts its clock backward 6.50 s, or

5. A new decentralized timestamping service

5.3. Selecting timestamps and sharing rewards

6.1. Finding transaction propagation & confirmation times

6.1.1. Experimental set-up

Fig. 5. The time transactions take to reach listening nodes.

6.2. Evaluating the prototype

6.2.1. Experimental set-up

7. Investigating backdated transactions

Fig. 9. The location which provided the best timestamps.

8. Cost evaluation & comparison

1. miners’ fees for confirming blockchain transactions;

10. Conclusions & future work

CRediT authorship contribution statement

You might also like