Substrate: The platform for blockchain innovators

Last update: Jun 17, 2022

Substrate · GitHub license GitLab Status PRs Welcome

Substrate is a next-generation framework for blockchain innovation 🚀 .

Trying it out

Simply go to substrate.dev and follow the installation instructions. You can also try out one of the tutorials.

Contributions & Code of Conduct

Please follow the contributions guidelines as outlined in docs/CONTRIBUTING.adoc. In all communications and contributions, this project follows the Contributor Covenant Code of Conduct.

Security

The security policy and procedures can be found in docs/SECURITY.md.

License

The reason for the split-licensing is to ensure that for the vast majority of teams using Substrate to create feature-chains, then all changes can be made entirely in Apache2-licensed code, allowing teams full freedom over what and how they release and giving licensing clarity to commercial teams.

In the interests of the community, we require any deeper improvements made to Substrate's core logic (e.g. Substrate's internal consensus, crypto or database code) to be contributed back so everyone can benefit.

GitHub

https://github.com/paritytech/substrate
Comments
  • 1. update README.adoc

    Fixes for better understanding and reading to developers. Added exact outputs and specific word names.

    Thank you for your Pull Request!

    Before you submitting, please check that:

    • [x] 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 appropriately if you have permissions to do so:
      • [ ] A* for PR status (one required)
      • [ ] B* for changelog (one required)
      • [ ] C* for release notes (exactly one required)
      • [ ] D* for various implications/requirements
      • [ ] Github's project assignment
    • [ ] 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 to the style guide
      • In particular, mind the maximal line length of 100 (120 in exceptional circumstances).
      • 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?

    Refer to the contributing guide for details.

    After you've read this notice feel free to remove it. Thank you!

    ✄ -----------------------------------------------------------------------------

    Reviewed by 6636345e at 2021-03-20 12:12
  • 2. Benchmarking also benchmark for decoding the call

    in the benchmarking macro, when user use the syntax: bench_name { $code }: $dispatch_name($origin, $args) verify { $code }, the benchmark only dispatch the call. This PR changes it, instead the benchmark decode the call and dispatch it.

    Breaking change

    Some benchmark code won't compile complaining about partially moved variables. It should be generally easily fixable using clone.

    Reviewed by thiolliere at 2021-07-13 18:25
  • 3. Implement `pallet-bags-list` and its interfaces with `pallet-staking`

    closes https://github.com/paritytech/substrate/issues/9440

    polkadot companion https://github.com/paritytech/polkadot/pull/3413

    Notes for reviewers

    Below is a table describing how an extrinsic would affect an account (relative to SortedListProvider and CounterForNominators) given its role in staking:

    | extrinsic | Chilled | Nominator | Validator | |:------------------:|:----------------------:|:----------------------:|------------------------| | chill, chill_other | nothing, nothing | on_remove, dec counter | nothing, nothing | | nominate | on_insert, inc counter | nothing, nothing | on_insert, inc counter | | validate | nothing, nothing | on_remove, dec counter | nothing, nothing | | bond_extra | nothing, nothing | on_update, nothing | nothing, nothing | | rebond | nothing, nothing | on_update, nothing | nothing, nothing | | unbond | nothing, nothing | on_update, nothing | nothing, nothing |

    TODO:

    • [x] update benchmarks of extrinsics that call do_rebag to force a rebag (relates to some work done in https://github.com/paritytech/substrate/pull/9529)
    • [x] Check the benchmark values for snapshot creation. There are some tests that tell us how many snapshot items we can take in a 2 second block. https://github.com/paritytech/substrate/pull/9507#issuecomment-899466440
    • [x] Write a remote-externalities-based test that checks the state of polkadot and substrate, and populates the list. Same as testing the migration basically: Done in companion.
    • [x] Test migration

    • [ ] (seperate_pr) Make all staking tests work with and without bags-list. For now we use bags-list only, and we do this in a follow up, to prevent a single super big PR.
    • [x] rename and fix docs, avoid using voter in bags-list, it should be id and vote-weight. Ideally we could also use something like priority instead of vote-weight.
    • [ ] (maybe+separate PR) Write a fuzzer/quick test that just bombards the SortedListProvider with random data and calls, and the internal state of the pallet should always remain correct. (https://github.com/paritytech/substrate/pull/9851)
    • [ ] (seperate pr) weight refunds for when the operation does not affect nominators (and thus not the bags list)
    • [ ] (separate PR) Allow the ability to reorder yourself within a bag.

    original description for #9081 below:

    Problem: there are too many nominators, we can't keep all of them. Solution: truncate the list by stake.

    Problem: an attacker can kick out as many people as they can afford to; those people at the low end would need to re-nominate. Solution: don't actually take them out of the nominator set, but compute the top N members at runtime.

    Problem: computing the top N at runtime is expensive. Solution: create many bags, each of which holds voters within a particular stake range. Each bag is a linked list, so it can be added to and removed from in O(1). We can then iterate over the bags in order and truncate anywhere we desire. Given a realistic distribution of stake, it doesn't matter where we stop; the final bag is the one with the lowest-staked individuals.

    polkadot companion: https://github.com/paritytech/polkadot/pull/3413

    Reviewed by emostov at 2021-08-05 21:21
  • 4. BREAKING Overlay transaction support.

    BREAKING: this pr adds externalities, and change mutability of existing one, the corresponding

    This PR is a refactor of overlay_change to allow transactional support, it is similar to #2980 goals, but does not stack Ext, it only stacks storage.

    It also switches from a stack of hashmap (previously prospective and top) to a single hashmap (containing history of values) and a transaction global state. Those values with state are managed with 'historied-data' crate (simple vec of data to query in front of a reference global state).

    Under this design access to data is not badly impacted by the number of open transactional layers. I did fuzz this code a bit against a partial simple layered hashmap implementation.

    Usage from a runtime with a function, in a similar way as ext_try from #2980, there is the very simple with_transaction function: internally it uses three host functions ext_start_transaction, ext_commit_transaction and ext_discard_transaction. This does not look as good as the single ext_try but is clearer: memory mgmt seems way simplier (as there is none).

    Note that to call global state action, modification of local values need to be synchronize. eg discard_transaction on states must be follow by apply_discard_transaction for all values related to this state and then follow by ensure_running.

    Technically we only maintain a counter of current number of stacked transaction as a global state (this start at 1 and can be 0 only to update some values: case of discarding content, but will then return to 1 through 'finalize_discard' call). Local state is either committed or the number of stacked transaction when the value was changed, this state is stored with the value history.

    polkadot companion: https://github.com/paritytech/polkadot/pull/999

    Reviewed by cheme at 2019-07-30 17:48
  • 5. pallet-vesting: Support multiple, merge-able vesting schedules

    closes: https://github.com/paritytech/substrate/issues/7101 polkadot companion: https://github.com/paritytech/polkadot/pull/3407

    Features

    • Support multiple vesting schedules per account. Each account is allowed up to MaxVestingSchedules, which is a configurable pallet constant.
    • A user can merge two schedules together to create a new schedule. See the new merge_schedules extrinsic

    Follow up work

    • Look into adding a vesting derive to polkadot-js that helps with understanding the affects of merging a schedule

    TODO:

    • [x] make sure all instances of per_block are replace with One::one if it equals 0. (https://github.com/paritytech/substrate/pull/9202#issuecomment-874501009)
    • [x] weights
    • [x] polkadot companion
    • [x] migration (check if any faulty schedules exist in polkadot)
    • [x] make sure tests cover (checked everything expect still need to figure out how force invalid vec length)
      • all dispatcherror paths are checked as noop <-- (a lot, and its important)
        • max length
        • validation of input ✔️
        • etc
      • shows single vesting is working just like before ✔️
      • shows multiple vesting works as expected ✔️
        • as a vesting ends, the vec is auto cleaned up
        • the last assertion at the end of N blocks is that the user has no vesting storage item left ✔️
      • merges two ongoing vesting schedules ✔️
      • merges one ended and one ongoing schedule ✔️
      • merges two ended schedules ✔️
      • merge ongoing and yet to be started schedule ✔️
      • merge ended and yet to be started schedule ✔️
      • merge 2 not yet started schedules ✔️
      • Check div by zero ✔️
    Reviewed by emostov at 2021-06-25 03:22
  • 6. Metadata with complete type information

    This fixes #917, which is one of the biggest pain point to me when working with Substrate (and polkadot.js), that any type information needs to be implemented twice and incompatible type information simply cause polkadot.js crashes without much helpful clues (other than it is mostly likely a codec error).

    This introduce type_registry to RuntimeMetadata which contains all the type informations i.e. the metadata itself stores the information about how to decode the storage types.

    Ideally, this will remove the needs to manually maintain type information in polkadot.js (currently implemented at https://github.com/polkadot-js/api/tree/master/packages/types/src). Those JS classes can be generated at runtime by parsing the metadata. TS files can be generated ahead-of-time if needed. This will also make implement (and support) other languages SDK much easily.

    Some code copied from parity-codec.

    Fixes #917 Enable the proper fix for https://github.com/polkadot-js/api/issues/416 Could be the foundation work for https://github.com/polkadot-js/api/issues/429

    This is the debug print of the resulting metadata: https://gist.github.com/xlc/19d010e55f84bf6d43afafdc5e5b5df6#file-metadata-L5525

    Reviewed by xlc at 2018-12-24 12:29
  • 7. New Weight Template + Organization

    This PR updates the organization of Weights using the new Handlebars based template generator.

    This layout should improve automation of weight generation (reducing from 2 files to 1), and ultimately be way more flexible in terms of the layout and content of the generated files.

    See https://github.com/paritytech/substrate/pull/7390 for more context.

    Reviewed by shawntabrizi at 2020-10-25 18:29
  • 8. Fix elections-phragmen and proxy issue

    Closes https://github.com/paritytech/substrate/issues/7030 polkadot companion: https://github.com/paritytech/polkadot/pull/1719

    📕 Detailed description of the PR is here

    Reviewed by kianenigma at 2020-09-07 14:43
  • 9. Decouple Staking and Election - Part 3: Signed Phase

    Attempt to break down #7319. Part 3

    Part1: https://github.com/paritytech/substrate/pull/7908 Part 2: https://github.com/paritytech/substrate/pull/7909

    Adds signed phase, ~~relatively light to review~~.

    polkadot companion: https://github.com/paritytech/polkadot/pull/2793

    Reviewed by kianenigma at 2021-01-15 15:57
  • 10. Enrich metadata with type information

    :warning: Breaking Metadata Change :warning:

    Closes https://github.com/paritytech/substrate/issues/917 :eyes:,

    polkadot companion: https://github.com/paritytech/polkadot/pull/3336

    Migration guide: https://gist.github.com/ascjones/0d81a4c44e84cacd9f714cd34a6de823

    Overview

    • Replaces in tree frame-metadata crate with https://github.com/paritytech/frame-metadata/
    • New v14 metadata structure defined here, which contains type information using scale-info
    • Annotates all SCALE encoded types with TypeInfo derive which will generate the static type information to be provided in the metadata.

    See the latest generated metadata json for the default node-runtime here. This was generated by running the substrate node on this branch and then running https://github.com/ascjones/subsee to download and decode -> json serialize.

    A prototype (Rust only for now) code generator exists here: https://github.com/ascjones/chameleon to verify whether there is enough information in the metadata to generate all types.

    todo:

    • [x] Generate errors metadata
    • [x] Restore and fix all commented out tests
    • [x] Figure out how to handle the existing DefaultByteGetter pattern for storage/constants for the new metadata.
    • [x] scale-info 0.7 release containing all substrate compatibility features
      • [x] update parity-common and frame-metadata to use this release
    • [x] Decide how to handle custom (non derived) codec encoding (see todos).
    • [x] Are the all the (required for scale-info type registration) vec! allocations okay which replace existing static array refs?
    • [x] Clean up and unify namespacing of frame-metadata and scale-info types, e.g. remove all the v13s and add some imports to remove fully qualified types, which are there primarily for easy grepping during development.
    • [x] Polkadot companion
    • [x] Revisit handling of PhantomData in scale-info as it can in some cases require an unnecessary trait bound for the generic parameter. Can just skip those fields, or just revisit the approach, see https://github.com/paritytech/scale-info/blob/f0f689be810fc221a2aa9f015c0b0e1cd35fdd55/src/ty/mod.rs#L425
    • [ ] Benchmark:
      • [x] Code size: by how much does this increase the size of the resulting wasm blob? If significantly we should consider storing the metadata somewhere else other than the runtime (see https://github.com/paritytech/substrate/discussions/8370#discussioncomment-487982)
      • [x] The size of the encoded metadata itself, the result of state_getMetadata, is there a benefit to oregenerating/compressing it? Relates to previous point.
      • [ ] Compilation times: how does having the extra type metadata affect the overall substrate compilation times? If a considerable slowdown then should we consider feature gating the metadata generation?
    • [x] Replace existing frame-metadata crate with https://github.com/paritytech/frame-metadata
      • [x] Remove existing crate and replace all usages
      • [x] Publish frame-metadata to crates.io and replace git dependecies with that
    • [ ] Verify encoding and decoding of substrate calls/events/storage/constants using the metadata, e.g. using https://github.com/ascjones/chameleon
    • [x] Note follow ups from review comments, possibly create an issue for them.

    Follow ups:

    • avoid explicit OpaqueMetadata::new(Runtime::metadata().into()) in runtime metadata API: https://github.com/paritytech/substrate/pull/8615#discussion_r665132975
    Reviewed by ascjones at 2021-04-13 15:37
  • 11. Replace libsecp256k1 with secp256k1

    Closes #8089 #9870

    libsecp256k has been replaced by secp256k1.

    According to the benchmarks the latter has been found to be faster by a factor of three/four.

    SecretKey memory cleanup has been implemented on Pair drop.

    Unfortunately this strategy is not effective over Pair moves (or the slices used to initialize Pair itself). This is a known issue and affects ed25519 and sr25519 secrets as well (even though they are using zeroize crate). More on this here

    The interfaces were left unchanged.

    polkadot companion: https://github.com/paritytech/polkadot/pull/4861

    Reviewed by davxy at 2022-02-04 15:23
  • 12. Remove Storage Layer Limit

    This PR removes the limit of creating new transactional storage layers.

    Instead, we will rely on the stack depth limit and sensible runtime development patterns to avoid people abusing the limit on transactional storage layers. And sensible depth of transactional layers should have a nominal impact into the measured performance of extrinsics.

    Note that it is still important that we track the number of storage layers, since we want to be able to tell that we are in a transactional layer at any point in time.

    Reviewed by shawntabrizi at 2022-06-23 23:40
  • 13. Rename outer enums to `OuterCall`, `OuterEvent`, etc

    we should really just rename the Call generated by the construct_runtime! to OuterCall.

    Originally posted by @kianenigma in https://github.com/paritytech/substrate/pull/8458#discussion_r602125898


    See confusions such as https://substrate.stackexchange.com/questions/3360/using-scheduler-pallet-to-schedule-contract-pallet-call

    Reviewed by kianenigma at 2022-06-22 14:05
  • 14. Allow timezone configuration for logs

    It is easier to deal and correlate logs in UTC, but currently node uses local timezone for logs and there is no config option that I can see to change that.

    Would be great to support such customization or even disabling default log handler such that node implementation can create its own.

    Reviewed by nazar-pc at 2022-06-22 13:20
  • 15. Node can send multiple same block requests while syncing from other nodes

    Is there an existing issue?

    • [X] I have searched the existing issues

    Experiencing problems? Have you tried our Stack Exchange first?

    • [X] This is not a support question.

    Description of bug

    Let's say node A is trying to sync from B, the block requests from A are not protected from sending the same block request multiple times, which can cause the B to mark A as a bad node sending the same requests over and over again and then send back an error result which will be considered as Refused on the side A.

    From node_A.log, you can see the same block request was sent dozens of times.

    $ cat node_A.log | grep 'New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, .* BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }'
    2022-06-22 16:36:32.202 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150023, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:36:42.787 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150024, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:36:54.317 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150026, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:37:04.543 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150030, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:37:15.808 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150030, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:37:28.596 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150032, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:37:40.292 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150034, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:37:50.816 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150035, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:38:02.211 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150036, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:38:14.312 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150041, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:38:26.220 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150044, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:38:36.866 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150046, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:38:48.553 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150046, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:39:00.230 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150046, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:39:11.379 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150048, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    2022-06-22 16:39:22.507 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150050, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }
    .....
    

    If I read it correctly, once the request was processed for the first time, with 2 more same requests, the reputation would change, Err(()) will be returned, on the side of node A, Err(()) will be converted as RequestFailure::Refused. Those two nodes will disconnect from each other afterwards.

    https://github.com/paritytech/substrate/blob/3c99545cb062fbc56b84e2f3e44def3b933123cd/client/network/sync/src/block_request_handler.rs#L216

    https://github.com/paritytech/substrate/blob/3c99545cb062fbc56b84e2f3e44def3b933123cd/client/network/src/request_responses.rs#L662

    2022-06-22 16:39:46.896 TRACE tokio-runtime-worker sync: [PrimaryChain] New block request for 12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP, (best:150056, common:2918) BlockRequest { id: 0, fields: HEADER | BODY | JUSTIFICATION, from: Number(2982), to: None, direction: Descending, max: Some(64) }    
    2022-06-22 16:39:47.438 DEBUG tokio-runtime-worker sync: [PrimaryChain] Request to peer PeerId("12D3KooWMkto1n3dJ7mu8zUiokrjkwcUzEveeyyrk9gJeLNQ5PWP") failed: Refused.
    

    Steps to reproduce

    No response

    Reviewed by liuchengxu at 2022-06-22 09:33
  • 16. Latest tagged ci-linux Docker image failing

    Is there an existing issue?

    • [X] I have searched the existing issues

    Experiencing problems? Have you tried our Stack Exchange first?

    • [X] This is not a support question.

    Description of bug

    It seems that using the latest tagged ci-linux Docker image fails to compile/test our project in a GitLab runner.

    We have an open PR to upgrade deps to 0.9.24, but it seems that anything different than paritytech/ci-linux:production fails to build the project because of an error related to prost-build v0.10.4.

    Here is a link to the latest failed CI job that was trying to use paritytech/ci-linux:eb1f6a26-20220518 (the latest image that is not production nor staging), while here is a link with a successful job using patitytech/ci-linux:production.

    We would rather upgrade the CI image version ourselves rather than always using the latest production. Is using production now the recommended way?

    Steps to reproduce

    No response

    Reviewed by ntn-x2 at 2022-06-22 07:00
The Nervos CKB is a public permissionless blockchain, and the layer 1 of Nervos network.

Nervos CKB - The Common Knowledge Base master develop About CKB CKB is the layer 1 of Nervos Network, a public/permissionless blockchain. CKB uses Pro

Jun 19, 2022
The Phala Network Blockchain, pRuntime and the bridge.
The Phala Network Blockchain, pRuntime and the bridge.

Phala Blockchain Phala Network is a TEE-Blockchain hybrid architecture implementing Confidential Contract. This repo includes: node/: the main blockch

Jun 15, 2022
Blockchain written with educational purpose
Blockchain written with educational purpose

Blockchain written with educational purpose

Feb 24, 2022
CosmWasm Multisend Contract on Terra Blockchain
CosmWasm Multisend Contract on Terra Blockchain

CosmWasm Multisend Contract on Terra Blockchain This is a multisend smart contracts in Rust built to run on Cosmos SDK module on all chains that enabl

Mar 31, 2022
Substrate: The platform for blockchain innovators
Substrate: The platform for blockchain innovators

Substrate · Substrate is a next-generation framework for blockchain innovation ?? . Trying it out Simply go to substrate.dev and follow the installati

Jun 23, 2022
Substrate: The platform for blockchain innovators
Substrate: The platform for blockchain innovators

Substrate · Substrate is a next-generation framework for blockchain innovation ?? . Trying it out Simply go to substrate.dev and follow the installati

Jun 17, 2022
Substrate: The platform for blockchain innovators
Substrate: The platform for blockchain innovators

Substrate · Substrate is a next-generation framework for blockchain innovation ?? . Trying it out Simply go to docs.substrate.io and follow the instal

Jan 8, 2022
Easy c̵̰͠r̵̛̠ö̴̪s̶̩̒s̵̭̀-t̶̲͝h̶̯̚r̵̺͐e̷̖̽ḁ̴̍d̶̖̔ ȓ̵͙ė̶͎ḟ̴͙e̸̖͛r̶̖͗ë̶̱́ṉ̵̒ĉ̷̥e̷͚̍ s̷̹͌h̷̲̉a̵̭͋r̷̫̊ḭ̵̊n̷̬͂g̵̦̃ f̶̻̊ơ̵̜ṟ̸̈́ R̵̞̋ù̵̺s̷̖̅ţ̸͗!̸̼͋

Rust S̵̓i̸̓n̵̉ I̴n̴f̶e̸r̵n̷a̴l mutability! Howdy, friendly Rust developer! Ever had a value get m̵̯̅ð̶͊v̴̮̾ê̴̼͘d away right under your nose just when

Jun 24, 2022
Substrate blockchain generated with Substrate Startkit

Substrate Node Template A new FRAME-based Substrate node, ready for hacking ?? Getting Started This project contains some configuration files to help

Oct 19, 2021
Substrate blockchain generated with Substrate Startkit

Substrate Node Template A new FRAME-based Substrate node, ready for hacking ?? Getting Started This project contains some configuration files to help

Oct 19, 2021
Substrate blockchain generated with Substrate Startkit

Substrate Node Template A new FRAME-based Substrate node, ready for hacking ?? Getting Started This project contains some configuration files to help

Nov 6, 2021
An Ethereum compatible Substrate blockchain for bounties and governance for the Devcash community.

Substrate Node Template A fresh FRAME-based Substrate node, ready for hacking ?? Getting Started Follow the steps below to get started with the Node T

Mar 30, 2022
Node implementation for aleph blockchain built with Substrate framework
Node implementation for aleph blockchain built with Substrate framework

This repository contains the Rust implementation of Aleph Zero blockchain node based on the Substrate framework. Aleph Zero is an open-source layer 1

Jun 16, 2022
Polkadex - An Orderbook-based Decentralized Exchange using the Substrate Blockchain Framework.

What is Polkadex? ?? Polkadex is a Open Source, Decentralized Exchange Platform made using Substrate Blockchain Framework that provides traders with t

Jun 16, 2022
A privacy-preserving blockchain on Substrate
A privacy-preserving blockchain on Substrate

Zerochain Zerochain is a generic privacy-protecting layer on top of Substrate. It provides some useful substrate modules and toolkit for protecting us

Jun 19, 2022
xx network Substrate based blockchain node

xx network Substrate based blockchain node Rust Setup First, complete the basic Rust setup instructions. MacOS users: setup to compile for Linux Befor

May 24, 2022
The Data Highway Substrate-based blockchain node.

DataHighway-Parachain, a parachain on the Polkadot network. Planned features include a decentralized LPWAN roaming hub for LoRaWAN IoT devices and network operator roaming agreements, participative mining, an inter-chain data market, and DAO governance.

Apr 20, 2022
Astar Network is an interoperable blockchain based the Substrate framework and the hub for dApps within the Polkadot Ecosystem
Astar Network is an interoperable blockchain based the Substrate framework and the hub for dApps within the Polkadot Ecosystem

Astar Network is an interoperable blockchain based the Substrate framework and the hub for dApps within the Polkadot Ecosystem. With Astar Network and

Jun 19, 2022
Fusion is a cross-platform App Dev ToolKit build on Rust . Fusion lets you create Beautiful and Fast apps for mobile and desktop platform.
Fusion is a cross-platform App Dev ToolKit build on Rust . Fusion lets you create Beautiful and Fast apps for mobile and desktop platform.

Fusion is a cross-platform App Dev ToolKit build on Rust . Fusion lets you create Beautiful and Fast apps for mobile and desktop platform.

Oct 19, 2021
A substrate pallet that enables Manta's decentialized anynonymous payment (DAP) protocol.
A substrate pallet that enables Manta's decentialized anynonymous payment (DAP) protocol.

This is a pallet that enables decentialized anynonymous payment (DAP) protocol. The best way to use this repo is to invoke it with a manta-runtime, available from either manta-node or cumulus.

Jun 14, 2022