Inherents,Transactions,extrinsics

Inherents

In Substrate, "inherents" refer to the intrinsic data or information that must be included in each block of the blockchain. Inherents are different from regular transactions because they are not initiated by users or external parties but are inherent to the operation of the blockchain itself. They provide essential data for t.he blockchain to function properly and include information that all nodes must agree upon, such as the timestamp, block number, and other consensus-related data.

Each inherent is added to a produced block. Each runtime decides on which inherents it wants to attach to its blocks. All data that is required for the runtime to create the inherents is stored in the InherentData. This InherentData is constructed by the node and given to the runtime.

Types that provide data for inherents, should implement InherentDataProvider and need to be registered at InherentDataProviders.

In the runtime, modules need to implement ProvideInherent when they can create and/or check inherents. By implementing ProvideInherent, a module is not enforced to create an inherent. A module can also just check given inherents. For using a module as inherent provider, it needs to be registered by the construct_runtime! macro. The macro documentation gives more information on how that is done.

Source code : substrate/primitives/inherents at master · paritytech/substrate ( github.com )

Here are some key points about inherents in Substrate:

1. Types of Inherents: Inherents can include various types of data, such as below : Timestamp: The exact time when the block was produced.

Block Number: The number of the current block.

Randomness: Randomness values used in consensus mechanisms.

Authorship: Information about the author of the block.

Seal: Data generated by block authoring mechanisms like Proof of Work (PoW) or Proof of Stake (PoS).

Finality Proof: Proof of finalized blocks in some consensus algorithms.

Transaction Queue: Pre-selected transactions for the block.

Custom Data: Any other data that needs to be included in every block.

2.Consensus and Validity: Inherents play a critical role in reaching consensus among different nodes on the state of the blockchain. All nodes must agree on the inherent data for a block to be considered valid and part of the blockchain.

3.Generated and Checked by the Runtime: Inherents are generated and checked by the runtime of the blockchain. The runtime ensures that all required inherents are included and valid before a block is finalized.

4.Inherent Data Extraction: During block authoring, the node generates the necessary inherents and includes them in the block header. During block validation, nodes verify that the inherents are valid and consistent with the current state.

5.Inherent Data Processing: The inherent data is processed by the runtime when the block is executed. The inherent data can affect the state transitions and operations within the block.

6.Custom Inherents: Substrate allows developers to define custom inherents to include additional information required for specific use cases or features.//! APIs and utilities for working with Substrate's Inherents in Tuxedo based chains.

Below is the defination from source code :

# Substrate inherents Inherents are a Substrate feature that allows block authors to insert some transactions directly into the body of the block. Inherents are similar to pre-runtime digests which allow authors to insert info into the block header. However inherents go in the block body and therefore must be transactions.

Classic usecases for inherents are injecting and updating environmental information such as a block timestamp, information about the relay chain (if the current chain is a parachain), or information about who should receive the block reward.

In order to allow the runtime to construct such transactions while keeping the cleint opaque, there are special APIs for creating inherents and performing off-chain validation of inherents. That's right, inherents also offer a special API to have their environmental data checked off-chain before the block is executed.

Complexities in UTXO chains !: In account based systems, the classic way to use an inherent is that the block inserts a transaction providing some data like a timestamp.When the extrinsic executed it, overwrites the previously stored timestamp in a dedicated storage item.

In UTXO chains, there are no storage items, and all state is local to a UTXO. This is the case with, for example, the timestamp as well.This means that when the author calls into the runtime with a timestamp, the transaction that is returned must include the correct reference to the UTXO that contained the previous best timestamp. This is the crux of the problem: there is no easy way to know the location of the previous timestamp in the utxo-space from inside the runtime.

# Scraping the Parent Block:The solution is to provide the entirety of the previous block to the runtime when asking it to construct inherents.This module provides an inherent data provider that does just this. Any Tuxedo runtime that uses inherents (At least ones that update environmental data), needs to include this foundational previous block inherent data provider so that the Tuxedo executive can scrape it to find the output references of the previous inherent transactions.

