Viewpoint | Hash map of the $6 billion valuation and Ethereum just positive? I am afraid it is not an opponent.

Translator's Note: The Hedera Hashtu project, represented by the third-generation DLT (Distributed Accounting Technology), received $100 million in financing in 2018, and the overall valuation of the project reached an astonishing 6 billion. USD, so what is the difference between this DLT technology and blockchain projects like BTC and ETH, is it really as good as described in the white paper?

Let us look at the negative voice. The original author is Eric Wall, a privacy technology consultant at the Human Rights Foundation.

The following is the translation content:

I wrote this article very quickly for the Twitter debate, so please forgive me if there are some minor errors in the text. The first part of this article is built around one of my specific arguments, but you can also jump to more interesting content by typing "CTRL+F" and then typing "fun stuff".

• Bitcoin will go back to $10,000, and NYSE Bakkt futures will be officially launched.
• Real-time settlement of contract transactions? Retail investors must manage their own hands
• Introduction to Technology | Solidity Programming Language: Byte Array, Mapping

So, Hedera Hashgraph (hereafter referred to as hash map) project will be released on September 16, this is the third generation of distributed ledger technology, it can achieve 10000 + TPS!

(basically a marketing slogan from the official website of the project)

Great, right?

Yes! Oh, wait, what I forgot.

Because I am holding a bunch of bitcoins (or BCH? Or something else? I am a little lost), I obviously can't sell them for some unbelievable reason. I have no other choice but to associate and spread about The FUD theory of Hashtu. Obviously, I can't just do simple things and then invest in it, which will break all the rules of the universe.

Anatomy of the hash map FUD

In this article, I will try to solve a simple question: How does the hash map achieve 10,000+ TPS?

First, we need to eliminate some of the myths about TPS.

Proof of workload (PoW) and low TPS

Cryptographic investors generally believe that the inefficiency of the Bitcoin blockchain is caused by the Workload Proof (PoW) mechanism. If someone invents a faster consensus algorithm, the Distributed Bookkeeping Technology (DLT) can Suddenly processing transactions at hundreds of thousands or millions of times per second.

Tweet from Demetri Kofinas, he is a Hashtu supporter

I guess this theory comes from the result of people observing the Bitcoin system. Bitcoin is a system in which a miner creates an area of ​​about 1.2 MB (current average) every 10 minutes. It is a bit like a train carriage coming from a mine. Computer.

Understanding block propagation (simplified)

This is a good mental model when you first explore Bitcoin, but it will give you the feeling that miners are the ones that limit the amount of data you receive. This is not only because the way the system is understood is incorrect, but technically it is not that work.

Since some time in 2016, Bitcoin Core has implemented a BIP152 improvement proposal, also known as the "Compact Block", if you have heard of any information about the FIBRE network , its compression technology is similar. . If you understand how BIP152 works, you will understand that the correct way to look at Bitcoin networks should be like this:

Miners don't actually broadcast trading blocks anymore, they only provide you with the minimum amount of information you need (the 80-byte block headers that meet the PoW requirements) to sort a batch of transactions that you have received from the network. This PoW job is very easy to verify, and you can verify all Bitcoin PoWs (592,926) on your laptop in less than a second.

To organize 1.2 MB of transaction data into Bitcoin blocks, it takes about 15,000 bytes to sort it (6 bytes for each transaction shortID), which is 1.25% of the overhead. The small train carriage represented by it. It does not involve advanced signature operations or operations that exhaust your computer resources. And you can receive it in parallel with the entire transaction stream.

Now, if you want to point your hand at the mining process and say it is the reason for slowing down the system, you are actually saying that you can speed up the system by reducing the size of that small train compartment. What you mean is "we found a way to reduce the overhead of 1.25% to 0.75%!". But we won't even notice this change.

So, if the miners are not limiting the number of transactions you can write on the blockchain, who is the limit?

It’s actually you . You are running the code through your own bitcoin node, and the code says:

“I only accept updates from miners who are trying to sort up to 4MB (Segwit theoretical maximum) data, otherwise I will refuse to update.”

So, can't I increase this limit right? What prevented me?

If you don't separate from the network, you can't change it. This restriction is a consensus rule, but of course, separation is still possible, such as Bitcoin cash (32 MB block = 100 + TPS) and Bitcoin SV (128 MB block = 400 + TPS).

However, simply because the upper limit of the application is increased, the computer and its connections to the network will not get faster. This simply means that some nodes will be difficult to keep up, and the decentralized nature of the system will begin to collapse. But BCH and BSV still believe that this is a trade-off worth doing.

You should understand now that blocking the Bitcoin main network to achieve high TPS is not mining, nor proof of workload.

