ECIP 1027: Scaling ETC with Sidechains

Abstract

It’s proposed here to support Sidechains to Ethereum Classic blockchain as a first class citizens, effectively sharding transactions between separate chains based on cheaper consensus algorithms (PoS, PoA, etc) and using Main Ethereum Classic chain to transfer state between these chains and use as a security checkpoint (Checkpoint Contract Consensus).

Checkpoint Contract is based on Smart Contract way to track Sidechain state, it has special methods to store Height/Difficulty/State of Sidechain in a separate parent chain. Consensus algorithm for a Side Chain could consider this information stored in parent chain when synchronizing side chain.

NOTE This document propose a general idea, where some parts can be implemented in different ways, and will be proposed with separate ECIPs

Definitions

• Parent Chain - a blockchain to make checkpoints to
• Sidechain - a dependent blockchain that uses Parent Chain Checkpoints as part of Consensus
• Checkpoint - a status of Sidechain committed to Parent Chain
• Private Chain - a custom blockchain w/o public nodes
• Mainnet - main Ethereum Classic blockchain
• PoS - Proof Of Stake
• PoA - Proof Of Authority

Motivation

One of the ways to provide Scalability is to split execution into several (semi-) independent parts and allow Peer to process only that parts of whole chains that Peer is using. This approach is usually called Sharding.

Proof Of Work consensus algorithm is proven to be good for chain security, but other consensus algorithms, such as Proof Of Stake or Proof of Authority are better for performance and much cheaper in execution, and therefore are good solution for Scalability.

By combining them into a Hybrid Multichain, where chains is split into Sidechains with better performing consensus algorithm, we can reach greater scalability. A business can have a fast and cheap chain for internal processing, but having a security from public Proof Of Work ledger.

Idea of Sidechain for scalability is not new, and different versions of same idea were discussed many times over past years ([1], [2]). Most of these discussions were about applying Sidechains to Bitcoin, which has a are limited execution model and it requires enhancements to start using it. Ethereum turing-complete VM is much more flexible and allows to use this approach for scalability even without running a Hard Fork.

Specification

Overview

A Peer configures Geth to follow a separate chain (Sidechain) and specifying a more secure chain (Parent Chain) to make checkpoints through a special smart contract. For simplicity it could be two separate instances of Geth, communicating through RPC API. For better usability it would be optimal to add ability to follow several chains from same Geth instance.

Key points:

• There should be a special Smart Contract deployed to Parent Chain to manage checkpoints
• Checkpoints are transactions in Parent Chain
• Sidechain can read from Parent Chain and verify that it follows longest or most difficult Sidechain
• Mainnet is going to work as usual. Not a fork.

It maybe helpful to introduce additional Opcodes to improve cross-transaction functionality. That will require a protocol upgrade, but that’s optional and will be discussed in separate ECIPs

Types of chains

There can be selected major 3 types of Sidechains:

• Private chain - uses mainnet only for consensus
• Trusted public chain - operated by a trusted party
• Public chain - general use blockchain operated in untrusted environment

Private Chain (C1)

Private Chain is a fully private chain executed in isolated environment which is using Parent Chain only as a security mechanism.

This can be a solution for many cases of a private corporate blockchains. This types of chain doesn’t share state with parent chain, and therefore doesn’t need cross transactions, or can perform them in individual way when needed.

Conception of making checkpoints on public secure blockchain is a popular idea in private chains and standalone services, also called as Anchoring.

See ECIP-1028

Trusted Public Chain (C2)

Trusted Public Chain is a chain managed by a public service or Dapp, and such service provides full management of that chain and performs cross operations for their users. Sidechain can use PoA or PoS for internal consensus, and a separate Oracle/Validator like service to send/confirm user actions performed across the chains. For most of the cases this chain could have a simple shared state, such as buying/selling internal tokens through a parent coin.

Smart contracts for controlling shared state, and Transaction Replay like logic can give users additional security for their cross-chain operations.

Example: a smart contract based Token Exchange with Deposit/Withdraw through a special Smart Contract in Parent chain

Public Chain (C3)

Public Chain is a general use blockchain, operated by multiple parties and in an untrusted environment. It can use a fast PoS consensus algorithm for fast and cheap transactions, or individual configuration of EVM.

Checkpoint authorization

Making a checkpoint will require verification mechanism to avoid corrupted state and to protect from malicious actors.

For simple cases, when Sidechain is solely managed by one business (C1/C2 types), it’s enough to authorize an address (or set of addresses) which can make such checkpoints.

For more sophisticated chains (C2/C3 types) verification a Sidechain can use methods similar to Proof Of Stake, or even implement full verification in a smart contract. Later is possible if a checkpoint can provide security by validating only a chain headers and part of shared state.

