Special thanks to Sacha Yves Saint-Leger & Joseph Schweitzer for review.

Sharding is one of the many improvements that eth2 has over eth1. The term was borrowed from database research where a shard means a piece of a larger whole. In the context of databases and eth2, sharding means breaking up the storage and computation of the whole system into shards, processing the shards separately, and combining the results as needed. Specifically, eth2 implements many shard chains, where each shard has similar capabilities to the eth1 chain. This results in massive scaling improvements.

However, there’s a less-well-known type of sharding in eth2. One which is arguably more exciting from a protocol design point of view. Enter sharded consensus.

Sharding Consensus

In much the same way that the processing power of the slowest node limits the throughput of the network, the computing resources of a single validator limit the total number of validators that can participate in consensus. Since each additional validator introduces extra work for every other validator in the system, there’ll come a point where the validator with the least resources can no longer participate (because it can no longer keep track of the votes of all of the other validators). The solution eth2 employs to this is sharding consensus.

Breaking it down

Eth2 breaks time down into two durations, slots and epochs.

A slot is the 12 second time-frame in which a new block is expected to be added to the chain. Blocks are the mechanism by which votes cast by validators are included on the chain in addition to the transactions that actually make the chain useful.

An epoch is comprised of 32 slots (6.4 minutes) during which the beacon chain performs all of the calculations associated with the upkeep of the chain, including: justifying and finalising new blocks, and issuing rewards and penalties to validators.

As we touched upon in the first post of this series, validators are organised into committees to do their work. At any one time, each validator is a member of exactly one beacon chain and one shard chain committee, and is called on to make an attestation exactly once per epoch – where an attestation is a vote for a beacon chain block that has been proposed for a slot.

The security model of eth2’s sharded consensus rests upon the idea that committees are more or less an accurate statistical representation of the overall validator set.

For example, if we have a situation in which 33% of validators in the overall set are malicious, there is a chance that they could end up in the same committee. This would be a disaster for our security model.

So we need a way to ensure that this can’t happen. In other words, we need a way to ensure that if 33% of validators are malicious, only about ~33% of validators in a committee will be malicious.

It turns out we can achieve this by doing two things:

1. Ensuring committee assignments are random
2. Requiring a minimum number of validators in each committee

For example, with 128 randomly sampled validators per committee, the chance of an attacker with 1/3 of the validators gaining control of > 2/3 committee is vanishingly small (probability less than 2^-40).

Building it up

Votes cast by validators are called attestations. An attestation is comprised of many elements, specifically:

• a vote for the current beacon chain head
• a vote on which beacon block should be justified/finalised
• a vote on the current state of the shard chain
• the signatures of all of the validators who agree with that vote

By combining as many components as possible into an attestation, the overall efficiency of the system is increased. This is possible since, instead of having to check votes and signatures for beacon blocks and shard blocks separately, nodes need only do the math on attestations to be informed about the state of the beacon chain and of every shard chain.

If every validator produced their own attestation and every attestation needed to be verified by all other nodes, then being an eth2 node would be prohibitively expensive. Enter aggregation.

Attestations are designed to be easily combined such that if two or more validators have attestations with the same votes, they can be combined by adding the signatures fields together in one attestation. This is what we mean by aggregation.

Committees, by their construction, will have votes that are easy to aggregate because they are assigned to the same shard, and therefore should have the same votes for both the shard state and beacon chain. This is the mechanism by which eth2 scales the number of validators. By breaking the validators up into committees, validators need only to care about their fellow committee members and only have to check very few aggregated attestations from each of the other committees.

Signature aggregation

Eth2 makes use of the BLS signatures – a signature scheme defined over several elliptic curves that is friendly to aggregation. On the specific curve chosen, signatures are 96 bytes each.

If 10% of all ETH ends up staked, then there will be ~350,000 validators on eth2. This means that an epoch’s worth of signatures would be 33.6 megabytes which comes to ~7.6 gigabytes per day. In this case, all of the false claims about the eth1 state-size reaching 1TB back in 2018 would be true in eth2’s case in fewer than 133 days (based on signatures alone).

The trick here is that BLS signatures can be aggregated: If Alice produces signature A, and Bob’s signature is B on the same data, then both Alice’s and Bob’s signatures can be stored and checked together by only storing C = A + B. By using signature aggregation, only 1 signature needs to be stored and checked for the entire committee. This reduces the storage requirements to less than 2 megabytes per day.

In summary,

By separating validators out into committees, the effort required to verify eth2 is reduced by orders of magnitude.

