White Paper

Smart-Contract Value-Transfer Protocols on a Distributed Mobile Application Platform

DavidNeff1 , MargaritaCoello1 , PeterMeyers1, Alex Norta2

1 Sinatra World, Singapore

2 Large-Scale Systems Group, Tallinn University of Technology,
Akadeemia tee 15A, 12816 Tallinn, Estonia

Abstract. Blockchain-enabled smart contracts that employ proof-of stake validation for transactions,promise significant performance advantages compared to proof-of-work solutions. For broad industry adoption, other important requirements must be met in addition. For example, stable backwards-compatible smart-contract systems must automate cross-organizational information-logistics orchestration with lite mobile wallets that support simple payment verification (SPV) techniques. The currently leading smart-contract solution Ethereum, uses computationally expensive proof-of-work validation, is expected to hard-fork multiple times in the future and requires downloading the entire blockchain. Consequently, Ethereum smart contracts have limited utility and lack formal semantics, which is a security issue. This whitepaper fills the gap in the state of the art bypresenting the Ethereum Sinatrasmart-contract framework that aims for sociotechnical application suitability, the adoption of formalsemantics language expressiveness, and the provision of smart-contract template libraries for rapid best-practice industrydeployment. We discuss the Ethereum Sinatrautility advantages compared to the Ethereum alternative and present Ethereum Sinatrasmart-contract future development plans for industrycases applications.

Key words: smart contract, business network model, DAPP, mobile, information logistics, cross-organizational, peer-to-peer, distributed system, e-governance, Ethereum Sinatraframework

1 Introduction

Orchestration and choreography protocols that facilitate, verify and enact with computing means a negotiated agreement between consenting parties, are termed smart contracts. The latter initially find application in diverse domains such as, e.g., financial-technology [6], Internet-of-Things (IoT) applications [33], digitalsigning solutions [11]. An essential aspect of smart contracts is a decentralized validation of transactions, initially by means of so-called proof-of-work (PoW) [42]. The core technology that enables smart contracts is a public distributed ledger termed the blockchain, which records transaction events without require.

Alex Norta

inga trusted central authority. Blockchain technology spreads in popularity with the inception of Bitcoin [23], a peer-to-peer (P2P) cryptocurrency and payment system that comprises a limited set of operations on the protocol layer. Bitcoins use PoW for transaction validation that is computationally expensive and electricity intensive.

In contrast to Bitcoins, many smart-contract systems are equipped with the Turing-complete language Solidity1 that resembles JavaScript syntax and targets for enactment, e.g., the Ethereum Virtual [44] machine. Ethereum is the defacto leading smart-contract system despite being plagued by several deficiencies. First, proof-of-work transaction validation diminishes scalability to the point where Ethereum is considered to not be feasible for most industry applications. Second, in a recent crowdfunding casestudy, the Ethereum affiliated Solidity smart contract was hacked2 because of security flaws resulting from alack in the state of the art with respect to tools for formal verifications [3]. The security flaw resulted in a loss of ca. $50 million. Consequently, Ethereum performed a hardfork resulting in a schism yielding two separate Ethereum versions3 . Yet another Ethereum hardfork4 was caused by a denial of service attack, and more hardforks must be expected5 for realizing proof-of-stake [2] transaction validation and blockchain sharding [20].

More reasons limit widespread Ethereumindustry adoption [8]. For example, an inability to automate cross-organizational information-logistics, lacking privacy protecting differentiations between external-versus related internal private contracts, secure and stable virtual machines for blockchains with better performing proof-of-stake [2] transaction validation, formally verifiable smartcontract languages, lite wallets that do not require downloading the entire blockchain, and mobile-device solutions for smart contracts with simple payment verification (SPV) [14]. The latter means that clients merely download block headers when they connect to an arbitrary full node [23].

While Ethereum Sinatrauses the Ethereum Virtual Machine (EVM) for a current lack of more suitable alternatives, according to [19], the EVM has deficiencies such as earlier experienced attacks against mishandled exceptions and against dependencies such as for transaction-ordering, timestamps, and so on. It is also desirable for a smart-contract system to achieve industry-scalability with employing sidechains [10] and unspent transaction outputs (UTXO) [10], achieving compatibility to other blockchain systems such as Bitcoins [23], or Colored coins [36]. Furthermore, an adoption of features from the Bitcoin Lightning Network [35] yields scalability via bidirectional micropayment channels.

  1. http://solidity.readthedocs.io/en/develop/
  2. https://www.wired.com/2016/06/50-million-hack-just-showed-dao-human/
  3. https://bitcoinsmagazine.com/articles/ethereum-classic-hard-forks-diffusesdifficulty-bomb-1484350622/
  4. https://cointelegraph.com/news/ethereum-hard-fork-no-4-has-arrived-as-dosattacks-intensify
  5. https://forum.daohub.org/t/whats-up-with-casper-proof-of-stake-andsharding/6309

