Substrate IBC: An IBC Implementation on Substrate via Cosmos

Substrate IBC Pallet (work in progress)

This project is funded by Interchain Foundation.

Purpose

This pallet implements the standard IBC protocol.

The goal of this pallet is to allow the blockchains built on Substrate to gain the ability to interact with other chains in a trustless way via IBC protocol.

This project is currently in an early stage and will eventually be submitted to upstream.

The pallet implements the chain specific logic of ICS spec, and is integrated with ibc-rs, which implements the generic cross-chain logic in ICS spec.

The chain specific logic of the modules in ICS spec implemented:

ics-002-client-semantics
ics-003-connection-semantics
ics-004-channel-and-packet-semantics
ics-005-port-allocation
ics-010-grandpa-client
ics-018-relayer-algorithms
ics-023-vector-commitments
ics-024-host-requirements
ics-025-handler-interface
ics-026-routing-module

Here is a demo for showing how to utilize this pallet, which initializes a series of steps for cross-chain communication, from client creation to sending packet data.

Design Overview

The ibc pallet is integrated with the modules in ibc-rs, which implements the ibc spec and leave the chain specific logics, which are named ???Readers and ???Keepers, to the ibc pallet.

List of Readers and Keepers of on-chain storage:

Installation

Thie section describe the modification of your substrate chain needed to integrate pallet ibc.

`Cargo.toml`

Specify some versions of ibc relevant crate

[patch.crates-io]
tendermint              = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-rpc          = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-proto        = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-light-client = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-light-client-verifier = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-testgen      = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }

#for libp2p
libp2p-noise                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-yamux                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-core                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-websocket                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-wasm-ext                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-uds                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-tcp                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-swarm-derive                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-swarm                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-request-response                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-relay                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-pnet                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-plaintext                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-ping                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-mplex                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-mdns                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-kad                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-identify                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-gossipsub                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-floodsub                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-dns                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-deflate                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }

Runtime's `Cargo.toml`

To add this pallet to your runtime, include the following to your runtime's Cargo.toml file:

pallet-ibc = { git = "https://github.com/octopus-network/substrate-ibc", branch = "master", default-features = false}

and update your runtime's std feature to include this pallet:

std = [
    # --snip--
    "pallet-ibc/std",
]

Runtime `lib.rs`

A custom structure that implements the pallet_ibc::ModuleCallbacks must be defined to dispatch messages to receiving module.

pub struct ModuleCallbacksImpl;

impl pallet_ibc::ModuleCallbacks for ModuleCallbacksImpl {}

impl pallet_ibc::Config for Runtime {
    type Event = Event;
    type ModuleCallbacks = ModuleCallbacksImpl;
    type TimeProvider = pallet_timestamp::Pallet<Runtime>;
}

You should include it in your construct_runtime! macro:

Ibc: pallet_ibc::{Pallet, Call, Storage, Event<T>},

Genesis Configuration

This pallet does not have any genesis configuration.

How to Interact with the Pallet

The Hermes (IBC Relayer CLI) offers commands to send reqeusts to pallet ibc to trigger the standard ibc communications defined in ibc spce. Hermes Command List.

Reference Docs

You can view the reference docs for this pallet by running:

cargo doc --open

or by visiting this site: https://docs.rs/pallet-ibc

Download Details:
Author: octopus-network
Source Code: https://github.com/octopus-network/substrate-ibc
License: Apache-2.0 License

#rust #blockchain #substrate #cosmos #ibc #octopus

Substrate IBC: An IBC Implementation on Substrate via Cosmos

Substrate IBC Pallet (work in progress)

This project is funded by Interchain Foundation.

Purpose

This pallet implements the standard IBC protocol.

The goal of this pallet is to allow the blockchains built on Substrate to gain the ability to interact with other chains in a trustless way via IBC protocol.

This project is currently in an early stage and will eventually be submitted to upstream.

The pallet implements the chain specific logic of ICS spec, and is integrated with ibc-rs, which implements the generic cross-chain logic in ICS spec.

The chain specific logic of the modules in ICS spec implemented:

ics-002-client-semantics
ics-003-connection-semantics
ics-004-channel-and-packet-semantics
ics-005-port-allocation
ics-010-grandpa-client
ics-018-relayer-algorithms
ics-023-vector-commitments
ics-024-host-requirements
ics-025-handler-interface
ics-026-routing-module

Here is a demo for showing how to utilize this pallet, which initializes a series of steps for cross-chain communication, from client creation to sending packet data.

Design Overview

The ibc pallet is integrated with the modules in ibc-rs, which implements the ibc spec and leave the chain specific logics, which are named ???Readers and ???Keepers, to the ibc pallet.

List of Readers and Keepers of on-chain storage:

Installation

Thie section describe the modification of your substrate chain needed to integrate pallet ibc.

`Cargo.toml`

Specify some versions of ibc relevant crate

[patch.crates-io]
tendermint              = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-rpc          = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-proto        = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-light-client = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-light-client-verifier = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }
tendermint-testgen      = { git = "https://github.com/informalsystems/tendermint-rs", branch = "v0.23.x" }

#for libp2p
libp2p-noise                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-yamux                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-core                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-websocket                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-wasm-ext                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-uds                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-tcp                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-swarm-derive                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-swarm                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-request-response                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-relay                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-pnet                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-plaintext                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-ping                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-mplex                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-mdns                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-kad                     = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-identify                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-gossipsub                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-floodsub                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-dns                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }
libp2p-deflate                    = { git = "https://github.com/octopus-network/rust-libp2p.git", branch = "feature/dep-ibc-rs" }

Runtime's `Cargo.toml`

To add this pallet to your runtime, include the following to your runtime's Cargo.toml file:

pallet-ibc = { git = "https://github.com/octopus-network/substrate-ibc", branch = "master", default-features = false}

and update your runtime's std feature to include this pallet:

std = [
    # --snip--
    "pallet-ibc/std",
]

Runtime `lib.rs`

A custom structure that implements the pallet_ibc::ModuleCallbacks must be defined to dispatch messages to receiving module.

pub struct ModuleCallbacksImpl;

impl pallet_ibc::ModuleCallbacks for ModuleCallbacksImpl {}

impl pallet_ibc::Config for Runtime {
    type Event = Event;
    type ModuleCallbacks = ModuleCallbacksImpl;
    type TimeProvider = pallet_timestamp::Pallet<Runtime>;
}

You should include it in your construct_runtime! macro:

Ibc: pallet_ibc::{Pallet, Call, Storage, Event<T>},

Genesis Configuration

This pallet does not have any genesis configuration.

How to Interact with the Pallet

The Hermes (IBC Relayer CLI) offers commands to send reqeusts to pallet ibc to trigger the standard ibc communications defined in ibc spce. Hermes Command List.

Reference Docs

You can view the reference docs for this pallet by running:

cargo doc --open

or by visiting this site: https://docs.rs/pallet-ibc

Download Details:
Author: octopus-network
Source Code: https://github.com/octopus-network/substrate-ibc
License: Apache-2.0 License

#rust #blockchain #substrate #cosmos #ibc #octopus

Rust Blockchain

1647262500

Quantum Tunnel: A Rust Cosmos to Connect Substrate Relayer

QuantumTunnel

QuantumTunnel is a basic relayer developed to connect tendermint_light_client and substrate_light_client with any cosmos and substrate chain respectively. It can also be used to test either substrate_light_client or tendermint_light_client by simulating their target chains. Refer here to know how it works under the hood.

This application is authored using Abscissa, a Rust application framework.

Compilation

To build QuantumTunnel you need to have rust nightly toolchain installed. You can find instructions here. After you have nightly toolchain installed, just run: make build

Running

QuantumTunnel relies on json files to read chain connection configuration, passed by -c command line argument. QuantumTunnel can either connects to live chain or read simulation data from file and pass it to light client.

If we are connecting to live chain as opposed to read simulation data, you need to set following environment variables:

For Substrate live chain: SUBSTRATE_SIGNER_SEED=<your >= 12 words seed>

For Cosmos live chain: COSMOS_SIGNER_SEED=<your >= 12 words seed>

The test_data folder in the repository contains different type of configuration and simulation data for both cosmos and substrate chain. Each chain's configuration field in json can be of two forms: real or simulation. Let's take a look at an example configuration:

{
  "cosmos": {
    "real": {
      "chain_id": "testing",
      "rpc_addr": "http://localhost:26657/",
      "lcd_addr": "http://localhost:1317/",
      "trusting_period": "720h",
      "unbonding_period": "721h",
      "max_clock_drift": "30s",
      "wasm_id": 1,
      "gas": 90000000,
      "gas_price": "0.25stake",
      "default_denom": "stake"
    }
  },
  "substrate": {
    "simulation": {
      "simulation_file_path": "test_data/substrate_light_client_simulated_2.txt",
      "should_run_till_height": 7
    }
  }
}

In this example, QuantumTunnel will connect to a real cosmos chain exposing rpc interface at port 26657, but on substrate side it will read headers from the file substrate_light_client_simulated_2.txt. This config implies to QuantumTunnel that we want to test substrate_light_client running on cosmos chain with simulation data contained in substrate_light_client_simulated_2.txt and the simulation will be considered success only if the substrate_light_client will run till height 7. This feature is useful to test light client against invalid header sequence. If the simulation is successful quantum tunnel will exit with zero, otherwise it will panic and exit with non-zero status code.

