ECIP-1027/28: Scaling ETC with Sidechains [WIP]

ECIPs/ECIP-1027.md

@@ -0,0 +1,218 @@
+### Title
+
+    ECIP: 1027
+    Title: Scaling ETC with Sidechains
+    Author: Igor Artamonov <[email protected]>
+    Status: Draft
+    Type: Standard
+    Created: 2017-07-17
+
+
+# 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.
+
+### 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/
+