Overview

Concept

Platform based on a unique (?) algorithm for achieving consensus among users who cannot trust each other.

Hedera Hashgraph claims to directly resolve the five fundamental obstacles to mainstream market adoption of public ledger technology: Performance, Security, Stability, Governance, and Regulatory Compliance. Their hashgraph data structure and consensus algorithm aim to provide a best-in-class, unmatched combination of performance and security. The Hedera platform and governance council promises to provide transparency, open innovation with platform stability, tools to enable opt-in KYC and AML, and global, cross-industry expertise to provide governance and decision making for a globally distributed network and cryptocurrency.

These are the claims — let’s see what Hedera Hashgraph actually delivers.

Actual product

Platform for achieving consensus. They use their own algorithm based on DAG (Directed Acyclic Graph).

DAG (Directed Acyclic Graph) — events instead of blocks; a chain of events instead of a chain of blocks. Transactions are verified by special “witness” nodes that check other nodes’ transaction validity.The algorithm provides:

• High transaction speed (PoS, not PoW)
• Protection from sybil attack (forging identities) and from DDoS (one of their arguments about being protected from DDoS is that they use for their network communications the IP:PORT without using DNS servers — we find this claim of being DDoS-resistant because of not using DNS questionable).
• Honesty when checking data, granting access, forming of transactions, and the order of transaction processing (via aBFT and their own algorithm).

The platform already released an SDK (no SDK documentation yet, but can download the alpha).

Governance

The platform is governed by 39 well-known organizations (all trusted, spread globally)

Decisions are made by voting.

They promise:

• Decentralization (39 organizations all over the world)
• Stability (all organizations are trusted and guarantee the protection of the platform from hard forks and invalid software inside the platform)
• Flexibility (1FA or full anonymity; The Council will allow real-document identification if desired — this identification can be recalled by users who wish to become anonymous)

Token

Needed for:

• PoS and to create own node
• Access to dApps
• Performing any actions within the platform (confidentially, without any centralized gathering of user data)
• Paying commissions

The token will have an ICO

Algorithm

The whitepaper has a lot of math — didn’t get through all of it.

Works similarly to the DAG algorithm. Hashgraph added to it a timestamp, thereby ordering transactions by time. Transactions are verified via the voting of certain trusted “witness” nodes.

Website

Looks good. Works fast. Clear emphasis on key points.

Nothing unusual or unnecessary — everything done effectively.

Hidden behind CloudFlare — so no direct IP shown on the Internet (protects against DDoS).

Uses Craftcms.com engine.

explit-db shows a few vulnerabilities, the latest in 2017.

The engine is good, paid, with an open source — GitHub is active

Social Media

• Facebook has 8k subscribers and active posting, but posts only get 0–2 likes/shares
• Medium periodically has articles and a good amount of likes
• Reddit posts are discussed, but barely
• Twitter has 27k subscribers but the latest post got just 17 likes
• YouTube has over 7k subscribers but only 500–1000 views

GitHub

• Essentially empty
• No source files
• A few repositories with just README.md and one with the source code from the Developers site

Team & Advisors

Team

Leemon Baird is the creator and the mastermind of the project. He has a colossal wealth of knowledge, including a PhD in Computer Science he received back in 1999. The core of the team includes Leemon himself, Mance Harmon, Patrick Harding, and Tom Trowbridge. Three of them are closely connected. Leemon and Mance both worked in Motorola in 2005–2006. Both also served in the U.S. military. Patrick seems to know Mance from their work in Ping Identity (where Patrick spent half of his career so far — 13 years).

We’ll get back to Tom in a bit, but let’s shift focus to Jordan Fried, Vice President of Hedera Hashgraph. Jordan is young but experienced. He’s responsible for the global development of the company. Jordan’s professional career dates back to just 2008, yet by 2013 he already became a co-founder of Buffered VPN — one of the fastest-growing VPN providers. Moving on to Ken Anderson, who is the most noteworthy of the bunch. He’s responsible for putting together the team of developers. Ken is a highly qualified specialist with 20 years of work experience. He went through a number of companies in his career, seemingly doing well in each. All team members (except Tom Trowbridge and Natalie Grunfeld Furman) work for Swirlds Inc — which is the company behind Hedera Hashgraph. We did not find anything shady about the company.

