Less Known Hedera Features
Aug 10, 2020
by Cooper Kunz
Developer Evangelist

While you may be familiar with Hedera’s unique consensus algorithm, hashgraph, which (even while throttled) allows us to process 10,000+ cryptocurrency transactions per second - or our Governing Council, which LG and Avery Dennison recently joined, there are a number of notable differences in functionality between our network and the likes of Ethereum, Polkadot, or EOS. Let’s dive into a few of the lesser-known things that you can do with Hedera “out of the box”.

Topics covered in this post include:

  • Account threshold & multi-signature schemas
  • Account receiving signatures required
  • Administrative permissions
    • Account updates
    • Account deletions
    • Hedera Consensus Service Write Access Controls
  • Account record thresholds

Threshold / Multi-Signature Accounts & Transactions -

Whether you’re building new payment methods with HBAR, or decentralizing your infrastructure with the Hedera Consensus Service, you can easily use threshold or multi-signature functionality with the Hedera APIs. This can be a 2 out of 3 key schemas (or any custom threshold that may be relevant to your business needs), or a 5 out of 5 key schemas (multi-sig). Flexible key schemas are supported on all Hedera transactions and accounts, providing additional security and flexibility.

Example use case -

When operating a “treasury” account, you can have multiple entities hold the keys comprising that account in different forms and physical locations. Instead of having an account with a large amount of cryptocurrency being held by 1 private key, it can be held by a larger number, making it more difficult for attackers to gain access. For instance, the Hedera Treasury (account 0.0.2) is managed in this format, which you can see here, if you click “view public key”.

Example usage -

less-known-features-1.png#asset:1087127


View a full example in JavaScript or Java.

Receiver Signature(s) Required-

With Hedera Accounts, you can set recevingSignaturesRequired to true. This means that in order for an account to accept incoming transactions, it needs to be signed by one (or potentially many) of the private keys that are defined by this account.

Example use case -

Banks and other financial institutions typically only deal with known entities. By requiring a receiving signature, they can drastically reduce their compliance burdens, and ensure they’re only accepting transfers from authorized parties. A counterparty would generate a transaction, then share it with the owner of the account to “countersign” - after signed by the receiving party, they would submit this transaction to the network to initiate the transfer.

Example usage -

less-known-features-2.png#asset:1087128


Administrative permissions -

Because Hedera isn’t a traditional blockchain, there is a much larger variety of flexibility that we can have when updating the state of the network, when the appropriate permissions and the associated signatures are configured. This includes being able to update the keys that are attached to an account, change who can write to a Hedera Consensus Service topic, or even delete content from the network.

Account update -

In most traditional blockchains, your private key is directly tied to the unspent transaction output (UTXO) set on the ledger. However, Hedera is an account-based ledger, which means that you have a “current balance” of HBAR within a given account. Due to this, Hedera enables you to update the details of your account, including which public/private key pairing is associated with it. This enables very nice features that enhance security, like key rotation.

Example use case -

Accounts on Hedera can rotate their keys every 24 hours, to ensure that if a malicious attacker had gained access to their keys, they would only have 24 hours maximum to move the funds before the keys that had stolen were rendered useless.

less-known-features-3.png#asset:1087129


Account deletion -

Due to Hedera’s account system, rather than utilizing UTXO sets, you can “delete” accounts from the state of the network. In other ecosystems, one can send a majority of their cryptocurrency to another public key but often results in “dust” or small amounts of cryptocurrency being leftover in their previous location on the ledger. When deleting an account on Hedera, you can ensure that 100% of the funds are moved to a new location.

Example use case -

Due to the fact that all transaction histories are by nature public on the distributed ledger, it is often helpful to have multiple accounts on Hedera. Perhaps one for your mobile wallet, one for easy spending with a browser wallet, and another to keep offline in “cold storage”. In the case that you ever wanted to consolidate your funds into a specific account, it is helpful for bookkeeping and compliance purposes to fully delete an old account, to reduce operational burden.

Example usage -

less-known-features-4.png#asset:1087131


Write Access Controls -

The Hedera Consensus Service is often used by a single application or a consortium that is leveraging the technology together, and instead of leaving the topic “open” where anyone can write to it, you can define submitKeys which are required to sign off on the data written.

Example usage -

less-known-features-5.png#asset:1087132


Example use case -

A consortium can deploy a Hyperledger Fabric network which uses the Hedera Consensus Service as an ordering (i.e. consensus) mechanism. The HCS topic can be restricted to only allow specific accounts to write transactions into it, namely, the members of that private Hyperledger deployment. If the membership of that Hyperledger Fabric deployment changes, whether someone joins, leaves, or updates their keys, the parties using HCS can update the topic to match the current membership set.

Example usage -

less-known-features-6.png#asset:1087133


Account Records -

All of the transaction history for Hedera isn’t stored “on-chain”, or in Hedera’s case, more accurately “on ledger”. This means that if an account wants to learn who has sent cryptocurrency to them, they would need to leverage a Hedera Mirror Node. If an account owner wants to retain historical records of their transactions on the mainnet consensus nodes, they can configure a minimum threshold of HBAR that will generate a dedicated record on the mainnet nodes.

Example use case -

A micropayments based publisher may not necessarily care about transactions that are under $0.1, as there could be millions of them. However, if there is a larger transfer into their account, perhaps the equivalent of $1, that would require additional reporting whether for internal metrics or potential regulatory compliance. By configuring their receiving threshold to 100ℏ they could generate all of the records they know that they will need, and save those on a rolling 24-hour basis - all without having to communicate with, or run, a mirror node.

Example usage -

less-known-features-7.png#asset:1087134


Recap

In this post we learned about:

  • Account threshold & multi-signature schemas
  • Account receiving signatures required
  • Administrative permissions
    • Account updates
    • Account deletions
    • Hedera Consensus Service Write Access Controls
  • Account record thresholds

Hopefully, you now can see how easy it is to do complicated functionality on Hedera, like threshold or administrative controls, write access controls to your Hyperledger Fabric network, or key rotation - especially when compared to other public networks. But these are just a few features that Hedera supports out of the box. To view the full Hedera API functionality, please visit our documentation, or go directly to the protobuf definitions, if you’re interested how the APIs are composed.