https://x.com/tradeparadex/status/1938570326990008443

TL;DR

Paradex is partnering with Karnot to run its own Madara sequencer on an entirely open-source SN Stack. This custom infrastructure turbocharges Paradex’s roadmap, potentially enabling:

(i) custom functionality built into the Paradex chain;

(ii) masked positions at the RPC layer; and

(iii) $DIME as the native gas token.

Paradex’s Growth Curve & What’s Ahead

When Paradex debuted in 2023, it was celebrated as the first Starknet app-chain: a DEX running on a StarkWare-operated sequencer with ETH DA. That setup proved purpose-built chains can match centralised exchanges in throughput and latency while staying fully on-chain.

Today, the team is pursuing a fuller vision: the SuperDEX.

Achieving that “better-than-CEX” UX now hinges on freedoms a generic L1 or L2 can’t grant: RPC-level privacy, total control over every layer of infrastructure, and chain-level protocol upgrades.

With this new partnership, StarkWare continues to run SHARP (the shared proving service), while Karnot takes over sequencing, scaling and more. The result: every performance dial sits in Paradex’s hands, with zero compromise.

Shifting Gears with Madara

Madara is the open-source Starknet sequencer that turns the SN Stack into modular bricks. Together with Paradex, we can integrate custom opcodes, swap DA layers, or migrate state between sequencers. Karnot’s engineers co-maintain Madara, bringing battle-tested familiarity that cuts upgrade risk.

What a self-owned stack unlocks:

1. Full Position Privacy. RPC masking can hide order and position data.

2. Native Gas in $DIME. Paradex can make $DIME the chain’s gas token.

3. Modular DA Paths. Pluggable DA lets Paradex drive costs even lower.

Why Karnot?

Madara Core Maintainer

Karnot, along with the Kasar Labs team, contributes code, reviews, and actively develops Madara. That hands-on familiarity gives us full control over new features, release timelines, and infrastructure resilience. The same team that ships the sequencer also runs it.

Validator-Grade Reliability

Karnot operates the second-largest Starknet validator, overseeing roughly 44 million STRK with perfect uptime. The same operational promise now backs Paradex.

Proven App-Chain Track Record

We’ve partnered with projects like Kakarot and Pragma, and our accelerator supports app-chains building AI marketplaces, RWA platforms, and stablecoin gateways. Furthermore, Karnot collaborates with Finternet, an open protocol layer aiming to connect global financial systems, using our experience running production-grade infrastructure to help build the world's financial rails.

Migrating the SuperDEX to a Karnot-run Madara stack turns infrastructure into leverage. Let's both teams double down on their specialities, trading logic for Paradex, zero-downtime chains for Karnot and set the stage for a new class of high-throughput, privacy-preserving protocols.

Before we talk about why Karnot, we would like to take a quick trip down the memory lane of Starknet app chains.

Why Starknet App Chains?

Starkware has been the age old pioneer in the app chain space. Before Starknet even existed, Starkware offered StarkEx chains to some of the most well known web3 companies today - dYdX, Immutable, Sorare and more. However, the solution was closed source and needed work with Starkware for deployment. So almost a year ago, the Madara effort started to build an open source solution for Starknet App Chains.

Why another stack?

Native account abstraction, Cairo, state diffs, native execution and more!

Key Advantages of the Starknet Stack

• Native Account Abstraction: The Starknet Stack offers account abstraction baked right into the protocol. You don’t need to convince external parties that charge you large amounts of money to get ERC 4337. Every account is a smart wallet out of the box!

• ZK friendly and affordable: Solidity is great but wait till you put your hands on Cairo. It’s similar to Rust, has a strong developer ecosystem, and is much more efficient when it comes to ZK proving

  You can do millions of transactions a month with the Starknet Stack without breaking the bank. A lot of other solutions in the market would charge you $100k/mo for the same scale.

• State diffs: Unlike optimistic rollups and some ZK rollups, the Starknet Stack doesn’t need to post every transaction on the base chain. You’ve a perp chain where two users trade a million times? Great, just post the final balances on Ethereum. NOT EVERY SINGLE TRANSACTION.

• Unmatched Performance: Starknet has already broken the record of maximum TPS achieved by an L2 (857!). And this is before we’ve Cairo native which will make it even faster. Top that up with Stwo coming next year and your costs will get even lower. The Starknet Stack is designed from first principles and is available today, it’s not a dream that you’ll need to wait for another year.

The Full Stack App Chain Suite

Users who choose to launch with Karnot get

• Madara sequencer with autoscaling

• Voyager explorer

• A white label bridge and faucet with customization

• Transparent pricing

• Seamless upgrades to the latest versions of the stack

• Real-time monitoring

You can read in detail about the offering on our new website.

Why Karnot?

Two simple reasons

1. Core Contributors to the Stack

At Karnot, we’re not just a RaaS company that offers cloud deployments of an open source stack. We do that of course (at production scale), but along with that, the Karnot team is a core contributor to the Starknet Stack (Madara to be precise). We’ve been maintaining Madara for more than a year now and we understand the stack inside out. Fun fact:

Karnot is the first team outside Starkware that has run an E2E version of the Starknet Stack.

Our deep expertise in the underlying tech not only ensures reliability and security but also allows us to offer very user specific customizations on top of the stack.

2. Trusted Across Starknet

Don’t trust us, verify! Karnot is the preferred infra partner in the Starknet Ecosystem. At the time of writing this, Karnot operates as the 2nd largest validator on Starknet, securing over 22M of staked STRK. We’re THE infra solution on Starknet and are aligned with it’s long term success.

Pricing That Scales With You

Karnot is for everyone - from budding startups to large enterprise. Our pricing is simple

• Free Devnet and Testnets

  • No blockers for the tinkerers. Get your devnet for free today and start testing.

• Mainnet Plans at $5,000/month

  • Designed for growing teams

  • High uptime

  • Detailed monitoring

  • On-call support

  • Customization options

• Enterprise Plans

  • Tailored solutions with SLAs

  • Higher level of customizations

Deploy your Starknet App Chain today.

Schedule a call with us here.

The Foundation: Zero-Commission Staking

Staking is fundamental to any blockchain ecosystem – it's how you participate in securing the network while earning rewards. Powered by Karnot's zero-commission nodes, with Native Staking you receive 100% of your staking yields, with minimal risk and zero commission.

Beyond Basic Staking: Eliminating Opportunity Costs

However, traditional staking comes with a trade-off: your locked STRK cannot participate in DeFi opportunities.

Securing the network shouldn’t come with an opportunity cost.

Endur: Bringing Endurance to the Ecosystem

Karnot has joined hands with StrkFarm, to create Endur, standing for our vision of endurance, commitment, and growth of the Starknet ecosystem. With Endur, we bring xSTRK: a liquid staking solution that combines the best of both worlds.

With xSTRK, you can:

• Earn the base staking yield

• Maintain full liquidity of your assets

• Participate in DeFi Spring strategies

• Use your staked assets across the ecosystem

xSTRK: An Ecosystem-First Approach

While there are several LSTs on Starknet, xSTRK is built with a focus on ecosystem-wide utility. As long-standing members of the ecosystem, we recognize the need for a neutral, high-quality LST that can seamlessly integrate across all platforms.

Working with StrkFarm

We're thrilled to announce that xSTRK is being developed in partnership with StrkFarm. Their team has been an integral part of the ecosystem for over 2 years, and their track record in building robust ERC 4626 architecture makes them the perfect partner to bring xSTRK to fruition. StrkFarm's expertise will be instrumental in ensuring xSTRK's technical excellence and long-term success.

Security First

Every xSTRK contract undergoes thorough auditing, ensuring your funds only interact with verified, secure code.

Integration Ecosystem

xSTRK is designed for seamless integration across Starknet's DeFi landscape, with a vision to evolve xSTRK into Starknet’s most liquid LST. xSTRK will be available on DEXs and Market Makers from Day 1. We envision these integrations to further develop with time, allowing the design of complex DeFi instruments atop xSTRK.

The Future of Staking

xSTRK introduces ecosystem-wide utility empowering DeFi innovation and boosting network security for Starknet. This marks just the beginning of our commitment to growing the ecosystem.

Reach out to us at @endurfi & stay tuned for detailed technical specifications and launch information!

https://t.me/+gZw5DWpFtFY2ZDZl

The Importance of Staking

Staking is a fundamental mechanism for blockchains, offering benefits that extend beyond simple yield generation.

• Enhanced Network Security: Enables economic participation from token holders.

• Long-term Network Stability: Stakers are vital in block production, attestation, and proving.

• Community Engagement: Opens opportunities for participation and network growth.

Understanding Starknet's Staking Model

