diff --git a/ECIPs/ECIP-1027.md b/ECIPs/ECIP-1027.md new file mode 100644 index 0000000..1817004 --- /dev/null +++ b/ECIPs/ECIP-1027.md @@ -0,0 +1,220 @@ +### Title + + ECIP: 1027 + Title: Scaling ETC with Sidechains + Author: Igor Artamonov + 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/ + \ No newline at end of file diff --git a/ECIPs/ECIP-1028.md b/ECIPs/ECIP-1028.md new file mode 100644 index 0000000..e4414a3 --- /dev/null +++ b/ECIPs/ECIP-1028.md @@ -0,0 +1,124 @@ +### Title + + ECIP: 1028 + Title: Private Sidechain checkpoints + Author: Igor Artamonov + 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) + \ No newline at end of file