On and Off-Blockchain Enforcement Of Smart Contracts Dr Ellis Solaiman Ellis.Solaiman@ncl.ac.uk School of Computing, Newcastle University Authors: C Molina-Jimenez, E Solaiman, I Sfyrakis, I Ng, J Crowcroft INTERNATIONAL WORKSHOP ON FUTURE PERSPECTIVE OF DECENTRALIZED APPLICATIONS -- FPDAPP 2018 IN CONJUCTION WITH THE 24TH INTERNATIONAL EUROPEAN CONFERENCE ON PARALLEL AND DISTRIBUTED COMPUTING – EUROPAR 2018
Motivating Scenario: Data-buyer/Data-seller Contractual Agreement 1 The data buyer is entitled to present the data seller with offers to buy data data … 2 The data seller is free to use her discretion to either reject the offer or … used for producing Alice’s domestic sensors Smart Contract Data seller S 1 Data buyer used for enforcing (Alice) (Bob) data contract-regulated operations S 2 repository S n Assumption: Parties are reluctant to trust each other. Required: Mechanism that assures: 1) All parties act in accordance with agreed upon set of rules (a contract). 2) Performed actions are indelibly recorded on means that that make them undeniable and examinable. FPDAPP 2018
Example Contractual Clauses that can be used to regulate data trading FPDAPP 2018
Contract between a buyer and store for trading data FPDAPP 2018
Centralized and decentralized smart contracts op/rp Adv: Simple. DisAdv: Single point of failure & N 2 B SC 2 Trust placed on the TTP. N 1 N 3 CP TTP node SC 1 SC 3 CP CP op/rp A SC CP op/rp op/rp SC 4 N 4 Adv: trust verification & B A Distributed data storage. DisAdv: Performance & a) centralised smart contract. b) descentralised smart contract. Consistency maybe Inadequate for a certain Class of applications. FPDAPP 2018
Problem statement ● Smart contracts can be used as a software mechanism to ensure that business partners act according to agreed upon rules . Smart contracts can be built on the basis of blockchain technologies . Examples of such technologies are Bitcoin, Ethereum and Hyperledger. ● However, blockchain-based smart contracts are only at their initial research stage, and plagued with questions about their scalability, performance, transaction costs and other questions that emerge from their decentralised nature. FPDAPP 2018
Contributions ● i) We discuss different approaches to implement smart contracts ranging from centralised to decentralised. ● ii) We explain the advantages and disadvantages of these approaches and argue that their suitability in solving the problem depends on the particularities of the application, the assumptions made about the application, and the facilities offered by the blockchain technology available. ● iii) We argue that there is a large class of applications that can benefit from a hybrid solution. FPDAPP 2018
Centralized implementation of a smart contract TTP node Adv: Simple. No need for a CP SC Protocol. (impl. by Alice’s domestic CCC) SC implemented in Drools, a sensors Java Based language (Turing Complete). op cc | ncc S 1 op op DisAdv: gateway data Single point of failure & S 2 (open | close) repository Trust placed on the TTP. rp rp Need to rely on a bank to Data buyer (Bob) Data seller (Alice) S n perform PAY operations. FPDAPP 2018
Decentralized implementation of a smart contract Adv: Replication of the SC, and No dependence on a TTP. N 2 SC 2 (trust verification & N 1 N 3 CP Distributed data storage). CP CP SC 1 SC 3 DisAdv: Transaction fee. CP Cost of running a CP: Alice’s domestic N 4 Performance & Consistency maybe sensors SC 4 c cc | ncc cc | ncc c cc | ncc o Inadequate for a certain Class of op | p n applications: c c S 1 Transaction rate. op op Latency problems. gateway data S 2 If Strong consistency protocols (open | close) repository rp rp are used then we end up with Data buyer (Bob) Data seller (Alice) scalability issues. S n FPDAPP 2018
Hybrid implementation of a smart contract (loose interaction) op/rp B SC 2 N 2 N 1 N 3 CP CP CP SC 1 SC 3 CP SC 4 N 4 c cc | ncc c p n d-op TTP node o | - d c c SC (impl. by Alice’s domestic CCC) sensors c-op cc | ncc S 1 c-op c-op gateway data S 2 (open | close) repository rp rp Data buyer (Bob) Data seller (Alice) S n FPDAPP 2018
Separation of distributed and centralized operations - factors ● Expressiveness of the language used for writing the contract. ○ if the blockchain does not offer a Turing--complete language, the implementers needs to keep the d—op category simple (bitcoin for example). ○ in a blockchain platform like Ethereum that offers a Turing--complete language the designer can afford to pass as much complexity to the decentralised part of the figure as she wishes to. ● Transaction fee. For example, Bitcoin and Ethereum have already experienced average transaction fees of 54.90 and 4.15 USD, respectively. ● Performance of the blockchain: for example, the number of transactions per second (may impact some applications – such as IoT), and consistency requirements. FPDAPP 2018
Hybrid [centralized / decentralized integration] use cases ● {Indelible blockchain--based log}: We can operate the blockchain—based part of the hybrid architecture as a passive log that records events that the parties consider worth duplicating. By passive, we mean that the nodes would not be involved in enforcing activities. Enforcement would be entirely the responsibility of the CCC. ● {Cryptocurrency--based payment channel}: The data buyer of the previous example takes advantage of the payment services offered by the public blockchain. This approach is recommended only when the payment operation is significantly larger than the transaction fees and is not repetitive. ● {Off-blockchain execution of operations}: The CCC on the TTP is used as an off- blockchain channel. Operations that cannot be executed on the blockchain because of issues discussed previously (e.g, performance), are executed on the the CCC. FPDAPP 2018
Future research directions ● Exploring the technical challenges involved in the Hybrid implementation of Smart Contracts. We are investigating how a hybrid architecture can be realized using the Ethereum Blockchain and a CCC implemented as a TTP. ● Investigating the interaction between the CCC and the blockchain (loose or tight). ● Investigate how to separate the contract into c-op and d-op so that the two contracts collaborate instead of conflicting with each other. This most likely will require the assistance of model checking tools for contracts with scores of clauses. ● Investigate languages used for writing the smart contracts. Current Blockchains support only imperative languages (Ethereum’s solidity for example). Arguably rule based declarative languages such as the CCC’s Drools language are more suitable for writing smart contracts. ● https://arxiv.org/pdf/1808.00093.pdf FPDAPP 2018
Thank You for listening ! Questions? FPDAPP 2018
Recommend
More recommend
