What is Substrate?

Joshy Orndorff gives an introduction to Parity Technologies’ Substrate, a modular framework for building custom blockchains that will be capable of connecting to the Polkadot Network or Kusama Network.

#substrate #blockchain #polkadot

What is GEEK

Buddha Community

What is Substrate?

Substrate Execute Block Code Walkthrough

Parity’s Joe Petrowski and Shawn Tabrizi give an introductory code walkthrough for the Substrate executive module, a Rust module for executing blocks in Substrate-based blockchains.

#substrate #rust module #substrate

Substrate Archive: Blockchain Indexing Engine

Substrate Archive


Blockchain Indexing Engine

Run alongside a substrate-backed chain to index all Blocks, State, and Extrinsic data into PostgreSQL.

Usage

The schema for the PostgreSQL database is described in the PDF File at the root of this directory.

Examples for how to use substrate-archive are in the examples/ directory

Prerequisites

Extended requirements list found in the wiki

  • depending on the chain you want to index, ~60GB free space
  • PostgreSQL with a database ready for lots of new data
  • Substrate-based Blockchain running with RocksDB as the backend
  • Substrate-based Blockchain running under --pruning=archive

Install The CLI

The CLI

The CLI is an easier way to get started with substrate-archive. It provides a batteries-included binary, so that you don't have to write any rust code. All thats required is setting up a PostgreSQL DB, and modifying a config file. More information in the wiki

The Node-Template CLI

The node-template CLI (in /bin/node-template-archive) is provided as an example of implementing substrate-archive for your chain.

Quick Start

git clone https://github.com/paritytech/substrate-archive.git
# Set up the databases
source ./substrate-archive/scripts/up.sh # Run ./scripts/down.sh to drop the database
cd substrate-archive/bin/polkadot-archive/
# Start the normal polkadot node with `pruning` set to `archive`
polkadot --chain=polkadot --pruning=archive
# Start up the substrate-archive node. `chain` can be one of `polkadot`, `kusama`, or `westend`.
cargo run --release --  -c test_conf.toml --chain=polkadot

You can access the help dialog via cargo run --release -- --help. Note that up and down scripts are meant for convenience and are not meant to be complete. Look in the wiki for more information about the database setup.

FAQ

Contributing

Contributors are welcome!

Read the Doc

Documentation

You can build the documentation for this crate by running cargo doc. More Docs here

Troubleshooting

Archive fails to start with a too many open files error.

Because of the way a RocksDB Secondary Instance works, it requires that all the files of the primary instance remain open in the secondary instance. This could trigger the error on linux, but simply requires that you raise the max open files limit (ulimit):

  • With Docker: $ docker run --ulimit nofile=90000:90000 <image-tag>
  • For Current Shell Session: ulimit -a 90000
  • Permanantly Per-User
    • Edit /etc/security/limits.conf
# /etc/security/limits.conf
*           hard    nofile      4096
*           soft    nofile      1024
some_usr    hard    nofile      90000
some_usr    soft    nofile      90000
insipx      hard    nofile      90000
insipx      soft    nofile      90000
root        hard    nofile      90000
root        soft    nofile      90000

For macOS and Linux, a warning message will be raised on the startup when there is a low fd sources limit in the current system, but Windows won't have such a low fd limit warning.

Contact

You can contact us at:

# /etc/security/limits.conf
*           hard    nofile      4096
*           soft    nofile      1024
some_usr    hard    nofile      90000
some_usr    soft    nofile      90000
insipx      hard    nofile      90000
insipx      soft    nofile      90000
root        hard    nofile      90000
root        soft    nofile      90000

Download Details:
Author: paritytech
Source Code: https://github.com/paritytech/substrate-archive
License: GPL-3.0 License

#rust  #rustlang  #blockchain #substrate 

ERIC  MACUS

ERIC MACUS

1647619200

UTXO On Substrate: A Substrate UTXO workshop

UTXO on Substrate

Note: this workshop is presently not actively maintained and is using older versions of all dependancies than presently used in substrate.

A UTXO chain implementation on Substrate, with two self-guided workshops. Original UXTO inspiration by Dmitriy Kashitsyn.

Substrate Version: 2.0.0-rc6. For educational purposes only.

Table of Contents

Installation: Setting up Rust & Substrate dependencies

UI Demo: Demo of UTXO implementation in a simple UI

Beginner Workshop: A self guided, 1 hour workshop that familiarizes you with Substrate.

Advanced Workshop: A self guided, 2 hour video tutorial, that teaches you how to build a UTXO blockchain from scratch.

Helpful Resources: Additional supporting documentation and references for troubleshooting.

Installation

1. Install or update Rust

