This post was originally published January 17, 2019 on Medium.

Scaling Ethereum through ephemeral economies

To date, scaling Ethereum has taken two forms: Layer 1 client improvements (L1), or Layer 2 (L2) mechanisms. While L1 scaling is realised through incremental code upgrades, L2 comes in the form of higher level external systems that leverage the greater security of the basechain.

Canto’s unique value proposition emerges as a hybrid with a foot in both camps. Simply put, client changes in the form of a new L1 subprotocol would enable L2 mechanisms to bloom more easily. The spec was recently released to the ETH Magician’s forum, check them out below:

• canto-ethereum/spec (broken link)

• CANTO: A Scalable Blockchain System Interconnect Model

I highly recommend reading both in full, as most of the information in this overview is taken in some form from there. If you’re short on time or technicals, follow along as we jump into what makes Canto an idea worth pursuing.

The idea for Canto came up over beers between Antoine Toulme (Consensys) and Zak Cole (Whiteblock) in November 2018. Their discussion focused on a few roadblocks: ETH 2.0 is going to take some time and there’s no guarantee that ETH 1.0 (1.x) improvements would all be implemented. How could they help push Ethereum forward with the current environment? From this frustration Canto was born. The name comes from poetry, referring to “one of the major divisions of a long poem.”

Following this initial brainstorm and some work, Will Meister (Consensys) and Daniel Choi (Whiteblock) were brought in to hash out some of spec details.

Conceptually, Canto is simple: the proposal hinges on a new Ethereum subprotocol. Every up-to-date ETH client includes four subprotocols, denoted by a short prefix: eth, les (light clients) shh (whisper), and bzz (swarm). The subprotocols facilitate important activities onchain in addition to the basic functions of the network.

Here’s a quick analogy. Imagine a client as a smartphone that only has 4 apps installed. Connecting users is limited to the design of only these 4 apps. Of course, this smartphone still allows people to do productive things, but what if another app could be added? Canto’s new app is a subprotocol named “can.”

“Can” would allow the creation of subnets, a catch-all term from networking: if Ethereum is the top-level network, Canto makes sub-networks that reside within it. These are flexible constructions that allow incredible design diversity, encompassing the potential of Plasma-like sidechains, novel testnets, ephemeral interactions, channels, games, and more.

Being embedded within a client at L1, but also facilitating an expressive L2. It permits mainchain to subnet communication while in the form of a client-integrated mechanism generator. It’s difficult to overemphasise how beneficial this arrangement is when compared to Plasma chains that have gone live. These require extensive coordination between operators and validators, maintenance, and monitoring to remain viable. While there are benefits like dependability and security, the marginal cost for each new chain is still quite high. This prevents rapid iteration and optimization of parameters for unique uses.

Here’s a rough equivalent: the role the ERC20 standard played during the 2017 runup. A thousand flowers (and some weeds) bloomed:

While some projects may have considered launching their own chains, the absence of hash-security combined with the network effects an ERC20 utility token precluded the notion (exchange support, existing high-quality code, etc.). Similarly, Canto could facilitate the coordination node services, operators, validators and users in a streamlined mechanism. Granted, hindsight shows that the majority of ERC20s were poorly designed, unnecessary, or outright scams. For better or worse, the barrier for ephemeral economies has dropped significantly.

A final comparison between ICOs and Canto is the role of ETH in this ecosystem. ETH from fundraising served first as operational runway for legitimate efforts, while the less scrupulous took large paydays and ran. Comparatively, Canto allows ETH to remain onchain as a staked bond placed in order to create the subnet. This further removes the need for high-stakes fundraising in deference to small scale experimentation.

The coordination process surrounding this creation would naturally accrue to marketplaces — see Livepeer’s Transcoder Explorer for a good example of service providers differentiating around a few simple variables.

In Canto, the design space expands from 1 to N dimensions. To start, there are the initialising parameters: consensus mechanism, privacy, gas economics, whether to implement research initiatives like state rent, among others. Will the subnet communicate with other subnets? How will node operators be rewarded? Templates, and template companies a la Wordpress, will spring up in and around these marketplaces. There is also room for the generalized mining narrative to thrive, as facilitators and supporters of subnet economies.

Second order effects of Canto, will be interesting to follow as it develops traction within the community.

Every subnet begins and is maintained through the same core of contracts, hosted on the Main ETH chain — however, the spec section on Contract Creation is a better source for technical readers.

Though Canto may initially appear similar to Plasma, there are some important distinctions between them.

Similarities:

• Both are L2 scaling solutions

• Both require some degree of coordination to kick off the network