How it works?

Quantum tunnel is asynchronus application relies on tokio to handle four tasks, which communicates with each other using crossbeam channels:

Cosmos send handler: Receives substrate header data from Substrate receive handler and send them to substrate light client running inside the cosmos chain.
Cosmos receive handler: Receives new headers from cosmos blockchain or simulation file and send them to Substrate send handler.
Substrate send handler: Receives new cosmos headers from Cosmos receive handler and send them to cosmos light client running inside the substrate chain.
Substrate receive handler: Receives new headers from substrate blockchain or simulation file and send them to Cosmos send handler.

Each side's handlers can start in one of the two modes:

Simulation mode: In simulation mode, receive handler reads header data from file instead of querying live chain and also keeps track of how many blocks has been consumed by opposite chain's send handler to determine result of the simulation. send handler in simulation mode just drains header data sent by opposite chain's receive handler, to prevent crossbeam channel to accumulate large number of unsent data. At max only one chain's handlers can run in simulation mode.
Real mode: In real mode, receive handler reads header data from live chain and pass it to opposite chain's send handler, which formats it and sends it to light client running in its chain.

Download Details:
Author: ChorusOne
Source Code: https://github.com/ChorusOne/quantum-tunnel
License: Apache-2.0 License

#rust #blockchain #substrate #cosmos #polkadot

Angelina roda

1625006340

What is Cosmos? | $ATOM Cryptocurrency Explained!

Wondering what is Cosmos? In this video, I explain what the Cosmos network is in simple language and explain the role of Cosmo’s native cryptocurrency – ATOM. So, let’s check it out!
Before the Cosmos Network, blockchains were siloed and unable to communicate with each other. They were hard to build and could only handle a small number of transactions per second. Cosmos offers a solution to some of those nagging issues of scalability, usability and interoperability we see in legacy blockchains such as Bitcoin and Ethereum.

The goal of Cosmos is to create the “Internet of Blockchains,” a network of blockchains able to communicate with each other in a decentralized way.

Who Created Cosmos?

The Interchain Foundation or – ICF for short - is a Swiss non-profit foundation that was formed to support the development of Cosmos and the ecosystem that will contribute to the Cosmos Network.

The ICF raised $17 million in April 2017 to fund the development of the Cosmos network. Since then, the price of ATOMS has ballooned to enormous heights. In an interview in late 2019 with CoinDesk, the ICF mentioned their treasury reserves have grown to over $100 million – and so this project is extremely well funded.

What Problem Does Cosmos Solve?

The Cosmos Network Will Address Three Issues:

The first issue the Cosmos Networks Addresses is Scalability Limitations: Decentralized applications built on top of Ethereum – for example - are inhibited by a low transaction rate – at the time of recording about 15 transactions per second. This is due to the Proof-of-Work consensus mechanism and dApps compete for the limited resources of a single blockchain. Although Ethereum is shifting to Proof of Stake, Ethereum still has serious concerns with scalability limitations. the Cosmos Network’s BFT Proof-of-Stake mechanism will enhance scalability and efficiency.
The second issue the Cosmos Network Addresses is Usability Limitations: Developers are granted a very low level of flexibility; they have to make certain compromises on the design and efficiency of their application, they are limited to only a few programming languages, and cannot implement automatic execution of code. The Cosmos Network changes this by enabling developers to code in the popular Go programming language.
The third issue the Cosmos network addresses is Interoperability Limitations: Historically, every blockchain developed are siloed and are unable to transfer assets between each other. The Cosmos Network changes this by developing a messaging protocol for blockchains to make them connected.

What is Cosmos Solution?

Cosmos achieves its goal of creating the Internet of Blockchains through a set of innovative open-source tools such as Tendermint, the Cosmos SDK and IBC. Cosmos makes blockchains powerful and easy to develop with Tendermint and the modularity of the Cosmos SDK. IBC enables blockchains to transfer value between one another. Cosmos uses an organizational concept of Hubs and Zones to connect one another. I explain each of these in more detail in the video!

What is ATOM?

The Cosmos Hub, a proof-of-stake blockchain, is powered by its native ATOM cryptocurrency. ATOM is the staking coin that is mainly used for governance.

Buyers of the ATOMS token can store their coins in a wallet or on an exchange to support the operation of the blockchain network to earn rewards and free cryptocurrency. Users that stake Cosmos are rewarded with annual yield of about 8 – 10 %.

