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 made by Nikita Golubev from www.flaticon.com is licensed by CC 3.0 BY
-
Icons made by Smashicons from www.flaticon.com is licensed by CC 3.0 BY
Icons Credits
Thank you!
1st year review
By orfeas
1st year review
20'-30' presentation
- 831