Smart-Contract Information-& Value Logistics

While smart-contract systems such as Ethereum attract attention, a widespread industry adoption does not exist for the above discussed reasons. This whitepaper addresses the gap by specifying the Ethereum Sinatra6 framework for smart-contract systems that answers the question of how to develop a smart-contract solution to satisfy critical customer requirements for enabling cross-organizational information logistics to reduce costs andtime? To establish a separation of concerns, we pose the following sub-questions. What differentiating technological performance advantages do Ethereum Sinatrasmart-contract solutions provide? What are critical smart-contract requirements the Ethereum Sinatraframework satisfies? What are the unique features of cross-organizational information logistics automation the Ethereum Sinatraframework aims to support?

The remainder of this whitepaper is structured as follows. First, Section 2 focuses on concrete advantages of the Ethereum Sinatraframework for achieving technologically performance increases in comparison to related solutions. Section 3 gives functional-and quality goals in combination with involved stakeholders for sociotechnically organized smart-contract systems. Section 4 shows how the running case is supported by the Ethereum Sinatra-framework value-transfer protocol. Finally, Section 5 concludes this whitepaper together with discussing limitations, open issues and future development work.

2 Ethereum SinatraPerformance Advantage

One of the primary goals of Ethereum Sinatrais to build the first UTXO-basedsmartcontract system with a proof-of-stake (PoS) [37] consensus model. The latter means the creator of the next block is chosen based on the held wealth in cryptocurrency. Thus, blocks are usually forged, or minted instead of being mined, there are block rewards in addition to transaction fees and forgers receive a percentage of ”interest” for the amount of funds they stake.

Ethereum Sinatrais compatible with the Bitcoin-and Ethereum ecosystems and aims at producing a variation of Bitcoin with Ethereum Virtual Machine (EVM) compatibility. Note that differently to Ethereum, the Ethereum SinatraEVM is constantly backwards compatible. Pursuing a pragmatic design approach, Ethereum Sinatraemploys industry use cases with a strategy comprising mobile devices. The latter allows Ethereum Sinatrapromoting blockchain technology to a wide array of Internet users and thereby, decentralizing PoS transaction validation.

The remainder is structured as follows. Section 2.1 compares the advantages of Bitcoin UTXO versus the Ethereum account model. Next, Section 2.2 discusses the consensus platform for the Ethereum Sinatrablockchain. Section 2.3 shows the integration of Ethereum Sinatracontracts into the EVM. Finally, Section 2.4 describes the payment model for Ethereum Sinatraoperations.


Alex Norta

2.1 UTXO Versus Account Model

In the UTXO model, transactions use as input unspent Bitcoins that are destroyed and as transaction outputs, new UTXOs are created. Unspent transaction outputs are created as change and returned to the spender [1]. In this way, a certain volume of Bitcoins are transferred among different private key owners, and new UTXOs are spent and created in the transaction chain. The UTXO of a Bitcoin transaction is unlocked by the private key that is used to sign a modified version of a transaction. In the Bitcoin network, miners generate Bitcoins with a process called a coinbase transaction, which does not contain any inputs. Bitcoin uses a scripting language for transactions with a limited set of operations7 . In the Bitcoin network, the scripting system processes data by stacks (Main Stack and Alt Stack), which is an abstract data type following the LIFO principle of Last-In, First-Out.

In the Bitcoin client, the developers use isStandard() function [1] to summarize the scripting types. Bitcoin clients support: P2PKH (Pay to Public Key Hash), P2PK (Pay to Public Key), MultiSignature (less than 15 private key signatures), P2SH (Pay to Script Hash), and OP_RETURN. With these five standard scripting types, Bitcoin clients can process complex payment logics. Besides that, a non-standard script can be created and executed if miners agree to encapsulate such a non-standard transaction.