The Cosmos Network envisions making it easy for developers to build application-specific blockchains, and breaking down the barriers between blockchains to communicate and transact with each other. The end goal is to create an Internet of Blockchains, a decentralized network of independent, scalable, and interoperable blockchains. Cosmos is an extremely exciting project and one that offers a ton of value to the entire ecosystem.

📺 The video in this post was made by Will Walker
The origin of the article: https://www.youtube.com/watch?v=KzeMok0Rfcw
🔺 DISCLAIMER: The article is for information sharing. The content of this video is solely the opinions of the speaker who is not a licensed financial advisor or registered investment advisor. Not investment advice or legal advice.
Cryptocurrency trading is VERY risky. Make sure you understand these risks and that you are responsible for what you do with your money
🔥 If you’re a beginner. I believe the article below will be useful to you ☞ What You Should Know Before Investing in Cryptocurrency - For Beginner
⭐ ⭐ ⭐The project is of interest to the community. Join to Get free ‘GEEK coin’ (GEEKCASH coin)!
☞ **-----CLICK HERE-----**⭐ ⭐ ⭐
Thanks for visiting and watching! Please don’t forget to leave a like, comment and share!

#bitcoin #blockchain #cosmos #$atom #cryptocurrency #what is cosmos

Rust Blockchain

1643578320

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:

matrix: #substrate-archive:matrix.parity.io
email: andrew.plaza@parity.io

# /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

Smart Contract Dev

1651634220

Pure Rust Implementation Of Secp256k1 for Polkadot

SECP256K1 implementation with no_std support. Currently we have implementation for:

Convert a private key to a public key.
Sign messages.
Signature verification.
Public key recovery from signed messages.
Shared secrets.

Feature flags

std: If disabled, works in no_std environment. Enabled by default.
hmac: Add certain features that requires the HMAC-DRBG. This includes signing. Enabled by default.
static-context: To speed up computation, the library uses a pre-computed table context for many ecmult operations. This feature flag puts the context directly as static variables. If disabled, the context must be created from heap manually. Increases binary size, enabled by default.
lazy-static-context: Instead of storing the pre-computed table context as static variables, store it as a variable that dynamically allocates the context in heap via lazy_static. It overwrites static-context. Impact bootstrap performance and only available in std, disabled by default.

Development workflow

Branch

This repository uses develop branch for development. Changes are periodically merged to master branch.

Pull request

All changes (except new releases) are handled through pull requests. Please open your PR against develop branch.

Versioning

libsecp256k1 follows Semantic Versioning. An unreleased crate in the repository will have the -dev suffix in the end, and we do rolling releases.

When you make a pull request against this repository, please also update the affected crates' versions, using the following rules. Note that the rules should be applied recursively -- if a change modifies any upper crate's dependency (even just the Cargo.toml file), then the upper crate will also need to apply those rules.

Additionally, if your change is notable, then you should also modify the corresponding CHANGELOG.md file, in the "Unreleased" section.

If the affected crate already has -dev suffix:

If your change is a patch, then you do not have to update any versions.
If your change introduces a new feature, please check if the local version already had its minor version bumped, if not, bump it.
If your change modifies the current interface, please check if the local version already had its major version bumped, if not, bump it.

If the affected crate does not yet have -dev suffix:

If your change is a patch, then bump the patch version, and add -dev suffix.
If your change introduces a new feature, then bump the minor version, and add -dev suffix.
If your change modifies the current interface, then bump the major version, and add -dev suffix.

If your pull request introduces a new crate, please set its version to 1.0.0-dev.

Download Details:
Author: paritytech
Source Code: https://github.com/paritytech/libsecp256k1
License: Apache-2.0 License

#blockchain #substrate #polkadot #smartcontract #substrate

Substrate IBC: An IBC Implementation on Substrate via Cosmos

Substrate IBC Pallet (work in progress)

Purpose

Design Overview

Installation

Cargo.toml

Runtime's Cargo.toml

Runtime lib.rs

Genesis Configuration

How to Interact with the Pallet

Reference Docs

Substrate IBC Pallet (work in progress)

Purpose

Design Overview

Installation

Cargo.toml

Runtime's Cargo.toml

Runtime lib.rs

Genesis Configuration

How to Interact with the Pallet

Reference Docs

QuantumTunnel

Compilation

Running

How it works?

Substrate Archive

Usage

Prerequisites

Install The CLI

The CLI

The Node-Template CLI

Quick Start

Contributing

Documentation

Troubleshooting

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

Contact

Feature flags

Development workflow

Branch

Pull request

Versioning

`Cargo.toml`

Runtime's `Cargo.toml`

Runtime `lib.rs`

`Cargo.toml`

Runtime's `Cargo.toml`

Runtime `lib.rs`

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