curl https://sh.rustup.rs -sSf | sh

# On Windows, download and run rustup-init.exe
# from https://rustup.rs instead

rustup update nightly
rustup target add wasm32-unknown-unknown --toolchain nightly
rustup update stable

2. Clone this workshop

Clone your copy of the workshop codebase

git clone https://github.com/substrate-developer-hub/utxo-workshop.git

UI Demo

In this UI demo, you will interact with the UTXO blockchain via the Polkadot UI.

The following example takes you through a scenario where:

  • Alice already owns a UTXO of value 100 upon genesis
cargo build --release
  • Alice sends Bob a UTXO with value 50, tipping the remainder to validators
./target/release/utxo-workshop --dev --tmp

Compile and build a release node

Start a node. The --dev flag will start a single mining node, and the --tmp flag will start it in a new temporary directory.

In the console note the helper printouts. In particular, notice the default account Alice already has 100 UTXO within the genesis block.

Open Polkadot JS making sure the client is connected to your local node by going to Settings > General and selecting Local Node in the remote node dropdown.

Declare custom datatypes in PolkadotJS as the frontend cannot automatically detect this information. To do this, go to Settings > Developer tab and paste in the following JSON:

{
  "Address": "AccountId",
  "LookupSource": "AccountId",
  "Value": "u128",
  "TransactionInput": {
    "outpoint": "Hash",
    "sigscript": "H512"
  },
  "TransactionOutput": {
    "value": "Value",
    "pubkey": "Hash"
  },
  "Transaction": {
    "inputs": "Vec<TransactionInput>",
    "outputs": "Vec<TransactionOutput>"
  },
  "Difficulty": "U256",
  "DifficultyAndTimestamp": {
    "difficulty": "Difficulty",
    "timestamp": "Moment"
  },
  "Public": "H256"
}

Confirm that Alice already has 100 UTXO at genesis. In Chain State > Storage, select utxo. Input the hash 0x76584168d10a20084082ed80ec71e2a783abbb8dd6eb9d4893b089228498e9ff. Click the + notation to query blockchain state.

Notice that:

  • This UTXO has a value of 100
  • This UTXO belongs to Alice's pubkey. You use the subkey tool to confirm that the pubkey indeed belongs to Alice

Spend Alice's UTXO, giving 50 to Bob. In the Extrinsics tab, invoke the spend function from the utxo pallet, using Alice as the transaction sender. Use the following input parameters:

  • outpoint: 0x76584168d10a20084082ed80ec71e2a783abbb8dd6eb9d4893b089228498e9ff
  • sigscript: 0x6ceab99702c60b111c12c2867679c5555c00dcd4d6ab40efa01e3a65083bfb6c6f5c1ed3356d7141ec61894153b8ba7fb413bf1e990ed99ff6dee5da1b24fd83
  • value: 50
  • pubkey: 0x8eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a48

Verify that your transaction succeeded. In Chain State, look up the newly created UTXO hash: 0xdbc75ab8ee9b83dcbcea4695f9c42754d94e92c3c397d63b1bc627c2a2ef94e6 to verify that a new UTXO of 50, belonging to Bob, now exists! Also you can verify that Alice's original UTXO has been spent and no longer exists in UtxoStore.

Coming soon: A video walkthrough of the above demo.

Beginner Workshop

Estimated time: 2 hours

In this workshop you will:

  • Get familiar with basic Rust and Substrate functionality
  • Prevent malicious users from sending bad UTXO transactions

Your challenge is to fix the code such that:

  1. The Rust compiler compiles without any errors
  2. All tests in utxo.rs pass, ensuring secure transactions

Directions

  1. Checkout the workshop branch. The Master branch has the solutions, so don't peek!
git fetch origin workshop:workshop
git checkout workshop
  1. Cd into the base directory. Run the test using: cargo test -p utxo-runtime.
compiling utxo-runtime v2.0.0 (/Users/nicole/Desktop/utxo-workshop/runtime)
error[E0433]: failed to resolve: use of undeclared type or module `H512`
   --> /Users/nicole/Desktop/utxo-workshop/runtime/src/utxo.rs:236:31
    |
236 |             input.sigscript = H512::zero();
    |                               ^^^^ use of undeclared type or module `H512`

...

Your first task: fix all the compiler errors! Hint: Look for the TODO comments in utxo.rs to see where to fix errors.

Once your code compiles, it's now time to fix the 8 failing tests!

failures:
    utxo::tests::attack_by_double_counting_input
    utxo::tests::attack_by_double_generating_output
    utxo::tests::attack_by_over_spending
    utxo::tests::attack_by_overflowing_value
    utxo::tests::attack_by_permanently_sinking_outputs
    utxo::tests::attack_with_empty_transactions
    utxo::tests::attack_with_invalid_signature
    utxo::tests::test_simple_transaction
  1. In utxo.rs, edit the logic in validate_transaction() function to make all tests pass.
