ChapterPDF Available

An Efficient Micropayment Channel on Ethereum

Authors:

Abstract and Figures

Blockchain protocols for cryptocurrencies offer secure payment transactions, yet their throughput pales in comparison to centralized payment systems such as VISA. Moreover, transactions incur fees that relatively hinder the adoption of cryptocurrencies for simple daily payments. Micropayment channels are second layer protocols that allow efficient and nearly unlimited number of payments between parties at the cost of only two transactions, one to initiate it and the other one to close it. Typically, the de-facto approach for micropayment channels on Ethereum is to utilize digital signatures which incur a constant gas cost but still relatively high due to expensive elliptic curve operations. Recently, ElSheikh et al. have proposed a protocol that utilizes hash chain which scales linearly with the channel capacity and has a lower cost compared to the digital signature based channel up to a capacity of 1000 micropayments. In this paper, we improve even more and propose a protocol that scales logarithmically with the channel capacity. Furthermore, by utilizing a variant of Merkle tree, our protocol does not require the payer to lock the entire balance at the channel creation which is an intrinsic limitation with the current alternatives. To assess the efficiency of our protocol, we carried out a number of experiments, and the results prove a positive efficiency and an overall low cost. Finally, we release the source code for prototype on Github (https://github.com/HSG88/Payment-Channel).
Content may be subject to copyright.
An Efficient Micropayment Channel on
Ethereum
Hisham S. Galal, Muhammad ElSheikh, and Amr M. Youssef
Concordia Institute for Information Systems Engineering,
Concordia University, Montr´eal, Qu´ebec, Canada
Abstract Blockchain protocols for cryptocurrencies offer secure pay-
ment transactions, yet their throughput pales in comparison to central-
ized payment systems such as VISA. Moreover, transactions incur fees
that relatively hinder the adoption of cryptocurrencies for simple daily
payments. Micropayment channels are second layer protocols that allow
efficient and nearly unlimited number of payments between parties at
the cost of only two transactions, one to initiate it and the other one
to close it. Typically, the de-facto approach for micropayment channels
on Ethereum is to utilize digital signatures which incur a constant gas
cost but still relatively high due to expensive elliptic curve operations.
Recently, ElSheikh et. al have proposed a protocol that utilizes hash
chain which scales linearly with the channel capacity and has a lower
cost compared to the digital signature based channel up to a capacity of
1000 micropayments. In this paper, we improve even more and propose a
protocol that scales logarithmically with the channel capacity. Further-
more, by utilizing a variant of Merkle tree, our protocol does not require
the payer to lock the entire balance at the channel creation which is an
intrinsic limitation with the current alternatives. To assess the efficiency
of our protocol, we carried out a number of experiments, and the results
prove a positive efficiency and an overall low cost. Finally, we release the
source code for prototype on Github1.
Keywords: Micropayment Channel, Ethereum, Merkle Tree.
1 Introduction
Cryptocurrencies such as Bitcoin [8] and Etheruem [11] enable secure payment
transactions between parties using blockchain technology. The major innovation
that made the success of Bitcoin was the Nakamoto consensus [8] that utilizes
Proof of Work (PoW) to enable distrusting peers to reach consensus. However,
this level of security comes at the cost of limited throughput and delayed con-
firmation. For example, the transaction throughput in Bitcoin and Ethereum
are roughly 5 and 20 transactions per second [1], respectively. Furthermore, it
was shown [5] that blockchain protocols based on PoW can hardly scale be-
yond 60 transactions per second without considerably weakening their security.
1https://github.com/HSG88/Payment-Channel
Additionally, the transaction fees are not constant and they vary significantly
based on the current price of the underlying coin, and also whether the network
faces high traffic of transactions. These limitations make applications such as
micropayments expensive to realize directly without further modification to the
consensus protocol.
A payment channel [3,6,7,9] is a protocol between two parties to send nearly
an unlimited number of payments interactions off-chain. To establish it, only two
transactions are required, one to open the channel (i.e., creating a smart contract
and funding it), and the second one to close it (i.e., reclaiming the funds). Fur-
thermore, a channel can have certain properties such as being a unidirectional
and monotonically increasing which allows us to have entirely off-line channel.
In other words, none of parties have to stay on-line to monitor changes on the
smart contract. All they have to watch for is the channel timeout. Furthermore,
a unidirectional and monotonically increasing payment channel is convenient for
a merchant and buyer scenario.
The de-facto standard payment channel protocols on Ethereum depend heav-
ily on digital signature schemes which incur a constant cost, yet a relatively high
one due to the cost of elliptic curve operations to verify the signature. Recently,
ElSheikh et. al [4] have proposed EthWord, a protocol that utilizes hash chain
to create an efficient payment channel as it scales linearly with the channel ca-
pacity (i.e., number of unit payments), and it has a lower gas cost up to roughly
a channel capacity of 1000 units of payments compared to the digital signature
based channels.
In this work, we improve even more on the efficiency and gas cost of the above
protocols and propose a scheme which scales logarithmically with the channel
capacity. Furthermore, the payer does not have to lock up the entire amount
in the construction of the payment channel, which is an intrinsic limitation
in the EthWord and digital signature based channels. Furthermore, as part of
our contribution, we also provide an open-source prototype on Github (https:
//github.com/HSG88/Payment-Channel) for the community to review it.
The rest of this paper is organized as follows. Section 2 provides a brief review
of a digital signature based channel construction referred to as Pay50, and the
hash chain based channel EthWord. In Section 3, we present the cryptographic
primitives utilized in the proposed scheme. Then, in Section 4, we provide the
design for our approach and compare its efficiency and cost to the other con-
structions. Finally, we present our conclusions in Section 5.
2 Related Work
Pay50. To argue the simplicity of building payment channels on Ethereum, Di
Ferrante [2] showed how to construct one using only ‘50 lines of code’ Solidity
implementation of a uni-directional, monotonic channel. Simply, the payer ini-
tializes a smart contract with the payee’s address, a timeout value, and deposits
some balance. Once it is deployed, the smart contract constructor stores the
payer’s address in order to verify the digital signatures of off-chain payments via
2
calling ecrecover (an op-code in Ethereum that returns the signer’s address).
After the deployment, the payer can send digitally signed payments messages to
the payee off-chain. The payee verifies the digital signature, and on success, the
payee provides the service or the item to the payer. At a later point of time but
before the channel timeout, the payee sends the last signed payment message to
the smart contract which releases the amount on successful verification.
EthWord [4] builds mainly on PayWord [10] and it depends significantly
on a hash chain which is constructed by iteratively applying a public one-way
hash function Hon a secret random number s. More precisely, assume that
Hi(s) = H(Hi1(s)) for i[1, n] (i.e, the length of the hash chain is n). The
last hash value in the chain Hn(s) is referred to as the tip. Furthermore, since the
utilized hash function His assumed to have the preimage resistance property,
then it is computationally infeasible for an adversary to find any preimage in the
chain given its tip. In the context of payments, the payer creates a hash chain
of length nwhich represents the maximum number of possible payments. Then,
the payer creates a channel by deploying a smart contract on Ethereum, passing
the tip, the payee address, and timeout value as parameters. Later, the payer
can send units of payments by revealing a preimage value deeper in the chain.
For example, to pay iunits, the payer sends Hni(s) to the payee. The payee
can verify it off-chain by iteratively hashing Hni(s)itimes, and see if the result
equals the tip. Before the channel timeout, the payee sends the latest Hnito
reclaim iunits once the smart contract has verified it. Similar to Pay50, after
the timeout, the smart contract sends the remaining balance back to the payer.
3 Preliminaries
Merkle Tree. is a core component of the blockchain protocols. In Ethereum [11],
Merkle trees aggregate the hashes of transactions, states, and receipts in a
particular block so that the root becomes a binding commitment to all these
values in that block. Technically speaking, a Merkle tree is a balanced bi-
nary tree in which the leaf nodes hold values and each non-leaf node stores
H(LeftChild||RightC hild), where His a collision-resistant hash function. Prov-
ing the membership of a value in the tree can be achieved with a logarithmic size
proof (in terms of the number of leaves), known as a Merkle proof. For example,
given a Merkle tree Mwith a root r, to prove that a value xM, the prover
creates a Merkle proof πby retrieving the siblings of each node on the path
from xto r. The verifier iterates over the nodes in πito construct a root r0and
accepts the proof if r0=r. It is worth noting that since Mis a binary tree, then
the proof size |π|=log2(n) as shown in Fig. 1.
The extension to our scheme that enables the payer to add funds to the
channel depends on a variant of Merkle tree which is not strictly balanced. The
objective is to append new values to the tree while at the same time maintain
correct Merkle proofs for the old values. More precisely, to append a new set
of mvalues to an existing Merkle tree Mnwith nleaves and root rn. First, we
generate a Merkle tree Mmwith a root rmfrom the mvalues. Then, we combine
3
a b c d
HaHbHcHd
Hab Hcd
Habcd
Figure 1: An example illustrating the Merkle proof for element cMwhich
consists of the nodes Hdand Hab
the Merkle trees Mnand Mmto generate a new tree M0that contains the roots
rnand rmas the child nodes of its root r0. Note that we still preserve the
correctness of Merkle proofs for values in Mnby augmenting any valid Merkle
proof πfor elements in Mnwith the root rmto be valid with respect to M0.
4 Protocol Design and Implementation
Assume that Alice runs an online service for which she accepts (ether) currency
on a micro-level (e.g., a very low fraction of ether that costs less than one
dollar). Bob is interested in that service and he wants to utilize it. However,
sending transactions to the Ethereum blockchain has a minimum cost of 21000
gas [11] which becomes too expensive for Bob as the number of interactions
between him and Alice increases. To make it efficient and also cheap, Alice and
Bob can utilize an off-chain payment channel. There are three phases in our
protocol from the initiation to completion.
4.1 Channel Setup
This phase starts with Bob generating a secret random number s0. Suppose that
he estimates the number of maximum units of payments (i.e., channel capacity)
he is willing to make is n. Note that we explain later how he can increase this
number in case he wants to utilize the service more than he expected. Then, Bob
uses a pseudo random number generator with the seed s0to create a sequence of
random numbers (s1, ..., sn)). After that, he creates a Merkle tree Mto bind the
elements ((1||s1), ..., (i||si), ..., (n||sn)) where every element is the concatenation
of a value i[1, n] and a random number si. We also assume that there is a
minimum unit of payment u, (e.g., u=GWei = 1 ×109ether).
At this moment, Bob deploys a smart contract on Ethereum to act as a
trusted third party that holds Bob’s balance and settles the final payment trans-
action to Alice. To deploy it, Bob passes the following parameters that control
the payment channel between him and Alice to the smart contract constructor:
1. Alice’s address Aadr on Ethereum.
4
2. A timeout value Tout before the channel is closed.
3. The root rof the Merkle tree M.
Additionally, Bob has to deposit an amount balance =n×uether in the smart
contract to be held in escrow, and pay Alice when she submits a valid Merkle
proof.
4.2 Off-chain Payments
Every time Bob wants to utilize Alice’s service, he sends her a new Merkle proof
πifor an amount of iunits. To generate the proof πi, Bob runs Algorithm 1 which
takes a Merkle tree M, an amount i, and the seed value s0as parameters. We
Algorithm 1 Create Merkle Proof πifor an amount iand random seed s0
1: function CreateMerkleProof(M, i, s0)
2: πi[]
3: siP RN G(s0, i)
4: node =H(i||si)
5: while node 6=M.root do
6: neighbour M.GetNeighbour(node)
7: πi.Append(neighbour)
8: node M.GetParent(node)
9: end while
10: return πi
11: end function
start by generating the corresponding random value si. Then, siis concatenated
to the amount ibefore feeding the result to the hash function H. Doing so prevents
Alice from guessing the pre-images of the leaves in MT . In our implementation,
we utilize Keccak256 as the hash function Hdue to its built-in support in the
Ethereum virtual machine as an op-code. Then, we append the neighbour node
of each node in the path from the leaf to the root rto the proof πi.
After receiving the proof πi, Alice has to verify it before providing the new
service to Bob. So she calls Algorithm 2, and she decides to accept or reject
based on the output. Note that, Algorithm 2 is also one of the functions in the
smart contract that settles the payment to Alice. Essentially, Alice has to only
keep track of the latest πi(i.e., the proof for largest iamount). Once, Alice and
Bob agree that there is no more payment interactions going between them and
before the channel timeout, Alice sends πito the smart contract which will verify
it and releases the payment to Alice.
4.3 Channel Termination
At this phase, Alice cannot issue any payment request to the smart contract as
the channel has reached its timeout. However, Bob can reclaim his remaining
5
Algorithm 2 Verify Merkle Proof πifor a Merkle tree with root r, amount i,
and a random number si
1: function VerifyMerkleProof(πi, i, si, r)
2: node =H(i, si)
3: for j1 to size(πi)do
4: if node < πi,j then
5: node H(node||πi,j )
6: else
7: node H(πi,j ||node)
8: end if
9: end for
10: if node =rthen
11: return true
12: else
13: return false
14: end if
15: end function
funds by calling selfdestruct. Typically, this will disable the smart contract
from processing any further transactions. However, the smart contract can be
alternatively designed to allow for reusing it for new payment channels without
destructing it. Nonetheless, in our implementation, we chose a similar design to
Pay50 and EthWord in order to make fair comparisons.
4.4 Dynamic Refund Extension
One major advantage for our approach compared to the other alternatives is the
ability to add more fund as Bob wants while the channel is open. In other words,
Bob is not required to lock the full amount of balance which can be a substantial
value at the time the channel construction. Toward this end, when required, Bob
creates a new Merkle tree M2with a root r2that binds the additional mamounts
of payments. Then, he sends r2to the smart contract along with the additional
balance. The smart contract combines the old root r1with r2and hash the result
to create a new root r0. Note that, since Ethereum is a public blockchain, then
Alice can see the transaction carrying r2. Therefore, she can still generate a valid
proof for previous payments by augmenting the r2to the Merkle proof πifor
i[1, n]. In other words, Alice can still guarantee that she can reclaim her latest
payments even if Bob acted maliciously and generated a bogus root r2for a fake
tree M2.
4.5 Evaluation
To assess our approach, we created experiments to check the efficiency and gas
cost associated with Pay50,EthWord, and our approach. We also created off-chain
clients to interact with the smart contract of each one. To our expectation, the
6
efficiency of our approach as indicated by its gas cost far outweighs the corre-
sponding cost of Pay50 and EthWord. The results shown in Fig. 2 indicate that
32
34
36
38
40
42
44
46
256 512 1024 2048 4096
x 104
Cost (gas)
Channel Capacity
PayMerkle
EthWord
Pay50
34.9
35
35.1
35.2
35.3
35.4
35.5
8 16 32 64 128
Figure 2: The total gas cost of payment channel creation and settlement for
different channel capacities.
our approach is better than Pay50 virtually on all practical channel capacities,
however, it is slightly behind EthWord when the the channel capacity is lower
than 256, due to the added cost of Merkle proof size and the code logic to verify
it. However, our approach scales much better after that level as the gas cost of
EthWord increases at a much faster pace, and stays behind Pay50 once the chan-
nel capacity is above 1000. Interestingly, invoking the dynamic refund extension
in our solution costs 28,941 gas which is much cheaper than the cost to deploy
a new EthWord payment channel (318,953 gas).
It is also worth noting that the size of the Merkle proof is taken into account
by the gas cost of the channel termination transaction. Hence, by achieving an
overall lower gas cost, this implies that the cost for the increased parameters
size in our protocol compared to the constant single parameter in EthWord and
Pay50 is paid off by the efficiency of verifying the Merkle proofs compared to
processing the hash chain in EthWord and verifying digital signature in Pay50.
Concretely, the largest non-realistic capacity is 2256, which requires a Merkle
proof of 256 hashes. Therefore, the Merkle proof size in bytes is 256 ×32 bytes
= 8-Kbytes. From the yellow paper of Ethereum, the fee for every non-zero byte
is 68 gas. As a result, the maximum possible Merkle proof size will incur a total
gas cost of 557,056 gas which is approximately 8% of the current block gas limit.
7
5 Conclusion
One way to improve the throughput of PoW based blockchains is by utilizing
second layer improvements such as payment channels. Furthermore, payment
channels increase the adoption of cryptocurrencies for simple payments as it re-
quires only two transactions to be committed to the blockchain while allowing
an unlimited number of transactions off-chain. The de-facto standard for pay-
ment channels is to utilize digital signatures which incur a constant cost, yet
relatively high one compared to hash-based solutions such as EthWord. In this
work, we further improved upon the efficiency of these schemes and proposed
a solution, based on Merkle trees, that scales logarithmically with the number
of payments. Additionally, our approach does not require the payer to lock the
entire amount of balance at the time of the channel construction. In other words,
the payer can add up funds at later points of time at a much cheaper cost than
recreating new payment channels as found in previous proposals such as Pay50
and EthWord. For future work, we will investigate how to scale our approach to
build payment networks between multiple parties, and also add the ability to
make a bidirectional channel.
References
1. Blockchain explorer: Number of transactions per day in bitcoin and ethereum,
2019. https://www.blockchain.com/explorer.
2. M. Di Ferrante. Ethereum payment channel in 50 lines of code. Medium, June
2017.
3. S. Dziembowski, L. Eckey, S. Faust, and D. Malinowski. Perun: Virtual payment
hubs over cryptocurrencies. In 2019 IEEE Symposium on Security and Privacy
(SP), pages 327–344, 2019.
4. M. Elsheikh, J. Clark, and A. M. Youssef. Deploying payword on ethereum. In In-
ternational Conference on Financial Cryptography and Data Security Workshops,
BITCOIN, VOTING, and WTSC (To Appear). Springer, 2019.
5. A. Gervais, G. O. Karame, K. W¨ust, V. Glykantzis, H. Ritzdorf, and S. Capkun.
On the security and performance of proof of work blockchains. In Proceedings
of the 2016 ACM SIGSAC conference on computer and communications security,
pages 3–16. ACM, 2016.
6. L. Gudgeon, P. Moreno-Sanchez, S. Roos, P. McCorry, and A. Gervais. Sok: Off
the chain transactions. IACR Cryptology ePrint Archive, 2019:360, 2019.
7. A. Miller, I. Bentov, R. Kumaresan, C. Cordi, and P. McCorry. Sprites and
state channels: Payment networks that go faster than lightning. arXiv preprint
arXiv:1702.05812, 2017.
8. S. Nakamoto et al. Bitcoin: A peer-to-peer electronic cash system. 2008.
9. J. Poon and T. Dryja. The bitcoin lightning network: Scalable off-chain instant
payments, 2016.
10. R. L. Rivest and A. Shamir. Payword and micromint: Two simple micropayment
schemes. In International workshop on security protocols, pages 69–87. Springer,
1996.
11. G. Wood. Ethereum: A secure decentralised generalised transaction ledger.
Ethereum Project Yellow Paper, 151:1–32, 2014.
8
... Payment channels allow two participants to send a nearly-unlimited number of payments off-chain. Only two transactions are required for the establishment of payment channels; creating smart contract and funding it opens the channel, while reclaiming the funds closes it [93], [94]. Payment channels serve the same purpose as sidechains; however, they are fundamentally very different. ...
Thesis
Full-text available
Blockchain is simply defined as a decentralized, immutable, and distributed ledger for recording transactions, tracking digital assets and building trust. Blockchain, such as Bitcoin and Ethereum, has excellent security against adversarial attacks, but suffers from scalability issues. Indeed, the number of transactions per second (tx/s) that can be processed is too small and insufficient (e.g., up to 7 tx/s for Bitcoin and 15 tx/s for Ethereum). This is unacceptable for most traditional centralized payment systems that require thousands of transactions per second (e.g., Visa handles an average of 1700 tx/s). Sharding is one of the most promising and leading solutions to scale blockchain. The basic idea behind sharding is to divide the blockchain network into multiple committees/shards, where each processes a separate set of transactions, rather than the entire network processes all transactions. However, sharding raises security issues due to its 1 \% attacks. Therefore, the design of strong models to analyze the security of sharding-based blockchain protocols is needed. This thesis consists of four main contributions. In the first contribution, we review and compare existing solutions to blockchain scalability. In particular, we focus on sharding as a promising solution to the scalability issue. Second, we propose a mathematical model (three probability bounds are used: Chebyshev, Hoeffding, and Chv\'atal) to analyze the security of sharding-based blockchain protocols. More specifically, we bound the failure for one committee and so for each epoch using probability bounds for sums of upper-bounded hypergeometric and binomial distributions. Moreover, we analyze the following fundamental question: ``how to keep the failure probability, for a given sharding protocol, smaller than a predefined threshold?''. In the third contribution, we propose a method to compute exactly the failure probability (instead of bounding it). The proposed method computes the failure probability for one sharding round taking into consideration the failure probabilities of all shards. However, using this method is intractable since we need to execute a huge number of trials, requiring high computational power and time, to accurately estimate the failure probability. In the fourth contribution, we propose a novel probabilistic method that is as accurate as the third contribution but tractable. In addition, we investigate the threat of Sybil attacks and compute the probability of a successful attack in these protocols.
... Polygon [17], formerly Matic Network, is a Layer 2 network that addresses the throughput and sovereignty challenges of Ethereum. Despite being the most popular platform for blockchain development, Ethereum is plagued by low throughput [10], making it unsuitable for certain applications. Polygon provides applicationspecific, Ethereum-compatible sidechains that combine the scalability and independence of separate chains with the community and security of Ethereum. ...
Preprint
The proliferation of blockchains has given developers a variety of platforms on which to run their smart contracts based on application features and requirements for throughput, security, and cost. However, a consequence of this freedom is severe fragmentation; Each chain is isolated, forcing users to silo their liquidity and limiting options to move liquidity and state between walled ecosystems. This paper presents LayerZero, the first trustless omnichain interoperability protocol, which provides a powerful, low level communication primitive upon which a diverse set of cross-chain applications can be built. Using this new primitive, developers can implement seamless inter-chain applications like a cross-chain DEX or multi-chain yield aggregator without having to rely on a trusted custodian or intermediate transactions. Simply put, LayerZero is the first system to trustlessly enable direct transactions across all chains. Allowing transactions to flow freely between chains provides opportunities for users to consolidate fragmented pockets of liquidity while also making full use of applications on separate chains. With LayerZero, we provide the network fabric underlying the fully-connected omnichain ecosystem of the future.
... The IoT gateway verifies the payment token X by checking H n (x ) = T . Also, the IoT gateway verifies the Merkle proof π of the payment token X using the algorithm in [54]. Then, the IoT device and IoT gateway exchange the message encrypted using an authenticated encryption scheme with the session key K s . ...
Article
Full-text available
In this paper, we present a Symmetric Key Inter-Cloud Authentication and redeemable micropayment Protocol () for IoT-Edge computing applications. The proposed protocol takes into account the mobile and limited resource nature of IoT devices by enabling them to register with their home cloud admin for computation offloading service provided by foreign Edge-Cloud instances. More precisely, ensures that mobile IoT devices can be authenticated and serviced by edge nodes outside of their home cloud coverage, while guaranteeing the associated charge redemption. Additionally, since our protocol considers the mobile and anywhere deployable requirements of IoT devices, we utilize physical unclonable function and cryptographic hash function to make it privacy-preserving and resilient to hardware compromise. Under the assumption of an indistinguishably secure physical unclonable function, we provide a formal security analysis of our protocol. Finally, we report performance on an ARM Cortex-A72 processor, and compare it with other closely related protocols.
... These costs are considerable when users need to write a huge number of data on blockchain networks. For example, Ethereum public network can only handle at most 20 transactions per second [7], [8]. On Oct. 01, 2020, 6,425 new generated blocks on Ethereum with an average block size of 36,799 bytes paid more than 2,7 million USD in total fees for writing data (rate: 1 ETH = 346.47 ...
... On the other side, CA h sends to CA v the secret key S and the Merkle root M r . CA v uses the secret key S to decode the temporary pseudo-identities of the IoT devices in the mutual authentication phase, while M r is used for verifying the Merkle proof of the IoT tip T i [20]. ...
... These costs are considerable when users need to write a huge number of data on blockchain networks. For example, Ethereum public network can only handle at most 20 transactions per second [7], [8]. On Oct. 01, 2020, 6,425 new generated blocks on Ethereum with an average block size of 36,799 bytes paid more than 2,7 million USD in total fees for writing data (rate: 1 ETH = 346.47 ...
Conference Paper
Currently, all blockchain-based applications conduct two primary operations, i.e., writing data on blockchain networks and reading these data from the networks. These tasks require users to have considerable knowledge in blockchain technology, and they become even more challenging if users want to utilize different blockchain platforms to write and read data. So far, we have not had a uniform mechanism to perform write and read operations on various blockchain platforms. In addition, writing a huge amount of data on blockchain networks is a time-consuming task and requires considerable transaction fees. To address these issues, we present in this paper a data mapping language named BML. BML allows developers to uniformly define mappings for data transformation from traditional data storage mechanisms into blockchain networks. Conversely, this language also assists users in describing requests to read transformed data. Furthermore, BML utilizes InterPlanetary File System (IPFS), which is a decentralized storage system, for directly storing the input data before writing the hash value of the data into blockchain networks. Currently, BML accepts five input data sources, including XML, JSON, XLSX, SQL (relational database), NoSQL, and supports two output platforms, including Hyperledger Sawtooth and Ethereum. We show that BML not only provides a unified way to read and write data but also has salient advantages of performance, scalability, parallelization, privacy, and decentralization.
... Then, he submits a transaction containing g x , π x , a Merkle proof of membership π Bob as parameters, and pays a collateral deposit F as shown in Fig. 4. The smart contract ensures that registration transactions are accepted only within the allowed interval and verifies both the Schnorr proof of DL knowledge and the Merkle proof of membership. For verifying membership of voters in the M T E , we use the VerifyMerkleProof algorithm implemented in [10]. Furthermore, recall that in the Open Vote Network, voters have fixed positions which allow them to properly compute Y i . ...
Chapter
Full-text available
McCorry et al. (Financial Cryptography 2017) presented the first implementation of a decentralized self-tallying voting protocol on Ethereum. However, their implementation did not scale beyond 40 voters since all the computations were performed on the smart contract. In this paper, we tackle this problem by delegating the bulk computations to an off-chain untrusted administrator in a verifiable manner. Specifically, the administrator tallies the votes off-chain and publishes a Merkle tree that encodes the tallying computation trace. Then, the administrator submits the Merkle tree root and the tally result to the smart contract. Subsequently, the smart contract transits to an intermediate phase where at least a single honest voter can contend the administrator’s claimed result if it was not computed correctly. Then, in the worst case, the smart contract verifies the dispute at the cost of an elliptic curve point addition and scalar multiplication, and two Merkle proofs of membership which are logarithmic in the number of voters. This allows our protocol to achieve higher scalability without sacrificing the public verifiability or voters’ privacy. To assess our protocol, we implemented an open-source prototype on Ethereum and carried out multiple experiments for different numbers of voters. The results of our implementation confirm the scalability and efficiency of our proposed solution which does not exceed the current block gas limit for any practical number of voters.
Chapter
Involving an intermediary between producer-consumer environments is a common practice that reduces the managerial overhead on both parties. However, this mediation has both pros and cons. For example, it can overtake the power of producers in pricing, which could cause unfair revenue distribution. We present a novel micropayment protocol called MARI, which enables verifiable pricing and facilitates payment delegation for the prod-con environment. The proposed protocol is a blockchain-based unidirectional off-chain payment mechanism using a novel Merkel tree-based smart contract. MARI allows producers to communicate the fee structure directly to their consumers. It grants total control over producers’ inbound payment flow, which an intermediary mediates and preserves the low overhead on the producers and consumers at the same time. Further, we explore how MARI meets the general requirements as a payment protocol and its scalability.
Conference Paper
Full-text available
Proof of Work (PoW) powered blockchains currently account for more than 90% of the total market capitalization of existing digital cryptocurrencies. Although the security provisions of Bitcoin have been thoroughly analysed, the security guarantees of variant (forked) PoW blockchains (which were instantiated with different parameters) have not received much attention in the literature. This opens the question whether existing security analysis of Bitcoin's PoW applies to other implementations which have been instantiated with different consensus and/or network parameters. In this paper, we introduce a novel quantitative framework to analyse the security and performance implications of various consensus and network parameters of PoW blockchains. Based on our framework, we devise optimal adversarial strategies for double-spending and selfish mining while taking into account real world constraints such as network propagation, different block sizes, block generation intervals, information propagation mechanism, and the impact of eclipse attacks. Our framework therefore allows us to capture existing PoW-based deployments as well as PoW blockchain variants that are instantiated with different parameters, and to objectively compare the tradeoffs between their performance and security provisions.
Chapter
We revisit the 1997 PayWord credit-based micropayment scheme from Rivest and Shamir. We observe that smart contracts can be used to augment this system, apply to ‘claim or refund’ paradigm of cryptocurrencies to remove the counter-party risk inherent in PayWorld, and use a smart contract to ‘staple’ real value (in Ether) to payments in the system. Our implementation is more concise than any Ethereum payment channel we are aware of and the offline payments are very compact values (264 bits). It only uses hash functions and not digital signatures. EthWord becomes cheaper than standard Ethereum transfers when more than 16 payments between the same participants are made and appears to maintain its advantage for up to 1000+ transactions, at which point signature-based payments become cheapest. The main drawback of EthWord is the moderate gas price of using the system—despite dropping signatures, it is still priced out of the micropayments use-case. Like any payment channel, requires only two on-blockchain function calls to open and close the channel, while allowing the rest to be made off-blockchain.
Article
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
Conference Paper
this paper. We discuss these related proposals further in Section 5. The user authenticates a complete chain to the vendor with a single public-key signature, and then successively reveals each payword in the chain to the vendor to make micropayments. The incremental cost of a payment is thus one hash function computation per party. PayWord is optimized for sequences of micropayments, but is secure and flexible enough to support larger variable-value payments as well. The second scheme, "MicroMint," was designed to eliminate public-key operations altogether. It has lower security but higher speed. It introduces a new paradigm of representing coins by k-way hash-function collisions. Just as for a real mint, a broker's "economy of scale" allows him to produce large quantities of such coins at very low cost per coin, while small-scale forgery attempts can only produce coins at a cost exceeding their value. 2 Generalities and Notation
Deploying payword on ethereum
  • M Elsheikh
  • J Clark
  • A M Youssef
M. Elsheikh, J. Clark, and A. M. Youssef. Deploying payword on ethereum. In International Conference on Financial Cryptography and Data Security Workshops, BITCOIN, VOTING, and WTSC (To Appear). Springer, 2019.
SoK: off the chain transactions
  • L Gudgeon
  • P Moreno-Sanchez
  • S Roos
  • P Mccorry
  • A Gervais
L. Gudgeon, P. Moreno-Sanchez, S. Roos, P. McCorry, and A. Gervais. Sok: Off the chain transactions. IACR Cryptology ePrint Archive, 2019:360, 2019.
The Bitcoin lightning network: scalable off-chain instant payments
  • J Poon
  • T Dryja
J. Poon and T. Dryja. The bitcoin lightning network: Scalable off-chain instant payments, 2016.
Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper 151
  • G Wood
G. Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper, 151:1-32, 2014.