Skip to content
This repository has been archived by the owner on Jul 18, 2020. It is now read-only.

Prysmatic Labs Request for Funding (Sharding) #36

Merged
merged 1 commit into from
Jun 11, 2018

Conversation

rauljordan
Copy link
Contributor

@rauljordan rauljordan commented Apr 13, 2018

Request for Nest membership and funding (#35)

Team name: Prysmatic Labs

Proof of concept / research whitepaper: https://github.com/prysmaticlabs/geth-sharding

Funds Raised: $275k

Burn rate: ~$32k/month

Legal structure: LLC partnership filed in Illinois - Prysmatic Labs LLC

Team and roadmap

Proposal

(Please review our extensive documentation and subscribe to our communication channels for updates on the following scheme, as it is heavily undergoing changes due to research updates)

We are implementing the first, working version of sharding for the geth client through a strong emphasis on development sprints and results. Our strong suit is being able to create effective, tested code for the community to explore. We are actively developing the project here and are hard at work on our first milestone as detailed in our comprehensive reference docs. We communicate on a day-to-day basis via our Gitter channel here.

Our work is heavily based out of and in collaboration with Py-EVM and the ETHResearch team. The basic idea of our initial implementation is as follows:

The ETHResearch team has proposed the following long-term roadmap for sharding:

  • Phase 1: Basic sharding without EVM
    • Blob shard without transactions
    • Proposers
    • Proposal commitments
    • Collation availability challenges
  • Phase 2: EVM state transition function
    • Full nodes only
    • Asynchronous cross-contract calls only
    • Account abstraction
    • eWASM
    • Archive accumulators
    • Storage rent
  • Phase 3: Light client state protocol
    • Executors
    • Stateless clients
  • Phase 4: Cross-shard transactions
    • Internally-synchronous zones
  • Phase 5: Tight coupling with main chain security
    • Data availability proofs
    • Casper integration
    • Internally fork-free sharding
    • Manager shard
  • Phase 6: Super-quadratic sharding
    • Load balancing
      To concretize these phases, we will be releasing our implementation of sharding for the geth client as follows:

The Ruby Release: Local Network

Our current work is focused on creating a localized version of phase 1, quadratic sharding that would include the following:

  • A minimal, collator client system that will interact with a Sharding Manager Contract on a locally running geth node
  • Ability to deposit ETH into the SMC through the command line and to be selected as a collator by the local SMC in addition to the ability to withdraw the ETH staked
  • A proposer client and cryptoeconomic incentive system for proposer nodes to listen for pending tx’s, create collations, and submit them along with a deposit to collator nodes in the network
  • Ability to inspect the shard states and visualize the working system locally through the command line

Proposers and collators will interact through a local file system, as peer to peer networking considerations for sharding are still under heavy research.

We will forego several security considerations that will be critical for testnet and mainnet release for the purposes of demonstration and local network testing as part of the Ruby Release.

The Sapphire Release: Ropsten Testnet

Part 1 of the Sapphire Release will focus around getting the Ruby Release polished enough to be live on an Ethereum testnet and manage a set of collators effectively processing collations through the on-chain SMC. This will require a lot more elaborate simulations around the safety of the randomness behind the collator assignments in the SMC. Furthermore we need to pass stress testing against DDoS and other sorts of byzantine attacks. Additionally, it will be the first release to have real users proposing collations concurrently along with collators that can accept these proposals and add their headers to the SMC.

Part 2 of the Sapphire Release will focus on implementing state execution and defining the State Transition Function for sharding on as an extension to the Ruby Release.

The Diamond Release: Ethereum Mainnet

The Diamond Release will reconcile the best parts of the previous releases and deploy a full-featured, cross-shard transaction system through a Sharding Manager Contract on the Ethereum mainnet. As expected, this is the most difficult and time consuming release on the horizon for Prysmatic Labs. We plan on growing our community effort significantly over the first few releases to get all hands-on deck preparing for real ether to be staked in the SMC.

The Diamond Release should be considered the production release candidate for sharding Ethereum on the mainnet.

Prysmatic Labs will begin by focusing its implementation entirely on the Ruby Release from our roadmap. We plan on being as pragmatic as possible to create something that can be locally run by any developer as soon as possible. Our initial deliverable will center around a command line tool that will serve as an entrypoint into a collator client that allows staking, a proposer client that allows for simple state execution and creation of collation proposals, and processing collations through on-chain verification via the Sharding Manager Contract.

Our implementation revolves around 4 core components:

  • A locally-running geth node that spins up an instance of the Ethereum blockchain and mines on the Proof of Work chain
  • A Sharding Manager Contract (SMC) that is deployed onto this blockchain instance
  • A collator client that connects to the running geth node through JSON-RPC, provides bindings to the SMC, and listens for incoming collation proposals
  • A proposer client that is tasked with processing pending tx's into collations that are then submitted to collators via a local filesystem for the purposes of simplified, phase 1 implementation. In phase 1, proposers do not execute state, but rather just serialize pending tx data into possibly valid/invalid data blobs.

Our Work So Far

Our initial implementation works through a simple command line arguments that will allow a user running the local geth node to deposit ETH into the SMC and join as a collator that is automatically assigned to a certain period. You can try it out and run it by following the instructions on our project README here!

Once again, review our extensive documentation and subscribe to our communication channels for updates on this scheme, as it is heavily undergoing changes due to research updates.

Team Communication and Updates

We communicate our updates through the following channels:

Our Medium Page for Prysmatic Labs
Our Newsletter: Opt-in Through Our Website
Our Official Twitter @prylabs
Our Gitter Channel: prysmaticlabs/geth-sharding

@CLAassistant
Copy link

CLAassistant commented Apr 13, 2018

CLA assistant check
All committers have signed the CLA.

Copy link
Contributor

@mariapao mariapao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @rauljordan we have been reviewing your application and getting familiar with the project. Blockchain scalability is a key technical challenge that needs to be solved for blockchain-based apps to reach mass adoption.

We don't only like the technical work that you guys are doing but also the strong focus on transparency and community of the project. Prysmatic Labs is a fit for nest and therefore we have decided to approve your request for funding.

Next steps: I'll send you an email to schedule a call this week to go over some minor details to close this process and discuss the payouts/disbursements of the grant.

Welcome to nest! :)

@mariapao mariapao merged commit c4a74a3 into aragon:master Jun 11, 2018
luisivan pushed a commit that referenced this pull request Jun 1, 2020
Prysmatic Labs Request for Funding (Sharding)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants