Making protocol changes in Madara

Madara is developed from the ground up to promote modularity and configurability, allowing developers to modify their app chain configurations to their specific product requirements. This includes allowing granular control over key Starknet parameters.

We will delve deeper into the Starknet pallet, located at ~/crates/runtime/src/pallets.rs.

Each of these parameters can be configured in the parameter_types macro in the starknet pallet file (opens in a new tab).

Configuring InvokeTxMaxNSteps

Starknet's invoke function allows users to execute a series of function calls within a single transaction. Enforcing a maximum step limit on invoke transactions offers several benefits.

• Predictable fees: Setting a limit prevents users from accidentally creating transactions with exorbitant costs due to unbounded execution steps, facilitating predictable and manageable transaction fees.
• Fairness and stability: Limiting the step count promotes fair resource sharing among users, preventing any single transaction from consuming excessive resources and impacting network stability.
• Adherence to block times: The maximum step limit also helps ensure that transactions fit within the designated block time, contributing to the network's overall predictability and stability.

In essence, InvokeTxMaxNSteps plays a critical role in allowing app chain developers to configure their Dapp for security and performance.

Configuring ValidateMaxNSteps

Starknet's __validate__ function acts as a pre-execution check. It receives a user's calls and executes validation to verify adherence to the contract's constraints. It returns "VALID" to signify successful validation, else aborting the transaction, and preventing unauthorized or invalid operations.

ValidateMaxNSteps enforces a maximum step limit within the __validate__ function safeguarding against DoS attacks.
Since failed __validate__ calls don't incur fees, malicious actors could exploit them to overload the network with invalid transactions. While a chain can have other methods like KYC or centralized checks to prevent DoS and allow for larger steps during validation, limiting the complexity of the validate function remains crucial in mitigating DoS threats on the chain.

Configuring MaxRecursionDepth

MaxRecursionDepth serves as a critical safeguard against infinite loops within Cairo contracts. It defines the maximum number of times a function can call itself recursively before execution is halted.

This parameter is essential for:

• Preventing DoS Attacks: Malicious actors could exploit uncapped recursion to create infinite loops, consuming excessive resources and potentially halting network operations.
• Encouraging Efficient Code: By imposing a limit on recursion, developers are incentivized to write code that utilizes iterative approaches or alternative control flow mechanisms.

Overall, MaxRecursionDepth plays a crucial role in maintaining the security, stability, and efficiency of the Starknet network by preventing infinite loops and encouraging sound programming practices within contracts.

Configuring ProgramHash

The ProgramHash field is a cryptographic identifier of the specific Starknet OS version used to generate proofs for L1 verification. These proofs are submitted to the base layer for verification.

This field must match the latest hash supported by Madara allowing for consistency in proof generation ensuring that when the Starknet OS undergoes an upgrade, the app chain is updated accordingly. This ensures all newly generated proofs utilize the latest version, enabling the network to evolve securely while maintaining compatibility with existing infrastructure.

Configuring DisableTransactionFee

DisableTransactionFee is a configurable parameter that allows developers flexibility in designing their app chain's economic model. When enabled, this flag waives transaction fees for users interacting with the app chain. This enables:

• Frictionless Onboarding: Removing fees can streamline user adoption, especially for Dapps where the transaction is meant to be abstracted away from users.
• Alternative Revenue Models: Developers can explore monetization through sponsorships, subscriptions, or in-app interactions instead of relying solely on transaction-based fees.
• Experimental Use Cases: DisableTransactionFee facilitates the testing of novel economic concepts or fee structures within a controlled environment.

NOTE: While transaction fees may hinder some users, they act as a crucial economic barrier against spam and DoS attacks, necessitating careful consideration before disabling them.