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

ECIPs/ECIP-1027.md

@@ -0,0 +1,220 @@
+### 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.
+
+See [ECIP-1028](ECIP-1028.md)
+
+### 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/
+

ECIPs/ECIP-1028.md

@@ -0,0 +1,124 @@
+### Title
+
+    ECIP: 1028
+    Title: Private Sidechain checkpoints
+    Author: Igor Artamonov <[email protected]>
+    Status: Draft
+    Type: Standard
+    Created: 2017-07-18
+
+
+# Abstract
+
+This proposal is a part of Multi Chain proposal defined by ECIP-1027. It provides a solution for a Private Chain 
+based on Proof of Authority [1] connected to ETC Main Chain.
+
+# Motivation
+
+Private Chains with PoS or PoA consensus algorithms are common solution for global business that needs a 
+distributed way of processing data on blockchain. This types of blockchain are executed in trusted environment in 
+a private network, and don’t need any communication with external entities. PoS/PoA are able to provide most of 
+functionality required for such processing, but lack of security and data immutability usually provided by PoW.
+
+Checkpoints proposed in [ECIP-1027](ECIP-1027.md) are able to improve security and data immutability 
+of such Private Chains. 
+
+# Specification
+
+ - Network has a custom Private Chain working under Proof-of-Authority
+ - Network has a Checkpoint Contract in public ETC mainnet with methods `makeCheckpoint` and `getLastCheckpoint`
+ - Network has set of trusted nodes with access to external network to make checkpoint, this can be same nodes as 
+   PoA or different set of nodes. Checkpoint is made every N blocks, where N can reflect from 1 minute to few hours 
+   of blockchain time and it does not affect Private Chain performance under normal conditions.
+ - Checkpoint Contract has list of addresses with granted access to make checkpoints
+ - Only one possible checkpoint is possible per Block Height, and height of a new checkpoint must be higher that 
+   existing checkpoint. Otherwise Trusted Nodes should come to agreement about Correct Fork if a 
+   network split is observed, this logic can be implemented in the Checkpoint Contract as well.
+ - A checkpoint is a Hash of State Root + Block Height in the Private Chain, which does not leak any internal data 
+   to public chain (`Hash(StateRoot | BlockHeight)`)
+ - A Private Chain peer periodical check Checkpoint Contract and in case of chain split chooses chain cornered to 
+   that contract most recently.
+
+# Implementation
+
+_WARNING_: following code is is for illustrative purpose only. It’s a very simplified implementation, should not 
+be used in a production system.
+
+## Contract
+
+````
+contract Checkpoint {
+
+   address historian;
+
+   uint64 height;
+   uint256 stateHash;
+
+   function Checkpoint() {
+       historian = msg.sender;
+   }
+
+   function makeCheckpoint(uint64 _height, uint256 _a, uint256 _b, uint256 _c, uint256 _stateHash) {
+       if (historian != msg.sender) {
+           throw;
+       }
+       if (_height <= height) {
+           throw;
+       }
+       height = _height;
+       stateHash = _stateHash;
+   }
+
+   function getLastCheckpoint() returns (uint64, uint256, uint256, uint256, uint256) {
+       return (height, 0, 0, 0, stateHash);
+   }
+
+}
+````
+
+## Consensus:
+````
+
+func MakeCheckpoint(contract *CheckpointContract, chain *BlockChain) {
+      height := chain.height()
+      block := chain.get(height)
+      hash := sha3(block.stateRoot, checkpointHeight)
+      contract.makeCheckpoint(height, nil, nil, nil, hash)
+}
+
+func (self *Checkpoint) FollowsCheckpoint(chain *BlockChain) bool {
+      checkpointHeight := self.height() //height at latest Checkpoint
+      checkpointHash := self.hash() //hash at latest Checkpoint
+      if (chain.height() < checkpointHeight) {
+             //chain is not fully synced yet, so maybe
+             return true
+      }
+      blockAtCheckpoint := chain.get(checkpointHeight)
+      chainHash := sha3(blockAtCheckpoint.stateRoot, checkpointHeight)
+      return chainHash == checkpointHash
+}
+
+func (self *Checkpoint) SelectFork(left *BlockChain, right *BlockChain) *BlockChain {
+      followLeft := self.FollowsCheckpoint(left)
+      followRight := self.FollowsCheckpoint(right)
+      if (followLeft && followRight) {
+             // Recent Split
+             return left.height() > right.height() ? left : right
+      }
+      if (followRight) {
+             return followRight
+      }
+      if (followLeft) {
+             return followRight
+      }
+      return nil
+}
+
+````
+
+# References
+
+ 1. Proof of Authority Chains - https://github.com/paritytech/parity/wiki/Proof-of-Authority-Chains
+ 2. Factom - Business Processes Secured by Immutable Audit Trails on the Blockchain (Paul Snow, Brian Deery, 
+   Jack Lu, David Johnston, Peter Kirby)
+