Introduction to COMP0143

6 minute read

UCL Course COMP0143 Cryptocurrencies: LEC-00

Overview

Goal

Creating censorship-resistant, digital payment systems
that anyone can use which avoids trusted third parties

Properties

Decentralized: Governed by a peer-to-peer network
Pseudonymous: Users go by many names
Transparent: All transactions are globally visible

Layers in Cryptocurrency Networks

From Top to Down:

Pseudonyms (Users)

The Addresses are hashes of public keys of a digital signature scheme,
which are a kind of weak identities and can
- Issue transactions towards receivers’ addresses
- Authorize transactions by attaching digital signatures
- Create as many addresses as they wish (only a new keypair have to be created)
However, this kind of weak identities DO NOT provide true anonymity
Application Layer

Applications (e.g., Decentralized Finance, Games, Gambling, Social Media, …)
run in this layer (whose backed runs on top of a distributed ledger platform)
are called decentralized applications (dApps) (often referred as smart contracts on Ethereum)
Transaction Layer

Blockchain platforms implement state machines which
use a distributed ledger as a public, persistent, append-only state

Consensus nodes are allowed to update the state under certain conditions
by appending blocks with transactions to the blockchain.

Blockchains usually differ in the way how transactions get formed, verified, and executed,
as well as how their state is structured: UTXO (Bitcoin) vs. Account-Based (Ethereum)

Here is Distributed Ledger: Above are Execution Environments | | Below are Infrastructures

Consensus Layer

The Safety goal is to establish a consistent view
in a distributed system of which transactions took place in what order

The Liveness goal is to make sure honest nods can make progress and agree
on such a transaction history even if a certain fraction of nodes is offline or malicious

Classic Byzantine Fault-Tolerant(BFT) Consensus assumes a fixed, well-known set of authoritative nodes,
such that nodes hear about transactions from their peers and collect them into blocks.

Process
(1) an elected leader gets to broadcast a block proposal to the rest of the network
(2) honest peers signal acceptance of the block if it fulfills certain predicates
(e.g., come from an elected leader, all transactions are valid state transitions…)
(3) If enough peers accept the block, then consensus has been reached,
and the state of the distributed system gets updated.

However, it is unclear how to elect a leader as the set of eligible nodes is unknown,
and voting may be subject to Sybil Attack since anyone can run as many nodes as they wish

Bitcoin introduced Nakamoto Consensus which shows how to achieve consensus in a decentralized way
using Proof-of-Work (PoW) (solving computationally hard puzzles), which also called mining
Network Layer

Nodes use protocols like traditional peer-to-peer (P2P) networks to find and communicate with each other.

Seed nodes are run on well-known, trustworthy community members,
whose IP address get hardcoded into the client software to enable initial peer detection

New nodes connect to these seed nodes to get an initial list of active peers to bootstrap

Nodes connect to a few random peers from the initial list,
the exchanging behavior is based on gossip protocols to exchange data
Nodes (Physical Devices)

Consensus Nodes
All nodes that participate in consensus, via mining, BFT consensus, etc.
Consensus nodes maintain a full copy of the entire blockchain (metadata + transactions).

Archive Nodes
All nodes that do not participate in consensus but store a full copy of the entire blockchain
to serve client requests (e.g. dApps, syncing requests by other peers).

Full Nodes
All nodes that do not participate in consensus but store a full copy of the latest \(N\) blocks of blockchain
to serve client requests (e.g. dApps, syncing requests by other peers).

Light Nodes
All nodes that only store blockchain metadata (e.g. mobile wallets)

Challenges

Extend Reading: Top Ten Obstacles along Distributed Ledgers’ Path to Adoption
Author: Sarah Meiklejohn @ University College London

Usability

Currently, Bitcoin transactions do not convey much meaning
unless users already know what they want to look for

Governance

Despite the original promise of decentralization,
governance of blockchain technologies is largely centralized,
e.g., in the form of mining pools (centralized in China)

How can we design protocols that distribute voting power more evenly?

Comparability

There are literally thousands of alternative cryptocurrencies by now,
and it is hard to understand how they differ from each other (aside from their names)

Can we come up with metrics to compare them?

Safety

When users lose their cryptographic keys, they will lose their coins in cryptocurrencies.

Proper key management is therefore paramount which is a huge challenge in particular for non-technical users.

How can we design usable and secure fallback mechanisms that allow to recover lost keys?

Agility

Systems use certain instantiations of abstract algorithms and protocols (e.g., SHA256, ECDSA, Nakamoto consensus)

What if we want to support different ones or have to update to other variants?

Interoperability

How can the countless different blockchain systems interact with each other as well as legacy systems?

Cost-Effectiveness

Bitcoin uses an enormous amount of energy to achieve a throughput of 7 transactions/second

How can we design cryptocurrency protocols that are more cost-effective?

Privacy

All data on the blockchain is publicly viewable in most cryptocurrencies.

How can we design cryptocurrencies that provide certain privacy and anonymity guarantees?

Example: Zcash, Dash, Monero

Scalability

Many blockchains are slow (e.g., Bitcoin has a throughput of only 7 transactions/second)

How can we improve the performance of distributed ledger platforms?

Blockchain record the entire transaction history of a cryptocurrency.

Since they are append-only data structures, they will continue to grow forever.

Additionally, blockchains also require that each peer stores the entire transaction history

How can we reduce these data storage requirements?

Endong Liu