running 8 tests
test utxo::tests::attack_by_overflowing_value ... ok
test utxo::tests::attack_by_double_counting_input ... ok
test utxo::tests::attack_by_double_generating_output ... ok
test utxo::tests::attack_by_over_spending ... ok
test utxo::tests::attack_with_empty_transactions ... ok
test utxo::tests::attack_with_invalid_signature ... ok
test utxo::tests::attack_by_permanently_sinking_outputs ... ok
test utxo::tests::test_simple_transaction ... ok

Advanced Workshop

VIDEO TUTORIALS COMING SOON

Estimated time: 2 hours

In this workshop, you will implement this UTXO project from scratch using Substrate.

You will learn:

  • How to implement the UTXO ledger model on Substrate
  • How to secure UTXO transactions against attacks
  • How to seed genesis block with UTXOs
  • How to reward block validators in this environment
  • How to customize transaction pool logic on Substrate
  • Good coding patterns for working with Substrate & Rust, including testing and refactoring

Checkout the startercode branch to get the boilerplate for this workshop.

git fetch origin startercode:startercode
git checkout startercode

Helpful Resources


Author: substrate-developer-hub
Source Code: https://github.com/substrate-developer-hub/utxo-workshop
License: Unlicense License

#blockchain #substrate 

ERIC  MACUS

ERIC MACUS

1647489600

Substrate Developer Hub: Substrate Documentation

(Old) Substrate Developer Hub (ARCHIVED)

THIS SITE IS ARCHIVED.

This repository houses documentation for the Substrate blockchain framework.

The docs are written in markdown, processed by Docusaurus, and hosted at the Substrate Developer Hub.

Contributing

Thank you for your interest in contributing to the Developer Hub and to the larger Substrate community! Please review our contributor guidelines prior to any contribution. If you have any further questions, don't hesitate to reach out on our substrate technical community channel.

Directory Structure

This repository is structured as a Docusaurus project with the markdown files organized in the /docs directory. Images and other assets are in the /docs/assets/ directory. The /website directory is a Yarn Docusaurus project with many helpful scripts (e.g. yarn build, yarn start) for working with this codebase.  In the /website directory you will find sidebars.json and siteConfig.js, which are important Docusaurus files. You will find the source code for some top-level pages in /website/pages/en. Follow our contribution guidelines.

Adding a new document

To add a new markdown document:

  • Create your markdown document in a suitable directory inside /docs.
  • If you have images in your document, put them in the /docs/assets/ directory.
  • Documentation should follow our contribution guidelines.
  • If you want your document to appear in the sidebar, add its reference in the /website/sidebar.json file under the   corresponding section.

Rename an existing document

To rename an existing document:

  • Change the name or path of the document.
  • After the change has been merged, go to the Crowdin project,   make sure the translation is already migrated to the new file automatically for all the target languages.
  • Then go to Crowdin project settings, remove the   old source file in Files tab.
  • If you don't have access to the Crowdin project, please send email to substrate-developer-hub@parity.io with the   file information you want to remove.

Local Testing

  • cd into the /website directory.
  • Execute yarn install and then yarn start.

The Substrate Developer Hub website should open in a browser window.

Link Checker

Once the website is running, you should use the included Yarn script (yarn check-links) to ensure that your changes do not introduce any broken links and to check for any links that have broken since the last time the check was executed. Please ensure all links are fixed before submitting any changes; if you have questions about broken links that you did not introduce, please create an Issue.

Once you are done with your changes, feel free to submit a PR.

Updates

There is a helper script that can be used to update substrate.dev/rustdocs links in the docs/knowledgebase directory.

# This examples demonstrates updating links from v2.0.0-rc3 to v2.0.0-rc4
OLD_VERSION=v2.0.0-rc3 NEW_VERSION=v2.0.0-rc4 ./scripts/update-kb-rustdocs

Production Deployment

Our production site is at substrate.dev. To deploy to production, merge your update into the source branch. This triggers the CI to build the website AND also pull in multilingual translation from our Crowdin project. The final built static site is then pushed to the master branch and hosted on GitHub Pages.

Staging Deployment

We have a staging deployment at devhub-maindocs.herokuapp.com, which is hosted on Heroku. Please check with the devhub team for the username and password to access the staging site.

To deploy to staging, you could push to the staging-source branch in the repository. This will trigger the CI to build the website, pull in multilingual translations from crowdin, and have the final built static site being pushed to staging branch. This in turn triggers Heroku to pick up the latest commit from staging branch and deploy to the staging site.