For a node to validate the beacon chain and all of the shard chains, it only needs to look at the aggregated attestations from each of the committees. In this way it can know the state of every shard, and every validator’s opinions on which blocks are and aren’t a part of the chain.

The committee mechanism therefore helps eth2 achieve two of the design goals established in the first article: namely that participating in the eth2 network must be possible on a consumer-grade laptop, and that it must strive to be maximally decentralised by supporting as many validators as possible.

To put numbers to it, while most Byzantine Fault Tolerant Proof of Stake protocols scale to tens (and in extreme cases, hundreds of validators), eth2 is capable of having hundreds of thousands of validators all contributing to security without compromising on latency or throughput.

Blockchain sharding, worded in the most succinct way possible, is the division of network activity into smaller, more manageable parts, to enhance performance and scalability. Execution sharding, more specifically speaking, involves breaking down the execution of smart contracts into smaller, more efficient pieces. Tahir Mahmood, co-founder of KRNL, and kOS, the company’s flagship product, are disrupting the execution sharding landscape with a fresh, innovative, and breakthrough approach

Should KRNL’s approach genuinely differ from traditional methods, such as data sharding, network sharding, and other approaches to execution sharding, it would prove critical to the future of dApps.

Sharding in Web3

Execution sharding is typically done using co-processors or separate environments, which can introduce inefficiencies and centralization issues. “Currently, the way people implement the equivalent of execution sharding is they tend to do it from the wallet level, or a different layer and different network altogether, as a way of managing the execution,” Tahir explains. “What we’re doing within KRNL is happening natively on the node, so that way it’s part of the standard transaction flow. It’s not a separate network, and it’s not a separate environment.”

People currently consider execution sharding to be tied to co-processors, which are dedicated environments. KRNL has an alternative approach, Tahir explains, “What we’re doing is we’re bringing the concept that all these layer ones and layer twos with all this functionality built on them, can be exposed without having to create unique specific environments, which is actually what co-processors are,” Tahir adds.

KRNL’s breakthrough solution

KRNL’s approach to execution sharding is fundamentally different from others looking to solve the sharding dilemma.

“Some protocols and projects are sharding at the consensus layer of the blockchain. Others are doing it as a proxy layer in front-end of the wallet but this places it outside of the native Ethereum architecture. This leads to a solution that lacks critical security,” Tahir explains. “We are taking a different approach by doing it natively on the node. This is a best-of-both-worlds scenario, making you natively part of the transaction flow, while allowing you to run computation pre-transaction with the requisite security.”

This approach allows KRNL to create a more efficient and secure system with kOS. Tahir states that

“We’re creating something that is much more than co-processors, which are dedicated environments. What we’re doing is exposing the functionality on different chains without having to create unique specific environments.”

kOS is being dubbed the “Superconnector”, offering app builders frictionless access to functions natively on the chain, making it inherently different from the existing suite of execution sharding solutions on the market. Unlike what LayerZero (LZ) does for assets, KRNL’s Superconnector makes boundless functionality available anywhere and by anyone, but with a more decentralized and secure approach. This ensures that application builders can access and utilize functions across different chains with minimal overhead, enhancing both performance and security.

Taking execution sharding omni-chain

KRNL’s long-term vision, Tahir shares, is to create a holistic ecosystem that enables developers to build truly decentralized applications without the inefficiencies and centralization issues that come with co-processors and other existing solutions. Thus, by enabling the execution of functions across multiple chains, KRNL is paving the way for more efficient and secure dApp development.

“We’re able to utilize the whole plethora of all those environments natively as they are, without having to do the heavy lifting to create something that is unique and specific as a co-processor,” Tahir notes.

KRNL’s Superconnector, kOS, is a reimagining of how execution sharding should be implemented. By enabling frictionless access to functions natively on-chain, KRNL breaks down all barriers to omni-chain dApp building. Make note, this is a game-changer for worldwide, democratized, and streamlined dApp developments. Even more importantly for developers, they will be able to register and monetize the features they create on KRNL’s upcoming marketplace.

Tahir & KRNL’s Future Vision

Tahir aims to expand KRNL technology from Ethereum to other EVM and non-EVM chains, creating a holistic ecosystem. “We see developers and builders being able to build feature-rich real-world applications with very little work, almost no code, and low-code solutions,” Tahir states.

This approach will allow developers to build more robust applications more quickly and efficiently.

