Hashgraph is a third-generation super-fast distributed ledger that you can utilize to build decentralized applications (dApp). The nodes that are run by the Hedera Governing council including industry leaders, such as : Boeing, DLA Piper, Deutsche Telekom, IBM, Nomura, DLA Piper and more. To get a quick overview about the platform, read the getting started article here.
Unlike second generation blockchain/DLT platforms, Hashgraph does not mandate or restrict the users to build their applications using native crypto or smart contracts. There are many creative ways you can combine these various offerings of the platform to build the next generation applications. Here is the link to a case study on Hashgraph feature set. In addition to this, the recent article published by AdsDax on using decentralized messaging queue using Beanstalkd is an amazing hands-on technical read.
The basic building block for any decentralized platform are Keys, Accounts and Transactions. Keys form the address and/or accounts for most platforms. The implicit security is assumed by the fact that you can sign your transactions with the private key and that in the current realm of computing limitations, it’s not possible to cryptographically derive your keys.
To make things easier, most cryptographic key management systems/processes have implemented various easy ways to recover your keys, most of which involve writing down dictionary based random words known as mnemonics that allow you to re-create your keys. This is helpful in an event where you lose your wallet or keys and want to recover all your crypto money elsewhere. This is a double edge sword for the fact that it is much easier for someone to steal your mnemonics, all they need is one quick look at the words list.
The crypto world is looking at use cases that need much more than just simple keys or rules on a smart contract. There are some really interesting ways to create, manage and sign transactions on the Hedera Hashgraph network.
Keys & Signature on Hedera Hashgraph
Below is a visual schematic of the keys and signature formats. If you are familiar with the Hashgraph protobuf definitions, it’s much easier to read this.
The Key is an essential part of setting up an account on the network, on which the platform enforces the parity of signature based on the key(s) structure. If you already have an account on Hashgraph, you can switch keys to a new format by performing an account update.
Your key can be one of the supported key types (ED25519, RSA-3072 & ECDSA with p384). There is also provision to hold the ID of a smart contract instance in case you want to authorize that programmatic access. The support for RSA and ECDSA keys will be extended in future.
Let’s take a look at some combinations of key types that you can create on your account. Here we will focus the use of ED25519 keys, as the same concept can be extended to other key types also.
- Simple Keys: A key that only has an ED25519 public key Abytes of length 32. This is the bare minimum for keys and signatures. The portal and all existing wallets use this simple key structure; hence the signature part is implemented using the similar format.
The parity signature for this account would look like this.
2. A list of Keys (Key List): A list of keys that are all required to sign the transaction. This list will contain multiple Keys which will contain each one ED25519 key; an example of this is as shown below
3. Threshold Keys: If you need to have a list of M keys that has full access the account, however you need at least N of those keys should sign each and every transaction to operate on that account. The ThresholdCount is the identifier that stores how many min keys are required to sign. An example of threshold account is as shown below:
4. Complex Keys: This is where it gets very interesting. If you go back to the above diagram and look at the structure, it will be evident that you can build your keys with a complex signatory requirement. Let’s review the key structure as shown in this diagram.
A business use case for such an account setup could be something like this: let us assume that a corporate account might need to meet the following rules for a money transfer:
This is a feature that has the capability to solve some of the complex multisig requirements in the crypto space. There are challenges aplenty in the area of how to create the transaction that can be sent to all signatories, collect the signature from all of them, and assemble those to create and send the transaction in the stipulated time window. There is also a feature of ReceiverSignatureRequired capability on an account, this is extremely helpful in the case of mutual consent transfer, such things were possibly earlier only using rules that were built into a Smart Contract.
This also means that you do not have to entirely depend on a smart contract based model for your transactions, the native crypto based transactions can themselves serve as an efficient way to enable certain transactional use cases.
There is also a cost to process the signatures that are complex, there also is a limitation of 4KiB per message payload to hold these keys and/or signatures. You can review these scenarios at the Hedera Fee page. This however still does not look that pricey when you apply it for the right purpose.
You can generate the keys using wallets, SDK’s and the Hedera CLI. The support to build complex keys is a user extended feature based on the SDK’s. If you are a dApp developer, it’s better to build the protocol buffer objects pertaining to your language of choice and plug that logic of keys & signature logic into your client.
Now that we have covered the various ways of generating the keys, it’s important to understand how you can persist or re-create these keys. You can read more on the BIP39, BIP44 and BIP32 implementation using the ED25519 key formats.
1. ED25519 Introduction : https://ed25519.cr.yp.to
2. Hedera Fees Estimator: https://www.hedera.com/fees#estimator
3. Hedera Docs Keys: https://docs.hedera.com/docs/keys-and-signatures
4. Example of Simple key
5. Example of KeyList
6. Example of Threshold Key (inside a complex key)
7.Example of Complex Key