Here is the link to Shardeum whitepaper.
To better understand what Shardeum is, please look at the Shardus project (which serves as the protocol layer of Shardeum) built over the last five years (see https://shardus.com/). In a nutshell, Shardus has developed the software to make it easy to create shared distributed ledgers. Shardus handles the protocol layer, gossip of transactions, consensus, syncing, sharding, etc. Developers can start with Shardus and define the application layer to easily build decentralized networks for a specific application, for example, a game with a very high TPS. So the answer to the question is YES since Shardus hides from the application layer that the network is sharded.
On Shardeum, transactions are processed on a FCFS basis individually. That means consensus happens at the transaction level and not at the block level as you see with typical blockchains. Processed transactions are then grouped together and passed onto archive nodes on the network. The protocol layer takes care of cross-shard consensus and data sharing. Shardeum will ensure complex transactions and smart contracts are executed effectively and parallelly in a sharded environment while maintaining the integrity and consistency of the blockchain. In other words, Shardeum will have atomic and cross-shard composability making life easier for developers.
It doesn’t quite fit into any of these. Shardus does consensus on each transaction independently without necessarily putting them into blocks. A proof-of-quorum receipt is generated for each transaction to show if it was accepted or not. The processed transactions (after a receipt is generated and accepted txs are committed) are grouped into blocks (we call them partitions) and passed on to archive nodes. This allows the consensus nodes not to have to deal with storing the transaction history and only maintain the current state of the accounts. Once you’ve done the consensus for the transactions, the data structure you use to store them does not matter. It matters for other networks because the data structure is tightly coupled with the consensus.
Short answer: Yes.
As Vitalik has discussed here, the only real solution to achieve scalability, decentralization, and security without compromising any of them is to use sharding. Shardeum is designed from the beginning to be sharded and not as an afterthought or add-on.
One of the goals of Shardus has always been to use an energy-efficient consensus algorithm, mainly because this will result in lower transaction fees and greater sustainability. And being good for the environment is a huge side benefit. Shardeum’s commitment to social and governance values is deeply rooted in our core principle of OCC (Open, Collaborative, Community-Driven). This approach ensures that we are on the right path toward building a truly decentralized and inclusive ecosystem.
Shardeum’s consensus mechanism is Proof of Quorum (PoQ) while its sybil deterrence mechanism is Proof of Stake (PoS).
Data sharding has been on Ethereum’s roadmap for a while now, and the purpose is to increase data availability to allow multiple L2 nodes to write data to the Ethereum network simultaneously. The purpose of data sharding in Ethereum is to optimize for scaling at L2. However, Ethereum does not plan to do execution and network sharding which is needed to gain the benefits of full state sharding. Shardeum shards compute, state and data to achieve dynamic state sharding. By assigning each node to a unique range of addresses Shardeum has demonstrated true linear scaling. Shardeum is the first L1 to increase TPS with each node added to the network while retaining cross-shard composability.
Shardeum’s novel architecture overcomes the challenges faced by existing sharded blockchains while providing a preferred horizontal approach to scaling rather than L2’s and other scaling methods, which use more powerful nodes and hardware to scale vertically.
First of all, Shardeum scales linearly. On Shardeum, transactions are ordered in a time based way i.e. FCFS basis, followed by consensus and processing done at the transaction level instead of the block level as you see with typical blockchains. And, through dynamic state sharding, the network will shard its state by evenly and dynamically distributing compute workload, storage, and bandwidth among all the nodes. Every node on the network will be assigned dynamic account spaces across multiple shards with sufficient level of overlaps between address ranges. This allows for parallel processing of transactions while maintaining atomic and cross shard composability.
Further, validator nodes will store only the state data of transactions/accounts they are involved in while the individually processed transactions are grouped and passed onto archive nodes on the network. Archive nodes will be responsible to store historical data. Low overhead for validators translates to the network scaling horizontally with low gas fees forever. Autoscaling will enable Shardeum to make efficient use of resources and the consensus mechanism will ensure active nodes/validators are auto-rotated with standby nodes asides from ensuring validity of transactions with immediate finality and low latency.
Ultimately, linear scaling is the main X factor that impacts every other outcome on a blockchain network favorably including throughput, decentralization, security, and constant transaction fees irrespective of the demand in the network. Shardeum is proving that scaling linearly (through sharding) combined with an optimal consensus algorithm, transaction ordering, and autoscaling, can help you in overcoming scalability trilemma. We are pleased to inform you that Shardeum codebase is open sourced. Asides from staying true to our ethos of decentralization, we are open-sourcing to inspire other blockchain networks to overcome the scalability issues and start onboarding the world to Web3.
Shardeum will utilize a decentralized, sharded blockchain network. This is different from the Foursquare incident, which was related to issues arising from MongoDB’s sharded but centralized database. Due to our decentralized architecture, the risks associated with centralized databases, like in the Foursquare case, are not applicable.
There will be 128 nodes in a shard. Most nodes in a shard (>64) would have to accept the tx to generate a PoQ receipt. Suppose a tx involves accounts A and B in shards 1 and 2. In that case, the nodes in these shards form a consensus group (256 nodes), and a majority (>128 since consensus group size is 256) needed to agree on accepting the transaction. It’s pretty simple conceptually, but the implementation is very tricky. The Shardeum dev team is innovating and solving complex challenges as we speak.
As a validator on the network, specific protocols must be adhered to, including staking a minimum amount of coins and meeting the minimum hardware requirements. Once these criteria are met, the network ensures fair and unbiased selection of nodes for consensus and validation, without prioritizing or favoring any particular node.
We are glad to inform you that Shardeum’s source code is open-sourced as we completed defensive patent filings for innovations in our protocol, including the consensus algorithm, autoscaling, and dynamic state sharding.
We have a dedicated webpage for our open-source initiatives. Explore all our projects, discuss your ideas and questions with our open-source team, and contribute to the development. Visit the webpage here.
EVM-based languages – Solidity and Vyper.
Ed25519 and SHA256
Node.js + TypeScript + Rust