Cross Transactions

Cross-transactions for public Sidechain (C3) is most complicated part. In additional to untrusted environment it can have multiple shared states managed by different types of services. It seems to be infeasible to implement a general algorithm which will work for all cases.

There could be few possible solutions to that problem:

• Tx Replay through a Smart Contract, when Transaction Owner is separated from Transaction Executor. One example is Replay Attack Issue for ETH/ETC, when once signed transaction can be reused by a third party on a separate chain. This can also be implemented through a smart contract, where an input operation in one chain can be easily replayed by another network participant (which could also get a small fee for this) effectively making cross transactions between chains. By using Smart Contract implementation it’s possible to achieve required effect different by chain.
• Ideas from Polkadot [4] and Tendermint/Cosmos [5] can be applied here. Both this approaches are targeting more broad set of blockchains, so can be significantly simplified for this particular task.

To improve capabilities of EVM to handle support for cross transactions, it seems to be helpful to add new Opcodes to do following:

• Get a hash of a whole mapping state of an address - that will allow to validate shared state on a checkpoint
• Signature validation for arbitrary data passed to a contract - that will allow to make same calls from another user (“replay tx”)

As there are few possible ways to implement such cross-chain transaction mechanism, it will be introduced in a series of a separate ECIPs.

Key Features

Proposed structure allows to use different EVM configuration per chain. It can be used for testing purposes, when a part of the network is used a test playground for new features of EVM. A business can apply custom optimization and additional features (OPCODES and Predefined Contracts) for their needs on their Sidechain. It could move most of politics aside, as sides can choose own subset of Sidechains for their needs.

Besides EVM it allows to use different type of VM for particular Sidechain, such as eWASM, WASM, JVM, etc

More to that, it’s possible to implement Sidechain with a totally new execution structure, which can be optimized just for one particular task, such as Token Transfer. Token Transfer Sidechain doesn’t need most of EVM features, therefore it can be implemented in ways similar to Bitcoin UTXO, Lighting/Raiden network, or can be used together with Zk-SNARKs, etc.

A particular Sidechain is free to use own subset of Sidechain, and practically allows to use Three of Chains, based on task or conditions. That could be a long living chain or ephemeral chain, global chain or geo-bounded chain suitable for local network of IoT devices.

Alternatives to proposed approach

• Address Space Sharding [6] - where a peer keeps only part of address space required for processing. This solution can be used together with proposed scheme and it gives additional joint for scalability.
• Raiden Network [7] - basically it’s a Sidechain in terms of this proposal, and can be considered as one of the possible implementations of a Sidechain

Implementation

Checkpoint Contract Interface

Minimal interface usable for a private managed chain

makeCheckpoint(uint64 height, uint256 difficulty, uint256 blockHash, uint256 parentHash, uint256 stateHash)

getLastCheckpoint() 
   returns (uint64 height, uint256 difficulty, uint256 blockHash, uint256 parentHash, uint256 stateHash)

It’s possible that for some cases it will be required to keep other data within the checkpoint, at this case it’s possible to extend parameters list with this new details. But for better compatibility and for standardization, it’s suggested to introduce custom methods to manage other details associated with the checkpoint

Extended interface

getHeight() 
    returns (uint64 height)
  
getBlocksCount(uint64 height) 
    returns (uint8 count)
    
getCheckpoint(uint64 height, uint8 index) 
    returns (uint256 difficulty, uint256 blockHash, uint256 parentHash, uint256 stateHash)

Geth Enhancements

Geth should have support for multiple consensus mechanisms, and a configuration for multiple chains. Part of this is already implemented, and we can have multiple custom/private chains with Geth starting at version 3.4.0. Similar features are already implemented in Parity.

It will also require improvements in user interface, new commands, configuration options and documentation. None of this is a breaking change

References

1. Enabling Blockchain Innovations with Pegged Sidechains (Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille) - https://blockstream.com/sidechains.pdf
2. Scaling Bitcoin with Sidechains - https://bitcointalk.org/index.php?topic=1083345.0
3. Sidechains, Drivechains, and RSK 2-Way peg Design - http://www.rsk.co/blog/sidechains-drivechains-and-rsk-2-way-peg-design
4. Polkadot, a heterogeneous extensible multi-chain - http://polkadot.io/
5. Cosmos: A Network of Distributed Ledgers (Jae Kwon, Ethan Buchman) - https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#sidechains
6. Ethereum ETH Sharding FAQ - https://github.com/ethereum/wiki/wiki/Sharding-FAQ
7. Raiden Network - http://raiden.network/