My Immutable Journey with Casper I: Intern to Inventing
This is going to be a 3-part blog of my journey from being an intern to building a protocol that partnered with the Casper Association under their new strategy to unite institutional EVM on an enterprise WASM.
The Beginning: Tackling the Transpiler Problem
My journey with CasperLabs began as an intern (believe it or not) — I had the opportunity to get connected to Mrinal Manohar via a prior boss. I was working under Tim Draper at the time and knew that financial models are not even 1% of life. Draper Goren Holm (one of our blockchain funds) was a Series A investor (small world) and I thought I should get as much exposure to development as possible before I set off into whatever awaited me.
Onboarding and Navigating
The onboarding process at CasperLabs was meticulously structured, providing me with the necessary tools and knowledge to contribute effectively. A significant part of my early days was spent understanding and utilizing the Network Control Tool (NCTL), an essential component for testing and managing blockchain networks. This tool was my gateway to mastering the technical nuances of Casper’s infrastructure. If you wanted a testnet for a testnet — that was NCTL. NCTL was the best way to kick off understanding and forking Casper at a higher level of understanding and implementation.
One tidbit: I only knew Solidity. The entire Casper contract call scheme was in Rust 💀.
Being proficient in Solidity allowed me to explore the depths of smart contract development. I learned to create contracts that were not only effective but also optimized for gas consumption, security, and integration with various blockchain components. This specialization meant delving into the nuances of blockchain technology, understanding how each smart contract interacts within the larger ecosystem, and exploring the vast possibilities of decentralized applications (DApps).
However, being proficient in only Solidity also came with its set of challenges. The blockchain landscape is continuously evolving, and keeping up with the latest developments, security practices, and emerging standards in the Solidity ecosystem required constant learning and adaptation. It also meant that I had to collaborate closely with experts in other areas of blockchain technology to ensure that the smart contracts I developed were well-integrated and aligned with the overall objectives of the projects.
Diving into Rust
At Casper, Rust isn’t just a programming language; it’s a philosophy. My experience with Rust was transformative, teaching me not just about safe and efficient coding, but also about thinking critically and systematically. Working with Rust was challenging, but it equipped me with a unique perspective on programming and problem-solving. But the key was(m) one thing: Web Assembly bytecode.
What made WASM so captivating for me at Casper was its unparalleled performance and flexibility. WASM is designed to be a portable compilation target for programming languages like C, C++, and Rust, enabling code to run on the web at near-native speed. This was a game-changer in blockchain contexts, where performance and efficiency are paramount. WASM allowed us to build more complex, resource-intensive applications that ran efficiently and reliably on the blockchain network.
In the realm of blockchain and specifically at Casper, WASM’s impact was profoundly felt in the development of smart contracts. Traditional smart contract platforms often face limitations in terms of performance, security, and scalability. WASM addressed these issues head-on. Its ability to execute code at near-native speed meant that smart contracts could be more powerful and efficient. This efficiency was crucial for Casper, as it enabled us to build more sophisticated and responsive decentralized applications (DApps).
Another aspect of WASM that I found particularly exciting was its ability to broaden the blockchain developer ecosystem. Since WASM is language-agnostic, it opens the door for developers proficient in languages like Rust and C++ to contribute to blockchain development without having to learn a new, blockchain-specific language. This inclusivity accelerates innovation and diversifies the range of applications being developed on platforms like Casper.
However, there was a core issue: WASM chains didn’t quite match the adoption levels of something like an EVM chain, especially in terms of developer tooling and liquidity. My initial thought was a straightforward solution: a transpiler. This tool would convert code compatible with WASM into a form that could work with EVM chains, potentially bridging a significant gap in the blockchain development landscape.
The challenge arose when this transpiler didn’t reach production. Its absence was more than a minor inconvenience; it was a substantial impediment to the workflow. Theoretically, with the transpiler, I could complete compilations using tools like Truffle or Hardhat and significantly streamline the development process. In reality, however, I was left grappling with a host of more complex and less integrated development tools — SDKs, RPCs, faucets — all while the idea of the transpiler continued to loom over my work, even after my time at Casper had ended.
This experience at Casper highlighted a critical gap in the blockchain ecosystem: the need for better integration and compatibility between different blockchain technologies, particularly between WASM and EVM platforms. Despite the technical potential and innovative strides we were making, practical implementation and ecosystem development still had some catching up to do.
Hacking Away: EVM on WASM
It was probably my summer at Apollo where I got back in touch with understanding why WASM was amazing for the world. During my time since Casper, many solutions have emerged as a result of that core issue of liquidity not meeting engineering scalability. Aurora on NEAR, NEON on Solana, SVMs on Polygon with Eclipse, Modular DA with EigenLayer + Celestia. This stuff was hot and it hasn’t cooled down even during the bear. If I was going to build something, I needed to do something like that.
Unlikely Meetup
I was at an All-Star Weekend Party in Salt Lake (s/o to Baron Davis for the invite) and I ran into Steve Careaga, a Casper co-founder and the person who managed strategic relationships. We had a lovely time and got to chatting about what I was building and planning to execute on Casper. Steve and I were a part of something bigger for Casper and a shared mission. We went through several ideas on how we could partner together until it finally came time to just do it. The solution was ready to partner with Casper as a means to go into a further goal — but my journey had just started.
