Distributed ledger and trust model

At collecting requirements for distributed systems, one of the most important requirement of the application is the trust model. Firstly, general trust model must be exactly specified: 

- Untrusted model: in untrusred model participants do not now each other and do not trust each other. Despite the system has to guarantee the participants can cooperate and can exchange value. In untrusted model almost the only logical choice is the public blockchain model, possibly with high security. 

- Semitrusted model: in semitrusted model, the participants might know each others and might trust each others up to a certain level, but they do not fully trust each others. In such a models, a consortium blockchain solution might be a good solution. 

- Fully trusted model: in a fully trusted model, the participants know each other and trust each other. In such a model, a blockchain solution is pretty much an overkill. 

The exact model can be further fine-tuned, like considering a more complicated architecture, including storage, computation, resource intensive computation, user interface, external oracles, communication channels. At each part we can define how much do we trust in the certain medium, or with other words, how much do we want create the certain part to be byzantine fault tolerant.   

Double spending and replay attacks in different distributed ledger systems

Double spending, avoiding double spending and avoiding replay attacks work differently in the different blockchain and distributed ledger systems, especially if we consider the ledger structure. 

- Bitcoin: in Bitcoin, there are only unspent transaction outputs that behave as coins. At proof of work, the winner miner defines an order of the transactions that are applied to the ledger, to the unspent coins. The rule is that every unspent output can be spent only once, so considering the transaction order of the winning miner, the first valid transaction spending an unspent transaction output will really spend it, the next such a transaction will be considered as double spending. Similarly, old transactions can not be replayed, because the output is already spent. 

- Corda: in some sense Corda uses a similar UTXO, unspent transaction based system as Bitcoin. However, the unspent outputs are not "coins", but complex state information of a contract. Similarly to Bitcoin, one output can be spent only once, realizing an efficient way of avoiding both double spending and replay attacks. As opposed to Bitcoin, there is no proof of work or mining, instead a special dedicated node, called the notary service is responsible for the ordering of the transactions. 

- Ethereum: Ethereum is not an UTXO but an account based system. Practically, every account has some kind of a value field with a nonce that is incremented at every transaction. So a transaction not simply referring to an account but to an  account with a certain nonce. At proof of work or proof of stake, the winning miner or validator creates a block that contain an ordering of the transactions. If there are two transactions referring to the same account with the same nonce, than the first will be executed and the second one will be recognized as double spending. 

- Hyperledger Fabric: Fabric has a little bit similar mechanism than Ethereum. Each transaction is simulated by the smart-contracts at the endorsement peers and read write sets are defined. A read operator is not only defined to a variable but to a version of a variable. As a consequence, two transactions referring to the same input variable in a way that one reads and one writes that variable can be executed only in one specific order. If in one round a transaction already wrote into a variable the version of that variable will be increased, so in the same round, the variable can not be the read input of another transaction. In Fabric, the is no proof of work, but a specific service, called the ordering service is responsible for creating a valid order of the transactions. 

Hashgraph censorship

The Hashgraph technology is aimed to be a fair censorship resistant, byzantine fault tolerant technology having a public network as well, where theoretically there is no need to ask a permission form the company Swilrds or from consortium members of Hedera and the network will eventually as public as for instance Ethereum. Recent achievements  suggest however that the situation wont't be so clean and simple. The recent direction is to censor social media appearance that do not match into certain corporate policies, certainly the official names are "quality improvement" and "policy compliance", but actually most dictatorial governments have the same names censoring the local social media for filtering out the content that they do not like. Such a censorship raises some serious ethical questions even if it is carried out by a corporation, but it is surely not acceptable at an open distributed ledger platform. Censorship of the social media will very fast result in the censoring of individual transactions and decentralized applications on the platform. 

So, let we see how Hashgraph can censor your transactions:

- The easiest way is blocking incoming transaction at peer level, simply not including into the Hashgraph by dropping the incoming transaction. For that actually it is not necessary to modify the Hedera software itself, incoming transactions can be filtered out on the operation system or on the network level, like filtering out certain transactions from a certain IP address. Certainly, a customer will eventually recognize if a transaction is dropped and will resend, possibly eventual to another node. As a consequence censoring at peer level works theoretically only if all of the peers drop the transaction. However, from a practical point of view a customer will probably give up including the transaction in the Hashgraph after a certain number of attempts. On the other hand, resending too many, like 20, times is probably not acceptable for most of the applications and use cases, so from a practical point of view blocking transactions at several peers, like in a geographical area can make certain applications not-usable, even if from a theoretical point of the transaction is 100% blocked.