Getting back to Tom Trowbridge: as the President of Hedera Hashgraph, he is an interesting combination of an investment banker and a telecommunications specialist. Tom received his MBA from Columbia University in 2003. His long career list of experience speaks for itself.

The experience/qualifications of Natalie Grunfeld Furman and Edgar Seah seem not to fit with the rest of the team, but only at first glance. Natalie is responsible for all legal aspects of running Hedera Hashgraph. As a successful lawyer, she has experience working in the Silicon Valley, where she consulted high tech startups. She was also a senior attorney at Paul Hastings LLP.

The last but not the least important in this team is Edgar Seah. Edgar is responsible for the Asia-Pacific region, representing the company’s interests there. His business experience dates back to 2003.

The team is obviously real: every member has 500+ LinkedIn contacts and is socially active. Core team members actively support and promote the project on various forums and in a number of conferences. Every one of them (except Natalie) list Hedera Hashgraph in their LinkedIn profiles.

Professional competency:

No competency doubt for any of these team members. All are top specialists with a strong reputation.

Leemon is a serious researcher focused on math and the creation of new algorithms, which research eventually led to the formation of Hedera Hashgraph. Leemon came up with the idea and developed the algorithm. Ken got invited into the project in order to bring it to life. The experience of the rest of the team will help to bring the project to market successfully.

Advisors

The advisory group are monsters of their field — Slava Rubin alone is a powerful endorsement (he is the founder of Indiegogo, billion dollar fundraising company known globally). So there’s no point to go over each advisor in detail. Can review the full list of advisors on the project’s website.

Enough to say that the group includes scientists, business people, developers, investors, and co-founders of successful projects. Rather strong group — all real people, actively present at conferences.

Few of the advisors mentions Hedera Hashgraph in their social bios

Whitepaper

Overview

The overview describes the following problems and how they solve them:

• Speed
• Security
• Governance
• Stability

As we described above, their algorithm is based on DAG, using a chain of events instead of a chain of blocks. Transactions are verified by “witness” nodes.

Performance

“If it is desired to keep the latency under the 7 seconds required by credit cards, while still achieving 200,000 transactions per second, it is possible to use 32 computers in eight regions, or use 64 computers in two regions, or use 128 computers in one region.”

So to keep latency low at large distances, you need to reduce the number of computers used. Which means limiting the number of nodes (32 for 8 regions) to keep high network throughput and low latency.

That being said, the nodes will not actually be limited to 32 in 8 regions — because of sharding.

Sharding

Nodes will be pooled into shards — if the operation can be executed within the shard, it will be kept there. But if, let’s say Alice wants to send money to Bob and they are in different shards — then the shards will exchange transactions.

Security

Node communication utilizes TLS 1.2, with everything encrypted via AES-256 RSA 3072, etc. They use the aBFT (asynchronous Byzantine Fault Tolerant) asynchronous Byzantine algorithm: with 66% nodes being honest, the network can work normally. Hashgraph follows the ACID principle (Atomicity, Consistency, Isolation, Durability).

Honesty

As far as Honesty of access — there is virtually no chance of blocking access to the network for a specific node, because of the randomness of the algorithm.

If this randomness is compromised, then (in theory) so can be the entire system.

Infecting 34% of nodes or making 34% of nodes malicious, the system stops being trusted (for blockchain, this would have to be 51%)

Honest timestamps — the entire algorithm relies on timestamps to work. The algorithm proves the honesty of timestamps by voting. If the time is different among nodes about a specific event, the timestamp can average out (suddenly!). So if the time averages out, can’t it average out not in our favor? For example, if Alice and Bob are both trying to buy a house on the lake and Alice’s time is averaged out to be after Bob’s time — Bob gets the house and Alice does not (even if Alice submitted her transaction earlier).

Since the time is taken from a computer’s system clock (what?), incorrectly set time on some nodes can mess up the order of transactions.

Governance (The Council)

The Council votes about the platform and on who should be allowed to create a node (and who shouldn’t be), plus collects fees for governance. So we get this decentralized centralized decentralization (voting and global distribution — decentralization; Council — centralization; platform — decentralization).

Stability

The impossibility of a hard fork (into a regular crypto or a different platform) because of the Council and the technical limitations.