Transactions

Transactions in a blockchain are fundamental units of data that represent a transfer of value or the execution of a specific action within the blockchain network. Transactions are the building blocks of the blockchain and are used to record changes to the ledger in a secure and verifiable manner. Each transaction typically includes information about the sender, recipient, amount of value being transferred, and any additional data required for the specific action being performed.

Here are the key components of a transaction in a blockchain:

1. Sender: The sender is the individual or entity initiating the transaction. It is the address or identifier associated with the source of the transaction.
2. Recipient: The recipient is the individual or entity receiving the value or the result of the action. Similar to the sender, the recipient is identified by an address or identifier.
3. Amount: The amount indicates the quantity of value being transferred. In cryptocurrencies, this often represents the amount of the cryptocurrency being sent.
4. Transaction ID: Each transaction is assigned a unique identifier, often in the form of a transaction hash, which acts as a fingerprint for that specific transaction. This hash is generated based on the transaction data and is used to identify and track the transaction.
5. Timestamp: The timestamp indicates when the transaction was initiated or confirmed. It helps in establishing the chronological order of transactions within the blockchain.
6. Additional Data: Depending on the blockchain's capabilities, a transaction may include additional data or information required for specific actions. For example, in a smart contract platform like Ethereum, a transaction might contain data that specifies a smart contract function to be executed.
7. Digital Signature: Transactions are often digitally signed by the sender using cryptographic techniques. This signature verifies the authenticity of the transaction and ensures that it cannot be tampered with.
8. Transaction Fee: Many blockchain networks require users to pay a transaction fee to prioritize their transactions and incentivize miners or validators to include the transaction in a block.

Once a transaction is created and signed, it needs to be validated and confirmed by the network's consensus mechanism. In proof-of-work blockchains like Bitcoin, miners compete to solve complex mathematical puzzles to add a new block of transactions to the blockchain. In proof-of-stake and other consensus mechanisms, validators take turns proposing and validating blocks.

Once a transaction is included in a validated block, it becomes a permanent part of the blockchain's history. Transactions collectively form a chronological record of all activities within the blockchain network, allowing participants to trace the flow of value and verify the integrity of the ledger.

It's important to note that different blockchain networks may have variations in the structure and details of transactions based on their specific features and use cases.

extrinsic

In the context of blockchain, particularly in Substrate-based blockchains like Polkadot, an "extrinsic" is a fundamental concept used to describe actions or transactions that originate from an external source and are submitted to the blockchain for processing. Extrinsic is a term specific to Substrate's framework, and it plays a significant role in how interactions are handled on the blockchain.

Here's a more detailed explanation:

1. External Actions: An extrinsic represents an external action that a user or an external entity initiates to interact with the blockchain. This action could be a transaction that transfers assets, invokes a smart contract, changes settings, or executes other operations on the blockchain.
2. User-Initiated Transactions: Externals are usually initiated by users or external systems interacting with the blockchain network. For instance, when a user sends cryptocurrency from their wallet to another address, they're initiating an extrinsic.
3. Structure: An extrinsic consists of several components, including:

• Call: This specifies the function or operation to be executed on the blockchain. It defines what action the extrinsic is attempting to perform, such as transferring funds, executing a contract, etc.
• Signature: Externals are signed with the sender's private key to prove their authenticity and authorization.

1. Processing and Inclusion: Once an extrinsic is submitted to the blockchain, it goes through the consensus mechanism for processing and inclusion in a block. Validators in the network validate the extrinsic's signature and verify the action's validity. If the extrinsic is valid, it's included in a block and becomes a part of the blockchain's history.
2. Interaction with Blockchain Logic: Externals are processed according to the rules and logic defined in the blockchain's runtime. The runtime governs how the actions specified in the extrinsics are executed and how they affect the state of the blockchain.
3. Types of Extrinsic: Different blockchains might support various types of extrinsics, depending on their use cases and functionalities. For example, in Substrate-based blockchains, you can have regular transactions, governance proposals, contract calls, and more, each represented as a specific type of extrinsic.