-   A similar censorship attack is to introducing a random delay for incoming transaction at the peer level. It is again something that can be carried out without modifying the official source code. If a transaction is 100% blocked, the customer will recognize it and resend it, possibly for another node. However if the transaction only delayed randomly it is more difficult to recognize. As a couple of minutes or hours random delay in the transaction processing is not acceptable for most of the decentralized applications, this can be an efficient denial of service attack for most of the distributed apps even if it is realized by one or two nodes.    

- As the transaction is included in an event, it is propagated with a gossip protocol throughout the network. You can use similar techniques here as well, like blocking event propagation that contains a certain transaction, or delaying and random blocking events containing a transaction. As the peers are connected with TSL, such an attack is difficult to realize by an external attacker, however it can be easily realized by the operators of the nodes as a censorship attack, again without modifying the code itself, implementing everything on the operation system or network side. Blocking a transaction or event will be efficient if more than one third will actively block, however at random delaying a much smaller number of number of censors could effectively make a DApp unusable. 

- There might be some further possible censorship possibilities at the state level and at the point as a transaction is applied to the state. As the implementation details are not known here, such attack vectors need further investigation.

- Last but not least, Hedera is basically a consortium that controls the code. It is pretty much an open question how the software upgrade mechanism will work what is sure that if the consortium votes against your transactions or DApp, a new software version can be delivered that will efficiently block your transactions and DApps. In practice, this process might be accelerated, as upgrading a new software version can be a slow process. I would probably create a configurable element in the software code itself where operators can individually set the blacklisted applications. It probably provides a further censorship attack vector.   

Nakamoto consensus, quorum and parallel processing

There is a fundamental difference between the two major consensus algorithms: Nakamoto consensus and quorum. Since in Nakamoto consensus always on node "wins" that creates the next block, the whole process is pretty much sequential. It means that the winning block will be a "dictator" for the block to create implying a quasi sequential processing. With that structure a lot of services and algorithms are not too easy to realize, such decentralized random oracle, decentralized external oracle, or decentralized exchange. On the contrary, in a quorum consensus some of the nodes create the next state together, implying a quasi parallel working which provides the real possibility to realize the previously mentioned service and algorithms.

On chain governance with Hashgraph

Creating a native on-chain governance on Hashgraph is similar to creating any kind of an on-chain governance system.  For the first run there must be some special internal governance variables that might influence consensus parameters, node configuration or any other details of the core algorithm. Such variables should have two properties:

1. They can not be changed absolute freely only after a kind of a community voting. 

2. They must be anchored somehow with the nodes or with the core algorithm. 

For modifying on-chain properties there must be a special transaction, instead of a change value of a blockchain field transaction, there should be:

TR: I vote for changing the value of a governance variable - signed by the private key of an account that can actually vote for such a change. Such accounts might be associated with nodes, or with consortium members of the Hedera Hashgraph. 

After the voting transactions are validated and ordered and the voting period might be at the end, each node can apply the result to the state individually. A possible algorithm might be:

- count the votes for a given change, if it is more than 50% apply to the change to the state. 

  

Creating native decentralized oracle with Hashgraph

Hashgraph provides the possibility to realize a fully decentralized Byzantine native oracle service. Let we imagine that we want to call an external data source in a smart contract function, like

