a peer-to-peer alternative to blockchain for managing distributed … · 2017. 6. 16. ·...

Motivation & Problem Proposed Solution Evaluation Conclusions & Future Work

A Peer-to-Peer Alternative to Blockchain forManaging Distributed Data Transactions

Samuel Cauvin Martin KollingbaumWamberto Vasconcelos

Dept. of Computing Science, University of Aberdeen, Aberdeen, [email protected]

SmartLaw@ICAIL 2017, London, UK

1 / 23

mailto:[email protected]


Outline

1 Motivation & Problem

2 Proposed Solution

3 Evaluation

4 Conclusions & Future Work

2 / 23


Content


2 Proposed Solution

3 Evaluation


3 / 23


Motivation

Large scale data sharing is important

More so due to more open societies of components such asSmart Cities and the Internet of Things

We adopt the view of data sharing as being facilitated bysmart contracts

4 / 23


Problem

Current data access policies are managed centrally

This comes with issues, such as:

Information ownershipReliance on a centralised authority

Our hypotheses are that it is possible to:1 Create a fully distributed mechanism to facilitate data sharing

with security guarantees2 Create a policy language to regulate data access which allows

for fine-grained control over how data is exchanged betweenstakeholders

3 Retain a high level of stakeholder satisfaction while stillproviding security guarantees

5 / 23


BlockChain

One solution to access management could make use ofBlockchain

As the primary security concern is ensuring transactions arelogged accurately, a distributed ledger would achieve this

The Blockchain implementation we focus on is the Bitcointransaction ledger, however we are aware of more recentdevelopments e.g. Monax and Ethereum.

We propose an alternative to BlockChain for this specific usecase

6 / 23


Proposal

We aim to provide an information model and mechanisms forparticipants in an open society to share data in adecentralised and secure manner

We propose controlling access to data through explicitpolicies within a fully distributed environment

In this environment, data and transaction records areencoded to avoid tampering

These transaction records are stored by each peer, and not ina central location

Our peers follow a specific protocol which they cannot deviatefrom

7 / 23


Content


2 Proposed Solution

3 Evaluation


8 / 23


Policy Specification Language

We have policies which define how data can be accessed

Policies are of the form 〈M, I ,D, ϕ, σ, ω〉, where:

M is a modality operator (Permit P or Prohibit F)I is a peer idD is a data elementϕ are conditions for policy activationσ are pre-obligations, which must be completed before accessis providedω are obligations, which must be completed after access isprovided

9 / 23


Example Policies

〈P, peer1 , d1 ,>,>, 〈provide(d4 , 5, peer2), 5, 10〉〉

Permit peer1 to access data d1

In return peer1 must provide 5 x data d4 to peer2

If not completed within ten “cycles”, a penalty of 5 is assigned

〈P, any , d1 , 〈recordsAccessed(any , d2) < 5〉,>,>〉

Permit any peer to access data d1

If they have accessed less than 5 x data d2 from any source

10 / 23


Transaction Records

To allow us to track transactions, each peer maintains theirown records

This is a solution to distributed record keeping

Transaction records are protected by encoded signatures, suchthat the authenticity of a record is easy to verify but hard tofalsify

For this we assume the existence of a refreshable encodingmechanism, which periodically updates how records areencoded

11 / 23


Peer Compliance

In order to exchange messages, all peers must follow themechanism we have designed

Message formats cannot be impersonated

Obligation penalties are self enforced by peers in the form of“penalty cycles”

Each cycle that a peer participates in a network hasassociated costs (bandwidth, power consumption)

Penalty cycles are cycles in which peers must participate inthe network, but cannot do anything which benefits them

12 / 23


Typical Transaction

Requestor Provider

(1) Data Request

(2) Policy Inform

No Data

(4) Record Inform

Reject Policies

(5)

No Access

(5a) Pre Obligation Inform

Malformed Records

(6) Data Result

(5c) Pre Obligation Complete

(6) Data Result

(3)

(7)

