We at Ocelot are always striving to look for new and innovative ways to help push the Celo mission forward. This article will highlight what we envision as a new and cutting-edge roadmap for the future of Celo’s architecture.

Celo As It Is Today

Celo is a Layer-1 EVM-compatible Proof-of-Stake network. When it first launched, the most innovative technology being built on it were both Phone Identity system and Plumo. Let’s cover both and where they are today.

The Phone Identity System, let’s call it PIS for this article, uses a service run by validators to attest that a new user can tie their wallet address to their phone number. This is a very cool technology, because any new user who creates a wallet on a mobile application — like, say, Valora — would then tie their phone number to their address. This allows users to be able to send cryptocurrency between them using just each other’s phone number, making crypto more approachable for non-crypto-native users from a UX perspective.

Currently, the only wallet on Celo that uses the PIS is Valora. Because of the decentralized nature of the attestation service, and the fact that it needs to be run by independent validators (who also need a Twilio or MessageBird account in order to operate it), the attestation experience on Valora hasn’t been very smooth. In order to solve this, Valora is moving towards a federated attestation model where they can provide an attestation for users using a more-centralized approach, and one that requires users to trust Valora for attestation. That could seem like a reasonable approach for Valora to improve its user experience. However, it does beg the question of why there’s a decentralized model for attestation that exists at all if Valora is moving to the federated attestation model. Currently, all SMS attestations sent by validators are for Valora users. No other wallet at this time is using the PIS for tying phone numbers to wallet addresses on Celo.

Now, let’s look at Plumo. Plumo is an ultra-light client that is designed to be run on mobile phones thanks to its very small footprint. The client uses zkSNARK technology to compress hundreds of days worth of blocks into one SNARK proof. And this allows for much faster syncing of the blockchain client on mobile devices. There were several rounds run in a trusted-setup computational ceremony by many people in Web3 to generate and secure the proofs to make Plumo ready.

Plumo was designed to be run on Valora, but currently Valora doesn’t even use Plumo. Instead, it relies on third-party RPC node providers in order to sync with the blockchain.

As we can notice from the current landscape, here we have 2 cutting-edge technologies — designed for mobile-first blockchain applications — and the flagship, most popular application on Celo is either not using that tech or moving towards a more-trusted approach. This begs the question of which elements of Celo are being used that are truly mobile-first and decentralized.

If we take a step back and look at the history of Celo, it was originally designed to be built on top of Ethereum as its own protocol. However, in order to target emerging markets and mobile-first users, there was a need for a PIS which couldn’t be achieved on Ethereum, and thus required the creation of a new Layer 1 to fulfill the Celo mission.

But as we are seeing from earlier: if the most popular wallet on Celo wants to move away from the attestation service and PIS that was the raison d’etre of building a Layer 1 for Celo, then why does Celo even need to be a Layer 1?

Celo currently allows users to pay for gas using native stablecoins. However, is this feature such a huge differentiation that it requires its own L1?

Objectively speaking, with its current trajectory Celo does not really provide a whole lot of differentiation than Ethereum.

Furthermore, other parts of Celo — called the Core Contracts —use coin-weighted governance mechanisms to upgrade and include the Celo Reserve (which helps with the native stablecoins like cEUR, cUSD, and cREAL, as well as with the on-chain Community Fund).

For us, the truth is all of these core contracts can be set of smart contracts that can work on another L1. And with the stalling of the Baklava testnet due to a Validator doing a hot swap that halted the chain, it added even more work on restarting the Baklava network, and updating Mainnet to circumvent the vulnerability — a major distraction from the Celo mission. It prompted some key questions, namely: Why should core developers be working on consensus issues on IBFT, instead of focusing on improving the EVM?

An Alternative Roadmap for Celo

Given the overview on the current state in the previous section, you would think that this article would want to propose Celo to become a dapp on another L1. That is not the intent — in fact we have a much larger vision for Celo.

We propose the following architecture for the future of Celo: Celo should become a Layer-2 ecosystem. Furthermore, we think it should be an EVM-compatible and Interoperable L2 that focuses on its core mission without worrying about L1 consensus. We all agree that one of the best networks to help achieve this vision is Celestia. Celestia is the first modular blockchain network, which has created what is known as the data-availability layer, providing the consensus mechanism and ordering of transactions while separating execution to Layer 2. Here, all Celo needs to do as an L2 is data-availability sampling from Celestia for the transactions relevant for Celo’s network. It doesn’t even need to download the entire Celestia block, just the transactions relevant to Celo.

This can help to solve many points highlighted in this article:

• Celo will no longer bear the burden of worry about validators and consensus issues, because it will use the Celestia network for this shared-security and data-availability approach.
• Celestia as a modular blockchain provides Celo with a lot of different customizations, while still allowing Celo to focus on its mission.
• Celo can better focus on its mission as a network, including using the core contracts as-is, by using them as part of a new L2 Rollup network just for Celo. Core developers need not worry anymore about consensus, and can just focus on improving the EVM on Celo.
• Valora and other future wallets can still resort to using their federated attestation model on the L2 system.
• The attestation service system that both has no incentive system and is costing validators money can be phased out.
• When it comes to light clients — and given the Celestia architecture not requiring the download of entire blocks — the more light nodes that are being run in the network, the larger the block size can be, which provides major scalability improvements.
• Scalability improvements for Celo means transactions stay affordable.

For more information on Celestia, we recommend reading the original research paper here.

Ocelot understands that such an immense proposal will take lots of time, resources, and coordination work in order to move in such a direction. Especially with the three largest entities governing Celo in such close proximity (Celo Foundation, cLabs, and Valora), the proposal to move to an L2 architecture would be difficult in terms of advocacy and convincing the community.

Therefore, we have a new proposed way of following that vision: an incentivized testnet for Celo that will make the goal of moving to an L2 better-established as a proof-of-concept.

Mezcal, An Incentivized Testnet For Celo

In order to fulfill the above vision and prove the concept, Ocelot is planning on spinning up an Incentivized and Canary Testnet for Celo called Mezcal.

The main goal of this incentivized testnet is to deploy the latest cutting-edge protocol and core technologies, that allow Celo to achieve it’s mission at scale. In order to be able to fully test these nascent features, Mezcal, (this new Celo testnet) needs to have an incentive structure for dapps to deploy and grow within the network.

The other main goal for the incentivized testnet is to move a replica of Celo to become an L2 Rollup on Celestia to fulfill this vision.

Mezcal will be in 3 phases:

• Phase 1: Instantiate the Mezcal network with validators and a snapshot taken from Celo to help onboard the ecosystem and dapp developers to utilize the incentivized testnet.
• Phase 2: Grow the ecosystem with incentives for developers to build on the Mezcal testnet first in order to test out new features. The Celo Reserve can also test the new tokens being deployed for diverse collateral.
• Phase 3: The Merge, moving Mezcal Incentivized Testnet from an L1 to an L2 Rollup on Celestia. Phase 3 will take some time as it requires waiting on Celestia Mainnet to go live.

We will share more information on Mezcal in the coming months and what to expect. We believe this roadmap has the vision and best potential for both fulfilling the Celo mission, as well as drastically improving the underlying architecture needed to sustain it.