Extrinsics are a crucial concept in Substrate-based blockchains as they enable the dynamic execution of actions by external entities. They provide a way for users and external systems to interact with the blockchain in a secure and controlled manner, while also ensuring that actions are verifiable and traceable on the blockchain's immutable ledger.

OriginFor<T>

• In Substrate's runtime development framework, the origin parameter with the type OriginFor<T> is commonly used in extrinsic functions. It represents the caller or the origin of an extrinsic call.
• OriginFor<T>: OriginFor<T> is a type alias that represents the origin type parameterized by the runtime configuration T. This type is a mechanism used in Substrate to manage the source or authorization of an extrinsic call. The origin can come from various sources, including signed accounts, root/administrator, or a smart contract.

In Substrate, there are different types of origins, such as:

• frame_system::RawOrigin: Represents a raw origin, which is used for special extrinsics like block authorship.
• frame_system::SignedOrigin: Represents an origin from a signed account. It is used for regular transactions initiated by external accounts.
• frame_system::SuperuserOrigin: Represents a superuser/administrator origin that can perform privileged operations.
• Custom origins: You can also define your own custom origins for specific use cases.

Ex: Transfer of token from one account to another . We are using whether the transaction or extrinsic is signed or not .

#[pallet::weight(0)]
pub fn transfer(
? ? origin: OriginFor<T>,
? ? to: T::AccountId,
? ? unique_id: [u8; 16],
) -> DispatchResult {
? ? // Make sure the caller is from a signed origin
? ? let from = ensure_signed(origin)?;
? ? let token = TokenMap::<T>::get(&unique_id).ok_or(Error::<T>::NoToken)?;
? ? ensure!(token.owner == from, Error::<T>::NotOwner);
? ? Self::do_transfer(unique_id, to)?;
? ? Ok(())
}         

Using the origin parameter allows your extrinsic functions to differentiate between different callers or sources of the transactions. This helps in applying access control, permissions, and determining how the operation should be treated based on who initiated it.

It is important to understand about some supporting libs used in implementing pallet:

The frame_system module provides the basic infrastructure for blockchain operations and state management, while the frame_support module offers a set of tools and abstractions that make it easier to create complex runtime modules. Both modules are foundational for building custom pallets and extending the functionality of a Substrate-based blockchain.

We will discuss them in detail in next articles, but let me give just overview of system pallets

• frame_system?provides core functionality for working with common data structures and primitives so they are available to all of the pallets that need them, enabling new pallets to be easily integrated into a runtime and to interact with each other.
• frame_support?provides core support services for handling function calls that are dispatched to the runtime, defining storage structures, preparing events and errors and core utilities.
• codec Module: The codec module, short for "codec," stands for "encoding and decoding." It provides a set of macros and traits that allow you to define how data structures should be serialized and deserialized. The serialization format used in Substrate is based on SCALE (Simple Concatenated Aggregate Little-Endian), which is designed to be compact and efficient.
• scale-info Module: The scale-info module is an integral part of the codec module. It provides metadata about types, which is used to ensure compatibility between different versions of a Substrate runtime. Metadata includes information like the version of the type, its unique identifier, and more.

Need to include them in the cargo.toml of pallet as below:

[dependencies]
frame-support = { default-features = false, version = "4.0.0-dev", git = "https://github.com/paritytech/substrate.git", branch = "polkadot-v1.0.0"}
frame-system = { default-features = false, version = "4.0.0-dev", git = "https://github.com/paritytech/substrate.git", branch = "polkadot-v1.0.0" }
codec = { package = "parity-scale-codec", version = "3.0.0", default-features = false, features = ["derive",] 
scale-info = { version = "2.1.1", default-features = false, features = ["derive"] }}

