ICT role in 21st century education and its challenges
01 what is blockchain
1. What is Blockchain?
And how does it work?
Dr. Bastian Blankenburg, UTU Technologies Limited
Nairobi, September 2018
2. Outline
1. Blockchain: a Distributed Ledger Technology
2. Smart Contracts and Decentralised Applications
3. Challenges of 1st and 2nd Generation Blockchains — and some Solutions
4. UTU’s case
5. Conclusion
4. Blockchain: a Distributed Ledger Technology
Source: Blockchain technology. Legislative Council of the Hong Kong Special Administrative Region, 2015,
http://www.legco.gov.hk/research-publications/english/essentials-1516ise15-blockchain-technology.htm, original source given: Oliver Wyman (2015)
• Ledger: history of transactions.
• Examples: Bank account, land registry, Facebook, any classical database
Centralised ledger Distributed ledger
5. How to Safely Distribute a Ledger? (1)
Each node to add only valid transactions:
•digitally sign a hash of the previous transaction and the public key of the next owner.
•recipient can verify the signatures to verify the chain of ownership.
6. How to Safely Distribute a Ledger? (1)
Each node to add only valid transactions:
•digitally sign a hash of the previous transaction and the public key of the next owner.
•recipient can verify the signatures to verify the chain of ownership.
7. How to Safely Distribute a Ledger? (2)
Prevent double-spend:
•Every node needs to know of all transactions.
•Majority of nodes need to agree on single history of the order of transactions.
Solution: time-stamping:
1. Take hash of a set (“block”) of transactions + previous timestamp.
2. Timestamp the hash.
3. Publish the hash + timestamp widely.
8. How to Safely Distribute a Ledger? (2)
Prevent double-spend:
•Every node needs to know of all transactions.
•Majority of nodes need to agree on single history of the order of transactions.
Solution: time-stamping:
1. Take hash of a set (“block”) of transactions + previous timestamp.
2. Timestamp the hash.
3. Publish the hash + timestamp widely.
9. How to Safely Distribute a Ledger? (3)
Problem: No central server for time-stamping.
Solution: p2p time-stamping using Proof of Work:
1. Everybody can create blocks + hashes.
2. But: hashing is made difficult.
3. Broadcast blocks to all known nodes (recursively)
4. Consensus: the longest chain always wins.
10. How to Safely Distribute a Ledger? (3)
Problem: No central server for time-stamping.
Solution: p2p time-stamping using Proof of Work:
1. Everybody can create blocks + hashes.
2. But: hashing is made difficult.
3. Broadcast blocks to all known nodes (recursively)
4. Consensus: the longest chain always wins.
Sources: Bitcoin: A Peer-to-Peer Electronic Cash System. Nakamoto, 2008, https://bitcoin.org/bitcoin.pdf,
11. How to Safely Distribute a Ledger? (3)
Problem: No central server for time-stamping.
Solution: p2p time-stamping using Proof of Work:
1. Everybody can create blocks + hashes.
2. But: hashing is made difficult.
3. Broadcast blocks to all known nodes (recursively)
4. Consensus: the longest chain always wins.
Sources: Bitcoin: A Peer-to-Peer Electronic Cash System. Nakamoto, 2008, https://bitcoin.org/bitcoin.pdf,
13. What are Smart Contracts?
• A smart contract
• is a program that is run as transactions on the chain,
• can execute transactions as specified through its code,
• has to be “mined” to made available in the chain, which includes assigning it an address,
• provides functions which are invoked in transactions,
• has a proper on-chain address, i.e. can hold and transfer coins,
• is publicly verifiable (because on-chain), and
• typically costs a transaction fee to execute (“gas”).
• Smart contracts enable decentralised apps:
• transaction sequences they specify are guaranteed by the platform.
• apps can be for use by humans but also autonomous software agents (cf. multi-agent system).
14. Smart Contract Example
contract Purchase {
uint public value;
address public seller;
address public buyer;
enum State { Created, Locked, Inactive }
State public state;
// Ensure that `msg.value` is an even number. Division will truncate if it is an odd
// number. Check via multiplication that it wasn't an odd number.
constructor() public payable {
seller = msg.sender;
value = msg.value / 2;
require((2 * value) == msg.value, "Value has to be even.");
}
modifier inState(State _state) {
require(
state == _state,
"Invalid state."
);
_;
}
event PurchaseConfirmed();
/// Confirm the purchase as buyer. Transaction has to include `2 * value` ether.
/// The ether will be locked until confirmReceived is called.
function confirmPurchase()
public
inState(State.Created)
condition(msg.value == (2 * value))
payable
{
emit PurchaseConfirmed();
buyer = msg.sender;
state = State.Locked;
19. How to Double-Spend
10 BTC
Malicious miner:
Legitimate balance:
Buys some goods online for 5 BTC.
5 BTC
tx: 5 BTC
20. How to Double-Spend
10 BTC
Malicious miner:
Legitimate balance:
Buys some goods online for 5 BTC.
5 BTC
Cheated balance: 10 BTC
tx: 5 BTC
21. How to Double-Spend
10 BTC
Malicious miner:
Legitimate balance:
Buys some goods online for 5 BTC.
5 BTC
Cheated balance: 10 BTC
Cheated chain needs
to grow longest to be
accepted.
Needs at least 51%
“hash rate”.
tx: 5 BTC
22. Challenge 1: Centralisation and 51% Attacks
• Nakamoto’s original argument: unlikely that a miner (or coalition) reaches >= 51% hash rate.
• But:
• Bitmain almost there for Bitcoin.
• Recently a number of 51% attacks happened on smaller chains (e.g. Bitcoin Gold).
• Vitalik Buterin’s recipe for takeover: create a smart contract for a coordinated activity such that:
• Any miner can join by sending a very large deposit to the contract.
• Miners send shares of their partially completed blocks to the contract; the contract verifies this and
also that you are a miner with sufficient hash power.
• Before 60% of all miners join, one can leave at anytime.
• After 60% of all miners join, you will be bound to the contract until the 20 blocks have been added to
cheating chain.
23. Excursus: Game Theory
• A (mathematical) tool to analyse strategic interaction between rational decision-makers.
• Types:
• Non-cooperative (no agreements) vs Cooperative (binding agreements)
• Simultaneous vs. sequential
• Perfect vs. imperfect information (-> Bayesian games)
• Zero-sum or not
• Repeated or one-time only
• Solutions:
• Non-Cooperative: Nash equilibrium
• Cooperative: Core, Shapley Value, Kernel etc.
24. Example: Prisoner’s Dilemma
Source: The legacy of John Nash and his equilibrium theory. Stephen Woodcock, 2015, The
Conversation, https://phys.org/news/2015-05-legacy-john-nash-equilibrium-theory.html
28. The Case Against the 51% Attack
Game-theory:
• “Grim Trigger” game:
• Should an heir to the throne kill the current queen/king?
• Subjects get guarantee of stability from the kingdom.
• Once you killed the 1st king, there’s no reason to not also kill all subsequent kings!
• Once a chain was 51%-attacked, there’s no reason to not do it again for miners in general. However:
• This only holds if miners have vested interest in keeping the blockchain working in the long term, and
not completely destroy its ecosystem.
• Other chains for which miners don’t care so much can be exploited, then miners move on.
• The attacks on Bitcoin Gold and other small chains, but not Bitcoin or other big chains seem to
confirm this.
29. Additional Options for Better Decentralisation
• Alternative consensus methods:
• (Delegated) Proof of Stake — unproven
• Acyclic Graphs of transactions — proven (arguably) only for permissioned chains
• Alternative approach to Proof of Work:
• Limit by memory bandwidth, not computation — works iff ASIC development held off “long enough”.
30. Additional Options for Better Decentralisation
• Alternative consensus methods:
• (Delegated) Proof of Stake — unproven
• Acyclic Graphs of transactions — proven (arguably) only for permissioned chains
• Alternative approach to Proof of Work:
• Limit by memory bandwidth, not computation — works iff ASIC development held off “long enough”.
Cuckoo Cycle
31. Challenge 2: Scalability
• Proof of Work leads to low number of transactions / time.
• Alternative to using different consensus: reduce number of on-chain
transactions.
• Æternity State Channels:
• A sequence of transactions is done off-chain, then later written to the
chain in one aggregated transaction.
• Similar to Bitcoin’s Lightning Network, but supports smart contracts:
1. Set of nodes open a channel.
2. Nodes transact on the channel fee-free and limited only by “normal”
computation/network latency.
3. Nodes close the channel, transferring the resulting state back onto the
chain.
32. Challenge 3: Solid Smart Contracts
• Ethereum’s Solidity was designed in an ad-hoc fashion.
• Many bugs and quirks such as silent overflows.
• Æternity’s approach for Sophia:
• Solid, language-design experienced team (some of the original Erlang developers).
• Cleanly designed, functional language of the ML family, strongly typed and restricted mutable state.
• First-class blockchain types:
• Oracles (interfacing to off-chain services)
• Naming (AENS)
33. Challenge 3: Solid Smart Contracts
• Ethereum’s Solidity was designed in an ad-hoc fashion.
• Many bugs and quirks such as silent overflows.
• Æternity’s approach for Sophia:
• Solid, language-design experienced team (some of the original Erlang developers).
• Cleanly designed, functional language of the ML family, strongly typed and restricted mutable state.
• First-class blockchain types:
• Oracles (interfacing to off-chain services)
• Naming (AENS)
Easier to reason about programs and proof correctness.
34. • Many early d-apps are “from nerds, for nerds”.
• Most non-tech users
• care about ease of use, value-add.
• don’t care about the underlying tech.
• However they increasingly want systems to be secure, privacy-
preserving, transparent, reliable etc.
• Therefore blockchain / smart contract platforms should provide
SDKs for easy high quality d-app development.
• Æternity:
• SDKs for Javascript, Python, Go
• UI Components for Vue.js
• Example æpps
Challenge 4: UX/UI
35. Challenge 5: Preventing Hard Forks / Governance (1)
• Hard Fork:
• a group of users forks the source code + chain state to branch
off on their own.
• possible with any open source chain.
• to prevent it, the number of users willing to break off must be
sufficiently small.
• Æternity provides:
• delegated voting mechanism, weighted by the amount of Æ.
• technical tools to permit governance.
• frameworks for human interaction for effective discussion.
43. Conclusion
• DLTs enable decentralised, transparent, censorship-resistant transfer of money, other assets, and
implementation of apps.
• Blockchains are one way to implement DLTs.
• So far, only Proof of Work-based public chains have been proven to be secure — as long as no one obtains
51% of the hash rate.
• Other methods like Proof of Stake, Hashgraph etc. promise much higher scalability at the potential cost of
security.
• Scaling Proof of Work chains with tools such as Æternity’s State Channels might be considered a good
compromise.
• There are many other challenges when developing reliable and user friendly d-apps, that are tackled in different
ways by different projects. Æternity provides many useful tools to tackle these.
• When designing a d-app with it’s own token/trading/reward/otherwise economic ecosystem, its token
economics has to be analysed, for which game theory and related economic models are particularly useful.
Traditional ledgers:
centralised
clearing house needs to be trusted:
knows all transactions
full control — possible censorship
no one except auditors can review — need to trust the auditors as well
DLT:
Transparency: Ledger can be stored and verified by multiple parties
Some set: private/permissioned
Anyone: public
Censorship-resilience
“Trustless”
The assets here can be currencies, also called coins in blockchain terms, or other assets. In blockchain we call the representation of an asset a token. So a coin is a special case of token, implementing a currency.
Also note that users usually can create multiple accounts or nodes in a DLT. In blockchain terms accounts are also called wallets. Each wallet has a cryptographic address, and you can keep it anonymously. Actually there are ways to de-anonymise wallets by tracking transaction histories and other things, but discussing this is out of scope for this talk.
How to ensure that a distributed ledger is valid and consistent?
First: ensure each node can verify that a transaction is valid
From original bitcoin paper:
Sign transactions of an asset digitally using a public-private key cryptographic method.
Then recipient can verify a transaction.
So for a single asset, we get a transaction history like this.
Each node also needs to verify that a transferred asset has not been spent before:
Only possible if we know the complete transactions history, i.e.
1. know of all transactions and
2. their order.
To achieve this, we can use time-stamping.
This works by [list]
So we get a history of blocks and their hashes like this.
Remember we’re in a distributed system without any central server, so who’s doing the time-stamping?
Solution:
Everybody can create blocks and hashes.
Made difficult by requiring the hash to start with a given number of 0s
Difficulty degree.
Using a nonce in the block to create different hashes.
So now our block sequence looks like this.
But why are we introducing this artificial difficulty?
Everybody can work on blocks at the same time, so alternative valid new blocks might appear at roughly the same time. And due to network latency, these might arrive at any order at other nodes.
Because we need to broadcast the blocks to all known node, who then re-broadcast to their known nodes etc. If some nodes learn of different, but also valid new blocks than other nodes, they’re now working on diverging histories.
10 minutes is believed to be enough to get new blocks to most nodes around the world, so there’s less chance for large chunks of the network working on different histories at any one time.
But it might still happen, so how do we resolve this?
Consensus: if there is a conflict, the longest (most difficult) chain wins.
Eventually, the differing groups will learn of each other’s alternative chains. By setting the rule that the longest chain wins, and if the set of nodes commanding the majority of the mining power is honest and adheres to this rule, then their chain will always outpace other chains.
This is an example of a Solidity smart contract.
Looks like “normal” code.
Contract definitions look similar to class definition in e.g. Java.
But methods can have modifiers, (pre-)conditions
D-app: p2p apps utilising DLT for transactions;
Some definitions also require open source and dealing with tokens.
Components:
UI,
blockchain client/library/sdk,
Smart contract(s)
We see a lot of centralisation because of Asics
Let’s have a look at what an attacker has to do to double-spend. Initially, we have a node with 10 BTC balance.
Recall: double-spending is prevented by consenting to accept the longer chain.
Therefore: majority of the network’s computing power will create the longer and accepted chains.
So if the majority in terms of computing power is honest
But there’s another argument why miners would not do this, even if they control >51% hash rate, and this is a game-theoretic one.
Now what is game theory?
Here, we’re mostly interested in non-cooperative games and their solution.
In a non-cooperative game, everybody plays against everybody. Also, everybody is perfectly rational. That means that everybody is selfish and tries to maximise their own utility without considering anything else.
Nash then analysed what happens in such situations. If we know what our opponents’ rational decision in any situation would be, because we know they’re also rational, we can determine our best response in each situation. But our opponents know the same of us, so they’d come up with a similar strategy, which we have in turn to consider recursively, as will they, and so on.
If there’s a fix point of resulting strategies to these recursive considerations, it is called a Nash equilibrium.
Just a quick note on cooperative games. These are also relevant in the blockchain context, because smart contracts enable binding agreements. In fact, Buterin’s smart contract based attack scheme could be modelled as a cooperative games with two parties, called coalitions: the attackers and the defenders. However, if we assume that users already decided whether they want to take part in the attack or not, we can also view this as a non-cooperative game of two actors, where the actors are the coalitions.
Let’s look at the classic example of non-cooperative game theory: the prisoner’s dilemma.
What should player A choose?
- If B Talks, A should talk. - If B stays silent, A should also talk.
For B it’s the same in reverse:
- If A Talks, B should talk. - If A stays silent, B should also talk.
So according to Nash, Talk/Talk is the stable solution, but it’s not the best solution. Because each of them would get only 2 years if they both stayed silent.
Other examples: auction and voting protocols.
But how this kind of analysis help us with the 51% attack scenario or other blockchain economic situations?
The main argument against the 51% attack is indeed a game-theoretic one. It’s based on a classic game called “Grim Trigger”, where we have a kingdom and an heir to the throne. The question is, should the heir kill the queen or king?
If they did, this would break the social contract that the kingdom provides law, order and stability for its subjects. You might then get a revolution or some chaos as in Game of Thrones.
That means that once you killed the 1st king, all subsequent kings might then just as easily be killed. So the heir is probably going to get murdered themselves. So if they’re rational, they should therefore not kill the queen in the first place.
The reason for a powerful group of miners is similar: [bullet points]
But generally, when designing any kind of protocol for transferring some real value, token economics has to be sorted out. You can use game theory to analyse whether your users have the right incentives.
Note on Lightning Network: there are ways to do smart contracts on Bitcoin and Lightning Network, but they’re complicated. Discussing this is out of scope here.
In a representative democracy, as we’re living in, you get to vote your few representative every few years, and then they’re supposed to represent you in every aspect.
But in the digital age, more flexible delegation schemes are possible.
In Liquid Democracy, you can delegate any topic or subtopic to anyone, change your delegations at any time, and vote for yourself whenever you prefer. Delegated votes are treated just as original votes, meaning delegates can delegate further on, or not.
Ætertnity is currenty considering implementing a liquid democracy voting scheme.
In UTU, we allow clients of services such as taxi, auto mechanics, doctors and others to endorse service providers and stake an amount of tokens on them.
Clients can then call our recommendation service, which serves up trusted recommendations by friends or other relations. If they choose the provider who has been endorsed by the first client and also endorse them, the first client is then rewarded according to both their stakes and some other parameters.
This is how our reward function looks like in terms of the original endorser’s stake and some fixed values for the other parameters. For several reasons that are not important here we designed to give diminishing returns, so it approaches a maximum value. So with increasing stake, you get closer to this maximum but never actually reach it.
In a sybil attack, an attacker runs multiple nodes and acts as if they belonged to different people. Here, they could use this to e.g. stake 10 times 1 token instead of 1 time 10 tokens. So they would avoid the diminishing returns.
However there are other properties of our system that make this unprofitable in most cases. We can again use game theory to show this, but we don’t have enough time here to go into this.
