Welcome to the recap of the July 18 Casper Developer Community Call! We're excited to share the highlights from the recent call, featuring Medha Parlikar who provided essential updates and insights on network upgrades. We were also delighted to host a special guest from Validation Cloud.
This article is intended for those who missed or would like to revisit the call to provide them with the latest updates on Casper.
You can access recordings of all past calls in our Discord under the call archive section.
We also recommend signing up for our biweekly newsletter to receive early updates and stay up to date.
Casper Labs CTO Medha Parlika was at the helm, providing deep insights into the ongoing processes and sketching out the future roadmap for Casper.
As it stands, version 1.5.2 is live on testnet. The network is in the process of standing up nodes on mainnet and has set the wheels in motion for the full historical sync process. One of the immediate beneficiaries of this stride forward is Robot Cache, which now runs its production system against the Casper testnet.
Historical sync, as described by Medha, is a decentralized, sustainable, and accessible process of setting up archival nodes. It can be thought as constructing a time bridge in two directions: into the future, adding new blocks that the network finalizes, and into the past, synchronizing with older blocks all the way back to genesis. This dual-direction development enables anyone on mainnet to spin up an archival service, adding a layer of robustness and resilience to the network.
Discussing the current state of affairs, Medha reported a surge in contract calls on the testnet and an ongoing synchronization effort by nodes. So far, the nodes have been performing optimally, indicating a smooth process with no significant concerns. Yet, she provided a note of caution that achieving full historical sync might require more time.
To ensure the sustainability and non-disruption of the network's operations, the 1.5.2 version will remain in the testnet for a projected 3 to 4 weeks, allowing the historical sync to progress gradually. This careful approach prevents overwhelming the validating nodes with data requests, ensuring a balance between progress and network stability.
Medha also outlined the rigorous testing protocol that preceded the 1.5 update. The network underwent four iterations of exhaustive testing, comprising 89 scenarios mainly centered around joining. These extensive tests, amounting to nearly 320 in number, excluded integration and unit testing, underscoring the comprehensive nature of the process.
Medha also touched upon the core features coming with 1.5 update. One of the noteworthy additions is the speculative execution endpoint, offering developers a tool for debugging against the global state. Note that this feature is turned off by default and requires activation by the node operator for use in the testnet.
In addition, the release introduces a significant RPC endpoint, "speculative_exec". This groundbreaking feature allows contract developers to estimate the potential gas cost of a deploy and to test it on the testnet and integration networks.
For more information about 1.5, please visit our GitHub repository.
While discussing the timeline for the 2.0 update, Medha stressed that the schedule is tentative and may need to be adjusted to address emerging issues in testnet or mainnet. The team's primary focus remains on ensuring uptime for mainnet and production environments, reflecting their commitment to delivering a reliable and robust network.
Before moving on to the details of 2.0, Medha recapped the status of the 1.6 update, expected to be available on the mainnet by November 1st. The 1.6 update notably reduces block times from 32 to 16 seconds and introduces a more robust and secure networking layer. This upgrade became feasible after the implementation of the 1.5 update, which addressed a significant limiting factor – the joiner. However, block times could only be halved to 16 seconds due to the core precepts of the Highway protocol.
The much-anticipated 2.0 version of the Casper Network is tentatively slated for release on April 1st. Medha emphasized that this acceleration, compared to Ethereum's 5 to 7-year timeline to similar capabilities post-mainnet launch, showcases Casper's intent to rapidly advance and innovate.
Following her in-depth discussion on the ongoing 1.5.2 and upcoming 1.6 updates, Medha turned her attention towards the highly anticipated 2.0 update. Slated for April 1st, just three years after mainnet's launch, this release is expected to catapult Casper Network's capabilities significantly.
To facilitate seamless transition and adoption, Casper will be providing a preview of the 2.0 update, which will start on December 1st. This separate environment will be continuously updated with the latest changes for 2.0, allowing contract authors to preview new features immediately after the completion of the execution engine work, expected around November 14th.
This preview environment, wholly run by Casper Labs, is aimed at enabling the community to familiarize themselves with 2.0. However, given the rapid development pace, Medha cautioned that state roll forwards and upgrades may not be supported initially, making this environment similar to the Delta testnet familiar to developers.
Casper 2.0 will be a monumental release with a host of impactful features and enhancements. Key among these will be the introduction of Zug consensus, refunding of gas fees, account and contract unification, and various enhancements to purses (PURSEs), unforgeable references (URefs), and contracts.
The current Highway consensus is quite noisy and limits the validator set to 100. Its rigid block times need to be increased or reduced by 2x. Also, its code is complex, making it difficult to verify. The new Zug consensus aims to address these issues by reducing message overhead, enabling an increased validator set to 250, and offering greater flexibility in block times.
Casper 2.0 will be able to create blocks as quickly as once per second, depending on the load. Validators will be paid for sending finality signatures, and the simpler code will be significantly easier to verify. The security audit for this feature is already underway.
The UX for using gas is also set to change, with the introduction of refundable gas fees. This adjustment will allow enterprises to use a revolving float for CSPR, improving the overall user experience.
One of the most anticipated changes in 2.0 is the merger of accounts and contracts. This unification will streamline and simplify code execution significantly, giving contracts all the capabilities of accounts. This merger, combined with refundable gas fees, will allow transaction processing contracts to loan tokens for processing transactions on behalf of users. It also paves the way for multi-signature upgrades.
Further enhancements in 2.0 include lifting PURSEs becoming a more central and visible part of the Casper system and simplifying URefs. These changes are interrelated with the account and contract merger. The enhancement of URefs will make them more secure and flexible, enabling features like whitelists, expiration, and shareability without forwardability.
Lastly, contracts will also see a wide range of enhancements, including support for the factory pattern, named keys enhancements, and host-enforced contract-level events. This large swathe of improvements will bring a significantly more trusted environment to the Casper ecosystem.
With the conclusion of her presentation, Medha invited questions and discussion, highlighting Casper's commitment to community feedback and involvement.
Following her updates on Casper 2.0, Medha turned her attention to answering queries from the community.
Question: "What is the current TPS with Casper 1.5?"
Medha's Response: “In the web 3.0 world, TPS (transactions per second) is often discussed. For example, Solana claims 3000 TPS, but these are mostly consensus messages, not actual user transactions. If Casper counted consensus messages, we could claim over 30,000 TPS. But we define TPS based on user-related work.
Throughput on Casper can vary depending on the type of transactions. Nonetheless, we believe protocol robustness, security, and reliability are more important than pure speed. Still, we're committed to improving speed and reducing block times. Our upcoming 1.6 update targets this, and we expect about a 60% net increase in throughput with every halving of block times.
Going forward, our performance gains will hinge on improvements to the WebAssembly core, the main bottleneck in our system. To address this, we plan to transition to WasmEdge for our WebAssembly interpreter.”
We had the pleasure of hosting a special guest: Kasey Alusi, the VP of Engineering at Validation Cloud. Alusi shared about the services they provide as a web3 infrastructure provider.
Validation Cloud is building three core products, with a focus on enterprises. The first product is the node API, which allows developers to read and write information from the blockchain, similar to using RPC providers in various blockchain development projects.
Validation Cloud prides itself on speed, scalability, and resilience, with the following features:
-Speed: Validation Cloud boasts the lowest global latency of any RPC provider, verified by a third-party website comparenodes.com.
-Scalability: Validation Cloud does not impose rate limits and offers elastic infrastructure. This is to ensure that if developers need to submit a large number of requests quickly, their provider will be able to handle it.
-Resilience: To meet the demands of enterprises building on web3, Validation Cloud offers features like regional failover, infra-region failover, and adequate hardware support.
Alusi mentioned that Validation Cloud runs nodes in various regions across the world, enhancing both resilience and speed. Users are automatically routed to the closest node for efficient service.
You can access the app at app.validationcloud.io. This is where you can create endpoints for any of the six different chains they support, including Casper. We also recommend following Validation Cloud on Twitter.
