mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-04-26 01:47:55 +00:00
Introduce Polkadot-Sdk developer_hub (#2102)
This PR introduces the new crate `developer_hub` into the polkadot-sdk repo. The vision for the developer-hub crate is detailed in [this document](https://docs.google.com/document/d/1XLLkFNE8v8HLvZpI2rzsa8N2IN1FcKntc8q-Sc4xBAk/edit?usp=sharing). <img width="1128" alt="Screenshot 2023-11-02 at 10 45 48" src="https://github.com/paritytech/polkadot-sdk/assets/5588131/1e12b60f-fef5-42c4-8503-a3ba234077c3"> Other than adding the new crate, it also does the following: * Remove the `substrate` crate, as there is now a unique umbrella crate for multiple things in `developer_hub::polkadot_sdk`. * (backport candidate) A minor change to `frame-support` macros that allows `T::RuntimeOrigin` to also be acceptable as the origin type. * (backport candidate) A minor change to `frame-system` that allows us to deposit events at genesis because now the real genesis config is generated via wasm, and we can safely assume `cfg!(feature = "std")` means only testing. related to #62. * (backport candidate) Introduces a small `read_events_for_pallet` to `frame_system` for easier event reading in tests. * From https://github.com/paritytech/polkadot-sdk-docs/issues/31, it takes action on improving the `pallet::call` docs. * From https://github.com/paritytech/polkadot-sdk-docs/issues/31, it takes action on improving the `UncheckedExtrinsic` docs. ## Way Forward First, a version of this is deployed temporarily [here](https://blog.kianenigma.nl/polkadot-sdk/developer_hub/index.html). I will keep it up to date on a daily basis. ### This Pull Request I see two ways forward: 1. We acknowledge that everything in `developer-hub` is going to be WIP, and merge this asap. We should not yet use links to this crate anywhere. 2. We make this be the feature branch, make PRs against this, and either gradually backport it, or only merge to master once it is done. I am personally in favor of option 1. If we stick to option 2, we need a better way to deploy a staging version of this to gh-pages. ### Issue Tracking The main issues related to the future of `developer_hub` are: - https://github.com/paritytech/polkadot-sdk-docs/issues/31 - https://github.com/paritytech/polkadot-sdk-docs/issues/4 - https://github.com/paritytech/polkadot-sdk-docs/issues/26 - https://github.com/paritytech/polkadot-sdk-docs/issues/32 - https://github.com/paritytech/polkadot-sdk-docs/issues/36 ### After This Pull Request - [ ] create a redirect for https://paritytech.github.io/polkadot-sdk/master/substrate/ - [x] analytics - [ ] link checker - [ ] the matter of publishing, and how all of these relative links for when we do, that is still an open question. There is section on this in the landing page. - [ ] updated https://paritytech.github.io/ --------- Co-authored-by: Liam Aharon <liam.aharon@hotmail.com> Co-authored-by: Juan Girini <juangirini@gmail.com> Co-authored-by: bader y <ibnbassem@gmail.com> Co-authored-by: Sebastian Kunert <skunert49@gmail.com> Co-authored-by: James Wilson <james@jsdw.me> Co-authored-by: Michal Kucharczyk <1728078+michalkucharczyk@users.noreply.github.com>
This commit is contained in:
@@ -26,9 +26,11 @@ use crate::{
|
||||
transaction_validity::{TransactionSource, TransactionValidity},
|
||||
};
|
||||
|
||||
/// Definition of something that the external world might want to say; its
|
||||
/// existence implies that it has been checked and is good, particularly with
|
||||
/// regards to the signature.
|
||||
/// Definition of something that the external world might want to say; its existence implies that it
|
||||
/// has been checked and is good, particularly with regards to the signature.
|
||||
///
|
||||
/// This is typically passed into [`traits::Applyable::apply`], which should execute
|
||||
/// [`CheckedExtrinsic::function`], alongside all other bits and bobs.
|
||||
#[derive(PartialEq, Eq, Clone, sp_core::RuntimeDebug)]
|
||||
pub struct CheckedExtrinsic<AccountId, Call, Extra> {
|
||||
/// Who this purports to be from and the number of extrinsics have come before
|
||||
|
||||
@@ -43,16 +43,37 @@ const EXTRINSIC_FORMAT_VERSION: u8 = 4;
|
||||
/// The `SingaturePayload` of `UncheckedExtrinsic`.
|
||||
type UncheckedSignaturePayload<Address, Signature, Extra> = (Address, Signature, Extra);
|
||||
|
||||
/// A extrinsic right from the external world. This is unchecked and so
|
||||
/// can contain a signature.
|
||||
/// An extrinsic right from the external world. This is unchecked and so can contain a signature.
|
||||
///
|
||||
/// An extrinsic is formally described as any external data that is originating from the outside of
|
||||
/// the runtime and fed into the runtime as a part of the block-body.
|
||||
///
|
||||
/// Inherents are special types of extrinsics that are placed into the block by the block-builder.
|
||||
/// They are unsigned because the assertion is that they are "inherently true" by virtue of getting
|
||||
/// past all validators.
|
||||
///
|
||||
/// Transactions are all other statements provided by external entities that the chain deems values
|
||||
/// and decided to include in the block. This value is typically in the form of fee payment, but it
|
||||
/// could in principle be any other interaction. Transactions are either signed or unsigned. A
|
||||
/// sensible transaction pool should ensure that only transactions that are worthwhile are
|
||||
/// considered for block-building.
|
||||
#[doc = simple_mermaid::mermaid!("../../../../../docs/mermaid/extrinsics.mmd")]
|
||||
/// This type is by no means enforced within Substrate, but given its genericness, it is highly
|
||||
/// likely that for most use-cases it will suffice. Thus, the encoding of this type will dictate
|
||||
/// exactly what bytes should be sent to a runtime to transact with it.
|
||||
///
|
||||
/// This can be checked using [`Checkable`], yielding a [`CheckedExtrinsic`], which is the
|
||||
/// counterpart of this type after its signature (and other non-negotiable validity checks) have
|
||||
/// passed.
|
||||
#[derive(PartialEq, Eq, Clone)]
|
||||
pub struct UncheckedExtrinsic<Address, Call, Signature, Extra>
|
||||
where
|
||||
Extra: SignedExtension,
|
||||
{
|
||||
/// The signature, address, number of extrinsics have come before from
|
||||
/// the same signer and an era describing the longevity of this transaction,
|
||||
/// if this is a signed extrinsic.
|
||||
/// The signature, address, number of extrinsics have come before from the same signer and an
|
||||
/// era describing the longevity of this transaction, if this is a signed extrinsic.
|
||||
///
|
||||
/// `None` if it is unsigned or an inherent.
|
||||
pub signature: Option<UncheckedSignaturePayload<Address, Signature, Extra>>,
|
||||
/// The function that should be called.
|
||||
pub function: Call,
|
||||
@@ -286,6 +307,7 @@ where
|
||||
}
|
||||
}
|
||||
|
||||
#[docify::export(unchecked_extrinsic_encode_impl)]
|
||||
impl<Address, Call, Signature, Extra> Encode for UncheckedExtrinsic<Address, Call, Signature, Extra>
|
||||
where
|
||||
Address: Encode,
|
||||
|
||||
@@ -250,7 +250,7 @@ impl<B: BlockNumberProvider> Lockable for BlockAndTime<B> {
|
||||
///
|
||||
/// A lock that is persisted in the DB and provides the ability to guard against
|
||||
/// concurrent access in an off-chain worker, with a defined expiry deadline
|
||||
/// based on the concrete [`Lockable`](Lockable) implementation.
|
||||
/// based on the concrete [`Lockable`] implementation.
|
||||
pub struct StorageLock<'a, L = Time> {
|
||||
// A storage value ref which defines the DB entry representing the lock.
|
||||
value_ref: StorageValueRef<'a>,
|
||||
|
||||
Reference in New Issue
Block a user