1st year PhD review

On Trust

28/5/2018

Blockchain Technology Lab

Orfeas Stefanos Thyfronitis Litos

1st Supervisor: Aggelos Kiayias

2nd Supervisor: Kousha Etessami

3rd Panel Member: Thomas Zacharias

Part I

Motivation

  • Trust is crucial for society

    • Trust the bus driver
    • Trust the government
    • Trust the bank

  • Trust exists in Blockchain

    • Trust the bitcoin developers (or read code)
    • Trust that there is honest majority
    • Trust security proofs (or study cryptography)

  • Trust exists in Game Theory

    • Trust the common prior
    • Trust signals - there is no "hidden agenda"
    • Trust the model (or conduct experiments)

Well-placed trust

Higher payoff

Misplaced trust

More damage

Tradeoff

  • Spend time to make informed decisions?

    • study Cryptography
    • inspect car engine

  • Trust and make fast decisions?

    • Deposit cash to a famous bank
    • Hire a secretary

Who and what to trust?

How much time to invest?

Applications

  • Decentralised E-commerce

    • Who to buy from?
    • How to pay?

  • Blockchain-backed payment channels

    • How to model them?
    • Why trustless?

Part II

Trust and E-commerce

Assets

Physical

Digital

  • Limited by physical laws
  • Consensus unachievable
  • Ownership disputable
  • Conflicts solved ad-hoc
  • Trust to courts
  • Defined by a protocol
  • Consensus possible
  • Ownership indisputable
  • Protocol solves conflicts
  • Trust to assumptions

Approach

  • Model a simple market
  • Model a generic reputation system
  • Define desired properties
  • Propose specific mechanisms
  • Prove (non) existence of perfect mechanism

Model

  • E sends desire to Alice
  • Alice asks Trust func. for vendor, answer is Bob
  • Alice asks Bob, Bob makes offer
  • If cheap, Alice pays
  • Bob may trade or steal
  • Alice gives feedback to:
    • Trust functionality
    • Environment
\mathcal{G}_{\mathrm{Ledger}}
\mathcal{G}_{\mathrm{Assets}}
\mathcal{F}_{\mathrm{Trust}}
\mathcal{F}_{\mathrm{Trade}}
\Pi_{\mathrm{SAT}}
\Pi_{\mathrm{SAT}}
...
\mathcal{E}
\mathcal{A}
  • Cheating security: the Environment should almost never receive report of a cheat
  • Single Corruption Game
    • A single player is malicious (not SAT prot.)
    • Game lasts for some rounds (unknown to the players)
    • Output: player with highest utility
  • Fairness
    • Adversary wins if is often the game output

Bayesian game

  • Utility: Probability of being able to satisfy desires in the future & gains from satisfied desires
  • Nature is like the Environment: unknown probabilities but players learn expected desires
  • Type: Exact moment for the calculation of utility
  • Nature chooses types and generates desires
  • Players try to satisfy them
  • Players have limited computational resources
  • They partly calculate their (and others') strategy
  • They partly trust some events happen as expected
    • Trust - time tradeoff

Part II

Payment Channels

Blockchains don't scale

  • Consensus is a complete common history
  • Every computer learns every transaction
    • Non-scalable

Solution: Payment channels

2 on-chain, unlimited off-chain transactions

1

2

Alice: 1

Bob: 2

Ledger

Alice: 0.9

Bob: 2.1

Alice: 1.1

Bob: 1.9

,

, ...

1.9

1.1

Alice: 1.1

Bob: 1.9

Ledger

Payment channels to the rescue!

  • Alice and Bob block some coins
    • 1 on-chain transaction
  • Alice pays Bob off-chain
    • 2-3 messages for an update
    • Only Alice and Bob know
  • Alice or Bob can settle with latest state
    • 1 on-chain transaction
    • Unilateral

2 on-chain for many off-chain transactions

Light and Trustless

  • If Alice and Bob agree (i.e. follow protocol) the world does not need to know
    • Updates are fast and cheap
  • If they disagree, the world is the arbiter
    • one transaction suffices
  • If Alice follows protocol, she cannot lose coins
    • No trust between parties

Multi-hop Payments

Alice: 3

Beth: 4

Beth: 5

Charlie: 2

Alice: 2

Beth: 4

For Charlie: 1

Beth: 4

Charlie: 2

From Alice: 1

Alice: 2

Beth: 5

Beth: 4

Charlie: 3

Literature

  • Lightning (Bitcoin)
    • Trustless, multihop payments, implemented
  • Perun (Ethereum)
    • Arbitrary off-chain contracts
  • Bolt (Zcash)
    • One end is anonymous
  • TeeChan (Intel TEE)
    • Very fast, uses secure enclaves
  • Fulgor, Rayo
    • Automatic routing

Considerations

  • Robustness (less than the ledger?)
  • Rounds of communication
  • Timeouts between actions
  • Frequency of checking ledger
  • On- and off-chain info leakage
  • Multi-hop routing
  • Incentives, threats and punishments
  • Number of members in a channel
  • Slowdown when Bob malicious
  • Can trust improve speed/cost?
  • Transaction fees
  • CPU, memory, storage, randomness costs

Model for channels

PC = \left(\left\{\left(P_1, c_1\right), ..., \left(P_n, c_n\right)\right\}, \left\{\left(e_1, b_1\right), ..., \left(e_m, b_m\right)\right\}, f : \mathcal{A}^n \rightarrow \mathcal{PC}\right)

Intuition: Payment Channel =

  • Pairs of players and "assured funds"
  • Pairs of on-chain endpoints and "tied funds"
  • A function from player actions to a new payment channel

Total assured funds ≤ total tied funds

Future work:

Formalise, Translate existing channels to our model

\sum\limits_{i=1}^n c_i \leq \sum\limits_{j=1}^m b_j

Inverting the question

  • Minimal ledger for robust payment channels?
  • Maybe not a blockchain?
  • Use trust for lighter systems?
  • No answers yet, future work

Icons Credits

Thank you!

Made with Slides.com