The following is a description of the Hashtu white paper:

As you can see, when they talk about the throughput of hash maps, they don't even talk about how fast their own consensus algorithms are. So let's put this absurd statement aside.

But the hash graph consensus algorithm is super KUA i…

No, no matter whether the hash graph consensus algorithm is so fast (so that it happens automatically). All you said is to reduce the size of the small train compartment. Even if you completely eliminate it, you hardly do anything to improve the performance of your system.

A quick description of speed: DLT has two ways to achieve "faster" .

One is TPS, and then the transaction confirmation time (final delay). Hash diagrams have faster finalism, which is basically correct, but it is also a bit controversial. I will give a few counterexamples to illustrate how to achieve a low latency at the hash level on Bitcoin and other PoW chains.

1. Sidechain: You can have a node federation control the multi-signature wallet where you store coins, where more than two-thirds of the nodes need to sign the transaction in the wallet before the transaction can take effect. This is the Liquidstream sidechain of Blockstream (running in 1 minute block time and finishing the final state in the 2nd block). You can set it up faster if needed. For example, a node running a wallet can run an open source XRP codebase and settle transactions at the same speed (about 4 seconds) as the hash map, with similar security guarantees.
2. Lightning Network (L2): Lightning network transactions are fast, which is a two-tier solution that relies on channel capacity, but can be close to real-time settlement transactions, and its security guarantee is sufficient;
3. Pre-Consensus: Another way to reduce the final delay is to let the mine reach a consensus on which transactions in the mempool to include in the next block, and isolate any miners who do not follow the plan (which means they will lose the block) reward). This is the Avalanche (called “pre-consensus”) implemented by the BCH program. The Avalanche protocol can reach a consensus within 2 seconds, which has a strong probability of terminating;

4, zero confirmation (0-conf): As long as a transaction appears in your mempool, you can accept it, which is almost instantaneous. Oh, but you said it was not safe. What you mean is that although most miners follow the first-seen rule, there are still some mines that will replace transactions, which may eventually cost you money. So… you mean, it doesn't matter how fast the trade is going, but it's important to say how difficult it is to reverse such a trade. Does this require severe penalties for those who try to reverse the trade? Well, I agree with this view 🙂

Comparison of efficiency between hash map and PoW

Before I leave this section, I want to quickly discuss the hash graph consensus algorithm (compared to pow) how effective it is in terms of the amount of data needed to propagate and verify.

If you are not interested in this, you can skip to the next heading.

So the hash map has no concept of a block, and it has a message , which is described by the blue circle in the image above (the nodes in the system constantly send them to each other). These messages contain one or more transactions, just like blocks. The transactions in these messages have their own sender signatures. But the sender is different from the node, the sender is usually someone outside the network, they just want to confirm their transaction and pass it to the selected hash map nodes (Alice, Bob, Carol, etc.), which are responsible for It is included in the hash map. The transaction is ultimately delivered in the form of a message (equivalent to a block of cells).

Hash maps now have their own special way to reach a consensus on the order of transactions, which is not important to the subject of this article, but what you need to know is that they use a virtual voting process that is executed by the node. The so-called " gossiping about gossip ". This means that when a node receives a transaction, it passes the information to its neighbor, but it also passes the identifier of the last message it received and the last message it sent (this is the image above) Two "hash" in the middle). You don't need to understand why they do this, but that's why the system agrees without a vote.

Hash diagrams are now proud to broadcast these goesips very efficiently, because nodes only send identifiers and serial numbers instead of actual hashes, otherwise they will be quite a few bytes (see Hash White Paper, page 91). " Efficient Gossip "), and when using their design, each hash top is only one or two bytes. But the real overhead in this system is not hashing, but signing , each signature has 64 bytes. Remember that the signatures attached to each message by each node are independent of the cryptocurrency transactions they contain, and they are additional signatures that the node uses to achieve a credible consensus on the transaction order. This is part of the hash map voting protocol, so this is overhead!

Now, do you remember the bitcoin's PoW overhead? The cost of 6 bytes + 80 bytes per transaction (a few bytes more than the hash map, but not much):

Therefore, this means that unless each Gossip message in the hash map contains more than 10 transactions, the hash cost of the 64-byte hash map is not worth it. In addition, this overhead also includes signatures that verify that they need to perform signature verification steps on the computer.

For some reference frames, Bitcoin artificially limits the number of signature operations (sigop) that a block can contain: 20000 to avoid placing too much load on the computers that verify the block. This is equivalent to 20,000 signatures per 10 minutes, which is 33 signatures per second. As far as the consensus process is concerned, the hash map does much more than that. This does not include the hash identifier and timestamp of the hash map. These hash identifiers and timestamps also need to be Gossip with each message to make the consensus work.

