Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nightshade v3 -- New sharding #928

Open
wants to merge 115 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@ilblackdragon
Copy link
Member

commented May 1, 2019

Initial implementation Nightshade sharding algorithm with heaviest chain implementation.

Code split into:

  • core/ <- core cargos that are used across chain and runtime, but don't have own any logic.
    specifically, it's primitives, protos and storage.
  • runtime/ <- runtime logic, this includes wasm, validating tx and state transition itself.
  • chan/ <- chain and everything about it - network, rpc, configuration.

Chain is split:

  • chain/ <- logic of building / reorging / storing / updating the chain of "main" blocks.
    Uses RuntimeAdapter as an interface to the actual runtime. Has a test util with KVRuntime that mocks runtime adapter.
  • client/ <- main actor that produces blocks, syncs, communicates with network and responds to network and RPC requests. Additionally has ViewClientActor to serve queries/block requests in parallel to ClientActor.
  • pool/ <- very light tx pool that is suppose to order valid tx and keep track of them as blocks gets accepted and re-orged (tx pool reorg is not implemented yet).
  • network/ <- PeerManager actor is the main actor that accepts connections and creates outbound connections. Peer is a individual connection actor. It handles accepting network messages and routing them to Client (or in future to other actors of the system). Network in types.rs defines protocol of messaging between Peer & PeerManager <-> ClientActor.
  • jsonrpc/ <- actix-web web server, that accepts requests and passes them to ClientActor or ViewClientActor.

And at the end chain/near/ <- puts it all together into one binary. (Should just move to src/?)

  • config.rs contains a GenesisConfig that defines initial state of the runtime, Config which is combination of configs of all of the subsystem that then gets split into appropriate pieces.
  • runtime.rs implements near_chan::RuntimeAdapter for real runtime.

Things that are in progress on @SkidanovAlex side in separate PR:

  • Chunk Manager actor - worker that will spin up / spin down chunk actors
  • Chunk Actor - per chunk actor that produces chunks or accepts incoming ones. Tx pool will be moved there and tx execution will be happening here as well.
  • Connecting Chunks to Client, pretty much allowing block to be accepted only if the all chunks given nodes cares about are accepted.

Benchmarking:

  • 1 BP node: ~650-700 mTPS with nearmint/tools/bench/ tool.
  • 1 BP node: ?? mTPS with loadtester tool.

mTPS -- money transfer TPS.

SkidanovAlex and others added some commits Apr 23, 2019

ilblackdragon added some commits May 16, 2019

Simple intergration tests pass (2, 4, 7 nodes): moved out PeerStore i…
…nto separate file, fixed retrieving blocks wasn't sending the last one, sync headers wasn't validating them properly
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.