This repository is for draft, planned and enforced protocol improvement specifications for the Ellaism blockchain.
In this repository, we focus on specifications that influence or are related to Ellaism consensus or applications at large scale (like the JSONRPC definitions). For application-layer specifications, consider to submit it to Cross-Ethereum Specification Repository.
Ellaism is a decentralized blockchain, and its decision-making process also needs to be decentralized. This specification repository proposes that we use the swarm methodology for handling consensus-related decisions. Everyone is free to take or follow any initiative, or take no action at all, and nobody may tell anybody else what to do or what initiative to follow or not to follow. Everyone owns the Ellaism blockchain, and nobody shall need to ask permissions. And this is one of the important property while designing or modifying the process for this repository.
In consensus, it is often important to understand what others try to do when making our own decisions. We aim to use this repository to help this situation, by providing statistics (developer and company supports, CarbonVote and MinerVote) of what others claim they would decide to do, and to resolve dispute if two different parties have similar goals.
We use a modified version of an informal IETF-like process RFC 2026. The process works like below:
- A new specification or protocol improvement proposal is sent in a
pull request. The editor checks and helps the author to move the
specification into an acceptable quality. In this case, no
subjective judgement shall happen. After that, the specification is
merged in Proposed state. In this process, the specification
gets its RFC number in the format of
ella-$year-$number-$feature. - Once a specification is merged, the editor is responsible for collecting statistics of positive/negative support indications and transparently display them to readers. This can include technical discussion threads, developer and company support indications, voting results from coin owners and miners, and others.
- Once an implementation for a particular specification exists, the specification is moved to Draft state.
- From here, any developer or company can claim to deploy a consensus-related specification. In this case, the editor shall move the specification to Planned state, and transparently indicate support level (Majority Fork, Chain Split, or Minority Fork).
- Once a fork happens, and the forked chain survives, a specification
is moved to Enforced state. If chain split happened, it should
also incidate which particular chain this specification is
on. Specifications in this state also get a STD number in the format
of
ella-std-$number-$feature. - By default, if chain split happens, this specification repository would support both chains, unless one of the chains decided to abandon this process.
- If a specification cannot be deployed by itself but relies on other specifications, then it would only move to Draft state following the first specification that it relies.
The current editors are Ellaismer <ellaismer@protonmail.ch> and Wei Tang <hi@that.world>.
| Number | Title | Author | State | Discussion |
|---|---|---|---|---|
| 2017-0001 | Generalized Account Versioning Scheme for Hard Fork | Wei Tang | Proposed | #4 |
| 2018-0001 | Alternative Scheme of Precompiled Contract Versioning for Hard Fork | Wei Tang | Proposed | #5 |
| 2018-0002 | WebAssembly Smart Contracts | "ellaismer" | Proposed | #10 |
| 2018-0003 | Hardfork Meta: WebAssembly | "ellaismer" | Proposed | #11 |
| 2018-0004 | Hardfork Meta: Byzantium | "ellaismer" | Proposed | #12 |
| 2018-0005 | Reward Structure Adjustment to Make a Community Fund | Sooraj Singh | Draft | #13 |