Notes on the difficulty of smart contract programming languages

The idea that blockchain programming should be done by anyone is pretty dangerous. The problem is that programming for an immutable ledger for applications that probably store currency and has a lot of business values is difficult. It requires a lot practical and theoretical background, programming skills and quality assurance. Non-statically typed languages, like Javascript provide the possibility for everyone to implement fast small programs, however the language will be very soon a problem as one wants to implement either large scale or mission critical programs. For such highly secure, highly mission critical applications very strictly typed languages with formal verification and strong testing methodologies must be used.   

Notes on semi public blockchain networks, Hashgraph and regulation

There is an interesting combination between public and private blockchain networks and that is the sol called semi-public network. In such a field, the network will be operated or governed by several semi-trusted actors, but the network itself from a development or application point of view is open for everybody. However, it is pretty much questionable if that model can work at all. The model is that an application or transaction can only be censored if a majority of the consortium members will vote for that. It is good question what is going to happen on the practical side if an application is not conform with a regulation of a certain region. One model is that an application can only be filtered if most of the regions vote the application out. Exactly the opposite can happen however from the practical side as well, there might be the situation where an application has to be conform not just with one regulation of a certain region but with all regulation of all of the regions.   

Fabric composer tips and tricks - getting type of an asset

If you use inheritance of assets in fabric composer and want to implement a transaction that execution is dependent on the actual asset type, you can use the following convention. Supposing that you have inheriting assets, like:

asset Ancestor identified by assetId {

  o String assetId

}

asset Descendant extends Ancestor{

}

you can query the exact type and the namespace of the asset with the following code:

toState.$type

toState.$namespace

Designing a transaction oriented programming language

Blockchain programming languages have to be transaction oriented by design. Ideas might be taken from transaction oriented programming languages or early artificial intelligence approaches to implement procedural knowledge, like scripts or frames. Blockchain programming language has to have to following two main feature:

1. Even if the core can be realized by an imperative approach, each transaction must be supported by a strong declarative description providing elements for possible: 

- defining the input and output parameters of the transaction

- defining before and after safety checks for both the input and the output parameters

- defining the states that the transaction will change

- defining after and before safety checks for implied states.

- defining the list of cooperating transactions 

- defining advanced security model in a declarative way. 

2. The transaction must have a good and easy human readable approach. As blockchain implementations describe collaboration models between several actors, the best way would be to use and advanced hierarchical approach of artificial intelligence for representing procedural knowledge, like scripts. Such a formalism might have the following properties:

- the spot

- the scene

- the roles - actors

- properties and objects 

- scenes 

- activities - set of actions

Notes on blockchain programming languages

Blockchain and smart contract programming languages have actually a pretty bad approach as most of them start from an object oriented approach. In an object oriented approach, the fundamental modelling approach is the object that has some properties and some functions that mostly meant for changing the internal state of the of a given object. However in a blockchain system, the central modelling unit must be the transaction that will be executed and validated throughout the distributed ledger. Transactions do some kind of a change in the state which might be represented by objects or any other kind of formalism, nevertheless the focus is on the transactions, so the central point of the modelling must be the transaction as well. Probably that is the reason that object oriented initiatives, like solidity, are not natural in blockchain context and sometimes difficult to interpret what they should do. Languages, like the modelling and transaction language of Hyperledger fabric composer are more natural to follow.  

How fair is the transaction ordering in Hashgraph

Hashgraph algorithm and Hedera Hashgraph is said to have a fair ordering mechanism that means that the order of the transactions is created with the help of a general consensus, so practically no node can influence the order of the transactions. It is an improved version of a blockchain mining protocol where a miner can very strongly influence the order of the transactions. 

The situation is actually not so cool. The point is that the algorithm guarantees a fair ordering of the events and not directly the transactions. As soon as a transaction is put into an event the fair ordering can be guaranteed however previously the ordering can be gamed. A node that receives transactions from the outside world can choose to include, not include or delay a transaction. It can also game with the ordering of the different transactions by delaying one with a couple of event round comparing with another one. So actually a node that receives the transaction is pretty much a dictator of that transaction, similarly as a miner is a dictator of the transactions put into a block. For such a "game" in the ordering of the transactions the original source code not necessarily should be modified. It is possible to hack the transactions on the operation system or on the network level.

Considering a Byzantine fault tolerant model meaning that at most one third of the nodes can be hacked, fair ordering of transactions can be only guaranteed if the transaction from the customer side is sent to 33% + 1 nodes.   

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.   

Strategical roadmap of payment and state channels

Strategical roadmap of different payment and state channels of the Ethereum and Bitcoin stack can be seen on the previous picture. The major categories are the followings: 

- simple payment channels are integrated with Bitcoin or Ethereum and provide the possibility to exchange off-chain tokens between two nodes. 

- lightning network is routed payment channel implementation on Bitcoin, providing the possibility to send transactions between multiply nodes even if they are not directly corrected. 

- micro Raiden is a non routed state channel for transferring ERC20 tokens off-chain and integrated with Ethereum. In micro Raiden multiply 'client' nodes are connected with one common 'server' node. 

- Raiden is a routed state channel for transferring ERC20 tokens off-chain and is integrated with the Ethereum stack. 

- Plasma is a special protocol based on the same ideas. It integrates Ethereum smart contracts with other blockchains. As an example part of the business logic might run on the Ethereum live chain, part of it only on an Ethereum proof of authority chain. 

General state channel implementations are not common at the moment. Perhaps the reason is for that, that cryptoeconomical incentive mechanism can not necessarily used in this case because we do not know what will be implemented by the smart contract. 

Fabric composer tips and tricks - call external web service

Integrating external data with a blockchain platform is sometimes pretty much tricky. One way of doing it is with an external service called Oraclize. As Oraclize has already an integration possibility with Hyperledger Fabric, it still does not have any integration possibilities with Fabric Composer. However, if you want to integrate a relative simple and external data, you can explicitly call an external service from the fabric composer like in the following example:

const webServiceInfo = await request.get({ uri:'https://webserviceurl', json: true});

const intParam = parseInt(webServiceInfo.ParameterInteger);

In the above example, we simply call a get a web service that delivers a json object that has property with the name ParameterInteger. More complicated scenarios can also be imagined, like post query, but generally the it is not proposed to put complex calculation into a smart contract. Another aspect which is important that the delivered result has to be static, otherwise the endorsement peers get different information, so they can not really produce valid RW sets, so no valid state can be reached.     

A blockchain protocol for scheduled transactions

Although many most of the blockchain protocols do not gives the possibility to schedule a transaction for execution, there is actually a  simple way of doing that. First we have to use a transaction for that there is something similar already in bitcoin, saying that a given transaction can be mined only after a certain number of blocks, like:

Tr: send money from A to B after BlockNumber N signed by private key A

It practically means that the transaction stays in the pool of transactions until block number N because previously it can not be included in the chain as a valid transactions. As soon as the block N has been reached, the miners are free to mine the transaction. 

The problem is however, that there is no incentive to mine this transaction at around block N. In fact storing such a transaction for a long time might be costly. As a consequence an additional incentive mechanism must be built in that incentives putting the transaction as fast as possible after block N into a block. In fact nodes can be motivated to mine the transaction as soon as possible, as only the first who mined gets the reward. The incentive mechanism, might be even pretty 'sharp' as well rewarding a transaction only if it gets mined between the blocks [N - N+3]. A timed transaction can be cancelled before the block N, by double spending it.