Starknet's implementation introduces a dual participation model that enhances decentralization and aligns network engagement with economic interests:

Participants:

• Validators: Run nodes with a minimum of 20,000 STRK, earning rewards from self-staked tokens and commissions on delegated funds.

• Delegators: Participate without running infrastructure by delegating any amount of STRK to existing validators.

Furthermore, integrating native staking also extends STRK's utility to being a gas fee token, governance token, and yield-generating staked asset.

Native Staking with Karnot: Empowering Starknet's Ecosystem

As Starknet's leading Rollup-as-a-Service provider and an active maintainer of Madara (a sequencer & mainnet-ready full node), Karnot offers a unique validator option that aligns closely with Starknet's vision of a decentralised ecosystem.

Key Features of Karnot's Validator:

1. 0% Commission: We intend to launch our validator without any commission allowing more value to flow back into the community.

   1. Our primary goal for offering staking isn't revenue generation, but to contribute toward strengthening the ecosystem and advancing Starknet's decentralized vision.

   2. Our projected roadmap doesn’t include changes to our zero commission policy, as we don’t see staking as a revenue source; we primarily offer RaaS services for the same. However, if there’s a change in this plan, you can be well assured that all delegators will be communicated well in advance. That’s a big if though :)

2. Ecosystem Focus: With nearly two years of experience in the Starknet space, the Karnot team is exclusively dedicated to building and innovating within the Starknet ecosystem. We're aware of multiple stakers and staking solutions launching on Starknet, including companies that offer services across various chains and ecosystems.

   1. While cross-chain experience has its merits, our focus on Starknet allows us to stay deeply engaged with the ecosystem's latest developments. This engagement is reflected in our up-to-date clients, new integrations, and optimized yield strategies.

3. Technical Expertise: The Karnot team collaborates with projects such as Kakarot and Pragma, running full nodes, sequencers, and core infrastructure support. Delegating with Karnot places your funds with Karnot’s secure, battle-tested infrastructure.

4. Governance Participation: We are actively involved in Starknet governance, community forums, and technical discussions. By staking with Karnot, you strengthen the voice of engaged stakeholders in Starknet's growth.

5. Dedicated Support: Our exclusive focus on the Starknet ecosystem ensures fast updates and 24/7 support for our nodes.

How to Stake with Karnot:

• Coming Soon: A user-friendly Karnot staking dashboard where you can:

  • Connect any compatible wallet containing STRK

  • Stake and manage your delegations

  • View validator details including identity, addresses, active stake, and commission percentage

Empowering Starknet's Future Through Staking

At Karnot, we strive to achieve Starknet’s vision of a decentralised integrity-focused ecosystem, your stake contributes to allowing Karnot’s development of crucial infrastructure for Starknet and its app chains.

To get started or learn more about staking with Karnot, visit our website or follow us on Twitter. Together, we can contribute to Starknet's decentralization and secure its future as a leading Layer 2 solution.

Blockchains represent a significant advancement in decentralised, permissionless databases, built to be trustless and scalable. Ethereum, as a prime example is a global database operating with over six thousand nodes that constantly read and write to the blockchain. A distributed system of such proportions demands a state architecture that meets three key criteria: it must be immutably verifiable, enable lightning-fast lookups, and scale to handle tens of thousands of writes.

Ethereum achieves this by maintaining a "world state" - a global state that is constantly updated by executing transactions. This world state stores critical information about Ethereum accounts, such as balances and smart contract states. Each interaction, whether it's a transfer, NFT mint, or memecoin snipe involves multiple reads and writes to this state. During these interactions, the system accesses the world state and executes state transformation functions to update the state accordingly.

In this article, we'll discuss the evolution of Ethereum's state architecture, its future, and how we've reimagined state at Madara. We'll explore Madara's Bonsai architecture towards the end, but we recommend reading the preceding sections to establish a solid foundation.

Solving the State Verifiability Problem

The blockchain “verifiability problem” arises from the need for an architecture that can support thousands of reads and writes, while remaining verifiable even on compute-light machines (light clients). While centralised databases such as SQL are efficient, scalable and battle-tested, they lack the trustless nature that blockchains require.

The primary challenge lies in achieving a balance between performance and verifiability. Blockchains require nodes to validate and store each transaction. Consequently, blockchain state architecture must be designed to be lightweight and easy to verify.

As the blockchain state expands, block verification requires more resources, which state architectures like MPTs address. Here we discuss state architectures implemented by Ethereum and Starknet

Tries, Patricia Tries & Merkle Trees

In the following examples, we will use the words "bin," "binary," "tree," "trie," "move," and "movie" to illustrate the concept of tries. Additionally, we will present the key-value pairs (bin,10), (binary,8), (move,30), (movie,55), (tree,20), (trie,48) to demonstrate Merkle trees, Merkle Patricia trees, and Bonsai trees.

Tries: Efficient Retrieval by Key-Lookup

A trie is an ordered tree data structure used to represent a set of strings over an alphabet set. A trie's architecture allows for the efficient storage of words with common prefixes. This design allows optimised checks on the presence of a word in a dictionary.

Structure of a Trie

1. Nodes: Each node in a trie represents a prefix of the strings stored. A trie node can have multiple children, each corresponding to a different character.

2. Character Mapping: Each node contains a mapping from characters to child nodes.

Nodes in a Trie

In the adjoining diagram, there are two types of nodes:

1. Leaf Nodes (Green Nodes):

   1. Signify the end of a branch in a Trie

   2. Have a leaf flag to indicate whether the node is a complete word or a prefix.

   3. “tree” and “trie” are examples of leaf nodes that signal complete words in the dictionary.

2. Intermediate Nodes (Yellow Nodes):

   1. Have a character mapping to one or more child nodes

   2. “move” represents an intermediate node, a node that maps two child nodes to its existing prefix.

   3. “bin” behaves as a terminal node, representing a full word that exists in the dictionary while also having child nodes of its own.

A Trie’s unique design enables straightforward reads of leaf nodes by encoding the string as the path to the leaf node that stores the string. Hence the time complexity for insertion and search is proportional to the length of the string (O(m)), where m is the length of the string. This is because each operation involves traversing ALL the characters.

Similarly, tries demand a storage complexity of O(n), where n is the total size of all strings stored. However, the height of the trie depends only on the length of the longest string.

Patricia Tries

A trie’s structure allows efficient retrieval of leaf values, as the string is sufficient to determine its position within the Trie. As the Trie expands, this encoding allows for optimised lookup times; however a trie’s naive limitations can also be identified.

For sparse key sets, a trie may run unnecessarily deep, with many nodes having only one child. Long 'single-child' chains increase read and write times due to the need to traverse the entire tree depth.

PATRICIA (Practical Algorithm To Retrieve Information Coded In Alphanumeric) Tries are a specialised type of trie designed to optimise space usage by collapsing chains of nodes with only one child.

Structure of Patricia Tries

1. Nodes and Edges: Each node in a PATRICIA Trie represents a common prefix of the strings stored in the tree. Unlike a standard trie, where each edge corresponds to a single character, edges in a PATRICIA tree can represent multiple characters, leading to a more compact structure.

2. Merging Nodes: In a PATRICIA tree, any node that has only one child is merged with its parent. This merging reduces the number of nodes and the overall height of the tree, making it more space efficient.

A Patricia Trie’s optimisations result in improvements in the storage and compute complexity of lookups and insertions. While the worst case time complexity remains proportional to the length of the string (O(m)), due to the collapsed chains, the actual time can be less than in standard tries.

Similarly, due to a Patricia tries space-efficient design, the number of nodes required to represent a (sparse) dictionary reduce.

Using Patricia tries, we can create a data structure that quickly locates a node's position in any arbitrary tree based on its key. This allows for efficient lookups even in large databases.

Merkle Trees

With the implementation of a Patricia trie, we address the challenge of rapid reads/writes by enabling access to data storage slots through knowledge of the corresponding keys. However, in trustless environments, it is essential to ensure that the retrieved data is accurate. While Patricia tries can facilitate data retrieval, they require two separate read operations to achieve verification:

1. Value Retrieval: The first operation retrieves the value associated with a given key from the trie.

2. Value Validation: The second operation involves the validator traversing the trie again to validate the correctness of the retrieved value.

To validate without a second read, we can use a tree-like data structure that stores hashed values instead. This approach ensures that any change to the leaf node’s value automatically triggers a rehash across the tree, updating the leaf node and all its parent nodes up to the root.

The validation problem is reduced to a simple cryptographic check: if the provided leaf hash can be used to reconstruct the root hash through the Merkle proof, we can be certain that the leaf value is untampered.

Structure of Merkle Trees

