Hedera Hashgraph DLT Overview

Hedera Hashgraph is a new type of DLT (Distributed Ledger Technology) that unlike blockchain-based DLTs (ethereum, bitcoin, …) does not rely on blocks containing transactions. Hedera uses a different technology : hashgraph, which according to its creators, offers among other things, higher throughput, fair ordering, instant finality and lower transaction fees.

Hashgraph protocol

The Hedera Hashgraph protocol uses “events” which are basically small blocks of information, containing one or many transactions that have been submitted to the network alongside some overhead containing signatures, timestamp and hashes of previous events.

Nodes forming the network will constantly exchange these events with each other. These events, as mentioned before, contain hashes of previous events, which allow nodes to transfer to each other not only information about new transactions reaching the network, but also information about previous transactions (process known as “gossip about gossip”), effectively generating a “graph” of events that will allow nodes to reach a common consensus on events timestamp and ordering by virtual voting.

The Hedera Hashgraph protocol is quite complicated and honestly beyond the scope of this blog, but you can find a nice explanation in the following video :

Core Concepts

Hedera, at its core, consists of the following entities :

• Accounts: They can be compared to ethereum accounts, because they are in charge of delivering transactions to the network. However, they are technically very different. Hedera accounts have one or many keys associated to them. These keys (or some of them, depending on the account configuration) have to sign the transactions the account is submitting to the network. Accounts can hold any Hedera Token, but they need first to associate to it (only HBARs can be held without any previous association). To make it simple for ethereum users, an Account can be understood as an integrated multi-signature smart contract…
• Tokens: Hedera has taken the ERC20 and ERC721 standards a step further, embedding them into its core. In order to create a token you do not need to deploy a smart contract, just tell Hedera what kind of token you want and pay for the creation fees. Hedera fungible and non-fungible tokens offer the classic functionality (transfer, transferFrom, approve, …) plus some extra one like associating/dissociating and freezing/unfreezing accounts, pausing/unpausing the token…
• Smart Contracts: Since Hedera is EVM-compatible, any ethereum smart contract can be executed in Hedera. However Hedera’s smart contract are not just the byte code, storage and balance associated to it (like in ethereum), they also have administrators, they can stake their tokens automatically etc…
• Files: Hedera lets users store files (no more than 1KB per file) in a decentralized manner. As a matter of facts, smart contract’s byte codes are stored in multiple files. Files have administrator than can update the file’s content.
• Topics: We can also use the Hedera DLT as a queue where messages can be submitted and latter retrieved. Hedera guarantees proper ordering security (we can limit who can send messages) and availability.
• Scheduled transactions: Accounts are supposed to submit transactions to the network, however accounts can have multiple keys associated to them which means that multiple signatures are required for the account’s transactions to be accepted by the network. Normally, these signatures must be added off-chain then, when the transaction is ready, submit everything to a consensus nodes. To make this multi-signature process simpler, Hedera offers the possibility to send transactions that do not have yet all the required signatures attached to it, the network will store that transaction in a queue, waiting for the remaining signatures to arrive before the transaction can finally be submitted.

Fees

Fees in Hedera are paid using its native token “HBAR” although the amount to pay depends on the current HBAR to USD exchange ratio, the idea is for users to pay a fixed fee calculated in USD (the amount of HBAR will always be different though).

There are two categories of fees in Hedera:

• Transaction fees: paid once by the account submitting the transaction (to create an entity or operate with it).
• Storage fees: entities are not deployed on the DLT “forever”, they have an expiration time. Once an entity expires, it will be automatically removed from the DLT unless a renew fee is paid by the account defined as the renew account.

Governance

The Hedera network is, for the time being, fully managed by the Hedera governing council, an organization of up to 39 very well-known companies (currently only 27), each one running a node. Nevertheless, the goal is to completely decentralize the network at some point, letting anyone run a node.

Consensus protocol

The consensus protocol uses Proof-of-Stake, where nodes must have a minimum amount of HBAR to be allowed to validate events but cannot have more than a maximum amount (in order to prevent a node from taking over the network). Voting is proportional to the amount of staked HBAR. A transaction is validated and placed into consensus after it is validated by nodes representing an aggregate stake of over two thirds of the network’s total number of hbars (fixed at 50 billions).

Accounts and Smart Contracts can stake their HBAR to a node (or another account/smart contract) and get rewards when events are added to the hashgraph. Staking in Hedera, as opposed to staking on other DLTs, does not require the staked tokens to be locked, and slashing is not implemented in the protocol either, there is no “punishment” whatsoever for rogue nodes, at least for the time being…

There is a special account in Hedera (0.0.800 on mainnet) that centralizes the reward allocation. It holds all the rewards and distributes it proportionally to the accounts/contracts.

Accounts and contracts can be set to decline rewards.