“You’re now able to say, ‘I want to do XYZ on chain and off chain in the Web2 world,’ because that’s what really brings real-world applications to life,” Tahir adds.

KRNL’s innovative approach to execution sharding through the Superconnector will redefine how we think about decentralized applications. The future of execution sharding lies in KRNL’s natively on-chain approach, which is set to revolutionize the Web3 landscape, making real-world applications more accessible and robust.

Mentioned in this article

Blockchain sharding, worded in the most succinct way possible, is the division of network activity into smaller, more manageable parts, to enhance performance and scalability. Execution sharding, more specifically speaking, involves breaking down the execution of smart contracts into smaller, more efficient pieces. Tahir Mahmood, co-founder of KRNL, and kOS, the company’s flagship product, are disrupting the execution sharding landscape with a fresh, innovative, and breakthrough approach

Should KRNL’s approach genuinely differ from traditional methods, such as data sharding, network sharding, and other approaches to execution sharding, it would prove critical to the future of dApps.

Sharding in Web3

Execution sharding is typically done using co-processors or separate environments, which can introduce inefficiencies and centralization issues. “Currently, the way people implement the equivalent of execution sharding is they tend to do it from the wallet level, or a different layer and different network altogether, as a way of managing the execution,” Tahir explains. “What we’re doing within KRNL is happening natively on the node, so that way it’s part of the standard transaction flow. It’s not a separate network, and it’s not a separate environment.”

People currently consider execution sharding to be tied to co-processors, which are dedicated environments. KRNL has an alternative approach, Tahir explains, “What we’re doing is we’re bringing the concept that all these layer ones and layer twos with all this functionality built on them, can be exposed without having to create unique specific environments, which is actually what co-processors are,” Tahir adds.

KRNL’s breakthrough solution

KRNL’s approach to execution sharding is fundamentally different from others looking to solve the sharding dilemma.

“Some protocols and projects are sharding at the consensus layer of the blockchain. Others are doing it as a proxy layer in front-end of the wallet but this places it outside of the native Ethereum architecture. This leads to a solution that lacks critical security,” Tahir explains. “We are taking a different approach by doing it natively on the node. This is a best-of-both-worlds scenario, making you natively part of the transaction flow, while allowing you to run computation pre-transaction with the requisite security.”

This approach allows KRNL to create a more efficient and secure system with kOS. Tahir states that

“We’re creating something that is much more than co-processors, which are dedicated environments. What we’re doing is exposing the functionality on different chains without having to create unique specific environments.”

kOS is being dubbed the “Superconnector”, offering app builders frictionless access to functions natively on the chain, making it inherently different from the existing suite of execution sharding solutions on the market. Unlike what LayerZero (LZ) does for assets, KRNL’s Superconnector makes boundless functionality available anywhere and by anyone, but with a more decentralized and secure approach. This ensures that application builders can access and utilize functions across different chains with minimal overhead, enhancing both performance and security.

Taking execution sharding omni-chain

KRNL’s long-term vision, Tahir shares, is to create a holistic ecosystem that enables developers to build truly decentralized applications without the inefficiencies and centralization issues that come with co-processors and other existing solutions. Thus, by enabling the execution of functions across multiple chains, KRNL is paving the way for more efficient and secure dApp development.

“We’re able to utilize the whole plethora of all those environments natively as they are, without having to do the heavy lifting to create something that is unique and specific as a co-processor,” Tahir notes.

KRNL’s Superconnector, kOS, is a reimagining of how execution sharding should be implemented. By enabling frictionless access to functions natively on-chain, KRNL breaks down all barriers to omni-chain dApp building. Make note, this is a game-changer for worldwide, democratized, and streamlined dApp developments. Even more importantly for developers, they will be able to register and monetize the features they create on KRNL’s upcoming marketplace.

Tahir & KRNL’s Future Vision

Tahir aims to expand KRNL technology from Ethereum to other EVM and non-EVM chains, creating a holistic ecosystem. “We see developers and builders being able to build feature-rich real-world applications with very little work, almost no code, and low-code solutions,” Tahir states.

This approach will allow developers to build more robust applications more quickly and efficiently.

“You’re now able to say, ‘I want to do XYZ on chain and off chain in the Web2 world,’ because that’s what really brings real-world applications to life,” Tahir adds.

KRNL’s innovative approach to execution sharding through the Superconnector will redefine how we think about decentralized applications. The future of execution sharding lies in KRNL’s natively on-chain approach, which is set to revolutionize the Web3 landscape, making real-world applications more accessible and robust.

Mentioned in this article