You are viewing a single comment's thread from:

RE: Do You Even Hive, Bro?

in #hive5 years ago

I’d like your opinion on this part of DPoS the missing whitepaper:

Like all consensus algorithms, the most harm the block producers can cause is censorship. All blocks must be valid according to the deterministic open source state machine logic.

In my view, your second point takes a very serious negative activity and describes it as a valid part of DPoS:

2.. Any person running such software can choose to validate or ignore transactions from any account(s).

If a blockchain advertised this action as a valid option for its validators, then why would anyone use that blockchain? Do you view censorship resistance as a fundamental value proposition of blockchain technology or not? If you do not, how do you reconcile the contradiction between points 2 and 3? If it’s valid for producers to exclude any transactions they want, what prevents them from excluding transactions which would vote up other producers to take their place?

I think your point number two is dangerous and correctly described as “harm” in the DPoS whitepaper. If censorship of any kind on a blockchain is condoned as a valid activity then it becomes a permissioned system which, IMO, blockchain technology was invented to avoid.

Sort:  

Isolating point 2 from the rest of the points could certainly lead to something problematic. But point 2 doesn’t live in isolation.

I didn't discuss it in isolation. I talked about it direction with point 3 and why that creates a very serious problem.

To me, blockchain exists to solve censorship resistance as part of how it solves the Byzantine General's Problem where you can't (normally) trust the messages or trust that the messages haven't been censored. That's what PoW, PoS, DPoS, etc are all about. They give you a mathematical, game theory explanation of how, under specific circumstances, you can guarantee, 100%, the outcome.

Point 2 destroys this concept, IMO. It's toxic to the very reason blockchain exists and is correctly described by the inventor of DPoS as "harm."

  1. Any person can run any software they want on their computer.
  2. Any person running such software can choose to validate or ignore transactions from any account(s).
  3. Any user of the software can approve or unapprove any validator at any time by using their own stake.
  4. When a majority (soft forks) or a super-majority (hard forks) of validators is running the same software, then that software is what is “accepted” as the current chain by validators and stakeholders.
  5. At any time, any other group of validators can run a different version of the software and those validators can then “fork” the chain and run their own version of it, separate from the original chain.
  6. Each user participating in 1-5 is using their own property in the way they see fit. None of the steps in 1-5 contradict or counteract DPoS.

None of this is untrue. Some things may not be desirable but that does not invalidate the facts above.

To your point - yes, it could be bad for a blockchain if a group of validators ignored transactions. But I don’t think the “bad” can be universally applied. And ignoring/rejecting transactions is certainly not an action that is unique to DPoS. This can occur on any chain.

They give you a mathematical, game theory explanation of how, under specific circumstances, you can guarantee, 100%, the outcome.

There is no 100% guarantee of any outcome, which is why networks can be “attacked” and have mitigation protocols or system designs that help avoid such attacks. With DPoS, that mitigation exists through the election of trusted witnesses by stakeholders. This is why I stated that you can’t just cherry-pick one or two points from above and state that the system or its security would be invalidated.

If you need examples of how attacks and mitigation can play out - or how accounts can be protected - just observe what has happened with Steem and Hive.

There was a threat of centralization, the threat was temporarily neutralized (soft fork 22.2), an “attack” occurred (exchange collusion), and then a fork (HF23 - Hive) was deployed to get rid of the attack and to protect the tokens of those not involved in or supporting the attack.

What better example do you need? This confirms that all of the enumerated points in my post are indeed correct.

The question of “harm” when it comes to block production would appear to be based on harming the system. If the “censorship” involved is in fact an attempt to mitigate an attack meant to centralize block production, which is actually more harmful to the chain? The few “censored” transactions or the centralization of the entire transaction validation process?

If the “censorship” involved is in fact an attempt to mitigate an attack meant to centralize block production, which is actually more harmful to the chain? The few “censored” transactions or the centralization of the entire transaction validation process?

I appreciate this perspective as a lesser of two evils. I still think listing it among your criteria for what DPoS allows is inappropriate. There are many, many other forms of harm we could come up with that network participants could use. We didn't list those, so why list this? Is it to justify actions taken as if they are normal, every day occurrences that any witness "can" do?

A witness can shoot themselves in the head, shut down their server before disabling their witness account, run multiple nodes as a sybil attack, etc, etc... there are many things which we can call "facts" and say witnesses "can" do them. Of the items in your list, I only see #2 out of place because it is a form of harm against the network.

I think it would be more accurate list the protection mechanisms in a war-time scenario that DPoS can use to defend itself and what level of harm each of those create.

Either way, thank you for the respectful dialogue.