WIP on sharding and Ethereum 2.0 with enshrined-in-consensus data availability and Rust: a fast, safe, concurrent and practical programming language.
This repo contains code that is implemented to a deprecated sharding specification (notaries and proposers with a sharding manager contract), as well as previous code for collators and proposers. The latest specification is not finalised. Currently as of July 31 2018 work is underway on the networking aspect, with gossipsub. Note also that for a more up-to-date, but still outdated, implementation of the first version of the shasper (sharding + Casper) specification, see https://github.com/sigp/lighthouse.
We were working on a sharding implementation for Ethereum with the Rust programming language, which is fast, safe and concurrent. See also this "Why Rust?" post by ParityTech and the Rust book, 2018 edition to learn Rust. Sharding plans to scale Ethereum, with the current goal of 100k TPS (see the latest spec above for details).
We're implementing sharding according to collaboration with Ethereum research at https://ethresear.ch and other teams, which includes tasks outlined in the projects and issues. In the first phase of the roadmap, we only enshrine data availabilty, without execution, thus abstracting execution, and enabling faster and simpler implementation, with each phase being useful. For further information, please refer to our wiki, which includes an introductory video, background info, contributing info, and more. The plan is for this codebase to eventually be integrated into the Rust implementation of the EVM, Parity. diamond_drops is used as the name of the cargo crate for compatibility, and so the repo name also follows this.
Contents
For an introduction to Ethereum, see https://ethereum.org/ or https://github.com/ethereum/wiki/wiki/Ethereum-introduction. For information on sharding and implementations, refer to here.
-
Update Rust
rustup update
-
Install Rust Formatter
rustup component add rustfmt-preview
-
Install Cargo-make Task runner and build tool
cargo install --force cargo-make
-
Execute specific task runner flow. Default is Makefile.toml
cargo make --makefile tasks.toml <TASK_NAME>
- Command help
cd ~/diamond_drops; # you may wish to rename this to dod for convenience
cargo run -- --help- Sub-command "mode" help
cargo run -- mode --help-
Fork the repository https://github.com/Drops-of-Diamond/diamond_drops
-
Clone your fork of the repository (replace below with your Github username):
git clone https://github.com/<USERNAME>/diamond_drops; cd diamond_drops
-
Add the "upstream" repository to your remotes and show your list of remotes verbosely
git remote add upstream https://github.com/Drops-of-Diamond/diamond_drops; git remote --verbose -
Change from the "master" branch to the "develop" branch to see the latest features that are being integrated but are not officially ready for production
Click on the Twitter badge above.
-
Proposer Mode
cargo make p
-
Notary Mode
cargo make n
-
Both Proposer and Notary Modes
cargo make b
-
All above
cargo make all
-
All above with collation example
cargo make all-with-collation
-
Run all tests (unit and integration tests for main package and libraries)
cargo make test-all
-
Watch all tests (polls continuously for code changes during development, automatically running tests, and reports issues)
cargo make build; cargo install cargo-watch; cargo make watch;
cargo make docs-
View UML with Google Chrome, Mozilla Firefox, or Brave browser
cargo make uml-default-recommended; # The below options will only work for Mac OS X, otherwise use the above. cargo make uml-chrome; cargo make uml-firefox; cargo make uml-brave;
- On a Mac you can also use
ls /Applications; open SVG-COMPATIBLE-APPLICATION ./diagrams/ml.svg. - Optionally create a Pull Request to update Makefile.toml or open the diagrams/ml.svg file manually after building with the graphviz dependency for MML or an alternative installed.
- On a Mac you can also use
See this wiki article here.
This is WIP, pre-release software. It is planned to be integrated into Parity. There is a lot of research available on security alone; for example, CTRL+F "security" here or search in the pages here
Send a donation to jamesray.eth. All contributors will be paid according to their contributions and timesheets, once funds are received. As an example, my timesheet is available here. A multisig will be used when other developers are contributing full-time. Funds are needed to pay researchers and developers a reasonable hourly rate or salary, which may fairly be quite high due to the time required to learn about Ethereum, sharding, etc.; and because of the scarcity of those interested and qualified to be able to contribute in the blockchain industry. For more details see this issue.<!omitting until other regular contributors are well established, although I still vouch that contributions will be paid for according to assessing hours on timesheets--our multi-sig wallet at 0x6D446f9545dBC380A6BBDde8A285A7A8030D4381-->
See here for information. There is a lot of work to do in the sharding roadmap.
After comparing languages such as Rust, C++, Go, Javascript and Python, as well as implementations (e.g. Parity, cppethereum, Go-ethereum, ethereumJS and Py-EVM), Rust is most preferable, while I haven't tried being a user much of other implementations, so I can't comment on a comparison. Rust has advantages such as safety, concurrency, practicality, better memory safety (thanks to its ownership rules), zero-cost abstractions, and support for functional and imperative-procedural paradigms.