For example, using P2PKH for the process of script creation and execution, we assume paying 0.01BTC for bread in a bakery with the imaginary Bitcoin address ”Bread Address”. The output of this transaction is: OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG The operation OP_DUP duplicates the top item in the stack. OP_HASH160 returns a Bitcoin address as top item. To establishes ownership of a bitcoin, a Bitcoin address is required in addition with a digital key and a digital signature. OP_EQUAL yields TRUE (1) if the top two items are exactly equal and otherwise FALSE (0). Finally, OP_CHECKSIG produces a public key and signature together with a validation for the signature pertaining to hashed data of a transaction, returning TRUE if a match occurs.

The unlock script according to the lock script is:
❮Bread Signature❯ ❮Bread Public Key❯
The combined script with the above two:
❮Bread Signature❯ ❮Bread Public Key❯OP_DUP OP_HASH160
❮Bread Public Key Hash❯ OP_EQUAL OP_CHECKSIG

Only when the unlock script and the lock script have a matching predefined condition, is the execution of the script combination true. It means, the Bread Signature must be signed by matching the private key of a valid Bread Address signature and then the result is true.

Unfortunately, the scripting language of Bitcoin is not Turing-complete, e.g., there is no loop function. The Bitcoin scripting language is not a commonly used programming language. The limitations mitigate the security risks by preventingthe occurrence of complex payment conditions, e.g., generating infinite loops, or other complicated logic loopholes.


Smart-Contract Information-& Value Logistics

In the UTXO model, it is possible to transparentlytrace back the history of each transaction through the public ledger. The UTXO model has parallel processing capability to initialize transactions among multiple addresses indicating the extensibility. Additionally, the UTXO model supports privacy in thatusers can use Change Address as the output of a UTXO. The target of Ethereum Sinatrais to implement smart contracts based on the innovative design of the UTXO model.

Versus the UTXO model, Ethereum is an account based system8 . More precisely, each account experiences direct value-and information transfers with state transitions. An Ethereum account address of 20 bytes comprises a nounce as a counter for assuring one-time processing for a transaction, the balance of the main internal crypto fuel for paying transaction fees called Ether, an optional contract code and default-empty account storage.

The two types of Ether accounts are on the one hand, private-key controlled external and on the other hand, contract-code controlled. The former code-void account type creates and signs transactions for message transfer. The latter activates code after receiving a message for reading and writing internal storage, creating contracts, or sending other messages.

In Ethereum, balance management resembles a bank account in the real world. Every newly generated block potentially influences the global status of other accounts. Every account has its own balance, storage and code-space base for calling other accounts or addresses, and stores respective execution results. In the existing Ethereum account system, users perform P2P transactions via client remote procedure calls. Although sending messages to more accounts via smart contracts is possible, these internal transactions are only visible in the balance of each account and tracking them on the public ledger of Ethereum is a challenge.

Based on the discussion above, we consider the Ethereum account model to be a scalability bottleneck and see clear advantages of the Bitcoin-network UTXO model. Since the latter enhances the network effect we wish to offer, an essential design decision for the pending Ethereum Sinatrarelease is the adoption of the UTXO model.

2.2 Consensus Management

There are ongoing discussions about consensus and which platform meets the needs of respective project requirements. The consensus topics most widely discussed are: PoW [41], PoS [2], Dynamic PoS9 , and Byzantine Fault Tolerance [7] as discussed by HyperLedger. The nature of consensus is about achieving data consistency with distributed algorithms. Available options are, e.g., the Fischer Lynch and Paterson theorem [5] that states consensus cannot be reached without 100% agreement amongst nodes.


Alex Norta

In the Bitcoin network, miners participate in the verification process by hash collision through PoW. When the hash value of a miner is able to calculate and meet a certain condition, the miner may claim to the network that a new block is mined:


For the amount of miners M and the mining difficulty D, the Hash() represents the SHA256 power with value range [0, M], and D. The SHA256 algorithm used by Bitcoin enables every node to verify each block quickly, if the number of miners is high versus the mining difficulty.

The 80 byte BlockHeader varies with each different Nonce. The overall difficulty level of mining adjusts dynamically according to the total hash power of the blockchain network. When two or more miners solve a block at the same time, a small fork happens in the network. This is the point where the blockchain needs to make a decision as to which block it should accept, or reject. In the Bitcoin network, the chain is legitimate that has the most proven work attached.

