In the previous chapter, we were focusing on releasing self-emerging data to peers who control EOA accounts through private/public key pairs. In this chapter, we examine a more chal- lenging scenario that corresponds to the research task T-4 proposed in Section 1.1, namely releasing self-emerging data to a passive smart contract that has already been deployed by peers to a CA account. In short, mechanisms satisfying such requirements can facilitate a wide range of decentralized applications, allowing users to schedule their target smart con- tracts to be automatically executed at future points of time, without revealing their private input data (i.e., self-emerging data) before the expected execution time. Next, before going to the details, we first present the motivations that stimulate our study of releasing self- emerging data to smart contracts. We then present other key research questions associated with the objectives of this chapter.
Motivations and objectives: Recent implementations of blockchain-based smart contract platforms, such as Ethereum [128] and NEO [102], have attracted a large number of de- velopers to build decentralized applications using smart contracts that avoid the need of a centralized server to manage and maintain the data [2,92,94]. The market cap for the lead- ing smart contract platform, Ethereum, peaked at $134 billion [52] in 2018 and thousands of decentralized applications, ranging from social networks to financial software, have been de- veloped over Ethereum [118]. The Smart Contracts market is estimated to grow at a CAGR of 32% during the period 2017 to 2023 [117]. A decentralized application may involve one or more smart contracts and each smart contract may contain multiple functions that need to be invoked by application users through transactions. For instance, a sealed-bid auction smart contract [129] requires bidders to reveal their sealed bids by invoking a function (e.g.,
a reveal() function) during a time window. Similarly, a voting smart contract [92] requires voters to publish their votes using a vote() function during the voting time window. Each called function in a smart contract is executed by the entire blockchain network. Since both function code and function inputs (i.e., bid or vote) are available on the blockchain, the function outputs are deterministic and their correctness can be verified by the network, thus cutting out centralized middlemen or intermediaries for running these functions [78]. A key fundamental limitation of existing smart contract platforms is the lack of support for users to schedule timed execution of transactions such that their target functions can be invoked at a later time, even when the users go offline. For example, if Bob plans to take a week off work and could not respond to an auction or voting mechanism implemented on Ethereum during the prescribed time windows, he needs a mechanism to schedule these timed trans- actions by automatically invoking reveal() and vote() during the time windows. Here, the inputs to these functions namely the bids and the votes are extremely sensitive and need to be securely protected until the prescribed time windows even when Bob is offline. There- fore, we need a two-stage mechanism, namely (1) protecting the inputs of a function (i.e., self-emerging data) before a prescribed execution time and (2) automatically releasing these inputs to the contract address (CA) of target smart contract (i.e., auction smart contract) at the prescribed execution time to make the function get executed by miners.
Challenges: It is easy to implement such a mechanism in centralized application environ- ments as function inputs can be stored by centralized servers and function execution can be triggered by centralized servers at prescribed execution time. For instance, Boomerang [30] allows users of Gmail to schedule their emails to be sent when users have no connection with the Internet. Similarly, Postfity [108] helps users to schedule messages to be posted onto many centralized social networks. However, both the two stages of the aforementioned mechanism is hard to be designed in decentralized platforms such as Ethereum. First, to guarantee verifiability of function outputs, function inputs need to be put onto the blockchain and as a result, both function inputs and outputs become public to all peers at the time the schedule is initialized, thus leading to privacy risks with the input data. Second, when a transaction invoking a function is deployed into the network, the invoked function is ex- ecuted immediately, which makes it difficult to support timed execution when the user has
already gone offline.
Properties of contract accounts (CAs) in Ethereum: Unlike accounts controlled by peers (i.e., DHT nodes, Ethereum EOAs), a contract account (CA) in Ethereum is passive and transparent. The execution of any function of deployed smart contracts must be invoked through either transactions sent by EOAs or messages sent from CAs. All these transaction- s/messages, as well as function inputs inside them, are publicly recorded by the Ethereum blockchain, which makes the function outputs deterministic because all miners can execute the function with the same inputs and gets the same outputs.
Adversary models: In this chapter, we further increase the strength of adopted adversary models for the purpose of designing more robust countermeasures against potential attacks. In the previous Chapter4, we have assumed that all the peers are adversaries with rationality. In the first part of security analysis in this chapter, we follow the same assumption made in Chapter 4 and assume that all EOAs are rational adversaries but not malicious. Then, in the second part of security analysis in this chapter, we further assume that there exists a malicious (or irrational) adversary targeting a specific service request while all other EOAs not owned by this malicious adversary are still rational adversaries.
Technical approaches: In this chapter, we observe that instead of requesting an EOA account to invoke the target function at the release time, it is more effective to invoke the target function through a message sent by a smart contract. This is because smart contracts are trustworthy while peers running EOA accounts may perform undesirable misbehaviors. Therefore, we design a new mechanism that makes self-emerging data get released to a proxy contract deployed by the user of decentralized applications and then make the proxy contract automatically call the target function on behalf of the user. The mechanism jointly applies techniques of data redundancy and cryptocurrency-driven enforcement and can handle ra- tional adversaries and malicious adversaries altogether. The proposed mechanism does not reveal function inputs (i.e., self-emerging data) before the execution time window selected by the user, as the function inputs are privately maintained by a set of trustees randomly selected from the network and released only during the execution time window. The function inputs are protected through secret share [114] and multi-layer encryption [45] and possible misbehaviors of the trustees are made detectable and verifiable through a suit of misbe-
havior report mechanisms implemented in the Ethereum Smart Contracts and any verified misbehavior incurs the monetary penalty on the violator.
Evaluation: We implement the proposed approach using the contract-oriented program- ming language Solidity [11] and test it on the Ethereum official test network rinkeby [9] with Ethereum official Go implementation Geth [6]. Our implementation and experimental evaluation that the proposed approach is effective and the protocol has a low gas cost and time overhead associated with it.
In the rest of this chapter, we first introduce the timed execution in Ethereum in Section
5.1 and then present the designed protocols in detail in Section5.2. After providing security analysis in Section 5.3, we implement and evaluate the proposed protocol on the Ethereum official test network in Section 5.4. Finally, we summarize this chapter in Section 5.5.