Skip to content
  1. Dec 19, 2023
  3. Dec 18, 2023
  5. Dec 14, 2023
    • Sergei Shulepov's avatar
      sc-tracing: swap atty with is-terminal (#2718) · c1a11b73
      Sergei Shulepov authored 
      `atty` is unmaintaned. See the advisory
https://github.com/advisories/GHSA-g98v-hv3f-hcfr

I picked is-terminal because rustix is already in-tree, so doesn't
increase the dependency footprint, and I am not sure if we can rely on
`IsTerminal` from the std because I am not sure what our MSRV.
      c1a11b73
    • dependabot[bot]'s avatar
      Bump the known_good_semver group with 1 update (#2698) · 19984f22
      dependabot[bot] authored 
      Bumps the known_good_semver group with 1 update:
[syn](https://github.com/dtolnay/syn).

Updates `syn` from 2.0.40 to 2.0.41
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/dtolnay/syn/releases">syn's
releases</a>.</em></p>
<blockquote>
<h2>2.0.41</h2>
<ul>
<li>Support parsing syn::Field in <code>parse_quote!</code> (<a
href="https://redirect.github.com/dtolnay/syn/issues/1548">#1548</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/dtolnay/syn/commit/63b17012ab20ff72f3e49aaf821719a866b1a352"><code>63b1701</code></a>
Release 2.0.41</li>
<li><a
href="https://github.com/dtolnay/syn/commit/920ab7d6a061921d03541d86d7ac8daaf864bb7b"><code>920ab7d</code></a>
Merge pull request <a
href="https://redirect.github.com/dtolnay/syn/issues/1548">#1548</a>
from dtolnay/parsequotefield</li>
<li><a
href="https://github.com/dtolnay/syn/commit/5e1592408c3bcda68db10cd054f9d87e9e480f9b"><code>5e15924</code></a>
Test parse_quote implementation for Field</li>
<li><a
href="https://github.com/dtolnay/syn/commit/c268c6793f8a71ac2f3e8ee80201701e4352b407"><code>c268c67</code></a>
Support parsing Field in parse_quote</li>
<li><a
href="https://github.com/dtolnay/syn/commit/2ab0f6ae4b47d133c828d9123e86a50565a95447"><code>2ab0f6a</code></a>
Merge pull request <a
href="https://redirect.github.com/dtolnay/syn/issues/1547">#1547</a>
from dtolnay/testparsequote</li>
<li><a
href="https://github.com/dtolnay/syn/commit/46172a41a478920ff23c9e370a5b922fa984829d"><code>46172a4</code></a>
Add parse_quote tests</li>
<li><a
href="https://github.com/dtolnay/syn/commit/0fcdad044f330f4c32e2f3b1230271669d1951ea"><code>0fcdad0</code></a>
Support punctuated Pairs iterator in snapshot tests</li>
<li><a
href="https://github.com/dtolnay/syn/commit/06161ba80283edf6f741dfc86c91f6985297d168"><code>06161ba</code></a>
Update test suite to nightly-2023-12-12</li>
<li>See full diff in <a
href="https://github.com/dtolnay/syn/compare/2.0.40...2.0.41">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=syn&package-manager=cargo&previous-version=2.0.40&new-version=2.0.41)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores

)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions


</details>

Signed-off-by: default avatardependabot[bot] <[email protected]>
Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      19984f22
    • Svyatoslav Nikolsky's avatar
      Add Rococo People <> Rococo Bulletin bridge support to Rococo Bridge Hub (#2540) · 097308e3
      Svyatoslav Nikolsky authored 
      This PR adds [Rococo
People](https://github.com/paritytech/polkadot-sdk/pull/2281) <> [Rococo
Bulletin](https://github.com/zdave-parity/polkadot-bulletin-chain) to
the Rococo Bridge Hub code. There's a couple of things left to do here:
- [x] add remaining tests - it'd need some refactoring in the
`bridge-hub-test-utils` - will do in a separate PR;
- [x] actually run benchmarks for new messaging pallet (do we have bot
nowadays?).

The reason why I'm opening it before this ^^^ is ready, is that I'd like
to hear others opinion on how to deal with hacks with that bridge.
Initially I was assuming that Rococo Bulletin will be the 1:1 copy of
the Polkadot Bulletin (to avoid maintaining multiple
runtimes/releases/...), so you can see many `PolkadotBulletin` mentions
in this PR, even though we are going to bridge with the parallel chain
(`RococoBulletin`). That's because e.g. pallet names from
`construct_runtime` are affecting runtime storage keys and bridges are
using runtime storage proofs => it is important to use names that the
Bulletin chain expects.

But in the end, this hack won't work - we can't use Polkadot Bulletin
runtime to bridge with Rococo Bridge Hub, because Polkadot Bulletin
expects Polkadot Bridge hub to use `1002` parachain id and Rococo Bridge
Hub seats on the `1013`. This also affects storage keys using in
bridging, so I had to add the [`rococo`
feature](https://github.com/svyatonik/polkadot-bulletin-chain/blob/add-bridge-pallets/runtime/Cargo.toml#L198)
to the Bulletin chain. So now we can actually alter its runtime and
adapt it for Rococo.

So the question here is - what's better for us here
- to leave everything as is (seems hacky and non-trivial);
- change Bulletin chain runtime when `rococo` feature is used - e.g. use
proper names there (`WithPolkadotGrandpa` -> `WithRococoGrandpa`, ...)
- add another set of pallets to the Bulletin chain runtime to bridge
with Rococo and never use them in production. Similar to hack that we
had in Rococo/Wococo

cc @acatangiu @bkontur @serban300 

also cc @joepetrowski

 as the main "client" of this bridge

---

A couple words on how this bridge is different from the Rococo <>
Westend bridge:
- it is a bridge with a chain that uses GRANDPA finality, not the
parachain finality (hence the tests needs to be changed);
- it is a fee-free bridge. So
`AllowExplicitUnpaidExecutionFrom<Equals<SiblingPeople>>` + we are not
paying any rewards to relayers (apart from compensating transaction
costs).

---------

Signed-off-by: default avatardependabot[bot] <[email protected]>
Signed-off-by: default avatarAndrei Sandu <[email protected]>
Co-authored-by: default avatarAdrian Catangiu <[email protected]>
Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: default avatarAndrei Sandu <[email protected]>
Co-authored-by: default avatarEgor_P <[email protected]>
Co-authored-by: command-bot <>
      097308e3
    • Andrei Sandu's avatar
      Introduce subsystem benchmarking tool (#2528) · 8a6e9ef1
      Andrei Sandu authored 
      This tool makes it easy to run parachain consensus stress/performance
testing on your development machine or in CI.

## Motivation
The parachain consensus node implementation spans across many modules
which we call subsystems. Each subsystem is responsible for a small part
of logic of the parachain consensus pipeline, but in general the most
load and performance issues are localized in just a few core subsystems
like `availability-recovery`, `approval-voting` or
`dispute-coordinator`. In the absence of such a tool, we would run large
test nets to load/stress test these parts of the system. Setting up and
making sense of the amount of data produced by such a large test is very
expensive, hard to orchestrate and is a huge development time sink.

## PR contents
- CLI tool 
- Data Availability Read test
- reusable mockups and components needed so far
- Documentation on how to get started

### Data Availability Read test

An overseer is built with using a real `availability-recovery` susbsytem
instance while dependent subsystems like `av-store`, `network-bridge`
and `runtime-api` are mocked. The network bridge will emulate all the
network peers and their answering to requests.

The test is going to be run for a number of blocks. For each block it
will generate send a “RecoverAvailableData” request for an arbitrary
number of candidates. We wait for the subsystem to respond to all
requests before moving to the next block.
At the same time we collect the usual subsystem metrics and task CPU
metrics and show some nice progress reports while running.

### Here is how the CLI looks like:

```
[2023-11-28T13:06:27Z INFO  subsystem_bench::core::display] n_validators = 1000, n_cores = 20, pov_size = 5120 - 5120, error = 3, latency = Some(PeerLatency { min_latency: 1ms, max_latency: 100ms })
[2023-11-28T13:06:27Z INFO  subsystem-bench::availability] Generating template candidate index=0 pov_size=5242880
[2023-11-28T13:06:27Z INFO  subsystem-bench::availability] Created test environment.
[2023-11-28T13:06:27Z INFO  subsystem-bench::availability] Pre-generating 60 candidates.
[2023-11-28T13:06:30Z INFO  subsystem-bench::core] Initializing network emulation for 1000 peers.
[2023-11-28T13:06:30Z INFO  subsystem-bench::availability] Current block 1/3
[2023-11-28T13:06:30Z INFO  substrate_prometheus_endpoint] 〽️ Prometheus exporter started at 127.0.0.1:9999
[2023-11-28T13:06:30Z INFO  subsystem_bench::availability] 20 recoveries pending
[2023-11-28T13:06:37Z INFO  subsystem_bench::availability] Block time 6262ms
[2023-11-28T13:06:37Z INFO  subsystem-bench::availability] Sleeping till end of block (0ms)
[2023-11-28T13:06:37Z INFO  subsystem-bench::availability] Current block 2/3
[2023-11-28T13:06:37Z INFO  subsystem_bench::availability] 20 recoveries pending
[2023-11-28T13:06:43Z INFO  subsystem_bench::availability] Block time 6369ms
[2023-11-28T13:06:43Z INFO  subsystem-bench::availability] Sleeping till end of block (0ms)
[2023-11-28T13:06:43Z INFO  subsystem-bench::availability] Current block 3/3
[2023-11-28T13:06:43Z INFO  subsystem_bench::availability] 20 recoveries pending
[2023-11-28T13:06:49Z INFO  subsystem_bench::availability] Block time 6194ms
[2023-11-28T13:06:49Z INFO  subsystem-bench::availability] Sleeping till end of block (0ms)
[2023-11-28T13:06:49Z INFO  subsystem_bench::availability] All blocks processed in 18829ms
[2023-11-28T13:06:49Z INFO  subsystem_bench::availability] Throughput: 102400 KiB/block
[2023-11-28T13:06:49Z INFO  subsystem_bench::availability] Block time: 6276 ms
[2023-11-28T13:06:49Z INFO  subsystem_bench::availability] 
    
    Total received from network: 415 MiB
    Total sent to network: 724 KiB
    Total subsystem CPU usage 24.00s
    CPU usage per block 8.00s
    Total test environment CPU usage 0.15s
    CPU usage per block 0.05s
```

### Prometheus/Grafana stack in action
<img width="1246" alt="Screenshot 2023-11-28 at 15 11 10"
src="https://github.com/paritytech/polkadot-sdk/assets/54316454/eaa47422-4a5e-4a3a-aaef-14ca644c1574">
<img width="1246" alt="Screenshot 2023-11-28 at 15 12 01"
src="https://github.com/paritytech/polkadot-sdk/assets/54316454/237329d6-1710-4c27-8f67-5fb11d7f66ea">
<img width="1246" alt="Screenshot 2023-11-28 at 15 12 38"
src="https://github.com/paritytech/polkadot-sdk/assets/54316454/a07119e8-c9f1-4810-a1b3-f1b7b01cf357

">

---------

Signed-off-by: default avatarAndrei Sandu <[email protected]>
      8a6e9ef1
  7. Dec 13, 2023
  9. Dec 12, 2023
    • Branislav Kontur's avatar
      Ensure xcm versions over bridge (on sending chains) (#2481) · 575b8f8d
      Branislav Kontur authored 
      ## Summary

This pull request proposes a solution for improved control of the
versioned XCM flow over the bridge (across different consensus chains)
and resolves the situation where the sending chain/consensus has already
migrated to a higher XCM version than the receiving chain/consensus.

## Problem/Motivation

The current flow over the bridge involves a transfer from AssetHubRococo
(AHR) to BridgeHubRococo (BHR) to BridgeHubWestend (BHW) and finally to
AssetHubWestend (AHW), beginning with a reserve-backed transfer on AHR.

In this process:
1. AHR sends XCM `ExportMessage` through `XcmpQueue`, incorporating XCM
version checks using the `WrapVersion` feature, influenced by
`pallet_xcm::SupportedVersion` (managed by
`pallet_xcm::force_xcm_version` or version discovery).

2. BHR handles the `ExportMessage` instruction, utilizing the latest XCM
version. The `HaulBlobExporter` converts the inner XCM to
[`VersionedXcm::from`](https://github.com/paritytech/polkadot-sdk/blob/63ac2471aa0210f0ac9903bdd7d8f9351f9a635f/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465-L467),
also using the latest XCM version.

However, challenges arise:
- Incompatibility when BHW uses a different version than BHR. For
instance, if BHR migrates to **XCMv4** while BHW remains on **XCMv3**,
BHR's `VersionedXcm::from` uses `VersionedXcm::V4` variant, causing
encoding issues for BHW.
  ```
	/// Just a simulation of possible error, which could happen on BHW
	/// (this code is based on actual master without XCMv4)
	let encoded = hex_literal::hex!("0400");
	println!("{:?}", VersionedXcm::<()>::decode(&mut &encoded[..]));

Err(Error { cause: None, desc: "Could not decode `VersionedXcm`, variant
doesn't exist" })
  ``` 
- Similar compatibility issues exist between AHR and AHW.

## Solution

This pull request introduces the following solutions:

1. **New trait `CheckVersion`** - added to the `xcm` module and exposing
`pallet_xcm::SupportedVersion`. This enhancement allows checking the
actual XCM version for desired destinations outside of the `pallet_xcm`
module.

2. **Version Check in `HaulBlobExporter`** uses `CheckVersion` to check
known/configured destination versions, ensuring compatibility. For
example, in the scenario mentioned, BHR can store the version `3` for
BHW. If BHR is on XCMv4, it will attempt to downgrade the message to
version `3` instead of using the latest version `4`.

3. **Version Check in `pallet-xcm-bridge-hub-router`** - this check
ensures compatibility with the real destination's XCM version,
preventing the unnecessary sending of messages to the local bridge hub
if versions are incompatible.

These additions aim to improve the control and compatibility of XCM
flows over the bridge and addressing issues related to version
mismatches.

## Possible alternative solution

_(More investigation is needed, and at the very least, it should extend
to XCMv4/5. If this proves to be a viable option, I can open an RFC for
XCM.)._

Add the `XcmVersion` attribute to the `ExportMessage` so that the
sending chain can determine, based on what is stored in
`pallet_xcm::SupportedVersion`, the version the destination is using.
This way, we may not need to handle the version in `HaulBlobExporter`.

```
ExportMessage {
	network: NetworkId,
	destination: InteriorMultiLocation,
	xcm: Xcm<()>
	destination_xcm_version: Version, // <- new attritbute
},
```

```
pub trait ExportXcm {
        fn validate(
		network: NetworkId,
		channel: u32,
		universal_source: &mut Option<InteriorMultiLocation>,
		destination: &mut Option<InteriorMultiLocation>,
		message: &mut Option<Xcm<()>>,
                destination_xcm_version: Version, , // <- new attritbute
	) -> SendResult<Self::Ticket>;
```

## Future Directions

This PR does not fix version discovery over bridge, further
investigation will be conducted here:
https://github.com/paritytech/polkadot-sdk/issues/2417.

## TODO

- [x] `pallet_xcm` mock for tests uses hard-coded XCM version `2` -
change to 3 or lastest?
- [x] fix `pallet-xcm-bridge-hub-router`
- [x] fix HaulBlobExporter with version determination
[here](https://github.com/paritytech/polkadot-sdk/blob/2183669d05f9b510f979a0cc3c7847707bacba2e/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465)
- [x] add unit-tests to the runtimes
- [x] run benchmarks for `ExportMessage`
- [x] extend local run scripts about `force_xcm_version(dest, version)`
- [ ] when merged, prepare governance calls for Rococo/Westend
- [ ] add PRDoc

Part of: https://github.com/paritytech/parity-bridges-common/issues/2719

---------

Co-authored-by: command-bot <>
      575b8f8d
    • Chevdor's avatar
      Changelogs local generation (#1411) · 42a3afba
      Chevdor authored 
      

This PR introduces a script and some templates to use the prdoc involved
in a release and build:
- the changelog
- a simple draft of audience documentation

Since the prdoc presence was enforced in the middle of the version
1.5.0, not all PRs did come with a `prdoc` file.
This PR creates all the missing `prdoc` files with some minimum content
allowing to properly generate the changelog.
The generated content is **not** suitable for the audience
documentation.

The audience documentation will be possible with the next version, when
all PR come with a proper `prdoc`.

## Assumptions

- the prdoc files for release `vX.Y.Z` have been moved under
`prdoc/X.Y.Z`
- the changelog requires for now for the prdoc files to contain author +
topic. Thos fields are optional.

The build script can  be called as:
```
VERSION=X.Y.Z ./scripts/release/build-changelogs.sh
```

Related:
-  #1408

---------

Co-authored-by: default avatarEgorPopelyaev <[email protected]>
      42a3afba
    • dependabot[bot]'s avatar
      Bump names from 0.13.0 to 0.14.0 (#2686) · 2aaa9af3
      dependabot[bot] authored 
      Bumps [names](https://github.com/fnichol/names) from 0.13.0 to 0.14.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/fnichol/names/releases">names's
releases</a>.</em></p>
<blockquote>
<h2>Release 0.14.0</h2>
<h2><a
href="https://github.com/fnichol/names/compare/v0.13.0...v0.14.0">0.14.0</a>
- 2022-06-28</h2>
<h3>Changed</h3>
<ul>
<li>upgrade to <code>regex</code> 1.5.6</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/fnichol/names/blob/main/CHANGELOG.md">names's
changelog</a>.</em></p>
<blockquote>
<h2>[0.14.0] - 2022-06-28</h2>
<h3>Changed</h3>
<ul>
<li>upgrade to <code>regex</code> 1.5.6</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/fnichol/names/commit/8f09d5bf9860582c485b5856cbb325642d3e82c2"><code>8f09d5b</code></a>
release: names 0.14.0</li>
<li><a
href="https://github.com/fnichol/names/commit/b589b911b489812aa4a279efa1b91e6fe7ff7dfa"><code>b589b91</code></a>
release: update CHANGELOG.md</li>
<li><a
href="https://github.com/fnichol/names/commit/e1bed3056d38a98a22f28f39db42211404a00953"><code>e1bed30</code></a>
merge: <a
href="https://redirect.github.com/fnichol/names/issues/20">#20</a></li>
<li><a
href="https://github.com/fnichol/names/commit/12eb753220007a2aafe741031af83562c1e617f6"><code>12eb753</code></a>
Bump regex from 1.5.4 to 1.5.6</li>
<li><a
href="https://github.com/fnichol/names/commit/ed520b76b8542fdca09d9d80658f4ea0b8914464"><code>ed520b7</code></a>
merge: <a
href="https://redirect.github.com/fnichol/names/issues/19">#19</a></li>
<li><a
href="https://github.com/fnichol/names/commit/852eaee067bcadfb2a59e78b432919a87983fe6d"><code>852eaee</code></a>
chore: start next iteration 0.13.1-dev</li>
<li>See full diff in <a
href="https://github.com/fnichol/names/compare/v0.13.0...v0.14.0">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=names&package-manager=cargo&previous-version=0.13.0&new-version=0.14.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores

)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions


</details>

Signed-off-by: default avatardependabot[bot] <[email protected]>
Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      2aaa9af3
  11. Dec 11, 2023
  13. Dec 08, 2023
    • Bastian Köcher's avatar
      Update proc-macro-crate (#2660) · f6ae1458
      Bastian Köcher authored
      f6ae1458
    • Muharem Ismailov's avatar
      Westend: Fellowship Treasury (#2532) · da40d97a
      Muharem Ismailov authored 
      

Treasury Pallet Instance for the Fellowship in Westend Collectives.

In this update, we present a Treasury Pallet Instance that is under the
control of the Fellowship body, with oversight from the Root and
Treasurer origins. Here's how it is governed:
- the Root origin have the authority to reject or approve spend
proposals, with no amount limit for approvals.
- the Treasurer origin have the authority to reject or approve spend
proposals, with approval limits of up to 10,000,000 DOT.
- Voice of all Fellows ranked at 3 or above can reject or approve spend
proposals, with a maximum approval limit of 10,000 DOT.
- Voice of Fellows ranked at 4 or above can also reject or approve spend
proposals, with a maximum approval limit of 10,000,000 DOT.

Additionally, we introduce the Asset Rate Pallet Instance to establish
conversion rates from asset A to B. This is used to determine if a
proposed spend amount involving a non-native asset is permissible by the
commanding origin. The rates can be set up by the Root, Treasurer
origins, or Voice of all Fellows.

---------

Co-authored-by: default avatarjoe petrowski <[email protected]>
Co-authored-by: default avatarjoepetrowski <[email protected]>
      da40d97a
    • Davide Galassi's avatar
      Bump ark-scale version to 0.0.12 (#2652) · f5edd4f4
      Davide Galassi authored 
      As per title.

Fix in ark-scale `TypeInfo` implementation
      f5edd4f4
    • Sam Johnson's avatar
      Tasks: general system for recognizing and executing service work (#1343) · ac3f14d2
      Sam Johnson authored 
      `polkadot-sdk` version of original tasks PR located here:
https://github.com/paritytech/substrate/pull/14329

Fixes #206

## Status
- [x] Generic `Task` trait
- [x] `RuntimeTask` aggregated enum, compatible with
`construct_runtime!`
- [x] Casting between `Task` and `RuntimeTask` without needing `dyn` or
`Box`
- [x] Tasks Example pallet
- [x] Runtime tests for Tasks example pallet
- [x] Parsing for task-related macros
- [x] Retrofit parsing to make macros optional
- [x] Expansion for task-related macros
- [x] Adds support for args in tasks
- [x] Retrofit tasks example pallet to use macros instead of manual
syntax
- [x] Weights
- [x] Cleanup
- [x] UI tests
- [x] Docs

## Target Syntax
Adapted from
https://github.com/paritytech/polkadot-sdk/issues/206#issue-1865172283



```rust
// NOTE: this enum is optional and is auto-generated by the other macros if not present
#[pallet::task]
pub enum Task<T: Config> {
    AddNumberIntoTotal {
        i: u32,
    }
}

/// Some running total.
#[pallet::storage]
pub(super) type Total<T: Config<I>, I: 'static = ()> =
StorageValue<_, (u32, u32), ValueQuery>;

/// Numbers to be added into the total.
#[pallet::storage]
pub(super) type Numbers<T: Config<I>, I: 'static = ()> =
StorageMap<_, Twox64Concat, u32, u32, OptionQuery>;

#[pallet::tasks_experimental]
impl<T: Config<I>, I: 'static> Pallet<T, I> {
	/// Add a pair of numbers into the totals and remove them.
	#[pallet::task_list(Numbers::<T, I>::iter_keys())]
	#[pallet::task_condition(|i| Numbers::<T, I>::contains_key(i))]
	#[pallet::task_index(0)]
	pub fn add_number_into_total(i: u32) -> DispatchResult {
		let v = Numbers::<T, I>::take(i).ok_or(Error::<T, I>::NotFound)?;
		Total::<T, I>::mutate(|(total_keys, total_values)| {
			*total_keys += i;
			*total_values += v;
		});
		Ok(())
	}
}
```

---------

Co-authored-by: default avatarNikhil Gupta <[email protected]>
Co-authored-by: default avatarkianenigma <[email protected]>
Co-authored-by: Nikhil Gupta <>
Co-authored-by: default avatarGavin Wood <[email protected]>
Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
Co-authored-by: default avatargupnik <[email protected]>
      ac3f14d2
    • cheme's avatar
      Remove hashbrown from trie cache. (#2632) · 34c991e2
      cheme authored 
      Using hashmap instead (hashset do not expose entry), to get the default
random hasher her.
      34c991e2
  15. Dec 07, 2023
  17. Dec 06, 2023
  19. Dec 05, 2023
  21. Dec 04, 2023
  23. Dec 01, 2023