Files
pezkuwi-subxt/cumulus
Sam Elamin f2dc402cec add warp_sync_params (#1909)
* wait for relay chain to sync then get parachain header

* Spawn new thread to wait for the target block

* second round of comments from the PR on substrate

* third round of pr comments

* add zombienet tests

* rebase issues

* refactor tests based on pr comments

* rebase issues

* pr comments

* passing zombienet test

* cargo +nightly fmt

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* use cargo lock from master

* pr comments

* cargo fmt

* use finalised block instead of best block

* use import notification stream

* rebase changes

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/relay-chain-interface/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/relay-chain-interface/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* pr comments

* use new file names

* db snaphots moved to google cloud storage

* Update client/network/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Bastian Köcher <git@kchr.de>

* Update client/service/src/lib.rs

Co-authored-by: Sebastian Kunert <skunert49@gmail.com>

* pr comments

* Update zombienet/tests/0007-full_node_warp_sync.toml

Co-authored-by: Sebastian Kunert <skunert49@gmail.com>

* Update zombienet/tests/0007-full_node_warp_sync.toml

Co-authored-by: Sebastian Kunert <skunert49@gmail.com>

* Scenario 1

Parachain node and in-node relay chain both start with --sync warp. This ensures that the waiting logic works as expected.

Scenario 2
Parachain node starts with warp sync, relay chain points to a node already synced up

scenario 3
Parachain node starts with warp sync, relay chain points to a node that uses warp sync

* Use test-parachain

* use test-parachain chainspecs

* remove relay chain spec as it is no longer required

* add back relaychain spec file

* pr comments

* Upload snapshots to google cloud

* Update zombienet/tests/0007-prepare-warp-sync-db-snapshot.md

Co-authored-by: Sebastian Kunert <skunert49@gmail.com>

* update documentation

* Fix snapshot URLs

* use master lock file

* add finalized_block_hash

* Patch diener for CI

* Bump Zombienet

* Add 0007 zombienet test

* Bump zombienet

* Revert "Patch diener for CI"

This reverts commit 9ece6c9fc9b17058b61cd7e9dee29d3a9af87841.

* merge fixes

* use master lock file

* Update Substrate & Polkadot

---------

Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>
Co-authored-by: Sebastian Kunert <skunert49@gmail.com>
Co-authored-by: Bastian Köcher <info@kchr.de>
2023-02-14 19:15:43 +00:00
..
2023-02-14 19:15:43 +00:00
2023-02-14 19:15:43 +00:00
2023-02-14 19:15:43 +00:00
2023-02-14 19:15:43 +00:00
2020-05-18 17:17:34 +02:00
2022-08-02 13:12:34 +00:00
2023-02-14 19:15:43 +00:00
2023-02-14 19:15:43 +00:00
2021-06-02 09:00:18 +02:00

Cumulus ☁️

Doc

This repository contains both the Cumulus SDK and also specific chains implemented on top of this SDK.

Cumulus SDK

A set of tools for writing Substrate-based Polkadot parachains. Refer to the included overview for architectural details, and the Connect to relay and parachain tutorials for a guided walk-through of using these tools.

It's easy to write blockchains using Substrate, and the overhead of writing parachains' distribution, p2p, database, and synchronization layers should be just as low. This project aims to make it easy to write parachains for Polkadot by leveraging the power of Substrate.

Cumulus clouds are shaped sort of like dots; together they form a system that is intricate, beautiful and functional.

Consensus

parachain-consensus is a consensus engine for Substrate that follows a Polkadot relay chain. This will run a Polkadot node internally, and dictate to the client and synchronization algorithms which chain to follow, finalize, and treat as best.

Collator

A Polkadot collator for the parachain is implemented by the polkadot-parachain binary (previously called polkadot-collator).

Installation and Setup

Before building Cumulus SDK based nodes / runtimes prepare your environment by following Substrate installation instructions.

To launch a local network, you can use zombienet for quick setup and experimentation or follow the manual setup.

Zombienet

We use Zombienet to spin up networks for integration tests and local networks. Follow these installation steps to set it up on your machine. A simple network specification with two relay chain nodes and one collator is located at zombienet/examples/small_network.toml.

Which provider should I use?

Zombienet offers multiple providers to run networks. Choose the one that best fits your needs:

  • Podman: Choose this if you want to spin up a network quick and easy.
  • Native: Choose this if you want to develop and deploy your changes. Requires compilation of the binaries.
  • Kubernetes: Choose this for advanced use-cases or running on cloud-infrastructure.

How to run

To run the example network, use the following commands:

# Podman provider
zombienet --provider podman spawn ./zombienet/examples/small_network.toml

# Native provider, assumes polkadot and polkadot-parachains binary in $PATH
zombienet --provider native spawn ./zombienet/examples/small_network.toml

Manual Setup

Launch the Relay Chain

# Clone
git clone https://github.com/paritytech/polkadot
cd polkadot

# Compile Polkadot with the real overseer feature
cargo build --release --bin polkadot

# Generate a raw chain spec
./target/release/polkadot build-spec --chain rococo-local --disable-default-bootnode --raw > rococo-local-cfde.json

# Alice
./target/release/polkadot --chain rococo-local-cfde.json --alice --tmp

# Bob (In a separate terminal)
./target/release/polkadot --chain rococo-local-cfde.json --bob --tmp --port 30334

Launch the Parachain

# Clone
git clone https://github.com/paritytech/cumulus
cd cumulus

# Compile
cargo build --release --bin polkadot-parachain

# Export genesis state
./target/release/polkadot-parachain export-genesis-state > genesis-state

# Export genesis wasm
./target/release/polkadot-parachain export-genesis-wasm > genesis-wasm

# Collator1
./target/release/polkadot-parachain --collator --alice --force-authoring --tmp --port 40335 --ws-port 9946 -- --execution wasm --chain ../polkadot/rococo-local-cfde.json --port 30335

# Collator2
./target/release/polkadot-parachain --collator --bob --force-authoring --tmp --port 40336 --ws-port 9947 -- --execution wasm --chain ../polkadot/rococo-local-cfde.json --port 30336

# Parachain Full Node 1
./target/release/polkadot-parachain --tmp --port 40337 --ws-port 9948 -- --execution wasm --chain ../polkadot/rococo-local-cfde.json --port 30337

Register the parachain

image

Statemint 🪙

This repository also contains the Statemint runtime (as well as the canary runtime Statemine and the test runtime Westmint). Statemint is a system parachain providing an asset store for the Polkadot ecosystem.

Build & Launch a Node

To run a Statemine or Westmint node (Statemint is not deployed, yet) you will need to compile the polkadot-parachain binary:

cargo build --release --locked -p polkadot-parachain

Once the executable is built, launch the parachain node via:

CHAIN=westmint # or statemine
./target/release/polkadot-parachain --chain $CHAIN

Refer to the setup instructions to run a local network for development.

Contracts 📝

See the contracts-rococo readme for details.

Bridge-hub 📝

See the bridge-hubs readme for details.

Rococo 👑

Rococo is becoming a Community Parachain Testbed for parachain teams in the Polkadot ecosystem. It supports multiple parachains with the differentiation of long-term connections and recurring short-term connections, to see which parachains are currently connected and how long they will be connected for see here.

Rococo is an elaborate style of design and the name describes the painstaking effort that has gone into this project.

Build & Launch Rococo Collators

Collators are similar to validators in the relay chain. These nodes build the blocks that will eventually be included by the relay chain for a parachain.

To run a Rococo collator you will need to compile the following binary:

cargo build --release --locked -p polkadot-parachain

Otherwise you can compile it with Parity CI docker image:

docker run --rm -it -w /shellhere/cumulus \
                    -v $(pwd):/shellhere/cumulus \
                    paritytech/ci-linux:production cargo build --release --locked -p polkadot-parachain
sudo chown -R $(id -u):$(id -g) target/

If you want to reproduce other steps of CI process you can use the following guide.

Once the executable is built, launch collators for each parachain (repeat once each for chain tick, trick, track):

./target/release/polkadot-parachain --chain $CHAIN --validator

Parachains

The network uses horizontal message passing (HRMP) to enable communication between parachains and the relay chain and, in turn, between parachains. This means that every message is sent to the relay chain, and from the relay chain to its destination parachain.

Containerize

After building polkadot-parachain with cargo or with Parity CI image as documented in this chapter, the following will allow producing a new docker image where the compiled binary is injected:

./docker/scripts/build-injected-image.sh

Alternatively, you can build an image with a builder pattern:

docker build --tag $OWNER/$IMAGE_NAME --file ./docker/polkadot-parachain_builder.Containerfile .

You may then run your new container:

```bash
docker run --rm -it $OWNER/$IMAGE_NAME --collator --tmp --execution wasm --chain /specs/westmint.json