• No results found

As aftermath, Ripple Labs have agreed and acknowledged our security analysis in their public web-page [85] in 2015. Following our work [16], Chase and MacBrough have extended the analysis of Ripple’s consensus protocol in 2018 [81]. In the last section, the necessary condition for no fork was established with a counter example. We showed that if the intersection does not have more than 40% of the maximum size between two UNLs, a fork might happen. We saw that a fork can happen when |UNLu| = |UNLv| = 5 and |UNLu∩ UNLv| = 2 with

an overlap exactly 40% of the maximum size between two UNLs. This example implicitly assumes that both UNLs have same size. Chase and MacBrough have shown that the necessary condition can be relaxed by taking average instead of maximum [81]. The necessary and sufficient condition can be restated as:

5.5. ANALYSIS FROM CHASE AND MACBROUGH 53

For simplicity let’s denote, |UNLu| = nu and |UNLv| = nv. The condition

can be rewritten as: |UNLu∩ UNLv| > (1 − ρ)(nu+ nv).

To show this condition is necessary, we can have two cases:

Case 1: |B| = |UNLu∩ UNLv| ≤ (1 − ρ)nv. In this scenario, it is possible

for all servers in UNLu to publish ledger L1 and on other hand all servers in

C = UNLv\ UNLu can publish another ledger L2 as |C| ≥ ρ · nv, which results

in a fork.

Case 2: |UNLu∩ UNLv| ≤ (1 − ρ)(nu+ nv) and |UNLu∩ UNLv| > (1 − ρ)nv.

Hence,

|A| =|UNLu\ UNLv| = |UNLu| − |UNLu∩ UNLv|

≥nu− (1 − ρ)(nu+ nv)

≥ρ · nu+ (ρ − 1)nv

Now as per the assumption |B| = |UNLu∩ UNLv| > (1 − ρ)nv, (1 − ρ)nv

servers in B can publish L1. Furthermore, if all validating servers in A publish

the ledger L1, UNLu can receive at least (1 − ρ)nv+ ρ · nu+ (ρ − 1)nv= ρ · nu

many validations for ledger L1. Thus UNLu can publish the ledger L1. On the

other hand, only (1 − ρ)nv validating servers in B publish for L1. Hence, it

is possible for UNLv to publish another ledger L2 as, nv− (1 − ρ)nv = ρ · nv,

resulting a fork.

Next, we look whether Equation 5.11 is sufficient to prevent fork. Assume, the validating server u accepts the ledger L1 from its UNL and Equation 5.11

is true. The set A1∪ B1⊆ UNLu publish the ledger L1 i.e. |A1∪ B1| > ρ · nu

(see Equation 5.5). To prove that Equation 5.11 is sufficient to prevent fork, it is enough to show |B1| > (1 − ρ)nv, because in that case UNLv cannot have

sufficient validation for another ledger L2.

|B1| =|A1∪ B1| − |A1|

≥|A1∪ B1| − |A|

=|A1∪ B1| − (|UNLu| − |UNLu∩ UNLv|)

>|A1∪ B1| − (nu− (1 − ρ)(nu+ nv))

≥ρ · nu− (nu− (1 − ρ)(nu+ nv))

=(1 − ρ)nv

Thus Equation 5.11 is necessary and sufficient to prevent any fork.

Chase and MacBrough further investigated the current version of Ripple’s con- sensus protocol without the original byzantine accountability assumption. They concluded that in that case the UNL intersection has to be atleast 90% [81, Thm 8] to avoid forks. Furthermore, they provided a counterexample of liveness prop- erty [81, Sec. 4.2], where protocol can get stuck as soon as the UNL intersection

54 CHAPTER 5. ANALYSIS OF RIPPLE’S CONSENSUS PROTOCOL

is less that 99%. This results essentially shows Ripple consensus protocol is far away from being a distributed BFT protocol and rigorous improvement is required for its decentralization.

5.6

Summary

We describe the Ripple consensus protocol in detail and discuss its security. Our finding shows that the parameters suggested in Ripple whitepaper [5] do not prevent forks in the system. We also discuss the conditions to prevent forks [16] and an improvement suggested by Chase and MacBrough [81].

Part III

On Privacy in

Consensus-based

Distributed Economic

Dispatch Protocols in

Smart Grid

55

Chapter 6

A Brief Introduction to the

Smart Grid

6.1

Introduction

In this chapter, we give some background information on Smart Grid, its com- ponents, agents, and its security, privacy issues. Traditionally, the electricity is generated in bulk and transported via a high voltage transmission line. Af- terward, it is transformed into medium voltage and finally distributed among end consumers at low voltage. In a traditional grid, the electricity cannot be stored, and generation should match the consumption. In this model, electricity mainly comes from some central generators, and generated electricity relies on the predicted consumption. Since the last decade, the traditional electricity grid has undergone some major infrastructural changes in the direction to become smarter. This smart grid builds a bi-directional information communication network on top of the existing energy network aiming at a more efficient, sus- tainable, and reliable use of energy [86, 87]. This modern electrical grid includes several advantages over the traditional electricity grid, such as real-time energy monitoring, distributed generation, energy storage, energy trading, integration of renewable energy resources, refined energy measurement, and management, etc. Each consumer is equipped with smart meters for refined consumption mea- surement, and data is shared with suppliers for smooth operation in the grid. However, it raises severe privacy concerns as the shared measurement data re- veals private information about the users [88]. Furthermore, current energy management protocols in the smart grid are vulnerable to private information leakage [12]. In the next sections, we give an overview of the smart grid and discuss current security and privacy issues.

58 CHAPTER 6. A BRIEF INTRODUCTION TO THE SMART GRID