pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-13 23:21:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

Reorganising the repository - external renames and moves (#4074)

Browse Source 
* Adding first rough ouline of the repository structure

* Remove old CI stuff

* add title

* formatting fixes

* move node-exits job's script to scripts dir

* Move docs into subdir

* move to bin

* move maintainence scripts, configs and helpers into its own dir

* add .local to ignore

* move core->client

* start up 'test' area

* move test client

* move test runtime

* make test move compile

* Add dependencies rule enforcement.

* Fix indexing.

* Update docs to reflect latest changes

* Moving /srml->/paint

* update docs

* move client/sr-* -> primitives/

* clean old readme

* remove old broken code in rhd

* update lock

* Step 1.

* starting to untangle client

* Fix after merge.

* start splitting out client interfaces

* move children and blockchain interfaces

* Move trie and state-machine to primitives.

* Fix WASM builds.

* fixing broken imports

* more interface moves

* move backend and light to interfaces

* move CallExecutor

* move cli off client

* moving around more interfaces

* re-add consensus crates into the mix

* fix subkey path

* relieve client from executor

* starting to pull out client from grandpa

* move is_decendent_of out of client

* grandpa still depends on client directly

* lemme tests pass

* rename srml->paint

* Make it compile.

* rename interfaces->client-api

* Move keyring to primitives.

* fixup libp2p dep

* fix broken use

* allow dependency enforcement to fail

* move fork-tree

* Moving wasm-builder

* make env

* move build-script-utils

* fixup broken crate depdencies and names

* fix imports for authority discovery

* fix typo

* update cargo.lock

* fixing imports

* Fix paths and add missing crates

* re-add missing crates
This commit is contained in:
Benjamin Kampmann
2019-11-14 21:51:17 +01:00
committed by Bastian Köcher
parent becc3b0a4f
commit 60e5011c72
809 changed files with 7801 additions and 6464 deletions
Download Patch File Download Diff File Expand all files Collapse all files
substrate/docs/CODEOWNERS
+68
View File
@@ -0,0 +1,68 @@
# Lists some code owners.
#
# A codeowner just oversees some part of the codebase. If an owned file is changed then the
# corresponding codeowner receives a review request. An approval of the codeowner is
# not required for merging a PR though.
#
# **This is pretty much an experiment at the moment**. Feel free to remove yourself at any time if
# you do not want to receive review requests any longer.
#
# For details about syntax, see:
# https://help.github.com/en/articles/about-code-owners
# But here are some important notes:
#
# - Glob syntax is git-like, e.g. `/core` means the core directory in the root, unlike `core` which
# can be everywhere.
# - Multiple owners are supported.
# - Either handle (e.g, @pepyakin) or email can be used. Keep in mind, that handles might work better because they
# are more recognizable on GitHub, you can use them for mentioning unlike an email.
# - The latest matching rule, if multiple, takes precedence.
# Wasm execution and the wasm side of Substrate Runtime Interface
/core/executor/ @pepyakin
/core/sr-io/without_std.rs @pepyakin
/core/sr-std/without_std.rs @pepyakin
# Sandboxing capability of Substrate Runtime
/core/sr-sandbox/ @pepyakin
/core/primitives/src/sandbox.rs @pepyakin
# Transaction pool
/core/transaction-pool/ @tomusdrw
# Offchain
/core/offchain/ @tomusdrw
/sr-io/src/offchain/ @tomusdrw
# Everything that has RPC in it
/core/rpc/ @tomusdrw
/node/rpc/ @tomusdrw
/node/rpc-client/ @tomusdrw
/core/rpc-servers/ @tomusdrw
# GRANDPA, BABE, consensus stuff
/paint/babe/ @andresilva @DemiMarie-parity
/paint/grandpa/ @andresilva @DemiMarie-parity
/core/finality-grandpa/ @andresilva @DemiMarie-parity
/core/consensus/babe/ @andresilva @DemiMarie-parity
/core/consensus/slots/ @andresilva @DemiMarie-parity
# Contracts
/paint/contracts/ @pepyakin @thiolliere @jimpo
/paint/contracts/src/wasm/runtime.rs @Robbepop
# Inflation points
/paint/staking/src/inflation.rs @thiolliere
# NPoS and Governance
/paint/staking/ @kianenigma
/paint/election/ @kianenigma
# End to end testing of substrate node
/node/executor/ @kianenigma
# Transaction weight stuff
/core/sr-primitives/weights.rs @kianenigma
# Support crates
/paint/support/ @thiolliere @kianenigma
substrate/docs/CODE_OF_CONDUCT.adoc
+50
View File
@@ -0,0 +1,50 @@
= Contributor Covenant Code of Conduct
== Our Pledge
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
== Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
=== Facilitation, Not Strongarming
We recognize that this software is merely a tool for users to create and maintain their blockchain of preference. We see that blockchains are naturally community platforms with users being the ultimate decision makers. We assert that good software will maximize user agency by facilitate user-expression on the network. As such:
* This project will strive to give users as much choice as is both reasonable and possible over what protocol they adhere to; but
* use of the project's technical forums, commenting systems, pull requests and issue trackers as a means to express individual protocol preferences is forbidden.
== Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
== Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
== Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at admin@parity.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
== Attribution
This Code of Conduct is adapted from the http://contributor-covenant.org[Contributor Covenant], version 1.4, available at http://contributor-covenant.org/version/1/4
substrate/docs/CONTRIBUTING.adoc
+78
View File
@@ -0,0 +1,78 @@
= Contributing
The `Substrate` project is an **OPENISH Open Source Project**
== What?
Individuals making significant and valuable contributions are given commit-access to a project to contribute as they see fit. A project is more like an open wiki than a standard guarded open source project.
== Rules
There are a few basic ground-rules for contributors (including the maintainer(s) of the project):
. **No `--force` pushes** or modifying the master branch history in any way. If you need to rebase, ensure you do it in your own repo.
. **Non-master branches**, prefixed with a short name moniker (e.g. `gav-my-feature`) must be used for ongoing work.
. **All modifications** must be made in a **pull-request** to solicit feedback from other contributors.
. A pull-request *must not be merged until CI* has finished successfully.
. Contributors should adhere to the https://wiki.parity.io/Substrate-Style-Guide[house coding style].
== Merge Process
Merging pull requests once CI is successful:
. A PR needs to be reviewed and approved by project maintainers unless:
- it does not alter any logic (e.g. comments, dependencies, docs), then it may be tagged https://github.com/paritytech/substrate/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+label%3AA2-insubstantial[`insubstantial`] and merged by its author once CI is complete.
- it is an urgent fix with no large change to logic, then it may be merged after a non-author contributor has approved the review once CI is complete.
. Once a PR is ready for review please add the https://github.com/paritytech/substrate/pulls?q=is%3Apr+is%3Aopen+label%3AA0-pleasereview[`pleasereview`] label. Generally PRs should sit with this label for 48 hours in order to garner feedback. It may be merged before if all relevant parties had a look at it.
. If the first review is not an approval, swap `A0-pleasereview` to any label `[A3, A7]` to indicate that the PR has received some feedback, but needs further work. For example. https://github.com/paritytech/substrate/labels/A3-inprogress[`A3-inprogress`] is a general indicator that the PR is work in progress and https://github.com/paritytech/substrate/labels/A4-gotissues[`A4-gotissues`] means that it has significant problems that need fixing. Once the work is done, change the label back to `A0-pleasereview`. You might end up swapping a few times back and forth to climb up the A label group. Once a PR is https://github.com/paritytech/substrate/labels/A8-looksgood[`A8-looksgood`], it is ready to merge.
. PRs that break the external API must be tagged with https://github.com/paritytech/substrate/labels/B2-breaksapi[`breaksapi`], when it changes the SRML or consensus of running system with https://github.com/paritytech/substrate/labels/B3-breaksconsensus[`breaksconsensus`]
. No PR should be merged until all reviews' comments are addressed.
*Reviewing pull requests*:
When reviewing a pull request, the end-goal is to suggest useful changes to the author. Reviews should finish with approval unless there are issues that would result in:
. Buggy behavior.
. Undue maintenance burden.
. Breaking with house coding style.
. Pessimization (i.e. reduction of speed as measured in the projects benchmarks).
. Feature reduction (i.e. it removes some aspect of functionality that a significant minority of users rely on).
. Uselessness (i.e. it does not strictly add a feature or fix a known issue).
*Reviews may not be used as an effective veto for a PR because*:
. There exists a somewhat cleaner/better/faster way of accomplishing the same feature/fix.
. It does not fit well with some other contributors' longer-term vision for the project.
=== Updating Polkadot as well
If your PR changes the external APIs or interfaces used by Polkadot, **a corresponding PR on Polkadot must** be submitted as well. If you tagged the PR with `breaksapi` or `breaksconsensus` this is most certainly the case, in all other cases check for it by running step 1.
To update a corresponding Polkadot PR:
0. Pull lastet Polkadot master (or clone it, if you haven't yet).
1. Replace `polkadot-master` in all `Cargo.toml` with the name of the PR-branch - e.g. by running `find . -name "Cargo.toml" -exec sed -i "s/polkadot-master/PR_BRANCH/g" {}` (and to your repo, if the branch is not on mainline); Commit this change.
2. Make the changes required to pass the build again.
3. Submit all this as a PR against the Polkadot Repo, link that new PR in the existing substrate PR for reference
4. Wait for reviews on both
5. Once both PRs have been green lit, merge the Substrate PR into master and sync the changes onto the `polkadot-master` on mainline (push it). Now revert that first commit in your Polkadot PR, reverting the name back to `polkadot-master`, push and wait for the CI to confirm all is fine. Then merge the Polkadot PR.
As there might be multiple pending PRs that might conflict with one another, a) you should not merge the substrate PR until the Polkadot PR has also been reviewed and b) both should be merged pretty quickly after another to not block others.
== Helping out
We use https://github.com/paritytech/substrate/labels[labels] to manage PRs and issues and communicate state of a PR. Please familiarize yourself with them. Furthermore we are organizing issues in https://github.com/paritytech/substrate/milestones[milestones]. Best way to get started is to a pick a ticket from the current milestone tagged https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AQ2-easy[`easy`] or https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AQ3-medium[`medium`] and get going or https://github.com/paritytech/substrate/issues?q=is%3Aissue+is%3Aopen+label%3AX1-mentor[`mentor`] and get in contact with the mentor offering their support on that larger task.
== Releases
Declaring formal releases remains the prerogative of the project maintainer(s).
== Changes to this arrangement
This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.
== Heritage
These contributing guidelines are modified from the "OPEN Open Source Project" guidelines for the Level project: https://github.com/Level/community/blob/master/CONTRIBUTING.md
substrate/docs/PULL_REQUEST_TEMPLATE.md
+23
View File
@@ -0,0 +1,23 @@
Thank you for your Pull Request!
Before you submitting, please check that:
- [ ] You added a brief description of the PR, e.g.:
- What does it do?
- What important points reviewers should know?
- Is there something left for follow-up PRs?
- [ ] You labeled the PR with appropriate labels if you have permissions to do so.
- [ ] You mentioned a related issue if this PR related to it, e.g. `Fixes #228` or `Related #1337`.
- [ ] You asked any particular reviewers to review. If you aren't sure, start with GH suggestions.
- [ ] Your PR adheres [the style guide](https://github.com/paritytech/polkadot/wiki/Style-Guide)
- In particular, mind the maximal line length.
- There is no commented code checked in unless necessary.
- Any panickers have a proof or removed.
- [ ] You bumped the runtime version if there are breaking changes in the **runtime**.
- [ ] You updated any rustdocs which may have changed
- [ ] Has the PR altered the external API or interfaces used by Polkadot? Do you have the corresponding Polkadot PR ready?
After you've read this notice feel free to remove it.
Thank you!
✄ -----------------------------------------------------------------------------
substrate/docs/README.adoc
+528
View File
@@ -0,0 +1,528 @@
= Substrate
:Author: Substrate developers
:Revision: 0.2.0
:toc:
:sectnums:
== Intro in one sentence
Substrate is a next-generation framework for blockchain innovation.
== Description
At its heart, Substrate is a combination of three technologies: https://webassembly.org/[WebAssembly], https://libp2p.io/[Libp2p] and GRANDPA Consensus. About GRANDPA, see this https://hackmd.io/Jd0byWX0RiqFiXUVC78Bdw?view#GRANDPA[definition], https://medium.com/polkadot-network/grandpa-block-finality-in-polkadot-an-introduction-part-1-d08a24a021b5[introduction] and https://github.com/w3f/consensus/blob/master/pdf/grandpa.pdf[formal specification]. It is both a library for building new blockchains and a "skeleton key" of a blockchain client, able to synchronize to any Substrate-based chain.
Substrate chains have three distinct features that make them "next-generation": a dynamic, self-defining state-transition function; light-client functionality from day one; and a progressive consensus algorithm with fast block production and adaptive, definite finality. The STF, encoded in WebAssembly, is known as the "runtime". This defines the `execute_block` function, and can specify everything from the staking algorithm, transaction semantics, logging mechanisms and procedures for replacing any aspect of itself or of the blockchain's state ("governance"). Because the runtime is entirely dynamic all of these can be switched out or upgraded at any time. A Substrate chain is very much a "living organism".
See also https://www.parity.io/what-is-substrate/.
== Usage
Substrate is still an early stage project, and while it has already been used as the basis of major projects like Polkadot, using it is still a significant undertaking. In particular, you should have a good knowledge of blockchain concepts and basic cryptography. Terminology like header, block, client, hash, transaction and signature should be familiar. At present you will need a working knowledge of Rust to be able to do anything interesting (though eventually, we aim for this not to be the case).
Substrate is designed for use in one of three ways:
**1. Trivial**: By running the Substrate binary `substrate` and configuring it with a genesis block that includes the current demonstration runtime. In this case, you just build Substrate, configure a JSON file, and launch your own blockchain. This affords you the least amount of customizability, primarily allowing you to change the genesis parameters of the various included runtime modules such as balances, staking, block-period, fees, and governance.
**2. Modular**: By hacking together modules from the Substrate Runtime Module Library (SRML) into a new runtime and possibly altering or reconfiguring the Substrate client's block authoring logic. This affords you a very large amount of freedom over your blockchain's logic, letting you change datatypes, add or remove modules, and crucially, add your own modules. Much can be changed without touching the block authoring logic (since it is generic). If this is the case, then the existing Substrate binary can be used for block authoring and syncing. If the block authoring logic needs to be tweaked, then a new, altered block authoring binary must be built as a separate project and used by validators. This is how the Polkadot relay chain is built and should suffice for almost all circumstances in the near to mid-term.
**3. Generic**: The entire SRML can be ignored and the entire runtime designed and implemented from scratch. If desired, this can be done in a language other than Rust, provided it can target WebAssembly. If the runtime can be made compatible with the existing client's block authoring logic, then you can simply construct a new genesis block from your Wasm blob and launch your chain with the existing Rust-based Substrate client. If not, then you'll need to alter the client's block authoring logic accordingly. This is probably a useless option for most projects right now, but provides complete flexibility allowing for a long-term, far-reaching upgrade path for the Substrate paradigm.
=== The Basics of Substrate
Substrate is a blockchain platform with a completely generic state transition function. That said, it does come with both standards and conventions (particularly regarding the Runtime Module Library) regarding underlying data structures. Roughly speaking, these core datatypes correspond to +trait+s in terms of the actual non-negotiable standard and generic +struct+s in terms of the convention.
```
Header := Parent + ExtrinsicsRoot + StorageRoot + Digest
Block := Header + Extrinsics + Justifications
```
=== Extrinsics
Extrinsics in Substrate are pieces of information from "the outside world" that are contained in the blocks of the chain. You might think "ahh, that means *transactions*": in fact, no. Extrinsics fall into two broad categories of which only one is *transactions*. The other is known as *inherents*. The difference between these two is that transactions are signed and gossiped on the network and can be deemed useful *per se*. This fits the mold of what you would call transactions in Bitcoin or Ethereum.
Inherents, meanwhile, are not passed on the network and are not signed. They represent data which describes the environment but which cannot call upon anything to prove it such as a signature. Rather they are assumed to be "true" simply because a sufficiently large number of validators have agreed on them being reasonable.
To give an example, there is the timestamp inherent, which sets the current timestamp of the block. This is not a fixed part of Substrate, but does come as part of the Substrate Runtime Module Library to be used as desired. No signature could fundamentally prove that a block were authored at a given time in quite the same way that a signature can "prove" the desire to spend some particular funds. Rather, it is the business of each validator to ensure that they believe the timestamp is set to something reasonable before they agree that the block candidate is valid.
Other examples include the parachain-heads extrinsic in Polkadot and the "note-missed-proposal" extrinsic used in the Substrate Runtime Module Library to determine and punish or deactivate offline validators.
=== Runtime and API
Substrate chains all have a runtime. The runtime is a WebAssembly "blob" that includes a number of entry-points. Some entry-points are required as part of the underlying Substrate specification. Others are merely convention and required for the default implementation of the Substrate client to be able to author blocks.
If you want to develop a chain with Substrate, you will need to implement the `Core` trait. This `Core` trait generates an API with the minimum necessary functionality to interact with your runtime. A special macro is provided called `impl_runtime_apis!` that help you implement runtime API traits. All runtime API trait implementations need to be done in one call of the `impl_runtime_apis!` macro. All parameters and return values need to implement https://crates.io/crates/parity-codec[`parity-codec`] to be encodable and decodable.
Here's a snippet of the Polkadot API implementation as of PoC-3:
```rust
impl_runtime_apis! {
impl client_api::Core<Block> for Runtime {
fn version() -> RuntimeVersion {
VERSION
}
fn execute_block(block: Block) {
Executive::execute_block(block)
}
fn initialize_block(header: <Block as BlockT>::Header) {
Executive::initialize_block(&header)
}
}
// ---snip---
}
```
=== Inherent Extrinsics
The Substrate Runtime Module Library includes functionality for timestamps and slashing. If used, these rely on "trusted" external information being passed in via inherent extrinsics. The Substrate reference block authoring client software will expect to be able to call into the runtime API with collated data (in the case of the reference Substrate authoring client, this is merely the current timestamp and which nodes were offline) in order to return the appropriate extrinsics ready for inclusion. If new inherent extrinsic types and data are to be used in a modified runtime, then it is this function (and its argument type) that would change.
=== Block-authoring Logic
In Substrate, there is a major distinction between blockchain *syncing* and block *authoring* ("authoring" is a more general term for what is called "mining" in Bitcoin). The first case might be referred to as a "full node" (or "light node" - Substrate supports both): authoring necessarily requires a synced node and, therefore, all authoring clients must necessarily be able to synchronize. However, the reverse is not true. The primary functionality that authoring nodes have which is not in "sync nodes" is threefold: transaction queue logic, inherent transaction knowledge and BFT consensus logic. BFT consensus logic is provided as a core element of Substrate and can be ignored since it is only exposed in the SDK under the `authorities()` API entry.
Transaction queue logic in Substrate is designed to be as generic as possible, allowing a runtime to express which transactions are fit for inclusion in a block through the `initialize_block` and `apply_extrinsic` calls. However, more subtle aspects like prioritization and replacement policy must currently be expressed "hard coded" as part of the blockchain's authoring code. That said, Substrate's reference implementation for a transaction queue should be sufficient for an initial chain implementation.
Inherent extrinsic knowledge is again somewhat generic, and the actual construction of the extrinsics is, by convention, delegated to the "soft code" in the runtime. If ever there needs to be additional extrinsic information in the chain, then both the block authoring logic will need to be altered to provide it into the runtime and the runtime's `inherent_extrinsics` call will need to use this extra information in order to construct any additional extrinsic transactions for inclusion in the block.
== Roadmap
=== So far
- 0.1 "PoC-1": PBFT consensus, Wasm runtime engine, basic runtime modules.
- 0.2 "PoC-2": Libp2p
=== In progress
- AfG consensus
- Improved PoS
- Smart contract runtime module
=== The future
- Splitting out runtime modules into separate repo
- Introduce substrate executable (the skeleton-key runtime)
- Introduce basic but extensible transaction queue and block-builder and place them in the executable.
- DAO runtime module
- Audit
== Trying out Substrate Node
Substrate Node is Substrate's pre-baked blockchain client. You can run a development node locally or configure a new chain and launch your own global testnet.
=== On Mac and Ubuntu
To get going as fast as possible, there is a simple script that installs all required dependencies and installs Substrate into your path. Just open a terminal and run:
[source, shell]
----
curl https://getsubstrate.io -sSf | bash
----
You can start a local Substrate development chain with running `substrate --dev`.
To create your own global network/cryptocurrency, you'll need to make a new Substrate Node chain specification file ("chainspec").
First let's get a template chainspec that you can edit. We'll use the "staging" chain, a sort of default chain that the node comes pre-configured with:
[source, shell]
----
substrate build-spec --chain=staging > ~/chainspec.json
----
Now, edit `~/chainspec.json` in your editor. There are a lot of individual fields for each module, and one very large one which contains the WebAssembly code blob for this chain. The easiest field to edit is the block `period`. Change it to 10 (seconds):
[source, json]
----
"timestamp": {
"minimumPeriod": 10
},
----
Now with this new chainspec file, you can build a "raw" chain definition for your new chain:
[source, shell]
----
substrate build-spec --chain ~/chainspec.json --raw > ~/mychain.json
----
This can be fed into Substrate:
[source, shell]
----
substrate --chain ~/mychain.json
----
It won't do much until you start producing blocks though, so to do that you'll need to use the `--validator` option together with passing the seed for the account(s) that is configured to be the initial authorities:
[source, shell]
----
substrate --chain ~/mychain.json --validator
----
You can distribute `mychain.json` so that everyone can synchronize and (depending on your authorities list) validate on your chain.
== Building
=== Hacking on Substrate
If you'd actually like to hack on Substrate, you can just grab the source code and
build it. Ensure you have Rust and the support software installed:
==== Linux and Mac
For Unix-based operating systems, you should run the following commands:
[source, shell]
----
curl https://sh.rustup.rs -sSf | sh
rustup update nightly
rustup target add wasm32-unknown-unknown --toolchain nightly
rustup update stable
----
You will also need to install the following packages:
- Linux:
[source, shell]
sudo apt install cmake pkg-config libssl-dev git clang libclang-dev
- Linux on ARM:
`rust-lld` is required for linking wasm, but is missing on non Tier 1 platforms.
So, use this https://github.com/Plume-org/Plume/blob/master/script/wasm-deps.sh[script]
to build `lld` and create the symlink `/usr/bin/rust-lld` to the build binary.
- Mac:
[source, shell]
brew install cmake pkg-config openssl git llvm
To finish installation of Substrate, jump down to <<shared-steps,shared steps>>.
==== Windows
If you are trying to set up Substrate on Windows, you should do the following:
1. First, you will need to download and install "Build Tools for Visual Studio:"
* You can get it at this link: https://aka.ms/buildtools
* Run the installation file: `vs_buildtools.exe`
* Please ensure the Windows 10 SDK component is included when installing the Visual C++ Build Tools.
* image:https://i.imgur.com/zayVLmu.png[image]
* Restart your computer.
2. Next, you need to install Rust:
* Detailed instructions are provided by the https://doc.rust-lang.org/book/ch01-01-installation.html#installing-rustup-on-windows[Rust Book].
* Download from: https://www.rust-lang.org/tools/install
* Run the installation file: `rustup-init.exe`
> Note that it should not prompt you to install vs_buildtools since you did it in step 1.
* Choose "Default Installation."
* To get started, you need Cargo's bin directory (%USERPROFILE%\.cargo\bin) in your PATH environment variable. Future applications will automatically have the correct environment, but you may need to restart your current shell.
3. Then, you will need to run some commands in CMD to set up your Wasm Build Environment:
rustup update nightly
rustup update stable
rustup target add wasm32-unknown-unknown --toolchain nightly
4. Then, you need to install LLVM: https://releases.llvm.org/download.html
5. Next, you need to install OpenSSL, which we will do with `vcpkg`:
mkdir \Tools
cd \Tools
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
.\bootstrap-vcpkg.bat
.\vcpkg.exe install openssl:x64-windows-static
6. After, you need to add OpenSSL to your System Variables. Note that in order for the following commands to work, you need to use Windows Powershell:
$env:OPENSSL_DIR = 'C:\Tools\vcpkg\installed\x64-windows-static'
$env:OPENSSL_STATIC = 'Yes'
[System.Environment]::SetEnvironmentVariable('OPENSSL_DIR', $env:OPENSSL_DIR, [System.EnvironmentVariableTarget]::User)
[System.Environment]::SetEnvironmentVariable('OPENSSL_STATIC', $env:OPENSSL_STATIC, [System.EnvironmentVariableTarget]::User)
7. Finally, you need to install `cmake`: https://cmake.org/download/
==== Shared Steps
Then, grab the Substrate source code:
[source, shell]
----
git clone https://github.com/paritytech/substrate.git
cd substrate
----
Then build the code:
[source, shell]
----
cargo build # Builds all native code
----
You can run all the tests if you like:
[source, shell]
cargo test --all
Or just run the tests of a specific package (i.e. `cargo test -p paint-assets`)
You can start a development chain with:
[source, shell]
cargo run --release -- --dev
Detailed logs may be shown by running the node with the following environment variables set: `RUST_LOG=debug RUST_BACKTRACE=1 cargo run --release \-- --dev`.
If you want to see the multi-node consensus algorithm in action locally, then you can create a local testnet with two validator nodes for Alice and Bob, who are the initial authorities of the genesis chain specification that have been endowed with a testnet DOTs. We'll give each node a name and expose them so they are listed on link:https://telemetry.polkadot.io/#/Local%20Testnet[Telemetry]. You'll need two terminal windows open.
We'll start Alice's Substrate node first on default TCP port 30333 with her chain database stored locally at `/tmp/alice`. The Bootnode ID of her node is `QmRpheLN4JWdAnY7HGJfWFNbfkQCb6tFf4vvA6hgjMZKrR`, which is generated from the `--node-key` value that we specify below:
[source, shell]
cargo run --release \-- \
--base-path /tmp/alice \
--chain=local \
--alice \
--node-key 0000000000000000000000000000000000000000000000000000000000000001 \
--telemetry-url ws://telemetry.polkadot.io:1024 \
--validator
In the second terminal, we'll run the following to start Bob's Substrate node on a different TCP port of 30334, and with his chain database stored locally at `/tmp/bob`. We'll specify a value for the `--bootnodes` option that will connect his node to Alice's Bootnode ID on TCP port 30333:
[source, shell]
cargo run --release \-- \
--base-path /tmp/bob \
--bootnodes /ip4/127.0.0.1/tcp/30333/p2p/QmRpheLN4JWdAnY7HGJfWFNbfkQCb6tFf4vvA6hgjMZKrR \
--chain=local \
--bob \
--port 30334 \
--telemetry-url ws://telemetry.polkadot.io:1024 \
--validator
Additional Substrate CLI usage options are available and may be shown by running `cargo run \-- --help`.
=== WASM binaries
The WASM binaries are built during the normal `cargo build` process. To control the WASM binary building,
we support multiple environment variables:
* `SKIP_WASM_BUILD` - Skips building any WASM binary. This is useful when only native should be recompiled.
* `BUILD_DUMMY_WASM_BINARY` - Builds dummy WASM binaries. These dummy binaries are empty and useful
for `cargo check` runs.
* `WASM_BUILD_TYPE` - Sets the build type for building WASM binaries. Supported values are `release` or `debug`.
By default the build type is equal to the build type used by the main build.
* `TRIGGER_WASM_BUILD` - Can be set to trigger a WASM build. On subsequent calls the value of the variable
needs to change. As WASM builder instructs `cargo` to watch for file changes
this environment variable should only be required in certain circumstances.
* `WASM_TARGET_DIRECTORY` - Will copy any build WASM binary to the given directory. The path needs
to be absolute.
* `WASM_BUILD_RUSTFLAGS` - Extend `RUSTFLAGS` given to `cargo build` while building the wasm binary.
* `WASM_BUILD_NO_COLOR` - Disable color output of the wasm build.
Each project can be skipped individually by using the environment variable `SKIP_PROJECT_NAME_WASM_BUILD`.
Where `PROJECT_NAME` needs to be replaced by the name of the cargo project, e.g. `node-runtime` will
be `NODE_RUNTIME`.
[[flaming-fir]]
=== Joining the Flaming Fir Testnet
Flaming Fir is the new testnet for Substrate master (2.0) to test the latest development features. Please note that master is not compatible with the BBQ Birch, Charred Cherry, Dried Danta or Emberic Elm testnets. Ensure you have the dependencies listed above before compiling.
Since Flaming Fir is targeting the master branch we make absolutely no guarantees of stability and/or persistence of the network. We might reset the chain at any time if it is necessary to deploy new changes. Currently, the validators are running with a client built from `d013bd900`, if you build from this commit you should be able to successfully sync, later commits may not work as new breaking changes may be introduced in master.
Latest known working version: `a2a0eb5398d6223e531455b4c155ef053a4a3a2b`
[source, shell]
----
git clone https://github.com/paritytech/substrate.git
cd substrate
git checkout -b flaming-fir a2a0eb5398d6223e531455b4c155ef053a4a3a2b
----
You can run the tests if you like:
[source, shell]
cargo test --all
Start your node:
[source, shell]
cargo run --release \--
To see a list of command line options, enter:
[source, shell]
cargo run --release \-- --help
For example, you can choose a custom node name:
[source, shell]
cargo run --release \-- --name my_custom_name
If you are successful, you will see your node syncing at https://telemetry.polkadot.io/#/Flaming%20Fir
=== Joining the Emberic Elm Testnet
Emberic Elm is the testnet for Substrate 1.0. Please note that 1.0 is not compatible with the BBQ Birch, Charred Cherry, Dried Danta or Flaming Fir testnets.
In order to join the Emberic Elm testnet you should build from the `v1.0` branch. Ensure you have the dependencies listed above before compiling.
[source, shell]
----
git clone https://github.com/paritytech/substrate.git
cd substrate
git checkout -b v1.0 origin/v1.0
----
You can then follow the same steps for building and running as described above in <<flaming-fir>>.
== Key management
Keys in Substrate are stored in the keystore in the file system. To store keys into this keystore,
you need to use one of the two provided RPC calls. If your keys are encrypted or should be encrypted
by the keystore, you need to provide the key using one of the cli arguments `--password`,
`--password-interactive` or `--password-filename`.
=== Recommended RPC call
For most users who want to run a validator node, the `author_rotateKeys` RPC call is sufficient.
The RPC call will generate `N` Session keys for you and return their public keys. `N` is the number
of session keys configured in the runtime. The output of the RPC call can be used as input for the
`session::set_keys` transaction.
```
curl -H 'Content-Type: application/json' --data '{ "jsonrpc":"2.0", "method":"author_rotateKeys", "id":1 }' localhost:9933
```
=== Advanced RPC call
If the Session keys need to match a fixed seed, they can be set individually key by key. The RPC call
expects the key seed and the key type. The key types supported by default in Substrate are listed
https://github.com/paritytech/substrate/blob/master/core/primitives/src/crypto.rs#L767[here], but the
user can declare any key type.
```
curl -H 'Content-Type: application/json' --data '{ "jsonrpc":"2.0", "method":"author_insertKey", "params":["KEY_TYPE", "SEED", "PUBLIC"],"id":1 }' localhost:9933
```
`KEY_TYPE` - needs to be replaced with the 4-character key type identifier.
`SEED` - is the seed of the key.
`PUBLIC` - public key for the given key.
== Documentation
=== Viewing documentation for Substrate packages
You can generate documentation for a Substrate Rust package and have it automatically open in your web browser using https://doc.rust-lang.org/rustdoc/what-is-rustdoc.html#using-rustdoc-with-cargo[rustdoc with Cargo],
(of the The Rustdoc Book), by running the following command:
```
cargo doc --package <spec> --open
```
Replacing `<spec>` with one of the following (i.e. `cargo doc --package substrate --open`):
* All Substrate Packages
[source, shell]
substrate
* Substrate Core
[source, shell]
substrate, substrate-cli, substrate-client, substrate-client-db,
substrate-consensus-common, substrate-consensus-rhd,
substrate-executor, substrate-finality-grandpa, substrate-keyring, substrate-keystore, substrate-network,
substrate-network-libp2p, substrate-primitives, substrate-rpc, substrate-rpc-servers,
substrate-serializer, substrate-service, substrate-service-test, substrate-state-db,
substrate-state-machine, substrate-telemetry, substrate-test-client,
substrate-test-runtime, substrate-transaction-graph, substrate-transaction-pool,
substrate-trie
* Substrate Runtime
[source, shell]
sr-api, sr-io, sr-primitives, sr-sandbox, sr-std, sr-version
* Substrate Runtime Module Library (SRML)
[source, shell]
paint-assets, paint-balances, paint-consensus, paint-contracts, paint-council, paint-democracy, paint-example,
paint-executive, paint-metadata, paint-session, paint-staking, paint-support, paint-system, paint-timestamp,
paint-treasury
* Node
[source, shell]
node-cli, node-consensus, node-executor, node-network, node-primitives, node-runtime
* Subkey
[source, shell]
subkey
=== Contributing to documentation for Substrate packages
https://doc.rust-lang.org/1.9.0/book/documentation.html[Document source code] for Substrate packages by annotating the source code with documentation comments.
Example (generic):
```markdown
/// Summary
///
/// Description
///
/// # Panics
///
/// # Errors
///
/// # Safety
///
/// # Examples
///
/// Summary of Example 1
///
/// ```rust
/// // insert example 1 code here
/// ```
///
```
* Important notes:
** Documentation comments must use annotations with a triple slash `///`
** Modules are documented using `//!`
```
//! Summary (of module)
//!
//! Description (of module)
```
* Special section header is indicated with a hash `#`.
** `Panics` section requires an explanation if the function triggers a panic
** `Errors` section is for describing conditions under which a function of method returns `Err(E)` if it returns a `Result<T, E>`
** `Safety` section requires an explanation if the function is `unsafe`
** `Examples` section includes examples of using the function or method
* Code block annotations for examples are included between triple graves, as shown above.
Instead of including the programming language to use for syntax highlighting as the annotation
after the triple graves, alternative annotations include the `ignore`, `text`, `should_panic`, or `no_run`.
* Summary sentence is a short high level single sentence of its functionality
* Description paragraph is for details additional to the summary sentence
* Missing documentation annotations may be used to identify where to generate warnings with `#![warn(missing_docs)]`
or errors `#![deny(missing_docs)]`
* Hide documentation for items with `#[doc(hidden)]`
=== Contributing to documentation (tests, extended examples, macros) for Substrate packages
The code block annotations in the `# Example` section may be used as https://doc.rust-lang.org/1.9.0/book/documentation.html#documentation-as-tests[documentation as tests and for extended examples].
* Important notes:
** Rustdoc will automatically add a `main()` wrapper around the code block to test it
** https://doc.rust-lang.org/1.9.0/book/documentation.html#documenting-macros[Documenting macros].
** Documentation as tests examples are included when running `cargo test`
== Contributing
=== Contributing Guidelines
include::CONTRIBUTING.adoc[]
=== Contributor Code of Conduct
include::CODE_OF_CONDUCT.adoc[]
== License
https://github.com/paritytech/substrate/blob/master/LICENSE[LICENSE]
substrate/docs/SECURITY.md
+101
View File
@@ -0,0 +1,101 @@
# Security Policy
Parity Technologies is committed to resolving security vulnerabilities in our software quickly and carefully. We take the necessary steps to minimize risk, provide timely information, and deliver vulnerability fixes and mitigations required to address security issues.
## Reporting a Vulnerability
Security vulnerabilities in Parity software should be reported by email to security@parity.io. If you think your report might be eligible for the Parity Bug Bounty Program, your email should be send to bugbounty@parity.io.
Your report should include the following:
- your name
- description of the vulnerability
- attack scenario (if any)
- components
- reproduction
- other details
Try to include as much information in your report as you can, including a description of the vulnerability, its potential impact, and steps for reproducing it. Be sure to use a descriptive subject line.
You'll receive a response to your email within two business days indicating the next steps in handling your report. We encourage finders to use encrypted communication channels to protect the confidentiality of vulnerability reports. You can encrypt your report using our public key. This key is [on MIT's key server](https://pgp.mit.edu/pks/lookup?op=get&search=0x5D0F03018D07DE73) server and reproduced below.
After the initial reply to your report, our team will endeavor to keep you informed of the progress being made towards a fix. These updates will be sent at least every five business days.
Thank you for taking the time to responsibly disclose any vulnerabilities you find.
## Responsible Investigation and Reporting
Responsible investigation and reporting includes, but isn't limited to, the following:
- Don't violate the privacy of other users, destroy data, etc.
- Don’t defraud or harm Parity Technologies Ltd or its users during your research; you should make a good faith effort to not interrupt or degrade our services.
- Don't target our physical security measures, or attempt to use social engineering, spam, distributed denial of service (DDOS) attacks, etc.
- Initially report the bug only to us and not to anyone else.
- Give us a reasonable amount of time to fix the bug before disclosing it to anyone else, and give us adequate written warning before disclosing it to anyone else.
- In general, please investigate and report bugs in a way that makes a reasonable, good faith effort not to be disruptive or harmful to us or our users. Otherwise your actions might be interpreted as an attack rather than an effort to be helpful.
## Bug Bounty Program
Our Bug Bounty Program allows us to recognise and reward members of the Parity community for helping us find and address significant bugs, in accordance with the terms of the Parity Bug Bounty Program. A detailed description on eligibility, rewards, legal information and terms & conditions for contributors can be found on [our website](https://paritytech.io/bug-bounty.html).
## Plaintext PGP Key
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBF0vHwQBEADKui4qAo4bzdzRhMm+uhUpYGf8jjjmET3zJ8kKQIpp6JTsV+HJ
6m1We0QYeMRXoOYH1xVHBf2zNCuHS0nSQdUCQA7SHWsPB05STa2hvlR7fSdQnCCp
gnLOJWXvvedlRDIAhvqI6cwLdUlXgVSKEwrwmrpiBhh4NxI3qX+LyIa+Ovkchu2S
d/YCnE4GqojSGRfJYiGwe2N+sF7OfaoKhQuTrtdDExHrMU4cWnTXW2wyxTr4xkj9
jS2WeLVZWflvkDHT8JD9N6jNxBVEF/Qvjk83zI0kCOzkhek8x+YUgfLq3/rHOYbX
3pW21ccHYPacHjHWvKE+xRebjeEhJ4KxKHfCVjQcxybwDBqDka1AniZt4CQ7UORf
MU/ue2oSZ9nNg0uMdb/0AbQPZ04OlMcYPAPWzFL08nVPox9wT9uqlL6JtcOeC90h
oOeDmfgwmjMmdwWTRgt9qQjcbgXzVvuAzIGbzj1X3MdLspWdHs/d2+US4nji1TkN
oYIW7vE+xkd3aB+NZunIlm9Rwd/0mSgDg+DaNa5KceOLhq0/qKgcXC/RRU29I8II
tusRoR/oesGJGYTjh4k6PJkG+nvDPsoQrwYT44bhnniS1xYkxWYXF99JFI7LgMdD
e1SgKeIDVpvm873k82E6arp5655Wod1XOjaXBggCwFp84eKcEZEN+1qEWwARAQAB
tClQYXJpdHkgU2VjdXJpdHkgVGVhbSA8c2VjdXJpdHlAcGFyaXR5LmlvPokCVAQT
AQoAPhYhBJ1LK264+XFW0ZZpqf8IEtSRuWeYBQJdLx8EAhsDBQkDwmcABQsJCAcC
BhUKCQgLAgQWAgMBAh4BAheAAAoJEP8IEtSRuWeYL84QAI6NwnwS561DWYYRAd4y
ocGPr3CnwFSt1GjkSkRy3B+tMhzexBg1y7EbLRUefIrO4LwOlywtRk8tTRGgEI4i
5xRLHbOkeolfgCFSpOj5d8cMKCt5HEIv18hsv6dkrzlSYA5NLX/GRBEh3F/0sGny
vCXapfxa1cx72sU7631JBK7t2Tf+MfwxdfyFZ9TI9WdtP5AfVjgTkIVkEDFcZPTc
n3CYXqTYFIBCNUD8LP4iTi3xUt7pTGJQQoFT8l15nJCgzRYQ+tXpoTRlf+/LtXmw
6iidPV87E06jHdK9666rBouIabAtx7i0/4kwo+bSZ8DiSKRUaehiHGd212HSEmdF
jxquWE4pEzoUowYznhSIfR+WWIqRBHxEYarP4m98Hi+VXZ7Fw1ytzO8+BAKnLXnj
2W2+T9qJks5gqVEoaWNnqpvya6JA11QZvZ0w7Om2carDc2ILNm2Xx9J0mRUye8P0
KxcgqJuKNGFtugebQAsXagkxOKsdKna1PlDlxEfTf6AgI3ST8qSiMAwaaIMB/REF
VKUapGoslQX4tOCjibI2pzEgE//D8NAaSVu2A9+BUcFERdZRxsI7fydIXNeZ2R46
N2qfW+DP3YR/14QgdRxDItEavUoE1vByRXwIufKAkVemOZzIoFXKFsDeXwqTVW5i
6CXu6OddZ3QHDiT9TEbRny4QuQINBF0vKCwBEACnP5J7LEGbpxNBrPvGdxZUo0YA
U8RgeKDRPxJTvMo27V1IPZGaKRCRq8LBfg/eHhqZhQ7SLJBjBljd8kuT5dHDBTRe
jE1UIOhmnlSlrEJjAmpVO08irlGpq1o+8mGcvkBsR0poCVjeNeSnwYfRnR+c3GK5
Er6/JRqfN4mJvnEC9/Pbm6C7ql6YLKxC3yqzF97JL5brbbuozrW7nixY/yAI8619
VlBIMP7PAUbGcnSQyuV5b/Wr2Sgr6NJclnNSLjh2U9/Du6w/0tDGlMBts8HjRnWJ
BXbkTdQKCTaqgK68kTKSiN1/x+lynxHC2AavMpH/08Kopg2ZCzJowMKIgcB+4Z/I
DJKZWHWKumhaZMGXcWgzgcByog9IpamuROEZFJNEUAFf7YIncEckPSif4looiOdS
VurKZGvYXXaGSsZbGgHxI5CWu7ZxMdLBLvtOcCYmRQrG+g/h+PGU5BT0bNAfNTkm
V3/n1B/TWbpWRmB3AwT2emQivXHkaubGI0VivhaO43AuI9JWoqiMqFtxbuTeoxwD
xlu2Dzcp0v+AR4T5cIG9D5/+yiPc25aIY7cIKxuNFHIDL4td5fwSGC7vU6998PIG
2Y48TGBnw7zpEfDfMayqAeBjX0YU6PTNsvS5O6bP3j4ojTOUYD7Z8QdCvgISDID3
WMGAdmSwmCRvsQ/OJwARAQABiQI8BBgBCgAmFiEEnUsrbrj5cVbRlmmp/wgS1JG5
Z5gFAl0vKCwCGwwFCQB2pwAACgkQ/wgS1JG5Z5hdbw//ZqR+JcWm59NUIHjauETJ
sYDYhcAfa3txTacRn5uPz/TQiTd7wZ82+G8Et0ZnpEHy6eWyBqHpG0hiPhFBzxjY
nhjHl8jJeyo2mQIVJhzkL58BHBZk8WM2TlaU7VxZ6TYOmP2y3qf6FD6mCcrQ4Fml
E9f0lyVUoI/5Zs9oF0izRk8vkwaY3UvLM7XEY6nM8GnFG8kaiZMYmx26Zo7Uz31G
7EGGZFsrVDXfNhSJyz79Gyn+Lx9jOTdoR0sH/THYIIosE83awMGE6jKeuDYTbVWu
+ZtHQef+pRteki3wvNLJK+kC1y3BtHqDJS9Lqx0s8SCiVozlC+fZfC9hCtU7bXJK
0UJZ4qjSvj6whzfaNgOZAqJpmwgOnd8W/3YJk1DwUeX98FcU38MR23SOkx2EDdDE
77Kdu62vTs/tLmOTuyKBvYPaHaYulYjQTxurG+o8vhHtaL87ARvuq+83dj+nO5z3
5O9vkcVJYWjOEnJe7ZvCTxeLJehpCmHIbyUuDx5P24MWVbyXOxIlxNxTqlub5GlW
rQF6Qsa/0k9TRk7Htbct6fAA0/VahJS0g096MrTH8AxBXDNE8lIoNeGikVlaxK9Z
S+aannlWYIJymZ4FygIPPaRlzhAoXBuJd8OaR5giC7dS1xquxKOiQEXTGsLeGFaI
BZYiIhW7GG4ozvKDqyNm4eg=
=yKcB
-----END PGP PUBLIC KEY BLOCK-----
```
substrate/docs/Structure.adoc
+110
View File
@@ -0,0 +1,110 @@
= Structure
:Author: Substrate developers
:Revision: 0.3.0
:toc:
:sectnums:
== Overview
Substrate is split into multiple levels with increasing opinion and decreasing flexibility:
* primitives
* client
* PAINT (formerly `paint`)
Putting all these components together we have:
* Integration Tests
* Node
* Node template
* Subkey
=== Runtime
* _found in_: `/primitives`
* _crates prefix_: `sp-`
* _constrains_:
** must be `[no_std]`
** crates may not (dev-)depend on crates in other subfolders of this repo
In the lowest level, substrate defines primitives, interfaces and traits to implement any on-chain substrate transition system and its interactions with the outside world. This is the lowest level of abstraction and opinion everything else builds upon.
=== Client
* _found in_: `/client`
* _crates prefix_: `substrate-`
* _constrains_:
** crates may not (dev-)depend on any `paint-`-crates
In the client you can find a set of crates to construct the outer substrate-node, implementing outer runtime interfaces, thus it depends on `runtime`. It provides the outer building blocks like transaction queue, networking layer, database backend, full* and light-client support.
=== PAINT (formerly `paint`)
* _found in_: `/paint`
* _crates prefix_: `paint-`
* _constrains_:
** all crates that go on chain, must be `[no_std]`
** must not (dev-)depend on anything in `/client`
PAINT, the Parity Application Interface for Network-wide Transitions, is a set of modules implementing specific transition functions and features one (might) want to have in their runtime.
=== integration tests
* _found in_: `/test`
* _crates prefix_: `substrate-test`
* _constrains_:
** only helpers may be published
** purely testing crates must be `publish = false`
All tests that have to pull (dev)-dependencies out of their substree and would thus break the dependency rules, are considered intergration tests and should be stored in here. Only helper-crates in here shall be published, everything else is expected to be non-publish.
=== Binaries and template
* _found in_: `/bin`
We also provide some binaries pulling from the components creating full applications.
==== Node
* _found in_: `/bin/node`
The default (testing) application pulling together our recommended setup of substrate-client with a wasm-contracts-supporting paint-runtime. The node pulls it all together, constructs the (upgradable) runtime and wires up the client around it. You can find an example client, which includes a full wasm-contracts chain in `node`. This is also what is being build and run if you do `cargo run`.
==== Node Template
* _found in_: `/bin/node-template`
We also provide a template to get you started building your own node.
==== Subkey
* _found in_: `/bin/subkey`
Subkey is a client library to generate keys and sign transactions to send to a substrate node.
== Internal Dependency Tree
[ditaa]
....
+---------------+ +----------------+
| | | |
| runtime +<------+ paint |
| | | |
+------+-----+--+ +-------------+--+
^ ^ ^
| +----------------+ |
| | |
+------+--------+ | |
| | | |
| client | +--+-------+--------+
| +<---------+ |
+---------------+ | |
| test /bin/* |
| |
| |
+-------------------+
....
substrate/docs/license_header.txt
+15
View File
@@ -0,0 +1,15 @@
// Copyright 2017-2019 Parity Technologies (UK) Ltd.
// This file is part of Substrate.
// Substrate is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
// Substrate is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
// You should have received a copy of the GNU General Public License
// along with Substrate. If not, see <http://www.gnu.org/licenses/>.