(7)

(5b)

13 / 23


Worked Example

Requestor R wants to get ten items of data element d1 fromProvider P

In this example, objects that are encoded shall be highlighted

14 / 23


Worked Example


P has the following policies:

P1 〈P, any , d1 ,>,>, 〈provide(d4 , 5,me), 5, 10〉〉Permit d1 to anyone, but they provide 5 elements of d4 to P

P2 〈P, any , d1 , 〈recordsAccessed(any , d2) < 5〉,>,>〉Permit d1 to anyone who has accessed < 5 elements of d2

14 / 23


Worked Example





R has the following transaction records:〈d1 , 50〉, 〈d5 , 50〉, 〈d4 , 50〉, 〈d3 , 10〉, 〈d2 , 10〉, 〈d3 , 10〉

14 / 23


Worked Example





R has the following transaction records:〈d1 , 50〉, 〈d5 , 50〉, 〈d4 , 50〉, 〈d3 , 10〉, 〈d2 , 10〉, 〈d3 , 10〉

We define relevant records as any that mention a data elementfrom the policy. R determines that three transaction records arerelevant:〈d1 , 50〉, 〈d2 , 10〉, 〈d4 , 50〉These relevant transaction records are then sent to P

14 / 23


Worked Example





Relevant transaction records: 〈d1 , 50〉, 〈d2 , 10〉, 〈d4 , 50〉

P compares these transaction records to their policies, and findsthat P1 holds but P2 does not.

14 / 23


Worked Example





P1 obliges R to send 5 elements of d4 to P, and this will be doneafter receiving the data.

P generates a “receipt” and sends it, along with the ten dataelements of d2 to R

14 / 23


Content


2 Proposed Solution

3 Evaluation


15 / 23


Architecture

Neighbours

EncryptionMechanism Decryption

Mechanism

Peer Cycle

Reasoner

Policies

State ofAffairs

DataCollection

TransactionRecords

Peer

P2

P3 Pn...

16 / 23


Prototype

We have developed a prototype of our mechanism using Javaand Prolog

The Java part uses PeerSim to simulate the peer-to-peernetwork

The Prolog part consists of a peer knowledge-base andperforms all reasoning operations

In our prototype we have a number of peers withpseudo-random policies attempting to acquire a number ofdata items

17 / 23


Evaluation (1)

Our prototype tracks a number of metrics, but for now wefocus on the average satisfaction, i.e. the average percentageof wanted data that each peer received

Cycles

Ave

rage S

atisfa

ction (

%)

0

50

100

150

200

250

0

10

20

30

40

50

60

70

80

90

100

18 / 23


Evaluation (2)

Peers in the Network

Cycles

Pe

ers

0

50

10

0

15

0

20

0

25

0

0

50

100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

850

900

950

1000

19 / 23


Content


2 Proposed Solution

3 Evaluation


20 / 23


Conclusions

Contributions

Detailed a solution to managing distributed data sharingwithout the presence of a centralised authorityImplementation of our solution using Java and PrologInitial policy languageExploration of security problems and how they can be resolved

Issues

Current policy language is still fairly basicConflict resolution is handled primitivelyPolicies cannot be negotiated

21 / 23


Future Work

Complete development of prototype

Development of exploratory scenarios, such as Smart Citiesand Internet of Things

Run in-depth evaluations to explore our solution

Implement a transaction record encoding scheme

Compare our approach with Blockchain

22 / 23


Thanks & Questions

23 / 23

Blockchain vs. Our Approach

Initially we only considered BitCoin Blockchain which waspermission-less and partially centralised

Through our reviews e have been made aware of other formsof Blockchain and we intend to perform an evaluation tocompare our approach with some of these

For now, all we can confidently say is that our approachrequires minimal centralisation, and provides full control overpermissions; which overcomes some shortcomings of theBitCoin Blockchain

1 / 1

a peer-to-peer alternative to blockchain for managing distributed … · 2017. 6. 16. ·...

Documents