function () {
 state = external_oracle("http://external_datasource/%22)
}

At event propagation each {N1, N2, ... Nm} node has to call the http://external_datasource/ independently from each other producing a {V1, V2 ... Vm} possibly different values as results for the calls. These values are propagated, voted and ordered by the events together with the transactions. 

As soon as both the transactions and the values are communicated ordered and voted (so practically at applying to the state), we can use the following function to calculate the result of oracle: 

external_oracle calculation:
step1: filter from {V1, V2, .... Vm} the extreme big or small values, like 33% of all of the values
step2: do an average of the non-filtered values
step3: the result of the function is the average

Since at the time of the calculation each node sees exactly the same set of {V2, V2, ...Vm} values and the external_oracler calculation is deterministic, at each state there will be exactly the same value calculated even if they are calculated independently from each other. 

Since the communication architecture (Hashgraph) is Byzantine fault tolerant, probably the Oracle itself will be probably Byzantine fault tolerant as well (might require some more considerations)

The algorithm can be cryptoeconomically further secured, like giving a bigger transaction fee for nodes producing values that are less far for the end result of the external_oracle calculation function (providing a Schelling point from a game theoretical point of view).

Demo implementation can found in the following github repository.

Hashgraph, transaction censoring and transaction delaying

The Hashgraph algorithm provides from a mathematical point of view fair ordering and access. However it is important to point out that these mathematical proofs working on an event level, that might be a little bit different if we consider things on a transaction level or from a real architecure point of view.  

One attack might be to censor a newly created transaction on a node level, before the transaction even really reaches the network, before it will be put into a node. The censorship can be realized by directly hacking the Hedera software, but it might be realized indirectly as well, like censoring the transactions at the operation system or at the network level.  For such a censorship attack, there might be several resolution:

- users might use only trusted nodes. However in an untrusted or semitrusted architecture this is not a lucky algorithm. 

- users might broadcast a transaction to a node and monitor the system. If the transaction was not propagated, the transaction can be broadcasted again, or to another node, or several other nodes as well. It can work in situations where delaying or timing of the transactions can not cause problems. 

- to be 100% sure that the transaction is propagated as fast as possible, users has to broadcast the transaction to 33% +1 nodes. As the theoretical limit of a Byzantine fault tolerant architecture 33% in such a situation at least one node should work honestly and propagate the transaction right away.

Similar attack can be realized as a newly created transaction is propagated to the network by a node but not with the next possible event, but with a later one, cause indirectly a delay in the transaction. It might cause serious economical damage with certain timing relevant applications, like online gambling and games. To be sure that no delaying can occur with a newly created transaction, the most secure way is again to propagate the transaction to 33%+1 nodes in the system. In such situation, if one honest node propagates the transaction to the network as soon as it gets, than the transaction will be part of the hashgraph right away, independently if other faulty or hacked nodes delegate the transaction only with a delay.   

Fair ordering of transactions in Hashgraph

The Hashgraph virtual voting algorithm provides a fair ordering of the events in the following sense:

- Fair access: means that no individual can stop a transaction from entering the system,

or even delay it very much.

- Fair timestamps: A consensus timestamp that reflects when the majority of the network

members received that event. This consensus timestamp is “fair”, because it is not possible for a

malicious node to corrupt it and make it differ by very much from that time.

- Fair transaction order: A common order of the events that is to be seen exactly the same way after virtual voting by each node and that can not be influenced by individual nodes, or the minority of the nodes. 

There is one problem however, the mathematical side of the algorithms and the proofs guarantee a fair ordering of the events and not the transactions them self. Certainly, if each event contains at most one transaction, than fair ordering of the events equals with the fair ordering of the transactions. If however on event can contain multiply transactions, the situation is not so simple. A node creating multiply transaction for an event can game the order of the transactions in a certain event and even between multiply events. 

To avoid unfair ordering of transactions in an event an improvement might be to define an order and a timestamp of the transactions inside a node. On such an order might be to consider the hashes of the transactions in an event in a increasing order, like:

sha256(Tr_1), sha256(Tr_2), ... sha256(Tr_k) in an increasing order, where {Tr_1, Tr_2, ... Tr_k} is the set of transactions associated to an event. 

It does not really matter how an individual node orders the transactions in an event physically, the events are always regarded as the ordering of the transaction hashes. As a consequence it can not be gamed by the individual nodes unless transactions or signatures for transactions are forged that is usually pretty difficult because of the cryptographical algorithms.

Similarly a global order of the transactions can be defined as well:

- the global order of the events is provided by the Hashgraph algorithms.

- the order of the transactions in an event is provides by the ordering of the hashes. 

Based on the global order and the Hashgraph algorithm for attaching a timestamp for each event, the transactions can be associated by a timestamp as well:

- if an event contains only one transaction, the transaction timestamp equals with the timestamp of event. 

- if an event contains several transactions, the transactions must be timestamped in the event. A possible algorithm might be the following:

Consider an Ei event that contains the {Tr_1,Tr_2, .... Tr_j} transactions that are ordered as {sha256(Tr_1), sha256(Tr_2) ... sha256(Tr_j)}. The time period between Ei and Ei-1 can be evenly distributed among the transactions in a way that if a transaction gets a higher ordering, it gets a newer timestamp. 

Last but not least, a fair access can be only be reached if transaction are communicated to several nodes, like one 33% +1 of the exiting nodes.  

  

How to create real decentralized random oracle with Hashgraph

Real random oracle is one of unsolved Holy Grail of decentralized networks. Hashgraph technology promises perhaps a real possibility to solve it. A pseudo algorithm should be the following:

Let we assume that we have a smart contract function that assigns to a state a new value, like

function() {
 state = new_state
}

we basically do not call this function but create a transaction, like

TR: call function() signed by private_key of some account owner.

This transaction is propagated on the network by the gossip of gossip protocol, probably checked by every node, goes through a virtual voting and ordered with other transactions into a common order. Only after that, it is applied to the state (independently if it is an account based system or an UTXO based).

so let assume a function that calls a real native decentralized random oracle, like the following function:

function() {
 state = rand()
}

and a transaction that calls this function.

As soon as a node "sees" the transaction of function that contains a random oracle call, the node call its internal native random function and creates a ri random value, which is further propagated on the network similarly as the transactions. As a consequence there will be a set of {r1, r2, .... rN} random values propagated on the network, one for each node.

As a next step, we wait until there is a consensus and an order of these random values, so every node will see exactly the same order of these individual random values, like r4, r3, r1, r2 ... rN. And at this point we give a value to the random function as rand() = merkle_root(r4, r3, r1, r2 ... rN). As merkle_root is a deterministic function and and each node sees exactly the same order of individual random numbers, even if rand() is calculated independently at each node it will produce the same result.  

Certainly, the real quality depends on the individual random numbers as well. However as Hashgraph is Byzantine fault tolerant, if more than two third of the nodes provide a relative good random number meaning either cryptographically secure or pseudorandom, the result will have probably the same attribute, meaning cryptographically secure or  pseudorandom.

Experimental implementation can be found in the following github repo.

Types of blockchain governance

One of the critical part of every blockchain solution is governance. It is especially valid for blockchain platforms, like Bitcoin or Ethereum, but it is actually the same for blockchain applications that are realized on the top of a platform. Governance means carrying out changes or further development of the application. There are several models that has different advantages and disadvantages in the practice:

- Off-chain governance means that the governance model is totally independent from the blockchain itself. Changes of the platform is proposed by a community or trusted people and both the implementation and the implementation is carried out by these people as well. Such a model has the advantage that it is technologically less challenging, however it might cause a split in the community resulting a split or hard-fork in the platform itself as well. Such models are realized by Bitcoin and Ethereum where improvements are presented by improvement proposals, like Bitcoin Improvement Proposal (BIP), or Ethereum Improvement Proposal (EIP). The model caused several hard-forks in the above mentioned platforms, resulting for example Bitcoin Cash, or Ethereum Classic. 

- On-chain governance means that several elements of the platform is able to change by a community decision, and both the decision mechanism and the change implementation is supported by the platform itself. Such an example is the difficulty increase or decrease mechanism of the Bitcoin network which is hard-coded in the consensus mechanism and is practically relized by the voting of the miners or the voting of the stakeholders. Other platforms like Monero have much further developed on-chain consensus mechanism, as an example part of the transaction fee is collected into an online wallet as an improvement budget, which can be used for further development or even marketing projects based on the voting of the community. 

From another perspective blockchain governance can be categorized on the fact, who makes the decision. From this point of view there might be the following models: 

- Centralized governance: systems like Ethereum has a pretty centralized governance. From a practical point of view almost all of the changes are governed eventually by Buterin. It has certainly, the advantage of being able to adapt fast, however not necessarily truly open as participation. 

- Open governance: Systems like Bitcoin has a real open governance model. Practically everybody can initiate new changes in the system and the implementation of these changes require a pretty open consensus as well. Practically the core developers, the miners, the exchanges and the shops should all agree in order that a change is implemented successfully. As it is almost a pretty open democratic process, certainly it can be very slow and inefficient in the implementation phase.

- Governance by trusted actors: There can be model between the two previously mentioned examples as well, where several trusted (and sometimes well known) actors can initiate and implement changes in the platform. Such governance model will be implemented directly by Hedera Hashgraph. Similar initiative can be found like in Dash or Monero, where indirectly the stakeholders or the master node responsibles can be regarded as trusted actors.    

Blockchain as a decentralized communication channel

From a practical perspective blockchain can be regarded as a decentralized highly available and reliable communication channel between different actors. It is served at the moment rather to transfer value between the different actors without the primary goal to transfer information, however applications could also be imagined where instead besides of value rather information is exchanged. In this sense applications that should be based on a global decentralized event bus can be also imagined based on blockchain. 

Certainly, performance is still an issue, with the current speed of bitcoin or ethereum such an event bus can not be considered to be too performant. However with technologies as Hashgraph such an applications might be easily imagined. With that the question is which use-cases could be considered to be implemented on a distributed ledger technology that focus not only on value exchange, but somehow on information and value exchange ?