[features]
default = ["std"]
std = [
? "frame-support/std",
? "frame-system/std",
? "codec/std",
? "scale-info/std",
]        

codec and scale-info are modules that provide tools and abstractions for handling data serialization and deserialization. As you already know Serialization is the process of converting complex data structures into a format that can be easily stored, transmitted, or shared, while deserialization is the reverse process of reconstructing the original data from its serialized form. These modules are essential for efficient and consistent data management within Substrate-based blockchains.

How authorization, validation of transaction happens in substrate?

In Substrate, the process of validating and processing transactions involves several components working together. Let's break down the process step by step:

1. Transaction Submission and Validation:

• When a transaction is submitted to the network, it goes through initial validation. This validation checks for basic correctness, like properly formatted transactions, and checks against known rules to prevent invalid transactions from being processed further.
• The transaction also needs to be signed with the private key of the sender's account. This signature is used to verify the authenticity of the transaction and to ensure that it's coming from a valid user.

1. Transaction Pool:

• Valid transactions are added to the transaction pool. The transaction pool is a temporary storage area where pending transactions are held before they are included in a block. Transactions in the pool are ordered based on various factors like transaction fees.

2. Block Production and Consensus:

• Substrate supports different consensus mechanisms like Aura and BABE for block production. In Aura, a predetermined set of validators take turns producing blocks in a round-robin fashion. In BABE, validators are selected based on randomness.
• The selected validators create and propose blocks that include a set of transactions from the transaction pool. These transactions are ordered and included in the block according to the validators' decision.

3. Block Finalization:

• Substrate also employs the Grandpa finality gadget to provide finality to blocks. Grandpa is a finality gadget that works in tandem with block production mechanisms like Aura or BABE.
• A separate set of validators, often referred to as "finality validators," participate in the Grandpa consensus protocol. They finalize blocks by agreeing on a specific chain of blocks that cannot be reverted.

4. Local Database Update:

• Once a block is finalized, all nodes in the network update their local databases to reflect the changes introduced by the newly finalized block. This includes updating the state of accounts, balances, and other relevant data affected by the transactions in the block.

It's important to note that the exact details and configuration of these processes can vary based on the specific runtime configuration and consensus mechanisms chosen for the Substrate-based blockchain. The modular nature of Substrate allows developers to customize and configure these components according to their network's requirements.

Additionally, while validators play a significant role in block production and finality, it's not just validators that validate transactions. The network as a whole, including full nodes and potentially other specialized nodes, contributes to the validation process to ensure the security and correctness of the blockchain's operation.

Difference between extrinsics and inherent:

In the Substrate framework, both extrinsics and inherents are mechanisms for including information in blocks, but they serve different purposes and have different characteristics.

Extrinsics:

Definition: Extrinsics are transactions or operations submitted by users to the blockchain. They represent actions that users want to perform on the blockchain, such as transferring funds, invoking a smart contract, or any other state-changing operation.

Origin: Extrinsics typically originate from external users or entities interacting with the blockchain. They are submitted through the runtime via the transaction pool.

Inclusion: Extrinsics are included in blocks through the transaction inclusion process, where they are validated, executed, and their effects on the state are recorded.

Usage: Extrinsics are used for actions that need to be recorded in the blockchain's state and have a direct impact on the state transition.

Inherents:

Definition: Inherents are pieces of information that are inherent to the block itself and are not submitted by external users. They are included in the block header and represent contextual information about the block.

Origin: Inherents are usually generated by the block author (the entity producing the block) and are not directly submitted by external users. They provide context about the block, such as the timestamp, block number, or any other data relevant to the block as a whole.

Inclusion: Inherents are included in the block header during the block production process. They are not subject to the transaction pool or extrinsic validation.

Usage: Inherents are used for information that is shared across the entire block, providing context and metadata that is relevant to the entire block rather than to specific transactions.

Thanks for reading till end , will try to touch different topics in next articles.