Specifically: the transaction signature (hash) gets sent into the network. Then, after getting synchronized, that transaction is verified by the other nodes — after which the transaction counts as valid. And the hash of that signature (or the file’s hash) is stored in a hash tree (the nodes don’t see the entire hash, only part of it — which makes it secure). If a single node with this hash fails, that same hash can be retrieved from other nodes since hashes are stored in multiple copies.

Hard forks are impossible since during the forking, the new chain (i.e. network of chains) cannot in any way be associated with the parent chain. Therefore, after forking, old users will not appear in the new fork along with their balances (even partial). They would have to register again in the new fork. There is no connection to the parent chain.

Event signers are not moved to the new fork and therefore cannot sign any events (transactions) that would connect the fork to the original. The chain breaks — the algorithm starts fresh. The verification of an event (transaction) happens only in the original chain and does not leave it for the forked chain.

In case of a 50/50 fork, two forks will not exist — the original chain will disappear. One of the forks will become the main one and the other a regular fork. Old tokens will become worthless and the nodes will not be able to verify transactions or receive commissions. In short, it will kill the project. Hedera Hashgraph’s founders believe that these limitations should keep people from forking the chain.

Flexibility

A user can perform operations while either verifying own identity or remaining anonymous (can remove all real identifications from the account).

Also, the platform allows for the storage of files and for writing of smart contracts in Solidity.

File storage is redundant (for backup, if a node with a part of a file is offline, there is always another one with the same part). Plus, if the network already has the same file hash, it will be only saved once. Each file also has an ID — so retrieving the file from the network using its ID will get you the latest version of that file! If you retrieve it by hash — you’ll get the specific version requested.

IoT use case: IoT device firmware will be retrieved via File ID, and if the hash of the current firmware and the hash of the latest firmware do not match — the IoT device will not work until updated. Only certain users (who have a signed license) get the right to edit the file’s hash associated with a certain ID — the license is transferred only with the permission of its current owners.

PoS

Uses Stake & Proxy Stake:

• Stake for direct sales
• Proxy for proxied direct sales via other nodes

Commissions

The node’s commission is set by the note itself (!). So the node can set a sky-high commission… but that will quickly destroy any trust for that node.

The service commission is set by Hedera.

The transaction commission is also set by Hedera.

The balance check to ensure that a transaction can be performed is done on the node itself — so the user only pays the node commission if the balance is lower than needed for the transaction. After the node verifies a transaction, that transection passes onto the network.

The commission for file storage is equal to the commission for the number of files plus for every byte of the file plus for the time of storage. It’s not clear what happens to the file after its storage period runs out.

Roadmap

Strange — nothing specific.

Step 1: Give coins to the Council and others.

Step 2: Users can create nodes and expand the network; more coins will be available for the general user base.

Step 3: Users will be able to run identification or anonymization of their accounts, and create separate wallets (software).

Step 4: The independent coin store is established; market growth

The team is a little different between the website and the whitepaper (makes sense since the site is easier to update — but then why put the team in the whitepaper if you’re not going to update it?)

ASYNCHRONOUS BYZANTINE FAULT TOLERANCE

The whitepaper claims that the original blockchain was not Byzantine, but Wikipedia says otherwise:

“Using the blockchain and mining technology, originally used in the first decentralized system of electronic cash, Bitcoin, they solved a more general instance of the problem when the number of nodes in a network is unlimited and can change dynamically.”

I.e., Bitcoin solved the general problem and is partially ASYNCHRONOUS BYZANTINE FAULT TOLERANT, aka Byzantine.

Smart Contract

Not found, since so far everything is being tested within the Council and is used in a private subchain.

ICO has not yet started.

Questions for the Project

