My Immutable Journey with Casper II: The Transpiler
This is a continuation of a 3-part series on building a protocol that eventually partnered with Casper and their R&D into EVM.
Steve’s Green Light: From Idea to Action
In a previous update, I shared a brief glimpse into my ongoing adventure with Casper, a journey that has been both challenging and rewarding. This chapter of the story unfolded when I had the unique opportunity to pitch my innovative ideas directly to Steve, one of the visionary co-founders of Casper. The crux of my proposal was a daring and potentially transformative one: to integrate Ethereum Virtual Machine (EVM) compatibility into the Casper ecosystem. This integration aimed to bridge the gap between Casper’s capabilities and the vast, established Ethereum network, potentially opening up a myriad of new possibilities and applications.
Steve’s reaction to this proposal was nothing short of exhilarating. His eyes lit up with the spark of understanding and possibility. He didn’t just passively listen; he actively engaged, asking probing questions and pondering the implications of such integration. His response was not merely an approval but an enthusiastic endorsement. He expressed his excitement with a phrase that still resonates with me: “Let’s get to building!” This wasn’t just a green light; it was a rallying cry, a call to arms for innovation and progress.
Connecting with Mark: A Synergistic Partnership
So, the next chapter in this Casper saga? It’s all about the day I met Mark. Picture this: a casual meetup, probably less like a corporate strategy session and more like two tech enthusiasts bumping into each other in a Google Meet. Mark is this key figure in our mission, a guy with a deep dive knowledge in R&D, and just like me, he’s super into the idea of bringing EVM into the Casper world.
Our introduction was chill, yet it felt like something clicked right away. You know, like when you find someone who just gets it? That’s Mark for you. We’re on the same wavelength about blending Casper with Ethereum’s massive playground, and it’s like our brainstorming sessions are more of a laid-back chat about the future of blockchain.
Mark’s not just a talker, though. He’s got this practical side that really kicks things into gear. Mark wasn’t someone to bore with the business side but he wanted to stress the technology and bytecode mapping of a solution like what we were proposing. The transpiler was a great first place to start with development. He added me to this massive Telegram group, a melting pot of brains from Casper Core to various third-party wizards, all tinkering with the same puzzle. It’s this cool, informal hub where I can drop my video demos, kick back, and soak in all sorts of viewpoints and ideas. I even got to reconnect with my old manager, Maciej, who was one of the most fervent builders for a proposed EVM2CSPR system.
Honestly, it’s less like a formal work thing and more like hanging out in a virtual clubhouse, where everyone is geeking out over blockchain tech. We’re all in this together, sharing a common goal but also just enjoying the ride.
Tackling Core Protocol Incompatibilities
As we embarked on the intricate task of integrating Ethereum Virtual Machine (EVM) compatibility with Casper, we were promptly confronted with a series of technical challenges, primarily originating from inherent protocol incompatibilities between the two systems. These challenges were not merely superficial coding issues, but rather deep-rooted discrepancies in the fundamental operational frameworks of Casper and EVM.
One of the foremost hurdles we encountered was related to WebAssembly (WASM) preprocessing errors. These errors were indicative of profound differences in the code processing methodologies between Casper and EVM. Specifically, the errors emerged due to the divergent ways in which both platforms handle and execute smart contract code, with Casper’s approach being fundamentally distinct from that of EVM’s.
Further complicating our efforts were issues related to the rejection of floating point opcodes. This presented a significant obstacle, as it pertained to the fundamental operational logic of the EVM. The rejection of these opcodes necessitated a re-evaluation of the compatibility strategy, requiring a nuanced understanding of both platforms’ operational paradigms.
Additionally, we were challenged by a low threshold for the br_table instruction in the WASM environment. A br_table is basically an unnecessary indent that occurs in WASM files and if you’re transpiling EVM code — you’re gonna go WAY past the 256 line limit. This limitation posed a unique technical obstacle, as it restricted the complexity and scalability of the code that could be executed within the Casper framework, thereby complicating the integration process with EVM, which operates under different assumptions regarding such thresholds.
Each of these issues demanded not only a thorough technical understanding but also a creative approach to develop innovative solutions. The task required meticulous analysis, strategic planning, and a collaborative effort to reconcile these fundamental differences and ensure a seamless integration of EVM compatibility into the Casper ecosystem.
Easy solution is to tell the Telegram group “Hey can we just do this?” — but doing that would make me my worst nightmare: a Google product manager. Casper’s CTO Medha was always on the heel of security for enterprise clients configuring the solution and rightly so. br_tables and int opcodes made more succinct systems. There weren’t just technical challenges but there were stakeholders that weren’t willing to compromise on Vitalik’s blockchain trilemma.
Development Approach: Adapting Parity EVM’s Bytecode
Adopting a hands-on approach to address the aforementioned technical challenges, I focused on leveraging the Parity Ethereum Virtual Machine’s bytecode as the foundational element of our solution. This strategic decision was made to establish a solid base that aligns with the operational standards of the Casper network.
The initial step in this process involved updating the Parity EVM bytecode to ensure compatibility with the Solidity compiler (solc) version 0.8.16. This version was chosen due to its stability and widespread use in the Ethereum development community, making it an ideal candidate for ensuring seamless integration.
To cater to a diverse range of use cases and environments, I embarked on the creation of nightly builds for various operating systems. This initiative was crucial in ensuring that our solutions were not only robust but also versatile enough to operate efficiently across different platforms. The nightly build process involved continuous integration and testing, allowing for the timely identification and resolution of any issues that arose.
To test our adaptations and modifications, we employed a series of common algorithms and touchpoints. These tests were meticulously designed to simulate real-world scenarios, enabling us to comprehensively evaluate the performance and compatibility of our solutions within a controlled environment. By doing so, we could gauge the effectiveness of our integrations and make necessary adjustments to optimize the performance and interoperability between Casper and EVM.
This iterative process of development, testing, and refinement was pivotal in navigating the complexities of integrating two distinct blockchain technologies. It required not only technical acumen but also a strategic approach to problem-solving, ensuring that the end result was a seamless and efficient integration that leveraged the strengths of both the Casper and Ethereum platforms.
Mark’s Ambitious Goal: UniSwap v3 Levels on Casper L1
Mark had established a rather ambitious objective for our project — achieving functionality on Casper’s Layer 1 that paralleled the capabilities of UniSwap v3. This goal, while commendable in its vision, introduced a unique challenge: the inability to utilize the testnet for our developmental purposes. This constraint necessitated a shift in our approach, compelling us to devise alternative strategies for simulation and testing.
Without the conventional avenue of a testnet, our task was to explore and implement innovative methods to rigorously evaluate our developments. The primary aim was to ensure that these adaptations were robust enough to withstand the complexities and operational demands akin to a platform as sophisticated as UniSwap v3.
This situation required a blend of creative problem-solving and technical acumen, as we sought to replicate the real-world conditions and stresses that our solutions would encounter, but without the standard testing infrastructure typically available. The endeavor was challenging yet crucial, ensuring that our advancements were not only theoretically sound but practically viable in a live environment.
Seeking Help: Collaboration is Key
Acknowledging the intricate nature of the challenges we faced, it became evident that collaboration would be pivotal. To navigate through these complexities, we actively sought the expertise and support of the broader blockchain community. This phase of our project transcended beyond merely surmounting technical hurdles; it was fundamentally about cultivating a network of collaborative relationships, one that could offer valuable insights and guidance in our journey.
Engaging with the Casper EVM community provided us with diverse perspectives and specialized knowledge, crucial for addressing the multifaceted aspects of blockchain interoperability and the development of decentralized applications. This collaborative approach allowed us to tap into a wealth of experience and skills that were instrumental in refining our strategies and methodologies. I had somebody awesome remind me about what made this project solvable: NCTL — the very first thing I learned about when I was intern.
The emphasis during this phase was not solely on solving problems but also on forging partnerships and alliances that could enrich our project. This extended network of collaboration became a cornerstone of our approach, enabling us to delve deeper into the nuances of blockchain technology and emerge with solutions that were both innovative and practical. This collective effort underscored the importance of community and shared expertise in the realm of advanced technological development.
Eventually I finished successfully testing for 1Inch, Aave, Uni v1–3, and so on!