Let us tell you that Bitcoin's consensus process is already very lightweight. Except that each transaction requires 6 bytes to sort the transaction into one block, Bitcoin only sends about 80 bytes every 10 minutes. Data (to achieve consensus) (compared to hash maps, this is a very small amount of data, hash maps often gossip, each time the node gossip is attached with 64 bytes of signature data).

So maybe the Hash map is really a revolution in the efficiency of the voting protocol (I really don't know), but I know it has no advantage over PoW, because PoW doesn't need to deal with voting at all.

Start exploring fun stuff now!

Let's re-read the expression about hash map throughput:

"If a network node has enough bandwidth to download and upload a large number of transactions per second, then the entire network can handle as many transactions per second."

One thing that will surprise everyone is that Hashto is cloning Ethereum's EVM (the engine of Ethereum trading and smart contract execution), so it will be compatible with Solidity applications.

For those who tracked my Ethereum sync tweets , you will know that I am currently running EVM through my machine. Interestingly, the bottleneck is not in bandwidth. In fact, none of the following are the bottlenecks of my Ethereum node:

1. Download all blocks and transactions (in the correct order);
2. Verify the workload proof;
3. Memory (RAM);
4. CPU;

Since only 100kb/s is used, my machine has buffered enough transactions and they are waiting in the processing queue. And it is the speed of the SSD solid state drive that slows down the transaction speed. My MacBook Pro 2019 laptop is equipped with the fastest solid state drive (it's really competitive). And here is a snippet from my Ethereum log file:

These "tx/s" (tps) counts come from my SSD trying to squeeze the trade as fast as possible through the EVM. However, due to the inherent inefficiency of EVM and my SSD, our test speed did not exceed 300 TPS. I will tell you one thing, that is, using a hash map, the transaction processing speed will not be faster than this.

The reason is that it does not solve any bottlenecks. The only thing the hash map does is to sort the transactions that the EVM wants to receive, but the problem with EVM is that it can't receive an ordered 10,000 TPS, but it can't process transactions fast enough, even through a fast SSD. You will only make the queue time longer.

So let's revisit the picture below :

How can a hash map be able to complete 10000 + TPS (Ethernet is currently only 12 TPS) when both Hash and Ethereum use EVM ?

Ok, for this answer, I didn't actually mention interesting things. This comparison is not true because the hash map data actually has nothing to do with EVM, please see here:

"Cryptographic currency trading".

So, are these cryptocurrency transactions, such as Ethereum transactions, performed by EVM?

No, let's take a look at the architecture:

In a hash map, cryptocurrency transactions are done by an independent service, not by smart contracts. So when they talk about 10,000+ TPS and compare it to Ethereum's 12 TPS, they are not talking about trading through EVM, and can follow any smart contract logic (the entire purpose of Ethereum), but instead Talk about stupid accounts on account token transfers.

Now, I guess you are getting angry, maybe I am making you angry. Am I saying that the hash map has no effect on improving scalability? Leemon Baird and Mance Harmon are just lying openly? Somehow, this is a $6 billion project, but no one is talking about its flaws?

Of course not, this is not an IOTA. But are you ready to understand how hash maps achieve high TPS?

Introduction… Consensus service!

If you can read it from scratch, then I want to congratulate you (not the lazy people, they just jumped to the interesting part: C), because that's where all the magic happens.

The so-called consensus service is a service that the Hedera node runs in parallel with everything else they do. But it sounds differently than it sounds, for example, the service exposes an API that allows "normal users" to access events that occur on the hash map so they know if they have received a particular payment or account balance status.

So basically, a consensus service is a set of centralized databases that you can use to query information. Feeling disappointed? Well, you shouldn't be like this, because this consensus service actually provides you with a "state certificate"! With these proofs, you can rest assured that the answers you received are fully recognized by the Hedera node.

Here are the different levels of response ( source ) you can get from the Consensus Service API:

1. Response (Response) : This is just an ACK (confirmation) of the received transaction, and you are 100% trusting the consensus service node that is talking to you;
2. Subsequent query : This is the ACK (confirmation) of the transaction contained in the hash map. You are 100% trusting the consensus service node that is talking to you;
3. Receipt : When a transaction is included in a hash, a receipt is created (3 minutes). You can request this receipt from any consensus service node to get a "second opinion" to be more confident that the transaction is actually included. You are 100% trusting the consensus service node you are talking to;
4. Record (Record) :
5. Record + status certificate:

and many more!

Wait a minute, do you remember that beautiful picture?

Let's zoom in a bit and find that we forgot to read some things before:

“For Hedera, the scope of the transaction shows that no transaction records are required, but a transaction receipt is accepted.”

So… Is this 10,000+ TPS data not required to give proof of status ? You just count the number of times a node can declare a transaction per second, but it is not guaranteed, basically just a trusted API? Oh, this is unbelievable. It’s too bad for me not to put all my money into it now, but the magic is that I can’t sell my bitcoin.

But… well, let's continue.

1. Record: a receipt, but with more information, such as timestamps and the results of smart contract function calls;
2. Record + status proof: Here it starts to get interesting. Status proof! So what is the proof of status? This is equivalent for those who know how Bitcoin's SPV proof works. The Hedera node will sign a Merkle root that is included with the Merkle path, indicating that the current state of the state has a current time account balance, transaction (or any transaction queried). The signature on this Merkle root is also included. Therefore, the Hedera signature on the Merkle root will "prove" that the response you received is correct.

So, smart readers will now ask, well, I got some signatures with responses, but how do I know that these signatures are the signatures of the Hedera nodes?

Well, they also thought about this problem. They will send you the entire "Address Book History", which is also a complete list of all Hedera node public keys, and all changes made to the group public key signed by the previous node in each step. So it's like a small blockchain that tracks trusted keys, not coins.

So now smart readers will ask, "But how do I know that the activation key is correct?" For this question, I have to quote Hedera's blog :

"No hackers can fool Bob with a corrupted state certificate because they won't be able to recreate signature and address book history that matches known and trusted book IDs – this is published by Hedera on well-known channels."

砰-砰!

You see, it's impossible to start a public key because they have been posted on Hedera's website and well-known channels.

Vitalik, why didn't you do this? Why do you feel that when designing a technology that does not require trust, you must write an article to show how difficult it is to accept a credible shortcut?

(Actually, Vitalik did consider doing this, that is, turning Ethereum from PoW system to proof of rights PoS system)

PS Vitalik, why don't you set up a few nodes, then I can query 10,000 times per second about the transactions you assume have been confirmed? In this way, Ethereum will have the same TPS as the third-generation DLT (such as the Hedera Hash map).

Question: Ok, I understand. But suppose I checked the billions of startup keys with different people. I don't care if Bitcoin Maximists say it's not safe, which is enough for me. So, can the hash map achieve 10,000+ TPS?

A: Well, I assume that you have the correct startup key, but this does not ensure that the person controlling the public key cannot create a fully falsified proof of state.

Question: That is not true. Hedera hash map is "aBFT", which is the highest security standard that can be achieved by distributed consensus systems!

A: Just because it is aBFT (Asynchronous Byzantine Fault Tolerance) does not mean that most Hedera nodes cannot produce invalid results (if they wish). You still have to believe that they will not do bad things.

Question: Hedera Hash is a proof of interest (PoS), and if nodes provide false proof of status, they will lose a lot of money!

A: Ok, so we need to put the tape back a bit. What are the "state certificates" that prove part of the hash map state? These are not really proofs, they are more like commitments. This means that the Hedera node has been submitted to a Merkle root (state), but it does not actually prove that the state is valid.

Now, working in a real PoS chain is that if the verifier node signs an invalid state or multiple different states using the same block/serial number, you can destroy its pledge by broadcasting the fake proof they sent you ( Stake).

What about the Hedera hash map?

In the Hedera system, the node does not actually lock any scum that can be destroyed, so if this happens, you have to go to the court to solve the problem.

Scalability through court

In Bitcoin and Ethereum, we have a so-called "Layer 2" expansion solution. With these "upper layers", the underlying inefficiency issues are alleviated. In these "upper", you can complete thousands, tens of thousands, or even millions of transactions per second. If something goes wrong with these layers, or someone tries to deceive you, you can use the underlying as a "court." Then it is used to arbitrate.

This may mean that people trying to steal things will suffer a lot, or the basic layer will simply refuse the thief, but give the money to the right person. These "trials" are performed in a cryptographic manner as long as the underlying layer still functions. If you see some wrong behavior, you can question it. If you have cryptographic proof of misconduct, the "court" judgment will be in your favor, and this is the second time.

In order to keep this base layer truly magical and powerful in all situations and make it accessible to everyone, we limit the amount of data it needs to process.

And Hedera Hash, this third-generation DLT that can achieve 10,000+ TPS, will also be extended by the court.

But it uses old, traditional courts. You have to hire a lawyer, because if you are screwed up by this system, this is the only thing you can do.

But don't come to me, you go to Leemon (timestamp 23:20).

Interesting!

Ok, what can I say now?

The lawyer is on the scene?

good luck.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!