1. If for some reason all 39 companies will suddenly get bribed (closed, bankrupted, arrested, etc.) — what will happen with the whole system? (It’ll be a fiasco!)
2. Time is taken from the computer’s system clock (what?). Therefore, an incorrectly set time of some nodes can mess up the order of transactions and the timestamp itself. They say that the order of transactions is honest — but how, if the time averages out after all the verifications and the nodes can have an off-sync clock!? (What if someone infects every node and changes their clocks to a random time?). The timestamp is the most unique — and, at the same time, the weakest — point of Hedera Hashgraph. These problems are quite relevant and aren’t solvable because it’s an architectural screw up by the team — even though it’s not a critical one.
3. How will the record connecting a user’s real identity (passport, for example) to the account disappear form the entire history of the “blockchain” when a user decides to become anonymous? (The whitepaper mentions that self-identification is optional and that anonymity is the default state. If a user does not want to be anonymous, the account can be tied to a personal document to self-identify. But the user can recall this self-identification connection to the account. The mechanism of that recall is not described and we just have to take the team’s word for it (!!).) “Critically for privacy, the user can revoke the binding at any time as well — removing the binding between their identity and the account. Doing so might prevent them from using that account in certain situations but that would be their choice.”
4. A file license is transferred only with the current owners permission. (All the owners? Majority? Via a vote?)
5. Scalability is questionable! Will such a system (everyone randomly shares with everyone) be able to effectively scale and still support low latency between transactions on low Internet connection speeds? (This problem can be solved by limiting the number of nodes in each region, and by using sharding.)
6. 50/50 forking will kill the entire system. What guarantees that such a fork won’t happen? (There are no guarantees. Just the fact that this will kill the system should keep such forks from happening.)
7. 66% of nodes should be honest — what guarantees that so many will be? (Maybe they have a node rating system? Turns out they don’t — nodes work via PoS).
8. How resistant to being compromised is the randomness algorithm for selecting the next node for forming the event (block of transactions)? (Like the usual pseudo-randomizer — if the creators can quickly change the randomizer’s seeds or change out the entire algorithm — it should all be ok.)
9. Who are these 39 organizations? Are they periodically re-elected or always the same? What is the role of the Council, besides regulatory (and regulating what exactly)? Governing Members elect the Governing Board. The Governing Board determines the rules of participating in the Hedera Hashgraph Council, regulates the rules of how the network operates, regulates tokens, and approves changes to the platform’s codebase. The governing members protect the platform from forks, grant access to the codebase, and guarantee the software’s validity. “The Governing Members will also elect or appoint members to subcommittees that provide oversight of Hedera operations. The subcommittees will include but are not limited to the Technical Steering Committee, the Finance Committee, Joint Marketing and PR, and the Legal / Regulatory Oversight committee…. governance model is based on the original model used by National BankAmericard Inc., founded in 1968, which was later renamed VISA.” Ok, but VISA has clear-cut roles, responsibilities, re-election terms for Directors, etc. Here, there are no clear term limits or rules — just says ”The board establishes policy for council membership.”
10. Open Consensus determines the order of consensus for transactions — won’t commissions for file storage be too high? (Yes they will — they focus on small files: scans of passports, driving licenses, etc.)
11. How are node commissions regulated? (Seems like they are not at all regulated — the node can set any commission. The Council can take away the node’s ability to be a node for the system if it behaves maliciously — setting an extremely high commission could fall into that category.)
12. What’s up with their social media accounts? Lots of subscribers but barely any likes or shares.
13. Where is a serious roadmap? (No answer — they may already be running everything in a private network and we’d know nothing about it.)
14. Where is the SDK documentation? (None so far and doesn’t seem to be coming.)

Conclusion

Pretty workable algorithm. Seems interesting dApps can be built on it. The team and advisors are both strong. The whitepaper is padded with a lot of useless information, though does include many formulas at the end. Confusing governance model and questionable scalability. Overall, the system will be more closed than open — too many regulating bodies.

BUT, they did already raise $18 million and are actively looking for talent, attending conferences, bragging about their platform, and patenting their algorithms.

De facto, what they offer: tokens, smart contracts, file storage, SDK for their dApps (and all of it on their own platform — DAG hashgraph algorithm).

The SDK alpha is already out, so the platform is working in test mode — the foundation is there. Creating tokens is easy. File storage can be published in the SKD, but there is as of yet no documentation. Therefore, no file storage. No information about the execution of smart contracts. No support for smart contracts.

Verdict

The foundation is there. As is the money. As long as they develop all the other things they promised, should be ok. 

Our links:

https://t.me/c1s0r
https://twitter.com/c1s0r
https://medium.com/@c1s0r
https://steemit.com/@c1s0r
https://golos.io/@c1s0r
https://pastebin.com/u/c1s0r