-
Compress the Epoch Schedule:
Currently we have a 3 + 3 + 4 epoch schedule. This might be overkill, can we reduce it to 3 + 3
-
Convergent Tie Breaks: Cardano currently tie-breaks two tips at the same height by comparing block ids (max block id wins).
- Need to analyze if this is an improvement over the current first-seen design
-
Slash double-signed blocks (ie two blocks using the PoL, which is a byzantine behavior that we can slash).
- Mechanism: not adding the evolved commitment. PoL consumes one coin by revealing the nullifier and produces a new one by publishing a new commintment of the same value. If you don't add the new committent we have slashed the owner of that coin.
- This should be possible only during the slot, to avoid reorgs later on caused by byzantine nodes that release the second block invalidating the first one.
- This can be achieved by showing a proof of the two blocks and instead building on the parent. This cannot be done if the offending block has already a child block, in which case the canonical fork-choice longest-chain rule prevails.
- This operation adds + 1 to the length of the fork, to compensate for the potential loss of that the executor of the slashing would incur by not building a longer fork (ie next leader would not have a way to select this honest fork from an equally-long one, so we are making this one 1 block longer virtually as if the faulty block was included)
-
Epochless Crytparchia
- Since our new randomness is derived from the commitment set including the latest proposal in the fork, we can get rid of epochs for the PoL. The question then is if we can get rid of them completely.
- Epochless cryptarchia probably 6-10x's our block lookback buffer, it might be fine though since you probably just need to keep block headers, not full blocks.
-
Prove evolution of epoch nonce $\eta$ in PoL.
- currently, PoL exposes some randomness $\rho$ that is used as input to the epoch nonce $\eta$ derivation. Instead of making every validator maintain this epoch nonce, we could instead have the leader prove the evolution of $\eta$. This has a number of benefits:
- Since $\rho$ is derived from the leaders note, evolving $\eta$ in STARK would remove the risk of exposing some linkable identifier
- Validators become even more stateless as they would not have to maintain the epoch nonce state variable
- the drawback here is that it forces PoL to being proved after the parent block has been revealed. This squeezes the leader to try to build a block and proof leadership in the short window after it sees the previous block. Proof times are not good enough right now to support this.
-
Support Adaptive Corruption Resistence
- Currently, PoL doesn’t provide any adaptive adversary resistence. In the case where a node is corrupted, the attacker is able to regenerate new PoL for all the previous won slots, enabling potential attack vectors to rewrite the chain.
-
Multiple Concurrent Proposers
- Instead of coming to consensus on an ordered block of transactions from a single block proposer, each of the K proposers propose a set of transactions at the same time. The protocol then aggregates these proposals using a common subset primitive (or a similar algorithm, this is an active area of research), yielding an unordered set of transactions which are to be included in the block.
- MCP solves the problem of censorship-resistant inclusion, achieving the goals of Inclusion Lists in a more natural way. The output is an unordered set of transactions, so it does not solve the problem of reordering. That will be the responsibility of the execution layer.
-
Distributed Block Building
- Under a PBS paradigm, multiple builders will contribute to the block, which the proposer is enforced to propose
- Another option is to have multiple blocks merge, either by producing intersection or union.
-
Deterministic Ordering
- To do this, we must delay the calculation of the state root to the next block so that the execution layer has time to implement a deterministic ordering rule.
- Once it has the transactions, the execution layer has a new important job: figuring out how to order them. To do this, we need to select a deterministic scheduling rule.
- This deterministic ordering probably should introduce randomness from the previous block, to make the order unpredictable until its execution in the next block.
-
Prevent Tagging Attack through DA
- Forcing all mantle transaction data to go through DA gives us the leader the confidence that a large fraction of the network has seen this transaction and will not be tagged by including it.
- Important that the transaction that goes on chain with a reference the DA commitment does not include some additional user chosen data that could be used to tag a leader
-
Improved incentives for transaction inclusion for leaders
- Private Proof of Stake over transparent UTXOs brings a problem of transaction inclusion incentives. Since we need to give the same rewards to all block proposers for privacy reasons (to avoid tracking via reward distribution who was the proposer), we bring two pernicious side effects:
- Lazy leaders (potentially including nothing)
- Censorship resistance reduction (even in an MCP setting, now those who would be willing to take the risk, might not take it because there is no incentive)
- The objective is to find a solution to incentivize the inclusion of ALL mempool transactions that doesn't break privacy. Some ideas include:
- In an MCP setting, cryptoeconomic games to make all validators propose as much as possible.
- Encrypting/hiding the tx, by using a mechanism similar to encrypted mempools, whereas transactions are threshold-encrypted and decrypted immediately after inclusion.
-
Total Stake Inference: Uncle References To Improve Measurement of Slot Occupancy Rate
- Total Stake Inference relies on measuring the slot occupancy rate to infer the total active stake, we do this by measuring the honest chain growth rate during a fixed period. Since Cryptarchia is forky, those forks contain blocks that are not on the honest chain and so do not contribute towards the empirical measure of slot occupancy. In simulations we’ve found that this undercounts total stake by ~15%.
- If we had uncle references, that 15% error goes away since all nodes can now count blocks that are off of the honest chain.
-
Remove PoL Proof from block header
- All other proof structures are stripped from block id computation, the PoL proof provides a gameable source of entropy to the block id giving the leader control over the block id.