Dawn of Decentralization — The Erasure Protocol Awakens on Ethereum Mainnet

The Erasure Protocol is live. Learn about its core primitives, design philosophy, and unique architecture using EIP-1167 clone factories.

For the last three years, Numerai has been hard at work building their data science tournament. Along the way, they realized that the primitives Numerai has built could have a wide range of applications beyond the tournament. This is Numerai’s platform moment. The Erasure Protocol can bring Web3 to any website, and it has awoken on the Ethereum Mainnet. The Erasure smart contracts are now available on GitHub.

Products powered by Erasure

Erasure does not rely on any speculative technology. Everything required to build on Erasure exists today. They’ve built two applications of their own: Erasure Quant and ErasureBay.

Erasure Quant is a tournament used to crowdsource data on the Russell 3000 index. Participants submit daily price predictions on US stocks and are rewarded for contributing while building an immutable track record. Erasure Quant is a template that can be used by others to build their own tournaments.

ErasureBay is an open marketplace for information of any kind. It can be used to create credible signals over possession of local knowledge and attract a buyer willing to pay for it.

The Philosophy of the Erasure Protocol

The Erasure Protocol is based on a simple idea.

If you risk money on some information then it’s probably good information so people will want to buy it from you. Skin in the game leads to better data.

Skin in the game is a required component, but there are a couple more primitives used in the formation of an economic relationship: Track-Record, Payment, and Recourse. These are the 3 primitives used to build applications on Erasure.

Track-Record is about proving historical quality. It’s the public track record of the past. Prospective counterparties can evaluate the credibility of your claims and decide if they trust you by looking at your history. It’s your personal brand, it’s your credit score, it’s your Twitter feed. This is where blockchains shine. It only makes sense for this track record to be permanent and immutable.

Payments is the value transfer. This is where cryptocurrencies shine. They are unquestionably the best way to transfer value over the internet.

Recourse is the final piece of the puzzle. It’s the court system that performs arbitration over breach of contract. It’s the Uber rating system. It’s a coordination mechanism fundamentally hardwired in each of us. It’s also something that can be programmed in a smart contract. This is where Erasure shines.

These three primitives form the components necessary for an economic relationship to thrive. They took each of these primitives and implemented them as simple templates that anyone can use in their web apps. They want these Erasure Web3 elements embedded on websites across the internet.

The following templates will be available at launch, with more templates coming available as new uses cases emerge.

Track-Record through Posts and Feeds

Erasure_Post keeps track of the hash and timestamp of all the data submitted to the protocol. This serves as a proof of existence on which a track-record can be built. Creating a Post instance is as simple as submitting a multihash of your data to the smart contract. At first the data is hidden, but it can be publicly revealed at a later point by uploading it to decentralized storage. A Post will be particularly useful for one-off predictions or submissions.

Extending the concept of a Post is a Feed. A Feed allows for a user to establish credibility through an ordered history of Post committed. Since these posts are in a single append-only array, it is not possible to erase or reorder them once submitted. A Feed is designed for use-cases with continuous predictions.

The hash which is submitted to the Post contract is called a proofHash. A proofHash can be generated by prepending the submitted data with a user address and a user-generated salt to avoid potential impersonation or snooping attacks.

proofHash = multihash(userAddress + salt + data)

Payments through any cryptocurrency

As aforementioned, cryptocurrencies already do a great job with payments. This is why the Erasure platform supports payments with any cryptocurrency. They expect users to prefer using Ethereum-native cryptocurrencies like ETH, WBTC, and NMR since they can be used with the programmable escrow smart contracts we’ve built. These escrows are registered in the Erasure_Escrow registry which contributes to the single source of truth.

Recourse through Griefing

Recourse is achieved when a party is punished for wrongdoing. In the world of Erasure, this translates directly to staking and burning. When two parties decide to engage, they begin by staking NMR and agreeing on a set of conditions for punishment. We call this combination of skin in the game and rules of engagement an Erasure_Agreement.

The first type of agreement used on Erasure is called Griefing. Griefing allows a party to come to a resolution without a third-party arbitrator by punishing their counterparty at a cost. Creating a Griefing agreement is as simple as having both parties agree on their respective ratio and amount at stake. The ratio represents the cost in NMR to burn 1 NMR of the counterparty. When griefing occurs, both the cost and punishment are burned from the NMR supply forever.

