Skip to content

Product Information

Casper Highway Consensus Protocol: Comm Call

Casper Labs

On our January 26 Community Call, we invited Adam Gagol, Ph.D. to join us for a discussion about the Casper Highway Protocol, the consensus mechanism that maintains the Casper network. Adam is the co-founder and CTO of Cardinal Cryptography, who partnered with CasperLabs to publish the Highway Paper. CasperLabs co-founder and CTO Medha Parlikar and lead engineer Andreas Fackler joined from our side to take part in the conversation.

Medha: Let's dig into the Highway protocol a little bit and we'll talk about the paper. I'll turn it over to the two of you.

Adam: Since you mentioned the fork bomb, maybe that's a good starting point. This kind of an attack applies specifically to protocols that use the stack structure where the units as we call them, which are messages, form a graph that represents all kinds of causality. Any message you produce cites by hash an earlier messages that you have seen, so that you get this graph structure where you have this ordering on the messages that says which message must come first before the other message. In that kind of protocol - which is what CBC-Casper also implies - if you're an honest participant in the protocol, then each of your messages will cite your previous message because you can't pretend not to see your previous message. If you're an attacker, you could cheat and fork your stream of messages into multiple forks wherein each of them you claim that you don't know about the other fork. The fork bomb is a particular pattern of such messages that validators can download a ton of messages that could grow into terabytes. It's a resource exhaustion attack that would at least cause a liveness failure. The aleph protocol is also based on this DAG notion, and the aleph paper presented a solution for that which also inspired what we did in the Highway protocol.

Medha: Do you want to talk a little bit about the work that was done with Trail of Bits in the security review? What was that experience like for you? Was that the first security review you've gone through in your professional career or have you done other ones before now?

Andreas: I've had one previously in 2018. I felt like the Trail of Bits review was very in-depth. They looked into a lot of details, specifically in the core protocol itself. I'm glad that they didn't find any catastrophic problems. They pointed out a few things that we already had thought about ourselves but hadn't addressed yet like rate limiting against spam attacks and implementing what we had designed as the fork bomb protection, which at the time was still a work in progress. It was great to work with them and they dug down into the details and asked questions and made sure they understood the protocol, the implementation, and that everything was in line.

Medha: Could you share with the community how the Highway protocol is different from the original CBC-Casper paper and how it is similar?

Adam: I think the first obvious difference is that it has liveness proof, which was provided by Daniel Kane and which was lacking in the original CBC-Casper. The original CBC-Casper was not even claiming to be a full protocol; it was an idea and Highway is an extension of that idea which makes it a fully operating protocol. In terms of what is similar, I'd say that the spirit is similar. By the spirit, I mean that the main novelty that it introduces to the science of traditional BFT protocols is that it challenges the way we usually think about the power of an adversary. In traditional BFT protocols, people claim that once adversaries have a power stronger than 33% of the nodes, nothing can be done. What Casper is bringing to the story is natural intuitions from Bitcoin and from Proof of Work where additional blocks are built upon the old ones are adding to the security to the old block. This is something that is not present at all in normal BFT protocols, but something both Highway and Casper are very good at. A similar notion was present in the original Casper and it’s evolved version is in Highway.

Medha: Can we talk a little bit about some of the flexibility in Highway and how that's important and how does this make it special?

Adam: What we formally call “flexibility” is that you can have different finality thresholds in Highway. For example, if a lot of nodes are either malicious or they perhaps crashed for some reasons and only, for example, sixty percent of nodes are up, the protocol will still be able to carry on and do this little bit of finality that it's able to do with this number of nodes. This is something which traditional protocols are not able to do at all, they just stop. Even during moderately big attacks, the Highway protocol will still be able to finalize the blocks.

Andreas: The nice thing about the flexible finality is especially in the context of Proof of Stake, it gives you a very clear measure of the security of a block because it locks up a sum of money that you know the validators would have to forfeit if they wanted to cheat. If you have a block that has a finality threshold of seven million, you know that nobody else can see a conflicting block finalized unless the validators do cheat in a detectable way that will ultimately cost them seven million of their stake. I think that that's particularly for Proof of Stake and a nice feature to have.

Medha: Some of the recent proof of stake protocols use probabilistic finality or statistical finality and one of the things I like about Caspers’ Highway protocol specifically is that the stake has to participate in consensus to get rewarded so if you don't participate in finalizing a block in the Highway protocol, you don't get any rewards and by participating and finalizing a block your stake has to take an equivocation risk or be securing that block and it's not probabilistic like some of the more recent protocols that we've seen come out for proof of stake where it does kind of you know sacrifice security for speed right we decided that we were going to put security first and foremost so I’m very pleased in that regard that we can provide those kinds of guarantees to customers.

Medha: How do you feel we did in terms of upholding the spirit of CBC (Correct by construction).

Andreas: We tried to be mathematically correct and complete and made sure that there are no gaps in our proofs, and to make sure the math matches the reality.

Medha: Thank you both for joining today.

Technical Updates

Execution

  • The team has started the third weekly sprint of the 21.02 release cycle. This release will bring about protocol upgrades performance and hardening improvements and we're also going to complete the integration with our custody provider during this release cycle.

Current Focus

Highway

  • We’re implementing eviction of validators that are experiencing liveness failure. if a validator hits a liveness failure, they will be evicted completely out of the auction contract.
  • Designing a crash recovery mechanism to recover the network with a liveness failure.
  • Designing a framework to disable bids on liveness failures.
  • Nodes should walk linear chains backward when syncing from the last known state.
  • Pause if too much stake is offline

Node - Rust

  • Replace the gossiper component with the libp2p gossiping.
  • Implementing tracking of Validator set when synchronizing. This ensures validators get block info only from trusted validators when synchronizing their nodes.
  • Support for delegate tokens in accounts.csv (at Genesis).
  • Gap analysis on what remains to switch to stable Rust.

Ecosystem

  • We’re making a tutorial for multi-sig & key management and an example tutorial on smart contract upgrades.
  • We’re building a domain-specific language for upgradable Contracts along with some contract upgrading examples.

Economics

  • We’re harmonizing the consensus paper and economics paper.
  • We're going to be adding the staking auctions chapter to the economics paper, the idea is to publish a paper with the economics of the Casper blockchain.
  • JS SDK: Example script to claim delegator rewards for Javascript SDK.

Contract Runtime

  • We’re getting rid of some system contracts to enhance performance and to further decentralize the network.
  • We’re writing a contract for the vesting schedule for VFTA Holders.
  • Support user-provided transfer ids in AssemblyScript Contract API.
  • Use account main purse instead of user-supplied purses in auction methods.

Team and Company

Our weekly Governance/Community call holds every Tuesday:

Our weekly workshops/dApp Session holds twice a week on:

  • Thursdays 07:00 am Pacific time and
  • Fridays, midnight Pacific (4 pm Japanese Time).
  • The zoom meeting ID is https://casperlabs.zoom.us/j/924713678

Related Articles