This data structure is called a Merkle Tree. It is a tree based structure where each leaf node represents a hash of the underlying data, and each non-leaf node is a hash of its child nodes. This recursive hashing mechanism ensures that any data modification alters the hash of the corresponding node, propagating changes up to the root.

From this, we can derive two important properties:

1. To verify if all leaf nodes are unchanged between a “trusted” state tree and an “untrusted” state tree, we only need to compare the root node hash.

2. Merkle proofs verify the inclusion of specific data within the tree

To verify the presence of the leaf node "bin", we compute and return the following hashes:

• h(binary)

• h(h(move)+h(movie))

• h(h(tree)+h(trie))

By calculating these hash values, we can traverse through all sibling nodes, allowing us to reconstruct the hash of the root node, to verify whether the leaf node "bin" is included in the tree. Read more on Merkle Proof verification here and here.

Merkle trees enable efficient verification of the contents of a data structure by storing cryptographic commitments.

Merkle trees excel at proving data inclusion. To demonstrate the inclusion of a leaf node, a user can simply request a Merkle proof that shows a particular leaf is a child of the state root. Consequently,“Verifying Proof of Data Inclusion” requires only O(log N) time.

However, Merkle trees are inefficient at retrieving the "actual value" at the leaf node. This inefficiency arises because the position of a node is independent of it’s key. Hence the only way to fetch the “actual value” of a leaf node is to traverse the entire tree in a brute force fashion.

Read more about how Ethereum uses Merkle Proofs here.

Merkle-Patricia Trees: Ethereum’s Solution

A Merkle Trees property of enabling efficient checks on inclusion is leveraged in the Bitcoin Network. Light clients can use Merkle proofs to verify the status of a transaction. They do this by requesting a proof that demonstrates the inclusion of a transaction in one of the Merkle trees, with the root of that tree being included in the block header of the main chain.

This achieves Bitcoin’s use-case as a peer-to-peer version of electronic cash. However as Ethereum extends to behave as a global computer, Merkle Proofs are limiting. In particular, while Merkle Proofs enable verifying inclusion of transactions, proving the current state would require multiple, expensive reads.

Ethereum's state architecture must meet two crucial requirements:

• Rapid Access: The architecture must support fast reads and writes to the state

• Verifiability: Ethereum's state must allow inclusion proofs

To achieve this, Ethereum takes the Merkle tree concept one step further with “Merkle Patricia Trees”.

Trees & Tries: A tree in is a hierarchical data structure consisting of nodes connected by edges, where each node has at most one parent and zero or more children, with a single root node at the top.

A trie is a specialised tree-like structure designed to store strings. Each node in a trie represents one or more characters and paths corresponds to prefixes. A Merkle Patricia Tree derives properties from the Patricia Trie but is categorised as a Tree.

Merkle Patricia Trees

Merkle Patricia Trees, are specialised tree structures that combine the benefits of Merkle Trees and Patricia Tries. In particular, with an MPT, Ethereum gains the data integrity guarantees of a Merkle Tree, alongside the optimised reads/writes achieved through Patricia Tree’s key encoding. Due to these design advantages, MPTs today power Ethereum and several other blockchains.

Structure of a Hexary Merkle Patricia Tree

1. Node Types: In a Hexary Merkle Patricia Tree, nodes are categorised into three types:

   • Branch Nodes: These nodes can have up to 16 children, representing the 16-character hexadecimal alphabet. Each branch node contains a hash for each of its child nodes.

     • Storage: Represented as a 17-item array, where the first 16 elements are pointers to child nodes, and the last element stores the value, if applicable.

   • Leaf Nodes: These nodes indicate the end of a path in the trie and contain the final segment of the path along with the associated value.

     • Storage: Stored as a 2-item array, consisting of the encoded path and the value.

   • Extension Nodes: Similar to Patricia trees, these nodes optimise the trie by compressing paths for nodes with a single child, reducing the number of nodes required.

     • Storage: Stored as a 2-item array, which includes the encoded path and a reference to the next node.

2. Hashing: Similar to Merkle trees, each node in the tree has a unique hash value derived from its content. This ensures that any alteration in the data results in a change in the root hash, making tampering evident.

The MPT is visualised as a tree, however it is stored in a key-value database like RocksDB where each node is serialised and stored as a value, with its hash serving as the key. This allows for efficient retrieval and verification of nodes based on their hash values.

In the above example,

• The root node (h1) is a branch node that points to two child nodes (h2 and h3); it’s children are stored as a 17 member array with the first 16 nodes being pointers and the 17th member being the (optional) value

• Node h3 is an extension node that points to another node (h6). Extension nodes have a 2 item array, with the first member as the encoded path and the second member as the hash to the child node.

• Node h9 is a leaf node and has no children. Leaf nodes have a 2 item array as well, similar to extension nodes, with the first member as the encoded path and the second member as the hash to the child node.

Leaf nodes and Extension nodes are differentiated through the use of a bit prefix, however we’ve omitted this detail to maintain simplicity in the diagram.

Reads & Writes in Merkle Patricia Trees

• Key Lookup: When a read request is made, the system begins by converting the key into its corresponding hexadecimal representation.

• Traversal for Insertion: The system traverses the Tree using the hexadecimal string. If a suitable path does not exist (e.g., the key is new), the tree structure may need to be modified:

  • At each branch node, the tree traverses between 0-9 or 0xA-0xF allowing the trie to split across upto 16 child nodes.

  • New nodes may be created if the key diverges from existing prefixes.

  • Extension nodes may be added to compress the tree further.

To read the value encoded by the string "binary" in a Merkle Patricia Tree, follow this process:

1. Convert "binary" to a Hexadecimal String:

   The string "binary" is converted to its hexadecimal representation: 0x62696e617279.

2. Descend the Tree:

   Begin at the root branch node. At each branch node, descend to the child node linked to the current index of the hexadecimal string. The traversal follows the sequence of digits in the hexadecimal string: start with 6, then move to 2 and continue this pattern until reaching the last digit 9.

3. Handling Extension Nodes:

   When you reach an extension node, you can skip a prefix of the string entirely. This is possible because an extension node indicates that the prefix is common among all its child nodes, eliminating the need to traverse to a specific child node.

   • In the above example on traversing the tree, starting with 6 and then 2 we reach an extension node. Extension nodes bypass unnecessary nodes allowing the traversal to skip 0x696e and reach the next branch node.

4. Reaching the Leaf Node:

   Finally, you will arrive at the leaf node. The key section of the path can be compressed into a single key, allowing you to read the value stored at the leaf node.

The MPT inherits it’s compute complexity from the Patricia Tree’s structure with operations such as insertion, search, and verification proportional to the height of the tree, which is logarithmic in the number of leaf nodes (O(log n)). Similarly, the space complexity is also optimised due to the use of Patricia Trie's collapsing mechanism and the efficient hashing of Merkle Trees. This results in a space complexity that is generally better than standard tries (O(n)).

Binary Merkle Patricia Trees

Hexary Merkle Patricia Trees build short trees of height $$log(n)/log(16)$$, creating shorter Merkle Paths than in a Binary Tree. This allows faster computation, as disk accesses are a greater bottleneck than hashing; shorter trees means fewer DB reads.