Take for example an agreement between Alice and Bob. Alice is anonymous and has not built a track record. She stakes 500 NMR and selects a ratio of 0.5. Bob, however, has revealed his real-world identity and has an excellent track record. As such, he stakes 100 NMR and selects a ratio of 1.

Alice = { stake = 500, ratio = 0.5}
Bob = { stake = 100, ratio = 1}Bob punishes Alice for 10 NMR => Cost is 5 NMR (10 * 0.5)
Alice punishes Bob for 10 NMR => Cost is 10 NMR (10 * 1)new_Alice = { stake = 490, ratio = 0.5}
new_Bob = { stake = 90, ratio = 1}

Griefing avoids relying on a centralized oracle or a trusted third party to perform arbitration over the terms of the agreement and instead allows the parties to come to a resolution on their own. As new techniques for resolution like decentralized oracles are built on Ethereum, it will be possible to add them to the set of Erasure_Agreement.

The extensible architecture of the Erasure Protocol

There’s a natural tendency when working with blockchains — information really wants to be permanent. Submit a transaction, and that transaction cannot be taken back. Deploy a contract, and that contract is going to stick around (well, there are notable exceptions to this rule). Basically, every action you take will be irreversibly etched into history, block by block.

However, new systems and protocols built on top of this foundation do not have the luxury of resting on their laurels. The constant winds of change and march of progress move their requirements and constraints inexorably forward, and so new protocols must adapt when evolving conditions demand it lest they fall out of favor and into obscurity. (Not to mention that an un-patchable bug will sound the death knell of any project.)

Hence, their design requirements were set.

Must be decentralized (to ensure persistence)

Must have a single source of truth (to build a track-record)

Must be future-proof (to integrate new use cases)

Must be modular (to isolate security risks)

The Price of Progress

To reconcile these design philosophies, new techniques have been developed that inject some flexibility into the rigid blockchain bedrock. Many projects now park their core contracts at an account containing an upgradeable proxy, or a contract that delegates all its logic to an adjustable implementation contract. This lets the systems that rely on those contracts gradually evolve, but in doing so it often introduces the danger of malicious mutations at the hands of a few mad scientists who control the fate of the system.

The crux of this threat comes down to the fact that many systems are designed with a small handful of smart contracts that run the show. This encourages monolithic, centralized architectures with limited modularity and a generous portion of “trust us”. So, the challenge becomes finding a way to build a cohesive protocol while simultaneously limiting the control or scope of any one particular contract.

Decentralization Taken Into Account

The EVM already has a fantastic natural defense mechanism against this menace — the account. By spreading a system’s components out across as many accounts as possible rather than holding it all in one place, there’s no single point of failure or central orchestrator that holds the fate of the system in the balance.

Every agreement, user, entry, whatever may have its own account, and those accounts (or the factories that deploy them) can then report back to simple, shared registries that establish a single source of truth for a given protocol. This grants individual agents in the system the authority to opt-in to new changes, gives rise to a diversity of options for how to interact with the system, and quite literally makes the system more decentralized.

The Pearl of Great Price

OK, that all sounds fine and dandy… but remember, deploying contracts to new accounts is expensive. You’re talking 32,000 gas minimum, plus 200 gas per byte of the contract runtime. When you consider that most contracts that do much of anything will run their byte-count up into the thousands, the prospect of architecting a practical, scalable system that will deploy them ad-nauseam becomes, well, nauseating.

But hey, guess what — this task becomes much more palatable by leveraging one of the same techniques used to create upgradeable contracts. That mechanism is, of course, to deploy a proxy that refers to a logic contract. However, by stripping away the requirement for upgradeability, and distilling the proxy down to the bare minimum size, minimal proxies can be deployed with only 45 bytes of runtime code, and in some cases even less than that!

Enter Erasure Clone Factories

This is exactly how the Erasure Protocol is designed. Using the Spawner library, every item on Erasure is created as a clone of a previously deployed template. They call these Clone Factories. Every clone is also registered in a registry which provides a single source of truth on the status of the protocol. At launch, they have the following two registries: Erasure_Posts to keep track of Feed and Post templates and Erasure_Agreements to keep track of OneWayGriefing templates.

And just like that, all their requirements are met.