Accounts

Hedera Accounts must be created (as opposed to ethereum where any public key is technically an account) and fees must be paid when doing it.

In order to create new accounts in Hedera you can use an official wallet provider :

https://docs.hedera.com/guides/mainnet/mainnet-access,

or the Hedera portal if you need a testnet account :

https://portal.hedera.com/.

You can also obtain a Hedera Account by asking anyone to transfer funds to your ethereum public address. The transfer operation will automatically create your Hedera account and creation fees will be deducted from the transfer amount.

Scans

If you need to scan Hedera’s transactions, accounts, smart contracts… you can use hashscan on every network:

mainnet : https://hashscan.io/mainnet/dashboard

testnet :https://hashscan.io/testnet/dashboard

The Hashgraph and consensus protocol is open-source.

API

Hedera exposes an API (HAPI) that allows for anyone to interact with its core entities (tokens, accounts, …). The HAPI communication protocol is gRPC over HTTP and data is serialized using protobuf. However Hedera provides an SDK for multiple programming languages like JavaScript, Java, Go… allowing a seamless integration of its HAPI in already existing applications.

The HAPI is subdivided into services, each one dedicated to a specific core entity (HTS for Token creation and management, HSCS for for Smart Contract creation and management etc…).

The two big advantages of the HAPI is that it gives the possibility to developers to interact with Hedera’s core functionality without implementing a smart contract and it offers a huge throughput (thousands of transactions per second) since transactions do not need to be executed by the EVM.

Network

Hedera currently has three public networks:

• Mainnet: Main Hedera network where HBARs have actual value.
• Previewnet: Pre-mainnet network, where smart contracts and/or entities can be tested before deploying to mainnet.
• Testnet: A network for developer to test their implementation without any risk. The big difference between this network and the “previewnet” is that Hedera resets its content sometimes, removing all the existing entities, which is why it must be used only for “ephemeral” testing.

Hedera’s networks have two different types of nodes

• Consensus nodes: These are the nodes that process incoming transactions and add them to the Hashgraph. Any interaction with a consensus node costs HBARs, even if it is a transaction that only reads data from the DLT.
• Mirror nodes: These nodes do not take part in the consensus process, they are just like databases that store the current status of the DLT so that anyone can query them for free. Consensus nodes provide state changes in the form of signed files to the mirror nodes, meaning that there can be a tiny delay between the moment a new transaction is added to the DLT and the new state is available in the mirror nodes.

Transactions

A Hedera transaction can contain different fields, depending on which HAPI service and method they are being delivered to, but generally speaking they all contain the following fields:

• Node Account: The consensus node ID the transaction is been delivered to.
• Transaction ID: The Id consists of the sending Account ID followed by the transaction start time (not to be confused with the consensus timestamps calculated by the consensus nodes of the network).
• Transaction Fee: Maximum fee the sending Account is willing to pay for the transaction.
• Valid duration: Number of seconds the user wants the transaction to be valid for, starting at the “starting time” indicated in the Transaction ID.
• Signature: A transaction must be signed at least by the sending account but in some cases, transactions must be signed by multiple accounts.

Hedera’s transactions can trigger further transactions (for instance, when a smart contract method creates a new Token…). Parent and child transactions ID will be the same but child transaction will have an extra nonce indicating the order in which they were executed.

When a transaction is submitted and processed by the network, users can ask for the following confirmations:

• Receipt: receipts contain basic information about the transaction, they are free and only available for 3 minutes after the transaction gets validated.
• Record: records contain more information about the transaction than receipts, they are also available for only 3 minutes after the transaction gets validated but are not free.
• State Proof: This is a document signed by the consensus nodes that contains all the information related to the transaction, the big difference between state proofs and receipts/records is that state proofs could be use to cryptographically validate a transaction.

Compatibility with ethereum

Hedera is becoming more and more compatible with ethereum.

To begin with, consensus nodes run an EVM, allowing developers to deploy smart contracts implemented using Solidity or any other EVM compatible language.

Then, more recently, Hedera has added a new type of node to its networks : “relay nodes”. These nodes expose the ethereum JSON-RPC API, so that ehtereum-compatible wallets (metamask, …) can interact with them. Relay nodes act as a bridge between these ethereum wallets and the Hedera network, the way they do it is relatively simple, they receive ethereum transactions and they encapsulate them into Hedera transactions that are sent to the HSCS (Hedera Smart Contract Service).

Each relay node has an account which is the one that pays the transaction delivery fees, however transaction execution fees are paid by the account signing the ethereum transaction. For the time been, relay nodes are opened to anyone but at some point it is expected for these nodes to charge some kind of fee to compensate for the transaction delivery fees that are automatically charged to the relay node’s account.

New to trading? Try crypto trading bots or copy trading on best crypto exchanges