Introduction and onboarding process for new developers

Are you interested in making Ethereum faster and more mainstream?

If so, it's best to read this sharding introduction first.

Tasks:

• learn Rust.
• Work on tasks in the projects and issues.
• Start building sharding and Ethereum 2.0 in this repo, which involves:
  • Learn about sharding here.
  • Read the codebase, issues and projects.
  • Use a test-driven development approach to aim for 100% test coverage at all times.
  • Implement the latest specification and plans which will be updated in issue #13.
  • Research how to implement a sharding networking protocol, also refer to libp2p
  • Research and implement sharding syncing methods.
  • Contribute to research for further developments in the subsequent phases of the sharding roadmap.
• (ongoing operation): keep track of major Ethereum Research topics, particularly those that are on the sharding roadmap. But probably only do this on an as-needed basis once you get up to these topics in the development pipeline.
• raise funds as per issue 18.

Non-essential tasks

• Retired: Read the draft phase 1 sharding spec.
• Possibly further familiarize with the sharding implementation on top of PyEVM here. Since they are ahead in the development of sharding, it will be useful as a reference implementation, as well as because of Python's readability.
• Possibly further familiarize with Parity. While it's probably best to understand it in detail that may not be needed. Having an idea of the overall design/structure may be sufficient. However, note that the EVM execution engine in phase 2 may be almost completely rewritten and abstracted to allow multiple execution engines.
• This is not a high immediate priority as others have already tested Parity with EWasm: further familiarise with EWasm; and
• This is not essential according to the draft phase 1 sharding spec since as mentioned, the EVM execution engine may be almost completely rewritten and is abstracted to potentially allow multiple execution engines that are significantly different**: read the Yellow Paper (this is necessary for building a client from scratch, and important for developing one that may be integrated with an existing client like Parity, although with Ethereum 2.0 the EVM may be almost completely rewritten).
• This is not essential for phase 1 sharding: read about the stateless client concept.
• Possibly not essential (could wait for the draft phase 1 spec to be updated and continue building): familiarize with the (now depecrated) Python sharding repo here (a doc is available here). It may still be useful to refer to how the functions are implemented.
• This is not essential but it is helpful to know for development: learn about abstract programming language features.

At the moment I'm working pro-bono, living off my savings. Once funds are raised or a grant is given by the Ethereum Foundation a multisig that has been set up can be used to pay developers. Compensation to developers at this stage can't be offered, as it would depend on some form of revenue, which isn't available at this stage. However, revenue will be more likely to be obtained the more a product is demonstrated. All are welcome to contribute, in the spirit of open-source code and friendly collaboration. If revenue is obtained it will be shared accordingly and fairly with a budget. A more formal organization could be set up, e.g. controlled in a similar fashion to how the Ethereum Foundation is run. (A grant from the Ethereum Foundation has been applied for, as per this blog post.) It's probably best to have an MVP, or alpha or beta release, before actively raising funds. There are alternatives for revenue, e.g. EIP 908 and a DAII as detailed in issue 18.