-
Notifications
You must be signed in to change notification settings - Fork 732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for keyring
in runtimes
#2044
Conversation
@@ -723,6 +725,7 @@ impl_runtime_apis! { | |||
|
|||
impl sp_genesis_builder::GenesisBuilder<Block> for Runtime { | |||
fn create_default_config() -> Vec<u8> { | |||
log::info!("{:#?}", AccountKeyring::Alice.public().to_ss58check()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need this to work in wasm runtime.
Can be checked with:
RUST_LOG=info cargo test --release -p substrate-test-runtime -- default_config_as_json_works
it is still not working, I am getting compilation error (for
Looks like we have problem with |
Oh? We take the string "Alice", turn it into a secret key, which somehow pulls in some name of the chain, and then put the public key into the genesis config? I'd expect this adds considerable code to the runtime, like the 32kb basepoint table. I'm unsure how curve25519-dalek does backend selection now, but once upon a time it was manual. Anyways schnorrkel pulls in digest through curve25519-dalek and sha2, which could be optional probably, but schnorrkel does not obviously propagate std to either. https://github.com/search?q=repo%3Aw3f%2Fschnorrkel+path%3A%2F%5Esrc%5C%2F%2F+digest&type=code I'd expect digest gets pulled in a few othr places, like ss58 maybe. |
Yeah, we don't need secret key, true. Some other potential ways to go around:
|
You need them for derivation since presumably "Alice" is the secret key.
You could just add a check in the host that they agree I guess. It's not ideal to expose signing in the runtime since then people might think they can use it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good so far.
Can we not just disable the |
It looks like Is there a good |
Maybe the original crate @maciejhirsz can you shed some light on why you forked it? |
required support for
|
https://github.com/infincia/bip39-rs looks like abandoned. |
https://github.com/rust-bitcoin/rust-bip39/ this is the one that was forked. At least if you follow from crates.io |
Switched to https://github.com/rust-bitcoin/rust-bip39/ in new PR (to make review easier): #2084 |
Do you know what backend flags curve25519-dalek etc require for the runtime? |
No. This particular one
For
Do you recommend any adjustment here? |
I've no idea.. A while back, curve25519-dalek got much better at autodetection, which afaik solved all native issues. I'm not sure what happens in wasm though. Anyways you've watched it actually work? No bugs appear? |
I don't have any heavy tests to cross-check keys generation. Simple, naive shot seems to work fine - basically it is all we need. |
Switch from: https://crates.io/crates/tiny-bip39 to: https://crates.io/crates/bip39 Required for: #2044
@michalkucharczyk we can not merge this with git dependencies. This will break crates.io releases. |
We are actually working on getting rid off them: #2922 Must of them are currently either removed at release manually or are being in crates that we don't have released right now. Nothing of that applies here. |
@bkchr do you think I should create release on crates.io using this fork https://github.com/michalkucharczyk/rust-bip39 ? There are two pending PRs in original repo, but things seems to be stuck there: |
Personally I'm not a big fan of this. The problem being that releases put onto crates.io will stay there forever. However, I see that there is no movement. If you like, release it on your own. But please monitor and switch back to upstream when they have finished the release. |
* master: (65 commits) collator protocol changes for elastic scaling (validator side) (#3302) Contracts use polkavm workspace deps (#3715) Add elastic scaling support in ParaInherent BenchBuilder (#3690) Removes `as [disambiguation_path]` from `derive_impl` usage (#3652) fix(paseo-spec): New Paseo Bootnodes (#3674) Improve Penpal runtime + emulated tests (#3543) Staking ledger bonding fixes (#3639) DescribeAllTerminal for HashedDescription (#3349) Increase timeout for assertions (#3680) Add subsystems regression tests to CI (#3527) Always print connectivity report (#3677) Revert "FRAME: Create `TransactionExtension` as a replacement for `SignedExtension` (#2280)" (#3665) authority-discovery: Add log for debugging DHT authority records (#3668) Construct Runtime v2 (#1378) Support for `keyring` in runtimes (#2044) Add api-name in `cannot query the runtime API version` warning (#3653) Add a PolkaVM-based executor (#3458) Adds default config for assets pallet (#3637) Bump handlebars from 4.3.7 to 5.1.0 (#3248) [Collator Selection] Fix weight refund for `set_candidacy_bond` (#3643) ...
This PR replaces the usage of [secp256k](https://crates.io/crates/secp256k1) crate with [k256](https://crates.io/crates/k256) in `core::crypto::ecdsa` for `non-std` environments as outcome of discussion in paritytech#3448. `secp256k1` is used in `std`, meaning that we should not affect host performance with this PR. `k256` is enabled in runtimes (`no-std`), and is required to proceed with paritytech#2044. If desirable, in future we can switch to `k256` also for `std`. That would require some performance evaluation (e.g. for EVM chains as per paritytech#3448 (comment)). Closes paritytech#3448 --------- Co-authored-by: command-bot <> Co-authored-by: Davide Galassi <[email protected]>
This functionality is required for paritytech#1984. This PR enables [`sp-keyring`](https://github.com/paritytech/polkadot-sdk/blob/21d36b7b4229c4d5225944f197918cde23fda4ea/substrate/primitives/keyring/src/sr25519.rs#L31-L40) in `no-std` environments, allowing to generate the public key (e.g. `AccountKeyring::Alice.public().to_ss58check()`), which can be later used in the any of built-in [_runtime-genesis-config_ variant](https://github.com/paritytech/polkadot-sdk/blob/21d36b7b4229c4d5225944f197918cde23fda4ea/polkadot/node/service/src/chain_spec.rs#L1066-L1073). The proposal is as follows: - expose [`core::Pair` trait](https://github.com/paritytech/polkadot-sdk/blob/d6f15306282e3de848a09c9aa9cba6f95a7811f0/substrate/primitives/core/src/crypto.rs#L832) in `no-std`, - `full_crypto` feature enables `sign` method, - `std` feature enables `generate_with_phrase` and `generate` methods (randomness is required), - All other functionality, currently gated by `full_crypto` will be available unconditionally (`no-std`): -- `from_string` -- `from_string_with_seed` -- `from seed` -- `from_seed_slice` -- `from_phrase` -- `derive` -- `verify` --- Depends on rust-bitcoin/rust-bip39#57 --------- Co-authored-by: command-bot <> Co-authored-by: Davide Galassi <[email protected]>
Switch from: https://crates.io/crates/tiny-bip39 to: https://crates.io/crates/bip39 Required for: paritytech#2044
…ritytech#2250) The `lazy_static` package does not work well in `no-std`: it requires `spin_no_std` feature, which also will propagate into `std` if enabled. This is not what we want. This PR provides simple address uri parser which allows to get rid of _regex_ which was used to parse the address uri, what in turns allows to remove lazy_static. Three regular expressions (`SS58_REGEX`,`SECRET_PHRASE_REGEX`,`JUNCTION_REGEX`) were replaced with the parser which unifies all of them. The new parser does not support Unicode, it is ASCII only. Related to: paritytech#2044 --------- Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: Koute <[email protected]> Co-authored-by: command-bot <>
This PR replaces the usage of [secp256k](https://crates.io/crates/secp256k1) crate with [k256](https://crates.io/crates/k256) in `core::crypto::ecdsa` for `non-std` environments as outcome of discussion in paritytech#3448. `secp256k1` is used in `std`, meaning that we should not affect host performance with this PR. `k256` is enabled in runtimes (`no-std`), and is required to proceed with paritytech#2044. If desirable, in future we can switch to `k256` also for `std`. That would require some performance evaluation (e.g. for EVM chains as per paritytech#3448 (comment)). Closes paritytech#3448 --------- Co-authored-by: command-bot <> Co-authored-by: Davide Galassi <[email protected]>
This functionality is required for paritytech#1984. This PR enables [`sp-keyring`](https://github.com/paritytech/polkadot-sdk/blob/21d36b7b4229c4d5225944f197918cde23fda4ea/substrate/primitives/keyring/src/sr25519.rs#L31-L40) in `no-std` environments, allowing to generate the public key (e.g. `AccountKeyring::Alice.public().to_ss58check()`), which can be later used in the any of built-in [_runtime-genesis-config_ variant](https://github.com/paritytech/polkadot-sdk/blob/21d36b7b4229c4d5225944f197918cde23fda4ea/polkadot/node/service/src/chain_spec.rs#L1066-L1073). The proposal is as follows: - expose [`core::Pair` trait](https://github.com/paritytech/polkadot-sdk/blob/d6f15306282e3de848a09c9aa9cba6f95a7811f0/substrate/primitives/core/src/crypto.rs#L832) in `no-std`, - `full_crypto` feature enables `sign` method, - `std` feature enables `generate_with_phrase` and `generate` methods (randomness is required), - All other functionality, currently gated by `full_crypto` will be available unconditionally (`no-std`): -- `from_string` -- `from_string_with_seed` -- `from seed` -- `from_seed_slice` -- `from_phrase` -- `derive` -- `verify` --- Depends on rust-bitcoin/rust-bip39#57 --------- Co-authored-by: command-bot <> Co-authored-by: Davide Galassi <[email protected]>
This functionality is required for #1984.
This PR enables
sp-keyring
inno-std
environments, allowing to generate the public key (e.g.AccountKeyring::Alice.public().to_ss58check()
), which can be later used in the any of built-in runtime-genesis-config variant.The proposal is as follows:
core::Pair
trait inno-std
,full_crypto
feature enablessign
method,std
feature enablesgenerate_with_phrase
andgenerate
methods (randomness is required),full_crypto
will be available unconditionally (no-std
):--
from_string
--
from_string_with_seed
--
from seed
--
from_seed_slice
--
from_phrase
--
derive
--
verify
Depends on rust-bitcoin/rust-bip39#57