The Ethereum tree was originally hexary because database accesses are expensive and this would reduce the number of database reads. However, with some clever storage optimisations we can achieve hexary-like database accesses even with a binary tree (see https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751#:~:text=And here is,binary tree implementation.)

By optimising database reads to be hexary-like, we can make BMPTs equally DB efficient as Hexary ones. Binary Trees have only 2 children per node, so BMPT Merkle proofs require 15x less node information to be sent (one sibling vs 15 in a hexary tree), while only being 4x longer than a Hexary tree; ~4x savings.

Noting this, EIP 3102 proposed switching Ethereum to a Binary Merkle Patricia Tree. As “hashing was computationally cheaper than disk accesses”, binary tries looked to maximise hashing by growing the length of the tree while reducing its breadth.

Consequently, with a binary tree we achieve low proof sizes and a more efficient representation in the database.

In general, in an N-element tree with each element having k children, 
the average length of a branch is roughly 32 * (k-1) * log(N) / log(k)
plus a few percent for overhead. 

32 is the length of a hash; the k-1 refers to the fact that a Merkle proof 
needs to provide all k-1 sister nodes at each level, and log(N) / log(k) 
is an approximation of the number of levels in the tree 

For any N, the expression is minimized at k = 2. 
Here’s a table of branch lengths for different k values assuming N = 2**24:

While EIP 3102 was shelved in favor of Ethereum’s “Verge”, it was picked up by several rollups including Starknet, which now operates as a Binary MPT.

Similar to a hexary MPT, a binary MPT is also stored in a key-value database like RocksDB where each node is serialized and stored as a value, with its hash serving as the key. This allows for efficient retrieval and verification of nodes based on their hash values.

In the above example,

• The root node (h1) is an extension node that points to its child node (h2). Extension nodes have a 2 item array, with the first member as the encoded path and the second member as the hash to the child node.

• The node (h2) is a branch node that points to two child nodes (h3 and h4); it’s children are stored as a 3 member array with the first 2 nodes being pointers and the 3rd member being the (optional) value

• Node h12 is a leaf node and has no children. Leaf nodes have a 2 item array as well, similar to extension nodes, with the first member as the encoded path and the second member as the hash to the child node.

Leaf nodes and Extension nodes are differentiated through the use of a bit prefix, however we’ve omitted this detail to maintain simplicity in the diagram.

Structure of Binary Merkle Patricia Trees

The structure of a Binary MPT is quite similar to a Hexary MPT, with a simple modification where each node has upto two children. This design results in a longer tree—potentially up to four times longer than its hexary counterpart. However, the benefits of this structure are substantial.

In a BMPT, each branch node has only one sibling instead of fifteen, which achieves a reduction in the size of Merkle proofs, leading to a reduction of up to fifteen times in the data required for these proofs.

Additionally, BMPTs carry forward all the optimizations achieved by combining Merkle and Patricia trees.

A Binary Merkle Patricia Tree is architecturally similar to a Hexary Merkle Patricia Tree, hence it’s reads and writes are performed in a similar fashion, where bits are compared instead of hexadecimal digits for path encoding. The time and space complexity are also similar.

The Limitations of Current Solutions

While Merkle Patricia Trees and its binary version has significantly improved Ethereum's state management, challenges persist as the blockchain continues to grow. Today, an Ethereum archive node requires over 12 TB of storage, highlighting the need for more efficient state architectures.

1. Storage Bloat: As the chain grows, so does the state size, leading to increasing storage requirements.

2. Read Performance: Taller Merkle paths in growing trees result in slower read times, especially for accessing historical state.

3. Write Overhead: Updates to the state require traversing and updating the entire path from leaf to root, which becomes more time-consuming as the tree grows.

These challenges have led to the development of stopgap measures such as state snapshots and pruning.

Bonsai: A Unique Solution to the State Problem

Developed by Consensys, Bonsai reimagines state storage and access rather than incrementally improving upon existing tree structures. This new approach is built on two key insights:

1. For non-archive nodes, the majority of state reads occur within the most recent 500 blocks.

2. Optimising for recent state access can yield significant performance improvements and storage savings.

Key Features of Bonsai

The Bonsai Tree stands apart due to it’s distinct feature sets

• O(1) read times

• 90% reduced storage requirement (under optimal conditions where Bonsai retains all trie logs and minimal snapshots to balance storage and read times)

These metrics can be achieved due to Bonsai's implementation of leaf nodes as "directly accessible key-value pairs in a flat database".

A flat database is a data storage structure that organises data in a two-dimensional format, consisting of rows and columns, where each row represents a record and each column represents a field.

Bonsai Tree Structure

A Bonsai tree is a modified Binary Merkle Patricia Tree that stores leaf nodes in a flat database; hence significantly optimising read times. Unlike traditional Merkle Patricia Trees, where reading data requires traversing from the root node to a leaf, Bonsai enables retrieval with a single disk read.

However, updates or writes to the Bonsai tree are performed similarly to those on a BMPT, requiring traversal of the entire tree. This traversal is necessary to update the hashes for each parent node.

It is important to note that Bonsai stores state trie nodes based on their location within the trie. Therefore, an update to a value does not change its flat-DB key, allowing for O(1) reads to be maintained even after state updates.

While most representations of Ethereum's global state trie use a key-value store indexed by each node's hash, Bonsai stores state trie nodes based on their location within the trie. This allows for direct access to an account's data** from storage using its key**

The Bonsai tree is an modified Binary Merkle Patricia Tree that stores leaf nodes in a flat-database to enable O(1) read times

To present a short example of Bonsai’s state reads and updates, we can refer to the diagram above. Note that the diagram is a simplification and omits certain steps of tree construction.

Read Operations in Bonsai Trees

Reading data from a Bonsai Tree involves retrieving information based on a specific key. Here’s how it works:

• Key Lookup: The system converts the data queried into its corresponding flat database key.

• Data Retrieval: The system queries the flat database using the calculated key. By skipping the trie traversal, Bonsai Trees can achieve O(1) access times.

To read the value encoded with the key bin in a Bonsai Tree:

1. Key to Storage Translation: Bonsai stores data internally with the a calculated hash as the flat-database key, in our example this is h(bin)

2. Direct Storage Lookup: With the hash, Bonsai directly queries the flat-database and retrieves the data.

   1. This lookup is performed without traversing any trie structure or computing hashes.

Write Operations in Bonsai Trees

Writing data involves updating the state of the Bonsai Tree and the flat database:

• Key Conversion: The path key is converted into a binary string.

• Traversal for Insertion: The system traverses the Bonsai Tree using the binary string. If a suitable path doesn't exist, the tree structure may need modification.

  • New nodes may be created if the key diverges from existing prefixes.

  • Extension nodes may be added to compress the tree further.

• Updating the Flat Database: Once the appropriate leaf node is identified or created, the system updates it with the new value

An example of writing data to a Bonsai Tree is as follows.

1. Identify the Storage Slot: The key that is being written to is bin , this key is converted to it’s binary equivalent 01100010 01101001 01101110

2. Modify State Data: For example, let's say the value for this key needs to be updated from 10 to 11.

3. Update the Leaf Node: The system locates the leaf node associated with the key bin in the flat database.

   1. A trie traversal is performed, descending down the Bonsai trie according to the calculated binary key

   2. The final branch node in the path has the leaf node as a child. This leaf node is used to update hashes for parent nodes, whereas the actual value for the leaf node is stored and accessed from the flat-database.

4. Write New State Data: The new state data (e.g., updated value of 11) is written to the identified leaf node. The trie structure is updated to reflect this new state.

5. Calculate New Root Hash: After updating the trie, the system recalculates all parent hashes up to the root hash of the trie.

Thus, to write to a Bonsai Tree, the client must update all parent nodes of that leaf. This results in writes taking as long as Binary Merkle Patricia Trees.

Accessing Legacy State in Bonsai

Ethereum’s MPT allows for efficient retrieval of older data by maintaining a link between the current state and its historical versions. Each block in the blockchain contains a root hash of the state trie, which reflects the state of all accounts and contracts at that particular block.

As an MPT preserves older blocks, a user only needs to specify the block they want to query to access older data. Since all states are linked, an older block in the MPT can be fetched, and its state tree can be read. The MPT also allows unchanged storage in newer blocks to reference older blocks, reducing data duplication. Therefore, reading storage from block 175224 may require accessing block 175223, as the state tree of the former points to the latter.

In a Bonsai tree, keys to leaf nodes are derived from their location in the trie rather than from the values of child nodes, as is the case with Merkle Patricia Trees. Consequently, when a leaf node value is updated, the previous value cannot be retained, and Bonsai only stores the latest state, automatically pruning older values with each update.

To access older state data, Bonsai utilizes trielogs, which capture modifications made to leaf nodes within a specific block. Each trielog records updates to the flat-database including both previous and current values. These trielogs are stored in the database with the block hash as the key.

A Discussion on Trie Logs

Trielogs represent the differences between two blocks’ states by capturing each modification. To read an older state, a node can use the trielogs to selectively revert or apply changes. By traversing the trielogs from the current block back to the desired block, the node can reconstruct the state at that specific point in time.

For example, to read the state at block 175223, a node would start from the current block and apply the trielogs in reverse order until it reaches block 175223.

A simplified example of Trie Logs is attached below.

Block Hash: 0xabcdef1234567890...

Trielog:

  - Account: 

    - Account address: 0x1234567890abcdef...

    - Previous Value: { balance: 100, nonce: 0 , ...}

    - Next Value: { balance: 150, nonce: 1 , ...}

  - Storage Slot:

    - Account address: 0x1234567890abcdef...

    - Slot key: 0x0111...

    - Previous Value: 0x01

    - Next Value: 0x02

  - Code:

    - Account address: 0x1234567890abcdef...

    - Previous Value: 0xaabbccddeeff...

    - Next Value: 0x112233445566...

Key Elements of the Bonsai Architecture

1. Bonsai’s Flat Database:

   • As Ethereum's state grows, Merkle paths become taller, leading to slower read times as tree traversal grows complex.

   • With Bonsai’s architecture, O(1) read times can be achieved by directly accessing leaves in the flat database

2. Single State Representation:

   • Bonsai’s prioritises providing “real-time” state over functioning as an archive node.

   • This design enables the Bonsai tree to store only the latest state representation at any given time, resulting in no connections to previous blocks.

   • Consequently, this leads to a significantly more compact state representation compared to an MPT.

   • However, a single state representation means, unlike an MPT, Bonsai trees do not store previous block information in it’s state tree

3. Trielogs:

   • With a Single State Representation, Bonsai is still able to serve older block data through the use of Trielogs

   • Trielogs represent the differences between two blocks’ states by capturing each modification made.

     • They contain the prior and next versions for each modification, allowing for state changes to be reverted or applied selectively.

     • Through the use of Trielogs, Bonsai trees can efficiently perform chain reorganisations by “rolling back” or “rolling forward” state.

   • While enabling transitions between states, a recursive application of Trielogs to attain an older state can be both computationally and storage-wise expensive.

     • Thus, bonsai’s read-first design comes at a tradeoff of being unoptimised for reads on extremely old blocks.

Conclusion

In conclusion, blockchain state architectures have evolved significantly to address the challenges of verifiability, scalability, and performance. From simple Merkle trees to more complex structures like Merkle Patricia Trees (MPTs) and their binary variants, each iteration has brought improvements in efficiency and functionality.

Bonsai as the latest innovation represents a shift in state management. By storing leaf nodes in a flat database, Bonsai achieves O(1) read times and significantly reduces storage requirements. While optimized for recent state access, Bonsai uses trielogs to maintain historical data accessibility.

This evolution in state architecture demonstrates the ongoing efforts to balance the needs for rapid access, verifiability, and efficient storage in blockchain systems, paving the way for more scalable and performant decentralized networks.

The Ethereum scaling landscape has expanded rapidly in recent years; introducing rollups that repurpose the L1 as a settlement layer. Traditionally featuring Optimistic L2s including Arbitrum and Optimism, and zkEVMs such as Scroll and Taiko; rollups today have enabled a surge in economic and network activity across the Ethereum landscape.

While L2s enable complete modularity on all elements of the stack, most rollups operate as near-identical-EVMs. This approach does have merits: it ensures a consistent user experience, allowing rollups to feel "native" to the L1, and the reuse of Solidity contracts and EVM wallets allows a seamless transition for developers and users.

However, these benefits come at a significant cost. Such an architecture is constrained by the inherent limitations of EVMs, effectively carrying forward the very constraints L2s were meant to overcome. This ultimately undermines the core purpose and flexibility of L2s, which were intended to be a platform for innovation rather than mere scaled copies of existing systems.

This results in the carrying forward of EVMs’ ZK-unfriendly elements, such as the Keccak Opcode, which is exponentially more expensive to prove, and the Solidity programming language, whose shortcomings have often been critiqued.

Observing the limitations an EVM-identical rollup would suffer, Starknet chose an alternate approach with its ZK-focused Cairo VM.

The Ideology Behind Starknet

Starknet's vision was to reinvent an L2 from first principles. Starting with a clean slate allowed Starknet to make unconstrained decisions across all aspects of its chain.

For instance, Native Account Abstraction is standard for all Starknet wallets, yet account abstraction is still unseen in most other rollups. Similarly, Starknet developed Cairo, a new smart contract language designed specifically for ZK proofs, rather than adapting Solidity for ZK compatibility.

This redesign allowed Starknet to build a rollup without inheriting the technical debt of EVMs.

Starknet Tech Overview

1. Cairo: Rust-Like & Provable

The Cairo programming language was invented by StarkWare to resolve the flaws of Solidity that were discovered through a decade of experimentation. Cairo is the result of a vision to create a “better Smart Contract Programming Language” that is “innately ZK-Friendly”.

The Cairo programming language, invented by StarkWare, resolves the flaws of Solidity discovered through a decade of experimentation. Cairo is designed to be "innately ZK-Friendly", unlike Solidity, which was solely focused on smart contract development and includes several ZK-unfriendly components, such as the Keccak hash and its version of the Merkle Patricia Tree.

Cairo addresses Solidity’s limitations, including stack management, linear type system, and function imports, while being tailored for provability. For example, Cairo is not constrained by the limitations imposed by the EVM, such as the Keccak Opcode, which is approximately 1000x larger in circuit size compared to ZK-friendly hash functions like Poseidon.

By addressing Solidity's limitations and optimizing for ZK-proving, Cairo positions itself as a future-ready smart contract development language, particularly for ZK apps.

2. Account Abstraction

Another example of a shortcoming rooted in the EVM-identical approach is the lack of Account Abstraction across the rollup space.

Account abstraction enables the use of smart contracts instead of traditional Externally Owned Accounts. EIP-4337 has been on the Ethereum roadmap for years now, with Vitalik himself admitting its absence in Ethereum as an architectural regret.

EIP-4337 enables complex transaction logic to be executed through smart contract wallets without requiring direct user management of private keys. This enhances security and usability, whilst also supporting advanced authentication methods.

While Ethereum’s changes are understandably slow, the dearth of innovation in L2s is reflected in the reluctance to “go beyond” the EVMs spec. Despite the demand for it, bar zkSync no other ZK-Rollup has implemented native account abstraction.

On Starknet, Smart Contract Accounts are the norm with the likes of Argent and Braavos continuously innovating and demonstrating the benefits of native account abstraction.

What’s Ahead: The Starknet Roadmap

The Starknet stack comprises a robust suite built on aggregated proving, Cairo as a Domain Specific Language, and an industry-leading ZK Prover. These components collectively enable Starknet to function as a high-performance, secure network.

Building on the Starknet Stack, Starknet’s roadmap over the next six months focuses on “continuous improvement” in the chain’s UX and DevX; allowing ALL Cairo chains to be faster and more efficient. Key areas of development include Parallelisation, Cairo Native, Stwo & SHARP.

1. Optimistic Parallelisation

Starknet’s latest upgrade includes optimistic parallelisation, an approach that allows the sequencer to process multiple transactions simultaneously, achieving significantly lower confirmation times.

A similar optimisation is implemented in Solana, albeit through the use of access lists, which require each transaction to declare the storage slots it’ll access before execution. This enables Solana to identify non-conflicting transactions that can be processed in parallel.

In contrast, Starknet’s approach is based on optimistic parallelization, where transactions are initially executed concurrently under the assumption that they are independent. The sequencer then checks for conflicts. If it finds that one transaction needs to read storage slots modified by another transaction, it re-executes the affected transaction.

Starknet will be the only L2 to support parallelisation.

Starknet hence relies on a dynamically constructed dependency graph that tracks conflicts between transactions allowing Optimistic Parallelisation without access lists. The feature is live on Starknet’s Sepolia Testnet and is due to be on the Mainnet by late August.

A detailed piece on Starknet’s parallelisation is in the works by the Karnot team and will be released shortly.

Suggested Reading: The Starknet Architecture

While Starknet's architecture is complex and multi-layered, simplifying it helps us focus on Starknet’s two major upgrades: Cairo Native and Stwo. However to appreciate these optimisations, we must discuss two components of the Starknet architecture: The Sequencer and The Prover.

The Sequencer has two core tasks, sequencing and execution.

• Sequencing: Ordering transactions and appending new blocks.

• Execution: Executing transactions and updating the system’s state

  • The sequencer, hence is able to provide “soft confirmations” based on the result of its execution, however finality is only achieved with the chain’s settlement on L1.

  • Soft confirmations can be used by dApps to provide real time responsiveness on the premise that the Starknet sequencers’ execution is correct.

The Prover provides a mathematical guarantee that the transactions in a block are executed correctly.

• The prover re-executes the transactions in a “Provable Environment” and generates

  • An Execution Trace: A log of how each transaction was executed

  • A State Diff: A record of how the Starknet state changed after processing the block

• The prover then processes the execution trace, taking random samples to mathematically guarantee the executions validity

• Together “The Proof and State Diff” encapsulate thousands of transactions and their validity

• As dApps operate with Soft Confirmations from the sequencer, the prover is free to operate asynchronously and be scaled horizontally allowing Proof Submission to happen on “a rolling basis”.

2. Cairo Native: Enabling High Speed Execution with MLIR & LLVM

Cairo code today undergoes a multi-step compilation process, namely going from a Cairo program to an intermediate representation called Sierra (Safe Intermediate Representation), to finally Cairo Assembly (CASM) that is executed on the Cairo VM.

The presence of the Sierra step ensures safety and prevents runtime errors, guaranteeing that all transactions that reach the Cairo VM are eventually provable. Overall this prevents DDOS and reduces the likeliness of failing transactions reaching execution. Read more here.

Cairo Native significantly boosts performance, allowing up to 1700 swaps per second.

The LambdaClass team has been leading the development of Cairo Native, a compilation optimisation that converts Sierra code to native object code. Cairo Native’s optimised compilation enables significantly faster execution without the need for a Cairo VM. To get a brief idea of Cairo Native, we must understand two key compiler frameworks used in Cairo Native

• LLVM: Assembly Code Abstraction

  • LLVM IR is an intermediate representation that simplifies various CPU instruction sets (like x86 and ARM).

  • It allows for cross-architecture compatibility by using a generic language instead of specific assembly code.

  • LLVM IR maintains a linear instruction sequence, focusing on CPU instruction abstraction.

• MLIR: Abstraction over Intermediate Representation/Computation

  • MLIR builds upon LLVM by using flexible operations that represent a wider range of computations than simple CPU instructions.

• MLIR can convert its representations to LLVM IR, allowing it to benefit from LLVM's optimizations and generate efficient machine code.

How Cairo Native uses both:

• Cairo code is first compiled to Sierra.

• Cairo Native translates Sierra to MLIR operations.

• These MLIR operations are then lowered to LLVM IR.

• LLVM optimizes this IR and generates native machine code.

This approach allows Cairo Native to handle Cairo’s functionality in MLIR, then leverage LLVM's ecosystem for final optimization and code generation.

A detailed piece by the Karnot team on Cairo Native and it’s intricacies is in the works, meanwhile read more here.

3. Stwo: Starknet’s Industry Leading Prover

As discussed in the Architecture section; it is the role of a Prover to create mathematically sound proofs that attest to a transaction executing correctly. While computationally expensive, provers run “off-chain” and return a ZK-Proof to the Verifier contract; which is lightweight and sufficient to guarantee correct execution.

However, as ZK-Rollups scale, their biggest expenses steer towards being cloud costs incurred by running these provers. Consequently, any improvements in Provers has a amplified impact across the ecosystems expenses. Thus, a faster and more efficient Prover reduces proving costs, latency and potentially increases throughput.

StarkWare’s latest breakthrough titled Circle STARKs introduces major optimisations to STARK calculation (the math behind Starknet’s ZK-Proofs). By working over smaller 31-bit fields instead of 256-bit fields. Computing circle STARKs over 31-bit fields fully utilises 32-bit registers, reducing wasted space and leading to more efficient hardware design. Circle STARKs thus can represent information much more efficiently, making proof creation significantly more hardware friendly.

Stwo has achieved record breaking results, and has benchmarked 1000x the hash rate of its predecessor, Stone.

Read more about Circle STARKs here.

StarkWare shattered the world proving record with over 500,000 hashes proved per second

4. SHARP (a SHARed Prover): If it’s in Cairo, SHARP can prove it

Starkware’s SHARP is an industry first innovation, enabling Cross Chain Proof Aggregation. In simpler terms, SHARP reduces verification costs by generating recursive STARKs, accepting proofs from ALL Cairo chains.

SHARP’s cross-chain proof aggregation capability has been Mainnet ready since early 2023

By recursively aggregating multiple proofs from the Starknet chain, Paradex, DyDx and other Cairo chains, SHARP effectively spreads the cost of L1 verification across thousands of transactions, creating network effects across the ecosystem.

Stwo, scheduled for release in Q1 2025, is expected to significantly reduce proving costs. With SHARP as an aggregator wrapped atop Stwo, Starknet and all Cairo chains are expected to witness major savings in proving costs.

Kakarot zkEVM: The Best of Both Worlds

While we strongly believe Cairo is an efficient proving and advanced smart contract language, there are reasons to deploy on the EVM:

1. Reusing audited smart contracts

2. Leveraging existing Solidity experience for faster shipping

3. Staying with the improving EVM ecosystem

If you choose to build on the EVM, today's ZK-rollup ecosystem includes Scroll, zkSync and Polygon, each using a "low-level circuit" approach for EVM provability.

Kakarot zkEVM is an EVM implementation written in Cairo. It combines Starknet Stack advancements (Stwo, SHARP, Parallelisation, Cairo Native) with EVM ecosystem’s network effects.

Kakarot's intermediate language approach results in a 90% lighter codebase than circuit-based rollups, enabling faster adoption of EVM upgrades and fewer potential vulnerabilities.

Kakarot’s approach significantly simplifies introducing custom precompiles, allowing you to implement builtin functions that would be computationally expensive if executed in EVM bytecode be natively integrated into the Kakarot client; optimized for better performance.

Kakarot zkEVM is expected to achieve 100% EVM compatibility soon. Moreover Kakarot’s bytecode compatibility enables full reuse of Solidity contracts while running your appchain with the security guarantees and proving architecture of all Cairo chains.

Madara

The Starknet Stack hence comprises of powerful innovations in the ZK and blockchain space. However till date, the only way to run a custom Starknet chain, alike Paradex and DyDx was through StarkEx, Starkware’s appchain-as-a-service offering. And whilst StarkEx has been in production on Mainnet since June 2020, StarkEx was closed source and had limited access.

With Madara we bring the same stack that powers over $1B TVL to everyone.

Inspired by the StarkEx, Madara is a performant and open-source implementation of the Starknet Stack. Madara is developed with a focus on fractal scaling—the use of L2s and L3s to exponentially scale Ethereum, whilst benefitting from all upgrades to ANY components of the Starknet Stack.

Madara's architecture enables integrating app-level customizations deep into the protocol layer, allowing fine-tuning of block times, gas costs, provers, and data availability layer according to the app's requirements.

With Madara, any app can be an appchain.

Read more about Madara here.

Karnot

At Karnot, we're proud to be core contributors to the Madara project and the leading RaaS provider for Madara app chains. Our team brings years of experience in building scalable, fault-tolearnt systems. Through successfully running multiple devnets and testnets, we've continuously refined our services, ensuring robust and battle-tested solutions. We continue to actively contribute to Madara's development while strengthening our infrastructure to offer "Appchains as a Service". This dual focus puts Karnot in a unique position to build AND provide exceptional scaling solutions to appchains across the ecosystem.

Whether you're looking to build EVM app chains or Starknet app chains, we're here to support your project. We invite you to connect with us and explore how our expertise can accelerate your appchain journey.

"We are delighted to announce that Pyth Price Feeds will be available to all rollup developers choosing Karnot which will boost the growth of DeFi for the ecosystem.” — Abhimanyu Bansal, Head of Business Development at Douro Labs.

Meet Pyth

The Pyth Network is a first-party financial data oracle network that delivers secure, low-latency price data for various assets on blockchains. Pyth incentivizes major exchanges, market makers, and trading firms to contribute their proprietary data to the network. This aggregated on-chain price data is available for smart contracts to use. Decentralized applications can request or pull Pyth price updates on-chain as needed.

In under a year, Pyth has secured over $2 billion in total value and supports over $5 billion. With over 500 live data feeds covering crypto, equities, ETFs, FX pairs, and commodities, Pyth has facilitated over $500 billion in total trading volume across over 60 blockchain networks.

Integration with Karnot

We are delighted to announce that Pyth’s extensive price feeds will soon be integrated into Karnot's suite of tools. With Pyth's diverse, low-latency data on various commodities and cryptocurrencies, developers within the Starknet ecosystem can now build advanced, real-time applications using industry-leading resources.

Start Building Today

We’re eager to see the innovative solutions this integration will inspire within our chains and developer communities. If you’re interested in launching a rollup with Pyth's state-of-the-art oracle solution, contact us! Build with Karnot today and explore the vast possibilities Pyth’s oracle can unlock for your appchain.

While SHARP offers efficiency, its centralized nature motivates the exploration of decentralized alternatives. This is where Karnot's integration with Gevulot becomes pivotal. Gevulot's permissionless, general-purpose proof layer optimizes for being credibly neutral, highly configurable, and incredibly low cost, enhancing app chain security and scalability whilst also providing verification.

Why Karnot Chose Gevulot

Karnot sought a decentralized proving solution uncompromising on speed, developer experience, or cost-efficiency. Gevulot delivers on all fronts. The economic design and optimised workload distribution maximize their internet-scale compute network, offering performance on par with even centralized provers. Gevulot's inherent support for STARK proofs also enables seamless integration with Starknet App Chains built with Madara.

Benefits for Karnot App Chain Developers

Karnot's Gevulot integration delivers tangible advantages for app chain developers. Gevulot offers crucial decentralization and flexibility, expanding developers’ options beyond specialized services like SHARP. Its focus on usability streamlines development processes, saving time and effort. With Gevulot's devnet soon to be launched on March 25th, all Karnot App Chains will receive free proof generation and verification.

Conclusion

Our partnership with Gevulot expands Karnot's toolkit, offering cost-effective decentralized proof generation and verification. This integration strengthens Karnot's position as the leading RaaS provider for Madara app chains and demonstrates our commitment to cutting-edge solutions within the ecosystem.

We are excited to announce that Karnot will be hosting, deploying and managing a testnet for Kakarot over the next few months. This partnership aligns with Karnot's vision of becoming the leading RaaS provider, while simultaneously testing and accelerating Madara's path to mainnet readiness.

Kakarot has carved its niche as a key player in the ZK space, leveraging Cairo's inherent provability to build a verifiable zkEVM. This creates an Ethereum-compatible Layer 2, enabling seamless integration of existing EVM contracts, wallets, and transactions. This approach lowers the barrier to entry for developers and users familiar with the Ethereum ecosystem while also unlocking high scalability powered by STARKs and Cairo.

Kakarot's strategic decision to adopt Cairo for its zkEVM development offers significant advantages over the conventional approach of manually constructing low-level ZK circuits. By abstracting away complex cryptographic operations and circuit optimizations, Cairo, as a high-level language, allows the team to:

• Maintain agility: Building on Cairo streamlines proof generation, allowing Kakarot to stay ahead of the rapidly evolving Ethereum roadmap and potentially secure a significant competitive edge.

• Prioritize user experience: Freed from low-level complexities, the team can focus on enhancing the user experience by introducing features such as native account abstraction, face ID reinforced EOA’s and native multicall within the zkEVM environment.

• Benefit from continuous improvement: Leveraging Cairo, Kakarot automatically inherits performance optimizations and new features from Starkware's ongoing development, ensuring its zkEVM stays at the forefront of advancements in the ZK space.

The upcoming Kakarot testnet, in collaboration with Starkware and Karnot, brings exciting possibilities. Let's dissect its components to see how it works.

1. Kakarot RPC:  Acts as the EVM-compatible gateway, allowing users to interact with the Kakarot’s zkEVM through simple EVM transactions

2. Full Node: Maintains a complete copy of the current state and independently verifies transactions

3. Indexer: Facilitates quick reads of chain state by maintaining indices on parts of the current state

4. Validator: Validates and executes transactions, creates blocks and handles proof and DA submissions. Currently run by Starkware.

5. Karnot Shadow Testnet: A dedicated Madara app chain hosted by Karnot, independently simulates the activity on Starknet’s validator. It executes transactions, generates blocks, and calculates state diffs, enabling a stress test of Madara’s performance in enterprise-grade environments. By benchmarking against industry leaders like Starkware in this testnet, Madara gains valuable insights into its scalability and efficiency, allowing Madara to be further Mainnet-ready.

As Kakarot pushes boundaries, Karnot is proud to continue providing robust and scalable infrastructure solutions. We’re excited to build, deploy and grow from testnet to mainnet, to let Kakarot focus on innovation, not infrastructure.

If you’re building an app chain, Karnot offers unmatched scalability, security and expertise in the ZK app chain space. Reach out to us on Twitter, and get testnet ready in days instead of weeks.

Now it’s time that we start playing around with Madara - deploy accounts, contracts and get your app chain up and kicking (and move you on top of the leaderboard as well 😉).

Using starknet.js

Starkent.js is an npm library that allows you to interact with Starknet using Node.js. We have created some sample scripts for you that allow you to

1. Declare a contract

2. Deploy a contract

3. Transfer funds to an account

4. Get a transaction receipt

https://github.com/karnotxyz/madara-get-started

If you’ve ever used Node.js before, using these scripts should be a breeze! The instructions to use the scripts are in the README of the repo. Good luck 👍

Using starkli

Installing starkli

starkli is a CLI tool which allows you to interact with the Starknet based chain using your terminal! Currently, Madara is compatible with starkli v0.1.20. To install this version, go to this link and download the asset which is compatible with your machine (arm or x86, mac, linux or windows). Once downloaded, you can extract the file to get your binary. Once you’ve the binary, you can add the binary location to your PATH and access it on your terminal with starkli. Alternatively, you can cd to the location of the binary on your terminal and use ./starkli. For the tutorial, we will assume you’ve added it to your path.

Ensure you’ve the correct version using

starkli --version
0.1.20 (e4d2307)

Setting up starkli

1. Once you’ve starkli installed, add your Madara RPC url to the env. By default, this would be http://localhost:9944 if you’re running it locally. If you’ve hosted your chain for the Clash of Nodes campaign, this would be the rpc_url you submitted for the listing.

   export STARKNET_RPC="http://localhost:9944/"
   

2. The next step is to declare the Open Zepplin account contracts on your Madara chain! For this, you can use one of our js scripts above. You need to have Node.js installed.

   git clone https://github.com/karnotxyz/madara-get-started
   npm i
   node scripts/declare.js
   ./contracts/OpenZeppelinAccountCairoOne.sierra.json
   ./contracts/OpenZeppelinAccountCairoOne.casm.json 
   

   If you see the message, Contract is already declaredit’s fine! It means you’re on the later version of Madara where we added this contract to genesis.

3. Awesome! You’re now setup to start using starkli. Follow this amazing tutorial here to interact with your Madara chain.

4. Some pointers to keep in mind when running the above tutorial.

   1. Madara chains currently support Cairo 2.1.0. The above tutorial is also based on Scarb 0.6.1 which is compatible with this Cairo version. To install this specific Scarb version, you can use asdf as explained here.

   2. When you create your Scarb project according to the tutorial, add the following code inside the Scarb.toml file

      [dependencies]
      starknet = ">=2.1.0"
      
      [[target.starknet-contract]]
      

Learning more about Starknet and Cairo

By now, you might have got the idea that using a Madara chain is similar to using Starknet. You just need to point your RPC url to Madara! So, if you’ve used Starknet before, you are ready to get started. However, if you haven’t, it’s not too late! Here are some good resources to give you a head start on your journey.

1. Starknet book: https://book.starknet.io/

2. Starknet docs: https://docs.starknet.io/

3. Cairo book: https://book.cairo-lang.org/

4. Starknet Basecamp: https://www.youtube.com/watch?v=8GH92wM4jB0&list=PLMXIoXErTTYX-ZSxlaYDxsR66l5a39IwA

5. About Madara + Demo: https://www.youtube.com/watch?v=gKGumhRISLU

🛠️ Take part in the Madara Hackathon

Starkware has organised an hackathon with a Madara track. The track has over $4000 in cash prizes for projects that build exciting things on top of Madara. And one of the problem statements is building an app chain! So if you believe you’ve something exciting, don’t forget to share it with us here and possible grab a cash prize 💸

Firstly! Thanks a lot for the overwhelming response we received after launching the campaign. We are excited to see all of you trying out innovative things and testing our Madara and the CLI itself. However, we have seen some of you face a few hiccups when deploying the chain and that’s why we have decided to write this blog to answer some of the common questions we have received.

FAQs

How do I update my CLI to the latest version?

We have made some patches to the CLI tool to make the deployment process easier and to fix some bugs. To stay updated to the latest version, simply run the git pull command. Also, init a new app chain to ensure you’re using the latest code.

How do I use my Avail address for submitting DA blobs?

The CLI tool creates a da-config.json file for you at ~/.madara/app-chains/<your_app_chain_name>/da-config.json. The JSON file looks like this

{
    "ws_provider": "wss://goldberg.avail.tools:443/ws",
    "mode": "sovereign",
    "seed": "<seed>",
    "app_id": 0,
    "address": "<address>"
}

Edit the seed and address fields with your specific wallet details to change the wallet used for submitting data to Avail.

How do I host my chain using the CLI tool?

As a part of the campaign, you’re required to host your chain on a server and share your endpoints with us here. However, there seems to be some confusion on how to go about this. To clarify this, we are sharing some basic steps we used to launch a node on AWS using the Madara CLI.

WARNING: The CLI tool currently is to deploy quick devnets that are easy to test and play around with. Hence, it doesn’t make optimizations that are required for a production build. So while this setup might work for your devnet, we don’t recommend running this when you decide to run your mainnet

1. Firstly, we have made some patches to the CLI tool after the launch. So if you already have it installed, please update it using

   git pull
   cargo build --release
   

2. Install the dependencies mentioned here

3. Initialise your chain with

   ./target/release/madara init
   

4. Currently, the CLI tool doesn’t support running in a detached mode. So we will use screen to start the Madara chain in a separate session.

   screen -S madara
   ./target/release/madara run
   

5. Now that Madara is up and running, you can exit this screen session using CTRL + A D

6. Now, in a separate session, start the explorer. When starting the explorer, pass an additional flag to specify the host that will be used to access it. If you’ve a domain name configured, this is where it should go. It could also be your plane IP address. For example, --host=13.233.147.221. (notice you don’t need to specify http/https)

   screen -S explorer
   ./target/release/madara explorer --host=<HOST_ADDRESS>
   

7. Again, exit the session using CTRL + A D

Your Madara chain is up and running now 🚀

How do I get the endpoints needed for listing my chain?

Now that your chain is up and running, the next step is to expose the endpoints needed to list the chain. Specifically, you need

1. rpc_url: A public endpoint for your app chain to make RPC calls (port 9944 by default)

2. explorer_url: A public endpoint where your app chain explorer is visible (port 4000 by default)

3. metrics_endpoint: A public endpoint for your prometheus metrics (port 9615 by default)

If you followed the above part, then these endpoints are already available locally on your system. You just need to expose them for the outside world to use them. On AWS, you can do this by creating a security group with the following inbound rules

If your service is running on 13.233.147.221 for example (this could be a domain name as well if you’ve it configured), then your endpoints will be

1. rpc_url: http://13.233.147.221:9944

2. explorer_url: http://13.233.147.221:4000

3. metrics_endpoint: http://13.233.147.221:9615/metrics

NOTE 1: You need to add /metrics at the end of the metrics endpointNOTE 2: Do NOT add a trailing / to the endpoint

I am running out of AVL tokens, what should I do?

We have changed the default block time from 6s to 20s. This should significantly reduce the costs for running the app chain. However, if you find yourself in the need of more tokens, do reach out to us on the Discord channel mentioned below.

When will my PR get merged?

Thanks to the community, we have got a very high number of PRs already. In order to make the process easier for everyone, we are added a Github workflow which would automatically make the necessary checks on your PR to ensure all your endpoints are live and working. If you’ve already created a PR, please rebase on the latest main commit.

How can I skip the hassle of hosting the node?

You can ask use to do it 🫡

At Karnot, we excel at providing infrastructure for app chains so that you can focus on your core business logic. As a part of the Avail campaign, we are running these nodes free of cost for some limited users. If you’re interesting in this offering, please fill the form here. However, we only have limited places for this and app chains that are serious on getting their solution to the market will be given priority over here.

What specs do I need to run my node?

Ideally, 2 GB memory and 0.5 vCPU should be enough to run a devnet node. However, the Madara CLI tool currently builds the Madara image locally. This allows us to use the latest images and saves us the time of building and pushing docker images for multiple OS. While we do plan to optimize this eventually, currently this is the fastest way to play around with Madara. For my testing, we used an Ubuntu instance on AWS, we used an t4g.xlarge instance (4 vCPU, 16 GB memory and 50 GB storage).

Where can I ask questions?

The best place to ask questions right now would be the #developer-discussions channel on the Avail Discord. You can access it here. Do avoid asking questions on the Madara telegram for now as we want to reserve that for more dev discussions. However, we will be launching a Madara Discord soon 👀. Follow us here to remain updated!

EIP 4844 proposes to resolve this by introducing blob transactions and reducing costs for DA on Ethereum itself. While 4844 is promising, given Ethereum's scale and tech debt, we can be sure that a full-blown 4844 solution won’t happen anytime soon. We have proto-dank sharding, which is expected to reach mainnet this year; however, this would only be a half-baked solution in preparation for the actual 4844.

As a result, we have alternate solutions like Avail, which aim to bring data availability to rollups cheaper and much faster. Avail approaches the challenges of being an efficient, available and powerful DA solution by emphasising security and integrity.

To ensure security, Avail builds on the resilient design choices it inherits from the Polkadot SDK, closely following the paradigms that govern liveness (fault tolerance and progress guarantee) and finality (immutability) on the L1 chain.

Further, Avail employs KZG commitments to maintain data integrity, ensuring reduced memory, bandwidth, and storage footprints while ensuring proofs retain succinctness. Moreover, by using light clients for sampling, Avail also achieves flexibility to scale block sizes dynamically.

Avail is very close to launching its mainnet and has its incentivised testnet underway. We are very happy to announce our “Clash of Nodes” campaign with Avail for the same!

Participating in Clash of Nodes

Users must run a Madara app chain that uses Avail as a DA layer to participate in the Clash of Nodes campaign. While launching a Madara node can be difficult, we have streamlined the process to as simple as a few commands with our new CLI tool over here.

Playing around with Madara and Avail

Once your node is up and running locally, you can start playing around with it, deploy your contracts and make your first app chain MVP! Madara is completely compatible with all Starknet tools like ArgentX, Braavos, starknet.js, etc. So, using Madara should be as simple as using Starknet itself. If you face any issues, feel free to report them here. We also have a live bug bounty program running.

Deploying your chain

Once you have tested your chain and contracts locally, it’s time to go live 🚀. We’ve two options available for you here.

1. Use Karnot

   Choosing Karnot as your RaaS provider abstracts the nitty-gritty of managing infrastructure, deployments, and configurations, allowing you to build and deploy seamlessly as we host your chain and explorer. With Avail incentivising early movers, quick adopters stand to have their app chain infrastructure costs paid by the Avail team. So, if you would like to proceed with this option, please fill out this form, and we will take it from there.

2. Host it yourself

   For seasoned developers who prefer to control their infrastructure, Madara CLI allows you to run your own chain. To do this, you need to follow these steps.

   1. Use the Madara CLI to start your chain on a server. You would need to expose ports 9944 (RPC), 9615 (Prometheus) and 4000 (Explorer) so that they’re accessible to us. This is a good article on how to deploy a backend on AWS EC2.

   2. By default, the Karnot CLI uses 0 as the Avail app_id. However, for this campaign, you must register a unique app_id for your app. Read the appendix on how to do the same.

   3. Once you have an app_id registered, edit the file ~/.madara/app-chains/<app_chain_name>/da-config.json to replace the 0 app_id with your new app_id. Once your chain is live, make sure your endpoints are publicly accessible. If you like, you can also use a custom domain, but that’s not necessary.

   4. Now that your endpoints are working deploy your contracts on the chain and prepare them for your specific use case.

   5. Finally, follow the instructions on the repo here to get listed on the “Clash of Nodes” campaign.

Appendix

Registering an App Id on Avail

1. Go to https://goldberg.avail.tools/#/accounts and create an account on Avail. Keep the seed phrase safe.

2. Get funds on this new account using the Avail faucet.

3. Clone this repo.

4. cd avail-js/examples/node-examples/

5. npm i

6. Edit the avail-js/examples/config.ts file.

   1. Edit the “seed” to the seed phrase you got in step (1).

   2. Edit the endpoint to “wss://goldberg.avail.tools:443/ws”

7. Edit the src/create-app-id.ts file

   1. Change appName on line 14 to something unique for your app.

   2. Comment out line 26 (process.exit(0)). Without this, the app will exit before submitting your transaction to Avail. This should be fixed in the next release by Avail.

8. npm run create-app-id

9. You would see a log like the one below. 164 will be your app_id.dataAvailability.ApplicationKeyCreated:: ["0x546573742061707020617364736164736164616461206173646173646173","5Ci3f87otQeRC2y5gitVvbsez6EwCinhJwaK78MU2fCjv6Q5",164]

The Madara CLI is built to make it easier for developers to spin up local Madara nodes for development and testing purposes. It streamlines the creation, setup, and initialisation of your node to as simple as

madara init
madara run

And that’s it! You’re good to go 🚀

Unpacking the features of Madara CLI:

1. Node Orchestration:

   As mentioned above, the Madara CLI allows you to launch Madara nodes seamlessly. You no longer need to worry about the different configurations and setup commands. The CLI takes care of that, so you can start within a few minutes.

2. Node Management:

   As you begin testing with Madara, you will naturally find yourself playing around with different settings - DA layers, block times, genesis states and many other parameters. You will soon be overwhelmed with dozens of configurations and file systems. The Madara CLI creates a single aggregated interface in your terminal to make this easier. The run command shows you all the available app chains on your system so that you can select which one you want to start playing with!

3. Unveiling Network Insights:

   When building on testnets, the explorer is usually the go-to tool for developers to see what’s happening on the chain. To provide the same experience, the Madara CLI allows you to seamlessly integrate the StarkCompass explorer, allowing users to inspect the entire node with minimal effort. Use the explore command to start an explorer locally!

Roadmap

While this is our first version of the CLI tool, it’s enough for you to get kick-started with your Madara journey. As we progress and get more feedback, we will update the tool and add new features. For the moment, some items we plan on working on are

1. Adding more DA layers

2. Version management

3. Better installation experience

In conclusion, the CLI tool is a great fit if you seek a swift and hassle-free setup for Madara. To remain updated with future updates, follow us on Twitter.