• Shared challenges in the design of mass exit mechanisms (load balancer back to mainnet).

Differences:

• Canto ships with native flexibility when it comes to hardware and validator requirements. Discussed previously, Plasma requires significantly more coordination, whereas Canto might start as a wild west marketplace predicated on degrees of reputation.

• Smart Contracts on Plasma are a challenge — read “Why is EVM-on-Plasma hard?” from Kelvin Fichter.

Outside of Ethereum proper, Canto might also resemble Polkadot, a Parity project; again, there are important differences.

Similarities:

• Both are systems of smaller ‘dapp-chains’ that coordinate around a connecting base chain.

• Both enable smart contracts.

Differences:

• Canto is a ‘plug and play’ solution that runs within Ethereum, while Polkadot on a separate blockchain with a new architecture.

• Polkadot has a more rigid architecture that only allows for PoS — while the Ethereum basechain only permits PoW currently. Canto offloads onchain activity to to flexible subnets that can be PoW, PoS, PoA

• Canto’s subnets are “logically isolated from one another, responsible for their own security and function” while Polkadot’s parachains require interoperation in order to pool security collectively.

• Every parachain on Polkadot operates under on-chain governance. Canto leaves any governance (or lack of it) up to each subnet to decide.

While Canto is conceptually straightforward, there are still challenges that might slow implementation and the growth of a mature ecosystem.

To start, there’s the actual process to get a subprotocol implemented in a client. Aside from “eth”, light client support launched in January 2017, Swarm in December 2016, when the fledgling ecosystem was relatively small. Given the push today towards ETH 2.0 (and ETH 1.0, 1.x), it’s fortunate that that Canto doesn’t require a hard fork. A single client is all that’s needed to start demonstrating utility, but getting one onboard will take some effort.

Additionally, exit conditions still need to be developed and iterated on. Hopefully the developers will be informed by the large design space growing around Plasma. This is an open area of research that will need careful attention prior to release.

I’m looking forward to seeing development progress over the coming months. Hopefully sometime soon the larger Ethereum ecosystem will get to explore the capabilities of subnets.

To start, they are continuing to build out PoCs in Java and Go. You can track their Github progress here (broken link).

Thanks to Antoine (@_tmio) and Zac (@0xzak) for answering my questions and being super helpful. Please reach out with questions below or on twitter. (@trent_vanepps) \n

This post was originally published January 17, 2019 on Medium.

Scaling Ethereum through ephemeral economies

To date, scaling Ethereum has taken two forms: Layer 1 client improvements (L1), or Layer 2 (L2) mechanisms. While L1 scaling is realised through incremental code upgrades, L2 comes in the form of higher level external systems that leverage the greater security of the basechain.

Canto’s unique value proposition emerges as a hybrid with a foot in both camps. Simply put, client changes in the form of a new L1 subprotocol would enable L2 mechanisms to bloom more easily. The spec was recently released to the ETH Magician’s forum, check them out below:

• canto-ethereum/spec (broken link)

• CANTO: A Scalable Blockchain System Interconnect Model

I highly recommend reading both in full, as most of the information in this overview is taken in some form from there. If you’re short on time or technicals, follow along as we jump into what makes Canto an idea worth pursuing.

The idea for Canto came up over beers between Antoine Toulme (Consensys) and Zak Cole (Whiteblock) in November 2018. Their discussion focused on a few roadblocks: ETH 2.0 is going to take some time and there’s no guarantee that ETH 1.0 (1.x) improvements would all be implemented. How could they help push Ethereum forward with the current environment? From this frustration Canto was born. The name comes from poetry, referring to “one of the major divisions of a long poem.”

Following this initial brainstorm and some work, Will Meister (Consensys) and Daniel Choi (Whiteblock) were brought in to hash out some of spec details.

Conceptually, Canto is simple: the proposal hinges on a new Ethereum subprotocol. Every up-to-date ETH client includes four subprotocols, denoted by a short prefix: eth, les (light clients) shh (whisper), and bzz (swarm). The subprotocols facilitate important activities onchain in addition to the basic functions of the network.

Here’s a quick analogy. Imagine a client as a smartphone that only has 4 apps installed. Connecting users is limited to the design of only these 4 apps. Of course, this smartphone still allows people to do productive things, but what if another app could be added? Canto’s new app is a subprotocol named “can.”

“Can” would allow the creation of subnets, a catch-all term from networking: if Ethereum is the top-level network, Canto makes sub-networks that reside within it. These are flexible constructions that allow incredible design diversity, encompassing the potential of Plasma-like sidechains, novel testnets, ephemeral interactions, channels, games, and more.