Most PoS blockchains can source their heritage back to PeerCoin10 that is based on an earlier version of Bitcoin Core. There are different PoW algorithms such as Scrypt11, X1112, Groestl13, Equihash [4], etc. The purpose of launching a new algorithm is to prevent the accumulation of computing power by one entity and ensure that Application Specific Integrated Circuits (ASIC) can not be introduced into the economy. Ethereum SinatraCore chooses PoS based on the latest Bitcoin source code for basic consensus formation.

In a traditional PoS transaction, the generation of a new block must meet the following condition:

ProofHash ❮ coins X age X target

In ProofHash, the stake modifier [40] computes together with unspent outputs and the current time. With this method, one malicious attacker can start a double-spending attack by accumulating large amounts of coin age. Another problem caused by coin age is that nodes are online intermittently after rewarding instead of being continuously online. Therefore, in the improved version of PoS agreement, coin age removal encourages more nodes to be online simultaneously.

The original PoS implementation suffers from several security issues due to possible coin age attacks, and other types of attacks [16]. Ethereum Sinatraagrees with the security analysis of the Blackcoin team [40] and adopts PoS 3.0 14 into the latest Ethereum SinatraCore. PoS 3.0 theoretically rewards investors that stake their coins longer, while giving no incentive to coin holders who leave their wallets offline.

  1. https://peercoin.net/
  2. https://litecoin.info/Scrypt
  3. http://cryptorials.io/glossary/x11/ 13http://www.groestlcoin.org/about-groestlcoin/
  4. http://blackcoin.co/

Smart-Contract Information-& Value Logistics

2.3 Ethereum SinatraContract and EVM Integration

The EVM is stack-based with a 256-bit machine word. Smart contracts that run on Ethereum use this virtual machine for their execution. The EVM is designed for the blockchain of Ethereum and thus, assumes that all value transfer use an account-based method. Ethereum Sinatrais based on the blockchain design of Bitcoin and uses the UTXO-based model. Thus, Ethereum Sinatrahas an account abstraction layer that translates the UTXO-based model to an account-based interface for the EVM. Note that an abstraction layer in computing is instrumental for hiding the implementation details of particular functionality to establish a separation of concerns for facilitating interoperability and platform independence.

EVM Integration:All transactions in Ethereum Sinatrause the Bitcoin Scripting Language, just like Bitcoin. In Ethereum Sinatrahowever, there exist three new opcodes. –OP_EXEC: This opcode triggers special processing of a transaction (explained below) and executes specific input EVM bytecode.

–OP_EXEC_ASSIGN: This opcode also triggers special processing such as OP_EXEC. This opcode has as input a contract address and data for the contract. Next follows the execution of contract bytecode while passing in the given data (given as CALLERDATA in EVM). This opcode optionally transfers money to a smart contract.

–OP_TXHASH: This opcode is used to reconcile an odd part of the accounting abstraction layer and pushes the transaction ID hash of a currently executed transaction.

Traditionally, scripts are only executed when attempting to spend an output. For example, while the script is on the blockchain, with a standard public key hash transaction, no validation or execution takes place. Execution and validation does not happen untila transaction input references the output. At this point, the transaction is only valid if the input script (ScriptSig) does provide valid data to the output script that causes the latter to return non-zero.

Ethereum Sinatrahowever, must accommodate smart contracts that execute immediately when merged into the blockchain. As depicted in Figure 1 , Ethereum Sinatraachieves this by the special processing of transaction output scripts (ScriptPubKey) that contain either OP_EXEC, or OP_EXEC_ASSIGN. When oneof these opcodes is detected in a script, it is executed by all nodes of the network after the transaction is placed into a block. In this mode, the actual Bitcoin Script Language serves less as a scripting language and instead carries data to the EVM. The latter changes state within its own state database, upon execution by either of the opcodes, similar to a Ethereum contract.

For easy use of Ethereum Sinatrasmart contracts, we have to authenticate the data sent to a smart contract as well as its creator stemming from a particular pubkeyhash address. In order to prevent the UTXO set of the Ethereum Sinatrablockchain from becoming too large, OP_EXEC and OP_EXEC_ASSIGN transaction outputs are also spendable. OP_EXEC_ASSIGN outputs are spent by contractswhen their code sends money to another contract, or to a pubkeyhash address. OP_EXEC outputs

Alex Norta