Author: substrate-developer-hub
Source Code: https://github.com/substrate-developer-hub/substrate-developer-hub.github.io
License: Apache-2.0 License

#substrate #blockchain 

ERIC  MACUS

ERIC MACUS

1647481565

Substrate Docs: Substrate Developer Hub

Substrate Developer Hub

This repository serves as the developer hub for the Substrate blockchain framework. The docs are written in MDX format an extension of markdown, processed by Gatsby, and published to https://docs.substrate.io/ .

Contributing

Thank you for your interest in contributing to documentation for the Substrate development framework. As a member of the community, you are invited and encouraged to contribute by submitting issues, offering suggestions for improvements to existing content, adding review comments to existing pull requests, proposing new content, or creating new pull requests to fix issues or provide new content. Please review our contributor guidelines prior to any contribution. If you have any further questions, please do not hesitate to reach out on our Substrate technical community channel! We would love to get to know you and your work!

Directory structure

The content of this website is versioned in separate directories, where v<VERSION> is the convention used. The devhub is then hierarchically separated into the three main types of content: docs, how-to-guides, and tutorials.

Sub folders in these are of the form:

- v<VERSION>
  - <content type>
    - <XX-section>
      - <Y-page>
        - `index.mdx`

By convention we use XX numbering starting at 00 for sections, and Y lettering starting at a for pages.

File directory example: /v3/docs/00-style-and-contributor-guidelines/a-contributor-guidelines/index.mdx

Each index.mdx page has the content to be rendered to this page, and all pages include a header section with a slug item that is used for navigation on the generated site,

URL example: https://docs.substrate.io/v3/contribute/style-guide/

Configuration and styling files for gatsby live primarily in the src folder.

Builder notes

There are some unique requirements to be aware if you are contributing content in this repository to make your life, and the life of the maintainers much easier! Please review the Builder notes in the contributor guidelines if making any non-trivial PRs here.

Production deployment

🚀 Quick start

Clone the repo

# create a new folder to get going
git clone https://github.com/substrate-developer-hub/substrate-docs.git

Get setup

Navigate into your new site’s directory and install all dependencies.

cd substrate-docs/
nvm install
yarn # alias for `yarn install`

Configure environment variables

Copy example.env.development and rename to .env.development

Config URL variables based on your preferable local setup. URL will be used for links generation between Substrate websites.

Default localhost port configuration:

GATSBY_WEBSITE_URL=http://localhost:8100
GATSBY_DOCS_URL=http://localhost:8200
GATSBY_MARKETPLACE_URL=http://localhost:8300
GATSBY_CAREERS_URL=https://careers.substrate.io

Fire the engine

Navigate into your new site’s directory and use the following command to start the development server locally.

yarn develop

Open the code and start customizing!

Your site is now running at http://localhost:8001 and your GraphQL data layer is running at http://localhost:8000__graphql.

Edit to see your site update in real-time on save.

Learn more about GatbsyJS

Documentation

Tutorials

Guides

API Reference

Plugin Library

Cheat Sheet

Running link-checking locally

There are more than 10,000 links in this doc repo. So we have a link checker to go through most of them, both internal and external links, to make sure they are valid. We have settings to exclude some external links by default (more on this later).

We use blc (broken-link-checker) for links checking, which is a javascript project. It will be installed when you run yarn install in this package as it is depended on as a development package.

To run link checker, first in one terminal, build the gatsby site with clean cache:

yarn serve:fresh

This command takes a minute or two for the above command to complete, have the site built, and finally serving it at https://localhost:9000.

In another terminal, run:

yarn checklinks-local

You can further configure it in package.json file. Currently it has a list of paths being excluded. These paths are not regex-supported and just doing a plain string matching. They are excluded because for:

/rustdocs: all paths to /rustdocs/<splat> are going to be redirected to https://paritytech.github.io/substrate/. The redirection is handled by netlify redirect feature. Gatsby server will just rendered them as 404 pages.

/crates.io, /fonts.gstatic.com, /github.com, /wwww.nuget.org: they either have rate-limiting check or doesn't welcome web crawlers to fetch them and just return a 404 page.

Link checking as part of Github workflow

We configured a Github workflow to build the Gatsby site in production as a docker image and push it to Docker hub at jimmychu0807/substrate-docs. The image is then launched as a service in the next CI/CD job. checklinks is run against the running gatsby site in the docker container to check all links.

Security

Please report security bugs as stated in the static/security.txt file in this repository.


Author: substrate-developer-hub
Source Code:  https://github.com/substrate-developer-hub/substrate-docs
License: 

#substrate #blockchain