Hedera Technical Insights: Fragility in DLT | Hedera Hedera Network Services Token Service Mint and configure tokens and accounts. Consensus Service Verifiable timestamps and ordering of events. Smart Contracts Run Solidity smart contracts. HBAR The Hedera network's native cryptocurrency. Insights How It Works Learn about Hedera from end to end. Explorers View live and historical data on Hedera. Dashboards Analyze network activity and metrics. Network Nodes Understand networks and node types. Devs Start Building Get Started Learn core concepts and build the future. Documentation Review the API and build using your favorite language. Developer Resources Integrations Plugins and microservices for Hedera. Fee Estimator Understand and estimate transaction costs. Open Source Hedera is committed to open, transparent code. Learning Center Learn about web3 and blockchain technologies. Grants Grants & accelerators for your project. Bounties Find bugs. Submit a report. Earn rewards. Ecosystem ECOSYSTEM Hedera Ecosystem Applications, developer tools, network explorers, and more. NFT Ecosystem Metrics Analyze on-chain and market NFT ecosystem metrics. CATEGORIES Web3 Applications Connect into the innovative startups decentralizing the web on Hedera. Enterprise Applications Learn about the Fortune 500 companies decentralizing the web on Hedera. Wallets & Custodians Create a Hedera account to manage HBAR, fungible tokens, and NFTs. Network Explorers Hedera mainnet and testnet graphical network explorers. Developer Tooling Third-party APIs, integrations, and plugins to build apps on Hedera. Grants & Accelerators Boost your project with support from the Hedera ecosystem. Partner Program Explore our partners to bring your vision into reality. Hedera Council Over 30 highly diversified organizations govern Hedera. Use Cases Hedera Solutions Asset Tokenization Studio Open source toolkit for tokenizing assets securely. Stablecoin Studio All-in-one toolkit for stablecoin solutions. Hedera Guardian Auditable carbon markets and traceability. Functional Use Cases Data Integrity & AI Reliable, secure, and ethically governed insights. Sustainability Enabling fair carbon markets with trust. Real-World Asset Tokenization Seamless tokenization of real-world assets and digital at scale. Consumer Engagement & Loyalty Mint, distribute, and redeem loyalty rewards. Decentralized Identity Maintain the lifecycle of credentials. Decentralized Logs Scalable, real-time timestamped events. DeFi Dapps built for the next-generation of finance. NFTs Low, fixed fees. Immutable royalties. Payments Scalable, real-time, and affordable crypto-payments. HBAR Overview Learn about Hedera's token, HBAR. Treasury Management Hedera’s report of the HBAR supply. Governance Decentralized Governance Hedera Council See the world's leading organizations that own Hedera. About Meet Hedera's Board of Directors and team. Journey Watch Hedera's journey to build an empowered digital future for all. Transparent Governance Public Policy Hedera's mission is to inform policy and regulation that impact the industry. Meeting Minutes Immutably recorded on Hedera. Roadmap Follow Hedera's roadmap in its journey to build the future. Resources Company What's New Partners Papers Careers Media Blog Technical Press Podcast Community Events Meetups Store Brand Navigation QUICKSTART Hedera Technical Insights: Fragility in DLT technical Nov 08, 2018 by Paul Madsen Head of Identity, The HBAR Foundation Some consensus algorithms are fragile — they cannot adapt to changes, either in the membership of nodes, or in the influence of those nodes towards consensus. The result is that such changes cause consensus to be prevented or corrupted. This can be a problem for some types of distributed ledgers, but it is not a problem for Hedera. Hedera’s stake-based implementation of the hashgraph consensus algorithm was proven to be asynchronous Byzantine fault tolerant (ABFT) in this paper, and checked by computer with a Coq proof. Additionally, it is resilient in the face of changes to both node membership and the stake those nodes have, and so is not fragile. Nodes will join and drop, the amount of hbars those nodes stake towards consensus will change, the amount of hbars that other accounts proxy to those nodes will rise and fall, but the determination of consensus will adapt to such dynamics, and so will not be fragile. In order to determine a consensus order for transactions, nodes need only know the balances of hbars in accounts - the exact same requirement of a cryptocurrency. Importantly, nodes do not need to know the number of nodes in the network in order to be able to determine consensus. Fragility All distributed ledger technologies (DLTs) require that nodes have some level of knowledge about the rest of the network in order to:  1. Send messages to those nodes 2. Validate messages from those nodes Some DLTs also require that nodes be able to: 3. Assess the relative influence of other nodes towards consensus We can say a DLT is fragile if changes to the set of consensus nodes, or their influence towards consensus, can cause consensus to be prevented or corrupted. If, as an example, upon one node dropping, other nodes were to freeze, then clearly that system would be fragile. Similarly, if, upon a node changing its stake, the existing nodes were unable to appropriately determine the impact of that change towards consensus, then that too would be fragile. Hedera Hedera’s consensus model presumes that nodes have knowledge of the influence of other nodes and this influence can and will change over time. Though the network will launch with a permissioned phase, in time it will be possible for arbitrary nodes to participate — joining and leaving in ad hoc fashion. Additionally, a node’s influence will be proportional to their stake, and this will go up and down as they spend and receive hbars, or lose and gain proxy stake from other accounts. Hedera would be fragile if, as node membership or staking changed, then the calculation of a node’s influence was inconsistent, such as if Alice and Bob were to calculate the influence of Carol differently. But Hedera, like any proof-of-stake ledger that provides a total order for transactions, allows nodes to consistently adjust their calculations of influence and so account for node membership changes and other dynamics - and so guarantees that it will be resilient to such dynamics.   The hashgraph virtual voting algorithm has nodes examine their local hashgraph and logically cast votes on behalf of other nodes. For Hedera, these votes are weighted based on the stake of the nodes. All nodes must therefore be able to calculate the influence of all other nodes towards consensus. Calculation of a node’s relative influence is determined by: 1. The number of hbars the node controls and stakes towards consensus 2. The number of hbars that other participants proxy stake to that node towards consensus 3. The total number of hbars Concretely, we use stake to weight influence in the following ways: 1. For a given event, we say the timestamp will be the stake-weighted median of the times that active members of the community received it. The different times that the members of that set first learned of that event are put in order from earliest to latest, and the time at the 50th percentile of stake will be the consensus timestamp 2. We determine ‘active’ by having nodes vote on whether a given event is ‘famous’ - these votes are weighted by the stake of each node. The nodes that created such famous events are considered to be active 3. When the counted stake for Y (or alternatively N) on the fame of a given event exceeds 2/3 of the total stake, the election is over and the decision is final Note that no calculation uses the total number of nodes - that value is not relevant to consensus in Hedera’s implementation of hashgraph. The hashgraph algorithm itself allows other staking models, such as giving each node exactly one unit of stake. That simple staking model would then require knowing the number of nodes. But Hedera doesn’t do that. Hedera uses the full hashgraph algorithm, where different nodes can have different stake. So it needs to keep track of the total stake, not the total number of nodes. So, at a given moment in time, in order to calculate influence (and so consensus) all nodes need to know 1. The stake of all nodes 2. The total stake The total stake is fixed for Hedera at 50 billion hbars. The stake of a given Hedera node will be the sum of: 1. The hbars in the node’s staked account 2. The hbars in the accounts that have been proxy staked to that node As there is no bonding in Hedera, #1 will change as the node spends hbars from that account, or receives hbars into that account - from both node payments and unrelated transactions. Similarly, #2 will change as hbars move in and out of the proxy staked accounts, or as new proxy accounts are added, or existing proxying accounts decide to switch to another node. Ultimately then, the influence of a node will depend on its stake, and its stake is determined by the amount of hbars in a set of cryptocurrency accounts. The burden on Hedera nodes for calculating consensus is therefore, at any moment in time, to know how many hbars are in all staked accounts (unstaked accounts are immaterial). This is, of course, the exact same burden for a cryptocurrency. The fundamental value proposition of any cryptocurrency (including hbars) is to prevent someone spending coins they don’t own, such as spending 10 hbars when they only have 5 in their account. To make this guarantee, Hedera ensures that all nodes will agree on how many hbars are in every account at any moment in time. Any DLT that cannot make this guarantee is not a viable cryptocurrency. It is the fact that hashgraph delivers a total order for transactions (i.e. all nodes agree on the sequence of all transactions) that allows nodes to agree on the exact stake of all nodes at a given moment in time - and so be resilient to those staked amounts changing. Consequently, even transactions that change a node’s stake do not prevent the community from agreeing on stake, and so consensus. As an example, if node Alice has 10 hbars in her account but spends 2 of them on a purchase, the network will grant to her 10 hbars worth of influence up to the point when the purchase transaction is recorded, and 8 hbars worth afterwards. As all nodes will agree on the order of her 2 hbar transaction relative to all other transactions, they will agree on her new amount of stake, and when it takes effect, and so her influence towards the consensus calculation of those later transactions. In practice, as an optimization, Hedera nodes will take a snapshot of hbar balances (and so node stake) every 24 hours and use those values for the following 24 hours. But it would be equally resilient for nodes to constantly adjust the stake calculation to reflect real-time account balance flux.  Conclusion Hedera’s use of stake-weighted hashgraph is similar to other proof-of-stake ledgers, except without the loss of liquidity through bonding, or risk of loss of stake typical in most other systems. In Hedera’s deployment of hashgraph, all nodes must be able to calculate the influence of all other nodes. To do so they require only the stake any particular node has (both owned and proxied to it) and the total amount of issued hbars. The first is available from the associated cryptocurrency balances and the second a well-known and fixed value. Neither term in the calculation is impacted by other nodes joining or leaving the network, and so the stake calculations (and the consensus algorithm itself) are consequently resilient to any such flux. Share This Back to blog What is gRPC, gRPC-Web, and Proxies? Ed Marquez Pragmatic Blockchain Design Patterns – Integrating Blockchain into Business Processes Michiel Mulders Zero Cost EthereumTransaction on Success: Hedera's New Fee Model for Relay Operators Oliver Thorn Hedera Adopts Chainlink Standard for Cross-Chain Interoperability To Accelerate Ecosystem Adoption Hedera Team Hedera Developer Highlights March 2025 Michiel Mulders Hedera Release Cycle Overview Ed Marquez View All Posts Sign up for the newsletter CONNECT WITH US Transparency Open Source Audits & Standards Sustainability Commitment Carbon Offsets Governance Hedera Council Public Policy Treasury Management Meeting Minutes LLC Agreement Node Requirements Community Events Meetups HBAR Telegram Developer Discord Twitter Community Support FAQ Network Status Developer Discord StackOverflow Brand Brand Guidelines Built on Hedera Logo Hedera Store About Team Partners Journey Roadmap Careers Contact General Inquiry Public Relations © 2018-2025 Hedera Hashgraph, LLC. All trademarks and company names are the property of their respective owners. All rights in the Deutsche Telekom mark are protected by Deutsche Telekom AG. All rights reserved. Hedera uses the third party marks with permission. Terms of Use  |  Privacy Policy