The Casper Validator Connect Calls are back! This month’s session provided a deep dive into the Condor (Casper 2.0) features, technical improvements, rollout plans, and other updates.
Presented by Michael Steuer (CTO, Casper Association)
At a Glance:
Michael opened the call by reminding the audience of the organizational shift within Casper. The Casper Association has now assumed full responsibility for core engineering, streamlining processes, and eliminating confusion around shared ownership with Casper Labs.
Michael also emphasized the shift in focus toward mass-market use cases: "We are heavily investing time, effort, and attention into much broader use cases moving forward," he explained.
On the decentralization front, Michael highlighted the development of governance structures to give the community a stronger role in decision-making, which has been identified as a priority of the new interim board earlier this month.
Read more about Casper’s renewed focus.
He highlighted that community engagement has been doubled down with Casper Community Forum and CSPR.fans, which reached over 300,000 users since its launch in late September.
Check out the recent AMA with the new Casper Association Board to learn more about the mass-market and community participation focus.
Michael wrapped up his introduction by expressing confidence in the direction Casper is heading. He emphasized that Casper 2.0 will benefit from this renewed focus, and the community will have a strong voice in shaping what comes next for the network, before passing the stage to Ed Hastings for a deeper dive into Casper 2.0.
At a Glance:
Ed provided a detailed look at the scope of Condor (Casper 2.0). “The original plan was laid out years ago, but had evolved since,” he said. He highlighted the focus as addressing architectural limitations in the 1.x version that restricted future upgrades.
"Many of the roadblocks we encountered with 1.x were due to architectural decisions that limited our ability to introduce new features without breaking existing systems," Ed explained.
Moving the RPC system outside of the node was among the key changes he highlighted. The previous architecture had an embedded HTTP server handling RPC requests within the node itself, which made even minor changes to the RPC endpoints problematic.
"By externalizing the RPC, we’ve effectively insulated the node from volatility and made it easier to extend the system and handle RPC requests separately," Ed explained.
With this change also comes a sidecar component, which sits in front of the node and manages RPC requests and translates them between JSON and binary formats. Ed described this as a "circuit breaker" for the node, protecting it from potential overloads caused by high RPC traffic.
Another major improvement is in how delegator bids are handled. Previously, these bids were embedded within validator data, causing system inefficiencies and storage issues. In Casper 2.0, delegator bids are treated as top-level entries, which reduces the amount of data that needs to be fetched during auction interactions. Ed explained: "Delegator bids will now be a top-level concern, separated from validator data, which improves both efficiency and scalability."
Finally, he highlighted that pruning is now supported at the global state level, allowing the system to remove dead entries that no longer serve any purpose, freeing up space and improving overall efficiency.
Presented by: Ed Hastings (Head of Engineering, Casper Association)
Presented by Alexander Limonov (Engineer, Casper Association)
At a Glance:
Alexander detailed the Zug Consensus Protocol (whitepaper), which is set to replace the Highway protocol currently in use. Zug offers a much simpler and lighter consensus mechanism, thereby reducing the network overhead compared to Highway.
"While effective, Highway is complex and resource-heavy. Zug simplifies the process, and makes consensus faster and less computationally intensive," Alexander explained.
Similar to Highway, Zug starts with a leader node proposing a value (a block) to be added to the blockchain. Other participants send echo messages to signal their agreement with the proposal. If enough participants send positive echoes (a two-thirds quorum), the block is finalized.
"If two-thirds of the network agrees, we consider the block finalized. If not, we allow the round to be marked as skippable," Alexander said.
Skippable rounds are one of the most innovative features of Zug. In cases where the network cannot reach consensus, for example, during a partition or failure, the round is skipped without penalizing the network’s performance. In other words, skippable rounds prevent the network from stalling.
Zug also creates opportunities for future improvements. By reducing consensus overhead, the network could support faster block times or an expanded validator set without sacrificing performance.
Presented by Michał Papierski (Engineer, Casper Association)
At a Glance:
Michał presented a detailed preview of the upcoming VM 2.0. He explained how it will make life easier for developers. The current VM has been largely unchanged since Casper’s inception and introduced unnecessary complexity.
"There were many decisions that made sense at the time, but in practice, they have made things difficult for developers," Michał said. With the introduction of VM 2.0 URefs will be removed.
"URefs are complicated, hard to track, and ultimately unnecessary for most contracts. We’re getting rid of them to simplify the process," he stated.
Michał then moved on to transferable entry points, which allow sending tokens directly to contract entry points without needing a custom session code.
VM 2.0 will also focus more on high-level code, reducing the need to interact with low-level system details. Michał explained that by simplifying the developer experience, the VM will also make it easier to test contracts.
"With VM 2.0, you’ll be able to write and unit test contracts as easily as any other Rust code. Development is faster and less error-prone," he concluded.
The new system will have backward compatibility, ensuring that VM 2.0 contracts can call existing VM 1.0 contracts for a smooth transition.
Presented by Joe Sacher (Engineer, Casper Association)
At a Glance:
Joe took the stage to provide detailed insights into the rollout process for Casper 2.0. The team is preparing to cut RC5 next week. After the cut, internal testing will scale from 5 to 120 nodes in order to ensure that the release is stable across a variety of setups.
"We’ve been testing cuts of the 2.0 branch for some time now, and once we hit RC5, we’ll be ready to move into more extensive testing," Joe explained.
The new sidecar component was highlighted as a key feature, which will handle RPC requests independently of the node.
"The sidecar allows for translation between JSON and binary requests, protecting the node from potential overload," Sacher stated. This will improve overall performance and ensure that the node isn’t compromised by heavy RPC traffic.
"The rollout will be almost identical to previous upgrades, so node operators won’t have to learn anything new, apart from handling the new sidecar component," he said.
Sacher also confirmed that the team’s goal is to have Casper 2.0 live before the end of 2024.
"We’re aiming for a release before the end of the year, and we’ll be moving into more extensive testnet testing soon."
Q: Are there any plans to write native events into a separate storage or log for replayability?
Ed Hastings explained that there are no immediate plans to store native events for replayability in global state. Instead, native events will be checksummed and added to the event stream with the ability to confirm that an event occurred (but not retrieve the actual message).
Joe Sacher added that while nodes themselves won’t store the full events, sidecars or external systems can be used to store and replay those events. If sidecars are turned off, however, those events would be lost as they’re considered ephemeral data.
Q: How will old contracts that use URefs work with the new VM?
Michał Papierski clarified that URefs will still be retrievable in a read-only fashion from the new VM for migration purposes. However, developers should not expect to write new data to URefs under VM2. The new virtual machine operates on a “by value” model, rather than “by reference.” Any interaction with old contracts will focus on reading URef values rather than modifying them.
Q: Will the new execution engine make it possible to transfer native tokens from an account without a WASM proxy?
Yes, Ed Hastings confirmed that with Casper 2.0, a new feature called "transferable" will allow tokens to be transferred directly to contracts that implement this feature without needing a WASM proxy. If a contract does not implement the transferable feature, the transfer will fail with an error.
Q: When are you planning to switch to the latest Ubuntu LTS?
Joe Sacher stated that Casper plans to remain on Ubuntu 20.04 for a few more months, primarily due to complications with OpenSSL versioning (1.0 vs. 3.0). The team is exploring building multiple versions to support both, but the upgrade to a newer LTS version will take time and won’t happen until they’ve addressed compatibility issues.
Q: What was limiting the delegator capacity, and is this issue resolved in Casper 2.0?
Ed Hastings explained that the main constraints on delegator capacity are disk space and processing time. While the capacity might be increased from 1200 to 1500 delegators in Casper 2.0 initially, there will always be some limit. To help manage this, validators now can set minimum bids, reserve slots for specific delegators, and use other tools to optimize their delegator management.
Q: What is the realistic ETA for Casper 2.0 hitting the mainnet? Can we expect longer testnet testing?
Joe outlined that the team plans to cut RC5 next week, with internal testing to follow on Devnet. Once Devnet is stable, testnet will be upgraded and likely stay in testnet for a longer period than usual to allow the ecosystem to prepare.
The team is aiming for a mainnet launch before the end of 2024, but that depends on the ecosystem’s readiness.
.png)
