ethereumproject / ecips Goto Github PK
View Code? Open in Web Editor NEWThe Ethereum Classic Improvement Proposal
The Ethereum Classic Improvement Proposal
The latest round of attacks against ETH unearthed a number of possible attack vectors against the network. Some of them may be fixed/patched and thus mitigated, but a hard fork is required for a permanent solution, as discussed here:
ethereum/EIPs#150
My question is, should we strive to include such fix in a January hardfork, while we are at it? Would be interested in your perspective.
@whatisgravity @splix @igetgames @elaineo @mikeyb @ericsomdahl @avtarsehra @realcodywburns
In reference to:
ethereum/eip150
Concerning: Long-term gas cost changes for IO-heavy operations to mitigate transaction spam attacks
With the understanding that:
Issues to address:
a. EF Official
b. EF Official- no eip 150 fork
c. EF TheDao Classic (accepted 1920k but ignored GasReprice, not upgraded nodes basically)
d. ETC Early GasReprice, block 2,463,000 (uses upgraded EF version of geth with --oppose-dao flag)
e. ETC Late GasReprice, block 2500000 (uses etc version 2.0.0 client)
f. Ethereum Classic Classic (doomed) no forks ever from homestead
Urgency - this needs to be ready for testing as soon as humanly possible.
MAKE THE PLAN KNOWN. on all channels. smoke signals as need be.
Proposed actions:
0. MAKE KNOWN TO EVERYONE WHAT THE DECISION IS AND PUBLISH REQUIRED CHANGES IN ACCEPTED ECIP.
ERC: <to be assigned>
Title: Address-to-Address messaging system protocol
Author: Dexaran, [email protected]
Status: Draft
Type: ERC
Created: 20-12.2017
Resolution: https://github.com/EthereumCommonwealth/Address-to-Address-messaging
The following describes the details of the smart-contract based messaging system which aims to allow Ethereum users to directly contact the address owner without having to know who hi (she) is.
Ethereum lacks a central messaging system that will allow to contact an address owner directly. You can send him a transaction with ASCII message attached as data
but it is likely that address owner will not even try to recognize it as a text message. As the result there is no viable way to deliver a message to address owner directly.
This service is necessary in some circumstances, for example:
You sent someone a token, the existence of which this person does not know. It is likely that a person will spot an incoming ETH transaction, but there is no way that a person will spot an incoming token transaction or the fact that his balance of this token increases. You need to contact the owner of this address and ask to send your tokens back.
You sent ETC into someone's ETH address. The same situation as with tokens. It is likely that a person will not recognize an incoming transaction of an alternative currency. But he definitely can access it and send it back (or just go and sell it).
You spotted that someone have deployed a contract that is proven to be vulnerable. If you're a good guy then you want to contact an owner of the "vulnerable contract" and warn him that he is going to use a contract that contains vulnerability and his funds are at risk in this case.
You spotted that someone has hacked something. You would like to contact a hacker and kindly ask him to send everything back but the hacker likely will not respond if you will try to contact him via forums. I suppose that it is the most important case. On-chain methods of communication are the only way to securely contact a hacker or to respond if you are the hacker.
Basic address-to-address messaging smart-contract.
This is a simple smart-contract that stores messages mapped to addresses by id and a mapping that represents the last message id for each address. Last message id increases for the receiver address when this address receives a new message (there is no message at last_message_id
in fact... this represents a numeric id that will be filled with the next incoming message in fact). If the last_message_id
is equal to 0 then there are no messages for this address. If last_message_id
is equal to 2 then there are 2 messages at positions 0 and 1 for this address.
There is no possibility to edit, change, delete messages. This contract is not a messenger or a chat. This contract is an emergency way to contact an owner of a certain address when there is no possibility to contact him off-chain. As the result, editing and deleting messages has no reason because it will still be available via history of transactions.
Basically, there is no way to encrypt message on-chain because there is no way to hide an input call data. As a result, there is an additional field for attaching a public asymmetric encryption key. If the owner of a certain address has a desire to allow someone to contact him privately, then he can publish his public key at this contract and describe what type of key he has published at the "Key type" variable (for example PGP public key
or RSA 2048 bit public key
). Anyone else is allowed to look at the public key in the contract, encrypt the message outside the network and send an encrypted message on this contract.
function sendMessage(address _to, string _text)
Delivers a string message to _to
address owner.
function lastIndex(address _owner) constant returns (uint256)
Returns an index of the last message for the _owner
address.
NOTE: This means that there are messages at 0
to lastIndex - 1
positions. There is no message at lastIndex
position actually. This will be filled with the next message for this address. If the lastIndex
is equal to 0
then there is no messages for this address.
function getLastMessage(address _who) constant returns (address _from, string _text)
Returns the last message for the _who
address and the sender of this message.
NOTE: Message is actually at lastIndex(_who) - 1
position.
function getMessageByIndex(address _who, uint256 _index) constant returns (address, string)
Returns the message for _who
address at _index
position and the sender of this message.
function getPublicKey(address _who) constant returns (string _key, string _key_type)
Returns a public key of the _who
address and a type of this key.
function setPublicKey(string _key, string _type)
Sets a public key and a description of key type for the sender address.
Obviously, this contract can not guarantee that an owner of the address will receive a message. It requires to be supported by UIs. It is likely that an owner of a certain address will see a message if MyEtherWallet, MetaMask or Mist will display messages somehow (for example a certain number of last messages).
Also, it makes sense to standardize possible public key types. Ideally, UI should have a button "Send message to address" and "Send encrypted message to address" and distinguish public key, key type and then encrypt message automatically.
Why we need it at all, everyone can just create an issue with a problem?
Some thoughts on ETC Monetary Policy, copied from https://ethereumclassic.github.io/assets/Ethereum_Classic_-_The_New_Original_Innovator.pdf
Fixing ETC Monetary Policy - Options:
Keep unlimited token inflation forever, like current ETH
Fixed final supply with Bitcoin-like reward cut-offs (halvings)
Fixed final supply with exponential reward adjustments (per epoch)
Have concern about this proposal. Many projects support ETC only because it is easy to integrate using well-known libs (web3j, web3.js, etc). Changing API only for changing doesn't bring any value. Developers will have to do double work.
Title: Decentralized registry of official media resources.
Author: Dexaran, [email protected]
Status: Draft
Created: 3-05.2018
Resolution: https://github.com/Dexaran/media-resources-registry
The following describes a smart-contract that improves the degree of decentralization of the project by reducing the influence of owners/moderators of "official media resources". Official media resources can form public opinion and thus strongly influence the fate of the project. If the control over official media resources is concentrated in the hands of a certain group of people, then this greatly damages decentralization in the community.
Decentralization is one of the basic concepts of the crypto industry. Nevertheless, the following aspects of any projects are fully centralized and can be easily censored:
Most media resources have owners who can determine the fate of the project by forming public opinion. Of course, the official logo and the name of the project are not so important. However, many decisions in the community are taken not by the community itself, but by a group of people who control official media resources, i.e. which can make the "official announcement".
When it comes to making such critical decisions as performing a hardfork, it is necessary to notify exchanges and mining pools. In the end, whether hardfork will occur or not, depends on the exchange and pools that will support it or not. In many respects success depends on WHO will announce the forthcoming hardfork for the community and WHO will notify the exchanges (WHO = what media and whether they are "official" or not).
On the other hand, in a decentralized community there should not be unequivocally official resources, as any member of the community is as much official as the others.
The key issue here is who to consider to be "official", i.e. who has a permission to speak on behalf of the whole decentralized community.
The community can not make a decision on what media resources of this project are considered official and which are not. The community also can not express disagreement and change one of the resources if the interests of the owner of this resource are at conflict with the interests of the community.
This proposal introduces a Media Resources Registry smart-contract. This contract is intended to preserve a list of official resources that are approved by the community on-chain without 3d party interference.
This contract has a couple of methods add_entry and remove_entry which serve to add/remove official resources.
It should be decided that only those resources that are currently represented in the described contract are official and are approved by the community. It is absolutely necessary to make such an important decisions as approving a resource to be "official" on chain. Otherwise it will lead to a centralization.
This proposal can also improve the protection against scam websites and non-official links that can hurt users. It is possible to query the contract to ensure whether a given link is registered as an official resource or not.
It is also possible to create a user-friendly web UI that will represent this information. This can help to avoid confusion and uncertainty about what resources provide officially reliable information because fraudsters rely on this uncertainty to deceive users.
The proposal is to deploy the contract and announce its value and purpose to the community.
The contract has an access restriction mechanic, thus it is advised to use the official donation multisig for the first time. However, in the future, this contract will require an on-chain voting system to serve its primary goal. For example ECIP52.
It's best to add links without beginning (https://, http://) and endless (slash /) and lowercase to the contract.
This proposal is currently implemented in Callisto for testing and adoption reasons.
There is one owner address at the contract that will be replaced with the proposed on-chain governance system as soon as the governance contract is deployed.
I think we have a problem with general ECIP process, it was not officially accepted as ECIP active proporsal. Some datails you can read in README.md
, but it's not work. We have to accept our own process and publish it as ECIP, similar to BIP process, revised.
There will be an Ethereum Naming Service (ENS) launched soon. I will deploy and support ENS contracts on EthereumClassic mainnet as soon as finaly ENS version will be released.
I think it is needed to be done.
There will be no serious changes in ENS contracts but there also need to be a UI ECNS lookup realization.
EIP: ?
Title: Ethereum Classic Protocol Repository
Author: Wei Tang <[email protected]>
Discussions-To: [email protected]
Status: Draft
Type: Process
Created: 2017-04-28
This ECIP proposes "Ethereum Classic Protocol Repository (ECPR)", consisting of documents of the Ethereum Classic protocol specifications. It also proposes to fork Ethereum's yellow paper as ECPR-0.
Currently most of Ethereum Classic protocol implementors follows the specification of Ethereum yellow paper. While the yellow paper is clean and explains in detail of how the protocol works, it only documents the current newest protocol version. However, as the Ethereum/Ethereum Classic blockchain contains all the history since it has started, the current protocol version usually only apply from a certain block number, with older ones still using the older specification.
Hence, I purpose we create a Ethereum Classic Protocol Repository that consists of all the documents of the currently applied protocol specifications.
Firstly, Ethereum's yellow paper is forked as ECPR-0. All currently applied ECIPs or EIPs of the protocol design should also be forked and take subsequent numbers (ECPR-1, ECPR-2, ...). This might consists of hard forks of the gas cost changes, etc. All documents MUST specify that from which block number it starts to apply.
Modifications to ECPRs should be done through ECIPs. ECIPs, when related to protocol design changes, should also contain a document of either modifications to ECPRs, or a new document of an ECPR.
We can simply create a new repository ethereumproject/ECPRs
for holding those protocol specification documentations.
Good summary of the issue: https://github.com/ethereumclassic/README/issues/18
Current 'solutions' to the problem: https://github.com/ethereumclassic/README/issues/3
Additional discussion: https://github.com/ethereumclassic/README/issues/8
ECIP: ?
Title: Remove Old EIPs
Author: Wei Tang <[email protected]>
Discussions-To: [email protected]
Status: Draft
Type: Process
Created: 2017-04-29
Currently we have EIP-1001
to EIP-1009
in this repository. Those are duplicates of the ethereum/EIPs
. Plus, even the Ethereum Foundation changed their EIP process that new EIPs are not created in this way.
As those are not maintained by us, I suggest we remove those EIPs and only put ECIPs in this repository.
Some thoughts on ETC Monetary Policy, copied from https://ethereumclassic.github.io/assets/Ethereum_Classic_-_The_New_Original_Innovator.pdf
Platform token aligns economic incentives of users, miners and investors
Current Ethereum monetary policy undefined (unlimited token inflation)
ETH policy is supposed to change with a transition to PoS unpredictably
Lack of token scarcity does not support long-term investor confidence
ETC transition to a long-term PoW necessitates monetary policy decision
ETC commitment to a specific monetary policy:
provide certainty to the market
boost investor confidence
creates competitive differentiator to ETH with its undefined policies
Fixing ETC Monetary Policy - Options:
Keep unlimited token inflation forever, like current ETH
Pros: keeps the status quo, encourages token spending
Cons: long-term monetization uncertain, not a good store of value/investment
Fixed final supply with Bitcoin-like reward cut-offs (halvings)
Pros: experimentally proven to work for BTC, sustainable token monetization due to scarcity
Cons: changes existing inflationary parameters, disruptive “halving” events
Fixed final supply with exponential reward adjustments (per epoch)
Pros: no disruptive “halvings”, sustainable token monetization due to scarcity
Cons: changes existing inflationary parameters
Slack:@snaproll (sorry, can't find you on Github) started exploring ETC supply model here:
https://docs.google.com/presentation/d/1jWTiJr7FmGjTyNj80-OapxDOiRGKVwmlkQ63LOnPO24/
Current transaction execution model lacks of Atomicity for multiple transactions.
An atomic [database] transaction is an indivisible and irreducible series of database operations such that either all occur, or nothing occurs. https://en.wikipedia.org/wiki/Atomicity_(database_systems)
Applied to Ethereum it’s a set of calls to several contracts, when either all of them should be executed or none if error happened at any of the steps.
An example would be transferring token to an exchange, making an exchange operation and transfer new tokens back. This should happen atomically, all or none. If at any of the steps an error will occur, state should be reverted to an initial state before first transaction in this set.
It’s proposed here to create joint transaction type of transaction, which would be literally joined binary data of several transactions, which should be executed atomically.
nonce
and gasPrice
fields can be added just once, as well as tx signature details. But gasLimit
, to
, value
and data
can be repeated.
[nonce, gasPrice, [[gasLimit, to, value, data], [gasLimit, to, value, data]], v, r, s]
Hard Fork protocol upgrade, change to both p2p protocol (=consensus) and to RPC API
ERC: 223
Title: Token standard
Author: Dexaran, [email protected]
Status: Draft
Type: ERC
Created: 5-03.2017
Resolution: https://github.com/Dexaran/ERC23-tokens
ERC20 compatible example: https://github.com/Dexaran/ERC23-tokens/blob/ERC20_compatible/ERC23_token.sol
The following describes standard functions a token contract and contract working with specified token can implement to prevent accidentally sends of tokens to contracts and make token transactions behave like ether transactions.
Problems of ERC20 that ERC223 will solve:
transfer
. Doesn't matter is user depositing in contract or sending to an externally owned account.Those will allow contracts to handle incoming token transactions and prevent accidentally sent tokens from being accepted by contracts.
For example decentralized exchange will no more need to force users to call approve
at token contract then call deposit
that is calling transferFrom
taking allowed tokens. Token transaction will automatically be handled inside the exchange contract.
The most important here is a call of tokenFallback
when performing a transaction to a contract.
Token
Contracts that work with tokens
NOTE: An important point is that contract developers must implement tokenFallback
if they want their contracts to work with the specified tokens.
If the receiver does not implement the tokenFallback
function, consider the contract is not designed to work with tokens, then the transaction must fail and no tokens will be transferred. An analogy with an Ether transaction that is failing when trying to send Ether to a contract that did not implement function() payable
.
function totalSupply() constant returns (uint256 totalSupply)
Get the total token supply
function name() constant returns (string _name)
Get the name of token
function symbol() constant returns (string _symbol)
Get the symbol of token
function decimals() constant returns (uint8 _decimals)
Get decimals of token
function balanceOf(address _owner) constant returns (uint256 balance)
Get the account balance of another account with address _owner
function transfer(address _to, uint _value, bytes _data) returns (bool success)
function that is always called when someone wants to transfer tokens.
This function must transfer tokens and invoke the function tokenFallback (address, uint256, bytes)
in _to
, if _to is a contract. If the tokenFallback
function is not implemented in _to
(receiver contract), then the transaction must fail and the transfer of tokens should not occur.
If _to
is an externally owned address, then the transaction must be sent without trying to execute tokenFallback
in _to
.
_data
can be attached to this token transaction and it will stay in blockchain forever (requires more gas). _data
can be empty.
NOTE: The recommended way to check whether the _to
is a contract or an address is to assemble the code of _to
. If there is no code in _to
, then this is an externally owned address, otherwise it's a contract.
IMPORTANT: Token fallback function that will be called at receiver contract must be named tokenFallback
and take parameters address
, uint256
, bytes
. This function must have 0xc0ee0b8a
signature.
function transfer(address _to, uint _value) returns (bool success)
Needed due to backwards compatibility reasons because of ERC20 transfer function doesn't have bytes
parameter. This function must transfer tokens and invoke the function tokenFallback(address, uint256, bytes)
in _to
, if _to is a contract. If the tokenFallback
function is not implemented in _to
(receiver contract), then the transaction must fail and the transfer of tokens should not occur.
IMPORTANT: Token fallback function that will be called at receiver contract must be named tokenFallback
and take parameters address
, uint256
, bytes
. This function must have 0xc0ee0b8a
signature.
event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes _data)
Triggered when tokens are transferred.
function tokenFallback(address _from, uint _value, bytes _data)
A function to handle token transfers that is called from token contract when token holder is sending tokens. _from
is a token sender, _value
is amount of incoming tokens and _data
is attached data similar to data in Ether transactions. Works like fallback function for Ether transactions and returns nothing.
NOTE: msg.sender
will be a token-contract inside the tokenFallback
function. It may be important to filter which tokens are sent (by token-contract address). The token sender (the person who initiated the token transaction) will be _from
inside the tokenFallback
function.
IMPORTANT: This function must be named tokenFallback
and take parameters address
, uint256
, bytes
to match the function signature 0xc0ee0b8a
.
This is highly recommended implementation of ERC 223 token: https://github.com/Dexaran/ERC23-tokens/tree/Recommended
Title: Random Number Generator
Author: Dexaran, [email protected]
Status: Draft
Type: Protocol upgrade
Created: 11-04.2017
When developing smart-contracts and searching other contract-supporting blockchains I found it useful to have an integrated source of entropy. Entropy source is a real headache for every developer that need to generate a random number and this situation is frequent enough to implement a solution on protocol level.
I don't yet have a ready solution of this problem and I want to get more feedback now.
I'm now looking at AEternity that is already preparing to implement it: https://blockchain.aeternity.com/%C3%A6ternity-blockchain-whitepaper.pdf
10 Epoch (300,000 blocks)
5,010,000 (Epoch 167)
Decay Option # | Decay Percentage | Miner Decay Amount | Uncle Decay Amount | Years to Decay | Estimated Supply (Current Reward) | Block Height Reward Ends |
---|---|---|---|---|---|---|
1 | 5.00% | 0.2500 | 0.02500 | 5.236872146 | 99,851,032 | 11,010,000 |
2 | 4.00% | 0.2000 | 0.02000 | 5.950342466 | 100,226,032 | 12,510,000 |
3 | 3.00% | 0.1500 | 0.01500 | 7.139454909 | 100,851,532 | 15,009,990 |
4 | 2.00% | 0.1000 | 0.01000 | 9.517694064 | 102,101,032 | 20,010,000 |
5 | 1.00% | 0.0500 | 0.00500 | 16.65239726 | 105,851,032 | 35,010,000 |
6 | 0.50% | 0.0250 | 0.00250 | 30.92180365 | 113,351,032 | 65,010,000 |
7 | 0.25% | 0.0125 | 0.00125 | 59.46061644 | 128,351,032 | 125,010,000 |
5 ETC
0.5 ETC
The original ECIP 1010 ( #4 ) describes the details of delaying Difficulty Bomb growth for one year. It was suggested to change Difficulty Bomb formula to stop growing for period of time from January 2017 to December 2017, which is around blocks 3,000,000 and 5,000,000 accordingly. This would correspond with the end of era 1 per ECIP 1017 ( #15 ) and implementation of the new monetary policy.
The bomb was originally delayed to review:
Several of these items have been addressed, several more have been added in the past year including evm evaluation, file storage, and sharding.
I propose remaining at the current difficulty, extra difficulty 2**28, until block 9,000,000
or render safe forever (setting the default unfreeze block to 0x7fffffffffffffff
) as part of the activation of ECIP 1017.
This ECIP should be activated with an 'opt-out' flag. User wishing to keep the current ecip-1010 deadline should be allowed the option to use a --diehard
flag which will keep the bomb reactivation at block 5m. the default action (no flag) will be to move the bomb block to 9m
This issue is dedicated to discussion of ECIP-1010 Delay Difficulty Bomb Explosion by @splix.
Located here: https://github.com/ethereumproject/ECIPs/blob/master/EIPs/ECIP-1010.md
ECIP: TBD
Title: Utilizing a second authentication method to prove ownership and facilitate fund recovery in the event of a theft
Status: Draft
Type: Security
Author: Pyskell
Created: 2017-07-21
We essentially live in the wild west of currency, we have no central authority, and therefore we need to be able to provide users with adequate means to protect themselves.
When a wallet's private key is stolen it becomes very hard or impossible to prove ownership of the stolen funds because both the attacker and the legitimate owner now control the private key and there is no way to prove legitimate ownership.
Provide a secondary means of authentication via a contract on the Ethereum Classic blockchain. This secondary authentication will serve solely to prove ownership, and is in no way used for transferring or accessing funds.
ECIP: ?
Title: Generalized Version Bits Voting for Consensus Hard Fork
Author: Wei Tang <[email protected]>
Discussions-To: [email protected]
Status: Draft
Type: Informational
Created: 2017-06-28
(This is still a work-in-progress. TLDR, it tries to bring the best practices about how Bitcoin deals with consensus hard fork (BIP-9 and BIP-135) into Ethereum Classic. Rather than hard-code a block number as we currently do, each block mined emits support of the new consensus hard-fork. Only when a large enough portion of the network support it, the hard-fork is "locked-in" and will be activated.)
Lack of an appropriate voting method can results in network forking. The DAO hard fork was such an example. Currently the way Ethereum used to gather opinions was through CarbonVote. It indeed has the advantage that it brings the opinions of Ethereum holders rather than miners. However, it is not enforceable and we all know the disastrous result it brought during the DAO hard fork period. We don't want that to happen again.
Miner community and proof of work. It is common knowledge that Ethereum Classic will probably stay in proof of work, rather than, like Ethereum, switch to a proof of stake algorithm. Opinions from miners are as important for us as it is for Bitcoin, as those are the people that actually runs the network. If ever we go to proof of work and proof of stake hybrid, as some new blocks will be mined by stake holders based on how many stakes they own, this ECIP would automatically include opinions of both miners and ETC holders.
Best practices from Bitcoin. BIP-9, which uses version bits mined in each blocks to vote for consensus hard fork has be successfully conducted for several Bitcoin hard forks.
Potentially faster adoption of new consensus hard fork. When dealing with emergency consensus hard fork for preventing network attacks, the developer would not need to artificially insert a "hard fork block number" (which must leave enough time for everyone else to upgrade their clients, and then wait for that block). But rather, as soon as a large enough portion of the network clients have been upgraded, the new consensus hard fork would be active.
Ethereum Classic will become a stable protocol soon. When we finished dealing with the monetary policy and finally the difficulty bomb, ETC's protocol would become a rather stable one. This means most of the new consensus hard fork would be new features of the network, rather than fixing existing bugs. In that case, voting would be important to keep the whole network healthy.
Ethereum protocol has the extra data
field for every block mined. This is currently being filled by the client version. We can use this field to implement the exact same thing as defined in BIP-135 for new consensus hard fork activation.
ECIP: TBD
Title: A smart contract based system for ECIP management
Status: Draft
Type: Meta
Author: [email protected]
Created: 2017-03-26
ECIP stands for Ethereum Improvement Proposal. An ECIP is a design document providing information to the Ethereum classic community, or describing a new feature for Ethereum or its processes or environment. The ECIP should provide a concise technical specification of the feature and a rationale for the feature. The ECIP author is responsible for building consensus within the community and documenting dissenting opinions. This system is currently managed using a github repository which does not allow for voting. By using a smart contract based system for tracking and managing ECIPs it is hope a broader participation from the community can be achieved.
To overarching motivation for this proposal is to provide a medium for all future ECIP's a succinct environment allowing for financial transparency, a more inclusive decision making process, a disintermediation of proposals from the proposers and better funding channels to avoid centralization
There are three kinds of ECIP:
A Standard Track ECIP describes any change that affects most or all Ethereum implementations, such as a change to the [https://github.com/ethereum/yellowpaper Yellow Paper], the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard ECIPs can be broken down into the following categories.
** Consensus - Those ECIP's which effect the system of block creation
** Networking - Currently Networking discussion tracks in the [https://github.com/ethereum/devp2p devp2p repository].
An Informational ECIP describes a Ethereum Classic design issue, or provides general guidelines or information to the ETC community, but does not propose a new feature. Informational ECIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational ECIPs or follow their advice.
A Meta ECIP describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process ECIPs are like Standards Track ECIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational ECIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-ECIP is also considered a Process ECIP.
Registry: A publicly accessible smart contract that allows individual ECIPs the ability to register. It should be robust enough to provide:
ECIP contract: Smart contract that contains meta-data relating to the ECIP. At a minimum it should:
Front-end system: Any system external to the ECIP contracts which is able to submit web3(or similar) calls to the ETC EVM to retrieve information from contracts and present the data in a user friendly interface
ECIP collaborators – trusted community members assigned as administrators to the registry.
Legacy ECIP Process:
The ECIP process begins with a new idea for Ethereum Classic. It is highly recommended that a single ECIP contain a single key proposal or new idea. Small enhancements or patches that don't affect consensus often don't need an ECIP and can be injected into the ETC development workflow with a patch submission to the corresponding ETC issue tracker. The more focused the ECIP, the more successful it tends to be. The ECIP editor reserves the right to reject ECIP proposals if they appear too unfocused or too broad. If in doubt, split your ECIP into several well-focused ones.
Each ECIP must have an Owner -- someone who writes the ECIP using the style and format described below, submits the smart contract to allow for discussion, and attempts to build community consensus around the idea. The ECIP champion (a.k.a. Owner) should first attempt to ascertain whether the idea is ECIP-able.
Vetting an idea publicly before going as far as writing an ECIP is meant to save the potential author time. Asking the ETC community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where ETC is used.
Once the owner has asked the ETC community as to whether an idea has any chance of acceptance, a draft ECIP should be registered on the ETC chain using a standard ECIP contract and the ECIP registry. This gives the author a chance to flesh out the draft ECIP to make properly formatted, of high quality, and to address initial concerns about the proposal.
Once submitted to the registry contract the ECIP will be reviewed by the ECIP collaborators for fitness, grammar, and purpose the ECIP registry will assign the ECIP a number, label it as Standards Track, Informational, or Process, give it status "Draft", and add it to the git repository. The ECIP editor will not unreasonably deny an ECIP. Reasons for denying ECIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the ETC philosophy.
The ECIP author may update the Draft as necessary in their smart contract. The ECIP itself should not be stored on chain.
Standards Track ECIPs consist of three parts, a design document, implementation and finally if warranted an update to the [https://github.com/ethereum/yellowpaper formal specification]. The ECIP should be reviewed and accepted before an implementation is begun, unless an implementation will aid people in studying the ECIP. Standards Track ECIPs must be implemented in at least two viable Ethereum clients before it can be considered Final.
ECIP authors are responsible for collecting community feedback on an ECIP before submitting it for review. However, wherever possible, long open-ended discussions should be avoided. Strategies to keep the discussions efficient include: having the ECIP author accept private comments in the early design phases, setting up a wiki page or git repository, etc. ECIP authors should use their discretion here. Whenever possible, set an end date or block number for final comment.
For an ECIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
Once a ECIP has been accepted, the implementations must be completed. When the implementation is complete in at least two viable clients and accepted by the community, the status will be changed to "Final". An update to the [https://github.com/ethereum/yellowpaper formal specification] should accompany the "Final" status change.
An ECIP can also be assigned status "Deferred". The ECIP author or editor can assign the ECIP this status when no progress is being made on the ECIP. Once a ECIP is deferred, the ECIP editor can re-assign it to draft status.
A ECIP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.
ECIPs can also be superseded by a different ECIP, rendering the original obsolete. This is intended for Informational ECIPs, where version 2 of an API can replace version 1.
Some Informational and Process ECIPs may also have a status of "Active" if they are never meant to be completed. E.g. ECIP 1 (this ECIP).
Each ECIP should have the following parts:
Title:
Author: <list of authors' real names and optionally, email address>
Description: < short description of the ECIP >
External Url:
Comment array: < string array for on contract comment tracking>
It occasionally becomes necessary to transfer ownership of ECIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred ECIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the ECIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the ECIP. We try to build consensus around a ECIP, but if that's not possible, you can always submit a competing ECIP.
If you are interested in assuming ownership of a ECIP, send a message asking to take over, addressed to both the original author and the ECIP editor. If the original author doesn't respond to email in a timely manner, the ECIP editor will make a unilateral decision (it's not like such decisions can't be reversed :).
The current ECIP editors are:
For each new ECIP that comes in, an editor does the following:
If the ECIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
Once the ECIP is ready for the repository, the ECIP editor will:
Assign a ECIP number (almost always just the next available number)
Assign the appropriate fields in the registry for type, tract, and status
Send email back to the ECIP author with next step.
Many ECIPs are written and maintained by developers with write access to the ETC codebase. The ECIP editors monitor ECIP changes, and correct any structure, grammar, spelling, or markup mistakes they see.
The editors don't pass judgment on ECIPs. They merely do the administrative & editorial part. Except for times like this, there's relatively low volume.
…
A reference ECIP smart contract can be found at [[ 0xd9605C12abc5Bfb83bbab80d286821D110dA2dD3 ]]
JSON-ABI:
[{"constant":false,"inputs":[{"name":"_title","type":"string"},{"name":"_author","type":"string"},{"name":"_description","type":"string"},{"name":"_extUrl","type":"string"},{"name":"_type","type":"string"}],"name":"startecip","outputs":[],"payable":true,"type":"function"},{"constant":true,"inputs":[],"name":"created","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"extUrl","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"constant":false,"inputs":[],"name":"kill","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"title","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"constant":false,"inputs":[],"name":"bailout","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"description","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_comment","type":"string"}],"name":"comment","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"author","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"anonymous":false,"inputs":[{"indexed":false,"name":"comment","type":"string"}],"name":"newComment","type":"event"}]
The ECIP master registry contract is located at [[ ]]
This document was derived heavily from [https://github.com/bitcoin/bips Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [https://www.python.org/dev/peps/ Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Classic Improvement Process, and should not be bothered with technical questions specific to ETC or the ECIP. Please direct all comments to the ECIP editors.
Title: Voting mechanism for Ethereum Classic
Author: Dexaran, [email protected]
Status: Draft
Created: 3-05.2017
The following describes a simple version of the governance system written in smart contracts, which is able to work completely on-chain without any interference from the outside world.
Decentralization is one of Ethereum Classic fundamentals. However, such aspects as "official reddit page", "official logo", "official twitter account", "official github repository" are completely centralized. There is a minority of the community who decide which voice should be considered official and which one is not. This all is governed by certain people.
It appears that only on-chain decisions can be really decentralized and unbiased. As a result, it is necessary to implement an on-chain system that allows members of the community to cast their votes, thus participate in decision-making.
https://github.com/Dexaran/Onchain-Governance-System/blob/master/vote_system.sol
Title: EthereumClassic VM 2.0
Author: Dexaran, [email protected]
Status: Draft
Type: EVM
Created: 11-04.2017
Resolution: ethereum/EIPs#48
This ECIP proposes upgrading the VM by converting to use a subset of Webassembly (Wasm). Wasm is a new Assembly standard being built for the web. The main advantage of using wasm is performance (both speed and size). The main disadvantage would be the need to port our existing infrastructure to use a new ISA. Most of this ECIP is taken from Wasm's design docs which should be referenced for futher details.
Ethereum is planning to upgrade its VM to Wasm. I don't see any reasonable arguments against doing it so I think we need to do the same.
I found it very important to keep a minimal difference between Ethereum and Ethereum Classic in technical aspects as possible because of it will:
Read issue #48
The first ETH Hard fork in the metropolis fork will be the Byzantium release. will contain the following, however, not all are applicable to ETC:
A section has been added to the wiki page to indicate support of proposals
1 Epoch (30,000 blocks)
5,010,000 (Epoch 167)
Decay Percentage | Miner Decay Amount | Uncle Decay Amount | Years to Decay | Estimated Supply (Current Reward) | Estimated Supply (1.5% Growth Reward) | Block Height Reward Ends |
---|---|---|---|---|---|---|
0.5000% | 0.025000 | 0.002500 | 5.236872146 | 130,071,034.98 | 130,073,443.73 | 11,010,000 |
0.2500% | 0.012500 | 0.001250 | 8.090753425 | 161,716,038.24 | 161,720,708.59 | 17,010,000 |
0.1250% | 0.006250 | 0.000625 | 13.79851598 | 225,006,044.76 | 225,018,362.75 | 29,010,000 |
0.0625% | 0.003125 | 0.0003125 | 25.2140411 | 351,586,057.80 | 351,991,724.60 | 53,010,000 |
5 ETC
0.5 ETC
ETH recently introduced the REVERT opcode to allow for a transaction failure that does not consume all gas. As a side-effect they've had the status
element of a transaction receipt start actually returning a succeeded/failed status; rather than null
as seen prior to their Byzantium fork, and on the ETC blockchain.
While ETC does not necessarily need EIP-658 to function adequately I believe it would be nice to have so that those used to having status
available on the ETH chain also find it as they expect on ETC.
Concerns:
status
being null
, although this may be a rare occurrence.Reference: http://eips.ethereum.org/EIPS/eip-658
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.