Being embedded within a client at L1, but also facilitating an expressive L2. It permits mainchain to subnet communication while in the form of a client-integrated mechanism generator. It’s difficult to overemphasise how beneficial this arrangement is when compared to Plasma chains that have gone live. These require extensive coordination between operators and validators, maintenance, and monitoring to remain viable. While there are benefits like dependability and security, the marginal cost for each new chain is still quite high. This prevents rapid iteration and optimization of parameters for unique uses.

Here’s a rough equivalent: the role the ERC20 standard played during the 2017 runup. A thousand flowers (and some weeds) bloomed:

While some projects may have considered launching their own chains, the absence of hash-security combined with the network effects an ERC20 utility token precluded the notion (exchange support, existing high-quality code, etc.). Similarly, Canto could facilitate the coordination node services, operators, validators and users in a streamlined mechanism. Granted, hindsight shows that the majority of ERC20s were poorly designed, unnecessary, or outright scams. For better or worse, the barrier for ephemeral economies has dropped significantly.

A final comparison between ICOs and Canto is the role of ETH in this ecosystem. ETH from fundraising served first as operational runway for legitimate efforts, while the less scrupulous took large paydays and ran. Comparatively, Canto allows ETH to remain onchain as a staked bond placed in order to create the subnet. This further removes the need for high-stakes fundraising in deference to small scale experimentation.

The coordination process surrounding this creation would naturally accrue to marketplaces — see Livepeer’s Transcoder Explorer for a good example of service providers differentiating around a few simple variables.

In Canto, the design space expands from 1 to N dimensions. To start, there are the initialising parameters: consensus mechanism, privacy, gas economics, whether to implement research initiatives like state rent, among others. Will the subnet communicate with other subnets? How will node operators be rewarded? Templates, and template companies a la Wordpress, will spring up in and around these marketplaces. There is also room for the generalized mining narrative to thrive, as facilitators and supporters of subnet economies.

Second order effects of Canto, will be interesting to follow as it develops traction within the community.

Every subnet begins and is maintained through the same core of contracts, hosted on the Main ETH chain — however, the spec section on Contract Creation is a better source for technical readers.

Though Canto may initially appear similar to Plasma, there are some important distinctions between them.

Similarities:

• Both are L2 scaling solutions

• Both require some degree of coordination to kick off the network

• Shared challenges in the design of mass exit mechanisms (load balancer back to mainnet).

Differences:

• Canto ships with native flexibility when it comes to hardware and validator requirements. Discussed previously, Plasma requires significantly more coordination, whereas Canto might start as a wild west marketplace predicated on degrees of reputation.

• Smart Contracts on Plasma are a challenge — read “Why is EVM-on-Plasma hard?” from Kelvin Fichter.

Outside of Ethereum proper, Canto might also resemble Polkadot, a Parity project; again, there are important differences.

Similarities:

• Both are systems of smaller ‘dapp-chains’ that coordinate around a connecting base chain.

• Both enable smart contracts.

Differences:

• Canto is a ‘plug and play’ solution that runs within Ethereum, while Polkadot on a separate blockchain with a new architecture.

• Polkadot has a more rigid architecture that only allows for PoS — while the Ethereum basechain only permits PoW currently. Canto offloads onchain activity to to flexible subnets that can be PoW, PoS, PoA

• Canto’s subnets are “logically isolated from one another, responsible for their own security and function” while Polkadot’s parachains require interoperation in order to pool security collectively.

• Every parachain on Polkadot operates under on-chain governance. Canto leaves any governance (or lack of it) up to each subnet to decide.

While Canto is conceptually straightforward, there are still challenges that might slow implementation and the growth of a mature ecosystem.

To start, there’s the actual process to get a subprotocol implemented in a client. Aside from “eth”, light client support launched in January 2017, Swarm in December 2016, when the fledgling ecosystem was relatively small. Given the push today towards ETH 2.0 (and ETH 1.0, 1.x), it’s fortunate that that Canto doesn’t require a hard fork. A single client is all that’s needed to start demonstrating utility, but getting one onboard will take some effort.

Additionally, exit conditions still need to be developed and iterated on. Hopefully the developers will be informed by the large design space growing around Plasma. This is an open area of research that will need careful attention prior to release.

I’m looking forward to seeing development progress over the coming months. Hopefully sometime soon the larger Ethereum ecosystem will get to explore the capabilities of subnets.

To start, they are continuing to build out PoCs in Java and Go. You can track their Github progress here (broken link).

Thanks to Antoine (@_tmio) and Zac (@0xzak) for answering my questions and being super helpful. Please reach out with questions below or on twitter. (@trent_vanepps) \n