1st year PhD review
Blockchain Technology Lab
Orfeas Stefanos Thyfronitis Litos
1st Supervisor: Aggelos Kiayias
2nd Supervisor: Kousha Etessami
3rd Panel Member: Thomas Zacharias
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)
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?
- Who to buy from?
- How to pay?
Blockchain-backed payment channels
- How to model them?
- Why trustless?
Trust and E-commerce
- 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
- Model a simple market
- Model a generic reputation system
- Define desired properties
- Propose specific mechanisms
- Prove (non) existence of perfect mechanism
- 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
- 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
- Adversary wins if is often the game output
- 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
Blockchains don't scale
- Consensus is a complete common history
Every computer learns every transaction
Solution: Payment channels
2 on-chain, unlimited off-chain transactions
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
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
For Charlie: 1
From Alice: 1
- Trustless, multihop payments, implemented
- Arbitrary off-chain contracts
- One end is anonymous
TeeChan (Intel TEE)
- Very fast, uses secure enclaves
- Automatic routing
- 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
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
Formalise, Translate existing channels to our model
Inverting the question
- Minimal ledger for robust payment channels?
- Maybe not a blockchain?
- Use trust for lighter systems?
- No answers yet, future work
1st year review