# runtime_vs_smart_contract.rs - source
Source of the Rust file `docs/sdk/src/reference_docs/runtime_vs_smart_contract.rs`.

#
pezkuwi_sdk_docs/reference_docs/
runtime_vs_smart_contract.rs

    1//! # Runtime vs. Smart Contracts
    2//!
    3//! *TL;DR*: If you need to create a *Blockchain*, then write a runtime. If you need to create a
    4//! *DApp*, then write a Smart Contract.
    5//!
    6//! This is a comparative analysis of Bizinikiwi-based Runtimes and Smart Contracts, highlighting
    7//! their main differences. Our aim is to equip you with a clear understanding of how these two
    8//! methods of deploying on-chain logic diverge in their design, usage, and implications.
    9//!
    10//! Both Runtimes and Smart Contracts serve distinct purposes. Runtimes offer deep customization for
    11//! blockchain development, while Smart Contracts provide a more accessible approach for
    12//! decentralized applications. Understanding their differences is crucial in choosing the right
    13//! approach for a specific solution.
    14//!
    15//! ## Bizinikiwi
    16//! Bizinikiwi is a modular framework that enables the creation of purpose-specific blockchains. In
    17//! the Pezkuwi ecosystem you can find two distinct approaches for on-chain code execution:
    18//! [Runtime Development](#runtime-in-bizinikiwi) and [Smart Contracts](#smart-contracts).
    19//!
    20//! #### Smart Contracts in Bizinikiwi
    21//! Smart Contracts are autonomous, programmable constructs deployed on the blockchain.
    22//! In [FRAME](crate::pezkuwi_sdk::frame_runtime), Smart Contracts infrastructure is implemented by the
    23//! [`pezpallet_contracts`] for WASM-based contracts or the
    24//! [`pezpallet_evm`](https://github.com/pezkuwi-evm/frontier/tree/master/frame/evm) for EVM-compatible contracts. These pallets
    25//! enable Smart Contract developers to build applications and systems on top of a Bizinikiwi-based
    26//! blockchain.
    27//!
    28//! #### Runtime in Bizinikiwi
    29//! The Runtime is the state transition function of a Bizinikiwi-based blockchain. It defines the
    30//! rules for processing transactions and blocks, essentially governing the behavior and
    31//! capabilities of a blockchain.
    32//!
    33//! ## Comparative Table
    34//!
    35//! | Aspect                | Runtime                                                                 | Smart Contracts                                                      |
    36//! |-----------------------|-------------------------------------------------------------------------|----------------------------------------------------------------------|
    37//! | **Design Philosophy** | Core logic of a blockchain, allowing broad and deep customization. | Designed for DApps deployed on the blockchain runtime. |
    38//! | **Development Complexity** | Requires in-depth knowledge of Rust and Bizinikiwi. Suitable for complex blockchain architectures. | Easier to develop with knowledge of Smart Contract languages like Solidity or [ink!](https://use.ink/). |
    39//! | **Upgradeability and Flexibility** | Offers comprehensive upgradeability with migration logic and on-chain governance, allowing modifications to the entire blockchain logic without hard forks. | Less flexible in upgrade migrations but offers more straightforward deployment and iteration. |
    40//! | **Performance and Efficiency** | More efficient, optimized for specific needs of the blockchain. | Can be less efficient due to its generic nature (e.g. the overhead of a virtual machine). |
    41//! | **Security Considerations** | Security flaws can affect the entire blockchain. | Security risks usually localized to the individual contract. |
    42//! | **Weighing and Metering** | Operations can be weighed, allowing for precise benchmarking. | Execution is metered, allowing for measurement of resource consumption. |
    43//!
    44//! We will now explore these differences in more detail.
    45//!
    46//! ## Design Philosophy
    47//! Runtimes and Smart Contracts are designed for different purposes. Runtimes are the core logic
    48//! of a blockchain, while Smart Contracts are designed for DApps on top of the blockchain.
    49//! Runtimes can be more complex, but also more flexible and efficient, while Smart Contracts are
    50//! easier to develop and deploy.
    51//!
    52//! #### Runtime Design Philosophy
    53//! - **Core Blockchain Logic**: Runtimes are essentially the backbone of a blockchain. They define
    54//!   the fundamental rules, operations, and state transitions of the blockchain network.
    55//! - **Broad and Deep Customization**: Runtimes allow for extensive customization and flexibility.
    56//!   Developers can tailor the most fundamental aspects of the blockchain, like introducing an
    57//!   efficient transaction fee model to eliminating transaction fees completely. This level of
    58//!   control is essential for creating specialized or application-specific blockchains.
    59//!
    60//! #### Smart Contract Design Philosophy
    61//! - **DApps Development**: Smart contracts are designed primarily for developing DApps. They
    62//!   operate on top of the blockchain's infrastructure.
    63//! - **Modularity and Isolation**: Smart contracts offer a more modular approach. Each contract is
    64//!   an isolated piece of code, executing predefined operations when triggered. This isolation
    65//!   simplifies development and enhances security, as flaws in one contract do not directly
    66//!   compromise the entire network.
    67//!
    68//! ## Development Complexity
    69//! Runtimes and Smart Contracts differ in their development complexity, largely due to their
    70//! differing purposes and technical requirements.
    71//!
    72//! #### Runtime Development Complexity
    73//! - **In-depth Knowledge Requirements**: Developing a Runtime in Bizinikiwi requires a
    74//!   comprehensive understanding of Rust, Bizinikiwi's framework, and blockchain principles.
    75//! - **Complex Blockchain Architectures**: Runtime development is suitable for creating complex
    76//!   blockchain architectures. Developers must consider aspects like security, scalability, and
    77//!   network efficiency.
    78//!
    79//! #### Smart Contract Development Complexity
    80//! - **Accessibility**: Smart Contract development is generally more accessible, especially for
    81//!   those already familiar with programming concepts. Knowledge of smart contract-specific
    82//!   languages like Solidity or ink! is required.
    83//! - **Focused on Application Logic**: The development here is focused on the application logic
    84//!   only. This includes writing functions that execute when certain conditions are met, managing
    85//!   state within the contract, and ensuring security against common Smart Contract
    86//!   vulnerabilities.
    87//!
    88//! ## Upgradeability and Flexibility
    89//! Runtimes and Smart Contracts differ significantly in how they handle upgrades and flexibility,
    90//! each with its own advantages and constraints. Runtimes are more flexible, allowing for writing
    91//! migration logic for upgrades, while Smart Contracts are less flexible but offer easier
    92//! deployment and iteration.
    93//!
    94//! #### Runtime Upgradeability and Flexibility
    95//! - **Migration Logic**: One of the key strengths of runtime development is the ability to define
    96//!   migration logic. This allows developers to implement changes in the state or structure of the
    97//!   blockchain during an upgrade. Such migrations can adapt the existing state to fit new
    98//!   requirements or features seamlessly.
    99//! - **On-Chain Governance**: Upgrades in a Runtime environment are typically governed on-chain,
    100//!   involving validators or a governance mechanism. This allows for a democratic and transparent
    101//!   process for making substantial changes to the blockchain.
    102//! - **Broad Impact of Changes**: Changes made in Runtime affect the entire blockchain. This gives
    103//!   developers the power to introduce significant improvements or changes but also necessitates a
    104//!   high level of responsibility and scrutiny, we will talk further about it in the [Security
    105//!   Considerations](#security-considerations) section.
    106//!
    107//! #### Smart Contract Upgradeability and Flexibility
    108//! - **Deployment and Iteration**: Smart Contracts, by nature, are designed for more
    109//!   straightforward deployment and iteration. Developers can quickly deploy contracts.
    110//! - **Contract Code Updates**: Once deployed, although typically immutable, Smart Contracts can be
    111//!   upgraded, but lack of migration logic. The [`pezpallet_contracts`]
    112//!   allows for contracts to be upgraded by exposing the `set_code` dispatchable. More details on this
    113//!   can be found in [Ink! documentation on upgradeable contracts](https://use.ink/basics/upgradeable-contracts).
    114//! - **Isolated Impact**: Upgrades or changes to a smart contract generally impact only that
    115//!   contract and its users, unlike Runtime upgrades that have a network-wide effect.
    116//! - **Simplicity and Rapid Development**: The development cycle for Smart Contracts is usually
    117//!   faster and less complex than Runtime development, allowing for rapid prototyping and
    118//!   deployment.
    119//!
    120//! ## Performance and Efficiency
    121//! Runtimes and Smart Contracts have distinct characteristics in terms of performance and
    122//! efficiency due to their inherent design and operational contexts. Runtimes are more efficient
    123//! and optimized for specific needs, while Smart Contracts are more generic and less efficient.
    124//!
    125//! #### Runtime Performance and Efficiency
    126//! - **Optimized for Specific Needs**: Runtime modules in Bizinikiwi are tailored to meet the
    127//!   specific needs of the blockchain. They are integrated directly into the blockchain's core,
    128//!   allowing them to operate with high efficiency and minimal overhead.
    129//! - **Direct Access to Blockchain State**: Runtime has direct access to the blockchain's state.
    130//!   This direct access enables more efficient data processing and transaction handling, as there
    131//!   is no additional layer between the runtime logic and the blockchain's core.
    132//! - **Resource Management**: Resource management is integral to runtime development to ensure that
    133//!   the blockchain operates smoothly and efficiently.
    134//!
    135//! #### Smart Contract Performance and Efficiency
    136//! - **Generic Nature and Overhead**: Smart Contracts, particularly those running in virtual
    137//!   machine environments, can be less efficient due to the generic nature of their execution
    138//!   environment. The overhead of the virtual machine can lead to increased computational and
    139//!   resource costs.
    140//! - **Isolation and Security Constraints**: Smart Contracts operate in an isolated environment to
    141//!   ensure security and prevent unwanted interactions with the blockchain's state. This isolation,
    142//!   while crucial for security, can introduce additional computational overhead.
    143//! - **Gas Mechanism and Metering**: The gas mechanism in Smart Contracts, used for metering
    144//!   computational resources, ensures that contracts don't consume excessive resources. However,
    145//!   this metering itself requires computational power, adding to the overall cost of contract
    146//!   execution.
    147//!
    148//! ## Security Considerations
    149//! These two methodologies, while serving different purposes, come with their own unique security
    150//! considerations.
    151//!
    152//! #### Runtime Security Aspects
    153//! Runtimes, being at the core of blockchain functionality, have profound implications for the
    154//! security of the entire network:
    155//!
    156//! - **Broad Impact**: Security flaws in the runtime can compromise the entire blockchain,
    157//!   affecting all network participants.
    158//! - **Governance and Upgradeability**: Runtime upgrades, while powerful, need rigorous governance
    159//!   and testing to ensure security. Improperly executed upgrades can introduce vulnerabilities or
    160//!   disrupt network operations.
    161//! - **Complexity and Expertise**: Developing and maintaining runtime requires a higher level of
    162//!   expertise in blockchain architecture and security, as mistakes can be far-reaching.
    163//!
    164//! #### Smart Contract Security Aspects
    165//! Smart contracts, while more isolated, bring their own set of security challenges:
    166//!
    167//! - **Isolated Impact**: Security issues in a smart contract typically affect the contract itself
    168//! and its users, rather than the whole network.
    169//! - **Contract-specific Risks**: Common issues like reentrancy
    170//! attacks, improper handling of external calls, and gas limit vulnerabilities are specific to
    171//! smart contract development.
    172//! - **Permissionless Deployment**: Since anyone can deploy a smart contract,
    173//! the ecosystem is more open to potentially malicious or vulnerable code.
    174//!
    175//! ## Weighing and Metering
    176//! Weighing and metering are mechanisms designed to limit the resources used by external actors.
    177//! However, there are fundamental differences in how these resources are handled in FRAME-based
    178//! Runtimes and how they are handled in Smart Contracts, while Runtime operations are weighed,
    179//! Smart Contract executions must be metered.
    180//!
    181//! #### Weighing
    182//! In FRAME-based Runtimes, operations are *weighed*. This means that each operation in the Runtime
    183//! has a fixed upper cost, known in advance, determined through
    184//! [benchmarking](crate::reference_docs::pezframe_benchmarking_weight). Weighing is practical here
    185//! because:
    186//!
    187//! - *Predictability*: Runtime operations are part of the blockchain's core logic, which is static
    188//!   until an upgrade occurs. This predictability allows for precise
    189//!   [benchmarking](crate::reference_docs::pezframe_benchmarking_weight).
    190//! - *Prevention of Abuse*: By having a fixed upper cost that corresponds to the worst-case
    191//!   complexity scenario of its execution (and a mechanism to refund unused weight), it becomes
    192//!   infeasible for an attacker to create transactions that could unpredictably consume excessive
    193//!   resources.
    194//!
    195//! #### Metering
    196//! For Smart Contracts resource consumption is metered. This is essential due to:
    197//!
    198//! - **Untrusted Nature**: Unlike Runtime operations, Smart Contracts can be deployed by any user,
    199//!   and their behavior isn’t known in advance. Metering dynamically measures resource consumption
    200//!   as the contract executes.
    201//! - **Safety Against Infinite Loops**: Metering protects the blockchain from poorly designed
    202//!   contracts that might run into infinite loops, consuming an indefinite amount of resources.
    203//!
    204//! #### Implications for Developers and Users
    205//! - **For Runtime Developers**: Understanding the cost of each operation is essential. Misjudging
    206//!   the weight of operations can lead to network congestion or vulnerability exploitation.
    207//! - **For Smart Contract Developers**: Being mindful of the gas cost associated with contract
    208//!   execution is crucial. Efficiently written contracts save costs and are less likely to hit gas
    209//!   limits, ensuring smoother execution on the blockchain.
    210//!