Our London meetup in June was a special one because we were able to invite Professor Aggelos Kiayias, Chief Scientist at IOHK, to speak the community. Tom Kelly from Cardano Foundation welcomed everyone to the lecture theatre (and made sure the audience knew where we were having a drink afterwards!). We are very grateful to UCL and London Blackchain Labs for the kind use of the wonderful venue.
His presentation was on Ouroboros PoS Research: Protocol Design, Stake Pools, Incentives, Sidechains. A quick recap of his presentation is below. Dominic from IOHK was also at the meetup to record the presentation and this will be posted on IOHK’s YouTube in the near future.
Robust Transaction Ledgers
- are the problem that the Bitcoin protocol solves
- to properly solve a problem, one must fully understand the problem
- doing this was part of Aggelos’ research
- out of his research with Garay and Leonardos, the first formal definition of “robust transaction ledger” was formulated (in this paper: https://eprint.iacr.org/2014/765)
- there was a lot of follow-up work from this that look at refined models and definitions such as property definitions, partial synchrony, simulation-based definition and composition
- here, Aggelos noted that it is important to have definitions and a formal framework so that others can also use it to work on solving the problem
- there are two properties you can expect from a RBL:
- Persistence: for transactions to persist on the ledger and to be immutable
- Liveness: new transactions are to be recorded and incorporated into the ledger
Background on PoS
- generating the next block in Bitcoin is like an election
- a miner is elected with probability proportional to its hashing power
- on the other hand, the steps in a PoS system are:
- use of stake (a virtual resource) instead of hashing power
- miners are replaced with stakeholders, which is reported in the ledger
- use a randomized process that takes the current stake into account to elect the next “miner” eligible to produce a block
Pure PoS Approaches
- there are a number of approaches for PoS systems that have appeared in literary or proposed in systems
- it is important to categorize these into two groups:
- PoS blockchains = this protocol uses a hashchain, and some form of the longest chain rule. This means the protocol will mimic the Bitcoin protocol to some degree.
-Example of these are: Ouroboros, Snow White, NXT - PoS BFT = an upgrade of the classical Byzantine Fault Tolerant protocols to operate in the PoS setting
-Example of these are: Tendermint, Casper
The Bitcoin Folklore
- “it is impossible to write a RTL protocol following the Bitcoin logic setting”
- the reason for this argument: costless simulation and long range attack
- Costless Simulation = there are no physical resources that are used in producing blocks, therefore it is possible to build alternative transaction histories at essentially no cost
- compared to Bitcoin, when you are extending one version of history, you have to commit to it, and you must spend hashing power on each version of history you submit
- with this deficiency of PoS protocol that “nothing is at stake”, the question arises: does this kill this protocol or are there approaches to mitigate this problem?
- the second argument was the Long Range Attack
- the victim tries to distinguish between 2 alternative histories on the network without any recent information
- if you join the network after a big hiatus or you are new node, then you face the bootstrapping problem
- how does a new (or long term desynchronized) node synchronize with the blockchain?
- how does this new node choose the “right” history (right being the one followed by most people or the majority of the network)?
- you don’t want a trusted party to tell the victim which history is right
- in a PoW system, the adversarial version will be substantially shorter, counting difficulty as length
- the new node will therefore be able to figure out the right history based on accumulation (count the amount of work invested)
Dynamic Availability
- Dynamic Availability is the setting defined by Prof. Kiayias and his research team that “naturally captures decentralized environments within which real-world deployed blockchains protocols are assumed to operate”
- this is the environment where:
- parties join and leave at will
- number of online/offline parties dynamically change over time, or lose clock synchronization network connection
- protocol does not have a-priori knowledge of participation levels
The PoS question
- Is it possible to have a pure PoS protocol operate in a dynamic availability setting so that:
- the protocol satisfies persistence and liveness in the presence of a <50% stake adversary
- following the protocol as prescribed is aligned with the parties’ incentives
- this is the question that the Ouroboros research stream has set out to address
Ouroboros PoS
- it was first presented at Crypto 2017
- there were other PoS protocols before Ouroboros, but what was unique?
- Ouroboros set out to develop a PoS blockchain together with a proof that the protocol met the objective of realizing the functionality of RTL
- the proof and protocol were being worked on in tandem; with the intention of presenting an argument that a protocol can be a convincing substitute of PoW protocol
- Ouroboros included features like:
- random beacon generation process
- semi-adaptive security
- Ouroboros Praos came next and was presented at Eurocrypt 2018
- Praos achieved adaptive security and faster beacon generation
- Now, Ouroboros Genesis was released, about a month ago
- Genesis contains a feature that enables parties to bootstrap from genesis, addressing the problem of dynamic availability
Next, Professor Kiayias presented a few of the research streams at IOHK that take and apply Ouroboros.
Stake Pools
- the challenge is that PoS requires stakeholders to be online and to engage in the protocol execution
- compared to Bitcoin or a PoW protocol that decouple stakeholders from protocol participants
- this may be common sense to some, but it is not feasible because you cannot expect everyone who owns coins to want to participate to this level
- so how to address this?..Allow stake pools so that stakeholders can represent others
- if this is not addressed, you run into a situation where a small % of stakeholders that are interested are participating, which is not enough for a functional system
- note the duality of keys associated with an address (this is unique to PoS)
- there is duality with: the coins you would like to spend and the stake you have for participating in the protocol
- cryptographically speaking, you can have the same key for these functions but there is a disadvantage in this way because the staking key needs to be “hot” (therefore, can’t be on a paper wallet, etc)
- additionally, for the staking key, there are 3 features:
- Base address = this is a standard address. The advantage of having base addresses is for privacy. Two addresses from the same wallet will be indistinguishable and allow for a higher degree of privacy. But note that there is an disadvantage in this way that staking will require more effort from the user.
- Pointer address = does not have independent staking key, instead it points and inherits. Pointer addresses will be used for the normal mode of operation in that a base address can have pointer address(es) associated and this requires only the single address staking key.
- Enterprise address = does not have staking key at all (withdrawn from staking all together). This address would be potentially used with exchanges or businesses.
Creating a staking Pool
- the staking pool certificate will be used for naming the pool, determining features and details of how it manages members, signed by a number of staking keys
- signatures may come from base addresses with pointers, or a base address
- with each base address, there is stake associated with them
- the amount of stake behind the certificate is a sum of all these stakes
Joining a stake pool
- use your staking key to sign a delegation certificate that references that staking pool
- the stake pool will consist of their own stake + the delegates’ stakes
- then that stake pool will run a node as an entity that has this total sum
Challenges of Stake Pools
- one challenge is preventing stakeholders from aggregating to a single or few pools
- this would be bad as the system becomes centralized
- the second is Sybil attacks
- this is when there are multiple pools that are registered but are all actually controlled by a single actor
- in this situation, the system becomes centralized but is arguably worse as it “appears” to be multiple entities in the eyes of system and the users but in reality is a single actor
Incentives
- incentives are needed for stake pools tasks like:
- to be online to carry out basic protocol tasks
- to check when stake pool members are elected into a slot and to issue a block on their behalf
- to collect and relay transactions to other notes
- this research stream is designing a reward scheme that incentivizes parties to follow the protocol
- in Bitcoin’s case, the protocol rewards the miner that issues a new block with new Bitcoin and the transaction fees from the current block
- is this a good mechanism? (lots of debate here!)
- there are problems to Bitcoin’s protocol such as selfish mining attacks
- selfish mining attacks, in short, is when a selfish miner withholds a block to gain a short-term advantage over other pools
- the desired feature of a reward scheme = parties payoffs from the mechanism are such that they do not want to deviate from the protocol assuming they are rational
- there are other approaches such as Casper that gives negative penalties instead of rewards
- reward scheme in the Cardano protocol will be epoch-based
- a slot lasts 20 seconds, an epoch contains 21,600 slots and lasts 5 days
- so every 5 days there will be rewards
- rewards will come from two sources: the reserve where there is 14 billion Ada and transaction fees
- transaction fees have been explained with a sample calculation in this forum post: Summary: PoS Delegation & Incentives (Lars Brunjes)
- for the reward distribution, the scheme can reward pool leaders and members “automatically” (by crediting accounts / UTXO’s)
- pool leaders will declare a cost and profit margin
- pool members delegate their stake to the pool
- a distribution function will split the pool’s rewards taking into account cost, margin, stake
- Aggelos and his research team have performed many simulations and analyses to study how they can achieve a stable distribution of stake pools
Sidechains
- this is another research workstream that is ongoing at IOHK
- Sidechains are communication channels between blockchains
- what IOHK wants to achieve is sidechain participation independence
- the first generation sidechain system within Cardano is the Star Structure
- with the mainchain being the settlement layer
- sidechains support various enhanced operations – like the computational layer
- multiple computational layers can coexist: KEVM, IELE, Plutus
- sidechains in Ouroboros rely on cryptographic primitive called Threshold Multisignatures
- they allow stakeholders of a sidechain to succinctly signal to the mainchain maintainers the status of a sidechain
Edit: added video recording of Aggelos’ presentation 
For more videos from IOHK, head to their YouTube channel.
and if so, can put together a recap. 