Dive into Shardeum: The L1 blockchain, an autoscaling suite leveraging dynamic sharding

In this episode, Shardeum's CTO Srinivasan Parthasarathy shares how Shardeum built the first layer of the autoscaling suite of blockchains through a dynamic state sharding and blockless transaction model. The architecture enables linear scalability suite while maintaining a low barrier to entry for node requirements, providing a unique balance between performance and decentralization. He also discusses lessons learned from testnet operations, key bug bounty findings, and security approaches to the network, including a custom Proof of Quorum that rotates node responsibilities every 60 seconds. As an open-source, community-driven project, Shardeum plans to launch its mainnet on May 5, followed by phased support for smart contracts and incentive programs. (Synopsis: Mode Network: Driving Ethereum L2 Innovation to Become a Universal Efficient Expansion Kit) (Background supplement: 12 charts to gain insight into the Q1 market: DeFi activity is booming, Layer 2 rapid expansion kits, Web3 games are heating up) Introduction and Shardeum Overview Ehan: Welcome to Wu says unencrypted podcasts. Today, we're excited to have Srinivasan, Shardeum's Chief Technology Officer. Tell us about yourself and Shardeum. Srinivasan: Yes, everyone, I'm Srinivasan. I'm Shardeum's CTO. At Shardeum, we're building the world's first layer blockchain with the first autoscaling suite, and I'm very excited to be here. My journey into blockchain began in 2016. In 2017, I built my first NFT marketplace. Since then, I've worked in multiple places and built a lot of Web3-related products. I was VP of Engineering at DraftKings, helping to build the blockchain infrastructure for their flagship product. Recently, I worked for a company called Six where we sold NFT tokens representing resource rights in the United States. Now at Shardeum, I lead an amazing team focused on building this groundbreaking suite of auto-scaling suite layer 1 blockchains. How does Shardeum scale the suite while keeping the barrier to entry for node access low? Ehan: Shardeum claims to be the first layer of the first auto-scaling suite. How does its architecture achieve high transaction throughput while keeping node requirements accessible? Srinivasan: I thought it would be helpful to use a visual analogy to explain how blockchain works and how Shardeum differs — is that okay? A good way to think about event-driven blockchain is to imagine it as a spreadsheet with rows and columns. Each row represents a block, and each cell is a transaction. This spreadsheet is open to anyone and transparent, but can only be written by one person at a time—specifically, only one person can write a new row at a time. In most blockchains, the key question is: who has permission to write the next line? The essence of all consensus protocols is to determine who can write to this line. Now, imagine a spreadsheet with a billion rows and a single program to manage it all. As the number of rows increases from one billion to two billion to ten billion, it will become slower and less scalable. But what if it's not a huge table, but 1000 tabs, like Google Sheets? You can assign data to these tabs through a letter grouping algorithm, so you'll spread smaller datasets across many tables. That's basically how sharding works, and that's what Shardeum does. But Shardeum goes further. Instead of a fixed number of tabs—say, 1,000—we dynamically adjust them at runtime. You may start with only 10 tabs, but as the volume increases, you can expand the suite to 200, 1000, or more tabs. When the volume drops, it can be scaled back. This is called dynamic state sharding, and it is precisely that it that allows us to automatically scale the suite. There is one more important difference. Most blockchains operate around the concept of "blocks", which means that the writer has to write an entire line in the simulation of our spreadsheet. This allows the person writing the row to see the pending transactions and thus potentially manipulate them—such as reordering them. Shardeum does not rely on the concept of blocks. Instead, we process transactions in their purest form. The smallest unit we execute is a cell in that row. We don't need to write the entire row at once. While we mock blocks externally for EVM compatibility—so that JSON-RPC clients know how to interact with us—internally, we're not really limited to this structure. This architecture allows us to modify individual cells instead of entire rows, dynamically shard and redistribute workloads based on transaction volume, and scale out suites with minimal performance bottlenecks. It's a difficult technical challenge to solve, but it's what sets Shardeum apart. Ehan: So, are there any trade-offs to this auto-scaling suite design? Srinivasan: The obvious trade-off is that this design introduces a higher level of communication between nodes. In a traditional blockchain, each validating node stores a complete copy of the entire blockchain state — basically the entire spreadsheet in our previous simulation. This means that each node requires a lot of processing power and storage capacity. In Shardeum, because we divide the data into smaller pieces—or tabs—each node only needs to process a small part, say one of 1,000 tabs. This significantly reduces the compute and storage requirements per node, making it more accessible. However, the downside is that each node now only sees a portion of the overall state. It's like you can only access the "A" part of the phone directory. Therefore, when a node needs data outside its allocated segment, it must first determine which node holds the required data and then request data from it. This introduces a layer of communication between nodes, making things more complicated. Nevertheless, we solved this challenge with customized communication protocols that enable nodes to locate and share data efficiently. Yes, this adds complexity, but the payoff is enormous—Shardeum can scale the suite transaction throughput almost linearly just by adding more nodes. So, while decentralized inter-program communication is a tough technical challenge—and hasn't been fully solved in other systems—we believe we've cracked a scalable suite model that makes Shardeum a truly unique layer-1 blockchain. What did you learn from the incentive testnet? Ehan: What are the key insights you've gained in running a large-scale, truly decentralized incentive testnet? Srinivasan: Yes, that's a good question. We run four incentive testnets, and the level of participation is incredible—people are almost all over the world at execution nodes. Our homepage says "Decentralization for All" and we...