On and Off-Blockchain Enforcement Of Smart Contracts Dr Ellis - - PowerPoint PPT Presentation

on and off blockchain enforcement of smart contracts
SMART_READER_LITE
LIVE PREVIEW

On and Off-Blockchain Enforcement Of Smart Contracts Dr Ellis - - PowerPoint PPT Presentation

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


slide-1
SLIDE 1

On and Off-Blockchain Enforcement Of Smart Contracts

Authors: C Molina-Jimenez, E Solaiman, I Sfyrakis, I Ng, J Crowcroft

Dr Ellis Solaiman Ellis.Solaiman@ncl.ac.uk School of Computing, Newcastle University

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

slide-2
SLIDE 2

Motivating Scenario: Data-buyer/Data-seller Contractual Agreement

Smart Contract contract-regulated operations used for producing

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 …

S1 S2 Sn

Data seller (Alice) used for enforcing Data buyer (Bob) data repository Alice’s domestic sensors

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. Assumption: Parties are reluctant to trust each other.

FPDAPP 2018

slide-3
SLIDE 3

Example Contractual Clauses that can be used to regulate data trading

FPDAPP 2018

slide-4
SLIDE 4

FPDAPP 2018

Contract between a buyer and store for trading data

slide-5
SLIDE 5

Centralized and decentralized smart contracts

A B

  • p/rp
  • p/rp

TTP node A B

  • p/rp

CP CP CP CP N3 N2 N1 N4

  • p/rp

a) centralised smart contract. b) descentralised smart contract.

SC1 SC4 SC2 SC3 SC

Adv: Simple. DisAdv: Single point of failure & Trust placed on the TTP. Adv: trust verification & Distributed data storage. DisAdv: Performance & Consistency maybe Inadequate for a certain Class of applications.

FPDAPP 2018

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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

  • f 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

slide-8
SLIDE 8

Sn

data repository Data buyer (Bob)

S1 S2

Alice’s domestic sensors Data seller (Alice)

cc | ncc TTP node

gateway (open | close)

  • p
  • p
  • p

rp rp

SC (impl. by CCC)

Centralized implementation of a smart contract

Adv:

  • Simple. No need for a CP

Protocol. SC implemented in Drools, a Java Based language (Turing Complete). DisAdv: Single point of failure & Trust placed on the TTP. Need to rely on a bank to perform PAY operations.

FPDAPP 2018

slide-9
SLIDE 9

Decentralized implementation of a smart contract

Sn

data repository Data buyer (Bob)

S1 S2

Alice’s domestic sensors Data seller (Alice) gateway (open | close)

  • p
  • p

rp rp CP CP CP CP N3 N2 N1 N4

SC1 SC4 SC2 SC3

  • p

cc | ncc

  • p

c c | n c c cc | ncc cc | ncc Adv: Replication of the SC, and No dependence on a TTP. (trust verification & Distributed data storage). DisAdv: Transaction fee. Cost of running a CP: Performance & Consistency maybe Inadequate for a certain Class of applications: Transaction rate. Latency problems. If Strong consistency protocols are used then we end up with scalability issues.

FPDAPP 2018

slide-10
SLIDE 10

data repository Data buyer (Bob)

S1 S2 Sn

Alice’s domestic sensors Data seller (Alice)

cc | ncc TTP node

gateway (open | close)

c-op c-op c-op rp rp d-op cc | ncc c c | n c c d

  • p

B CP CP CP CP N3 N2 N1 N4

  • p/rp

SC1 SC4 SC2 SC3 SC (impl. by CCC)

Hybrid implementation of a smart contract (loose interaction)

FPDAPP 2018

slide-11
SLIDE 11

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

slide-12
SLIDE 12

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

slide-13
SLIDE 13

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
  • nly 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

slide-14
SLIDE 14

Thank You for listening ! Questions?

FPDAPP 2018