On the need of tokenized business and computational models.

Inevitable to most natural style of designing a blockchain application is to imagine a kind of a token model as a basic working mechanism. For that however we would need both the missing theory and practice as well to work with tokenized models, like inventing tokanized business models and/or tokenized computational architectures. Examples include but not limited to:

- tokenized data flow
- tokenized Turing machine
- tokenized Neumann architecture
- tokenized accounting systems and tripple accounting
- tokenized business management
- tokenized business models
- tokenized business cooperation models
- tokenized machine learning
- tokenized AI
- ...

And last but not least we would need general frameworks to abstractly model and describe tokens and collaboration of tokens. 

How to create a voting algorithm on a public blockchain

Creating a decentralized voting system on the top of the blockchain is actually not as easy as it looks like. There are many problems that can be resulted in a wrong implementation. The problem is that blockchain is pretty much public, even if we speak on a consortium blockchain solutions, data and transaction is public at least to the consortium nodes that might be less privacy as needed. Some of the problems might be the followings:

- The identity of the voters should not be revealed: for such a purpose there might be the possibility to use a pseudonym voting solution, where instead of names, we simply use like an ethereum address. Certainly, here the major challenge is to distribute the pseudonym addresses and making sure that one person votes only once. 

- The actual votes should not be revealed during the voting because they could influence the result of the voting. One way can be to set the voting into two phase: in phase one, voters vote with a hash value of the vote and some random salt. In the next phase, there is only aggregation of the votes where the participants reveal the voted values and salts. Certainly, it is pretty much questionable how the algorithm exactly works, like what happens if the some actors vote but do not reveal the votes in the next round. 

- If both the votes and the identities should be 100% hidden, meaning that not even pseudonym information can be revealed than it is pretty much questionable if it can be solved technically at all. Probably specialized zero knowledge proofs can help with the situation. 

- General question is how the voting rights can be distributed in a decentralized way. Who or what should be able to vote and how they get that right to vote.  

Fabric composer tips and tricks - importing external javascript library

In Hyperledger Fabric Composer at smart contact development importing external javascript libraries are not really supported at the moment. What you can basically do:

1. use the extra functionality on the client and server side and not directly in the smart contract. Pay attention that the smart contract is executed and evaluated on each endorsement peers of the Hyperledger Fabric architecture. This security guarantee is not always possible for most of the logic. Sometimes you can reconstruct your business logic in a way that the functionality provided by the external javascript library is executed on the client side and only the result is presented on the smart-contract side. 

2. if the code of the external javascript functionality is not huge, you can try to integrate the javascript files as extra files in your business network archive file. The framework references automatically the added javascript files. Certainly, you added files can not have external references. 

Fabric composer tips and tricks - return value of a transaction

Unfortunately there isn't possible to return value from a transaction in Hyperledger Fabric Composer. What you can do however:

- Emitting an event, like

  let retValEvent = getFactory().newEvent(namespace, 'RetValEvent');
  retValEvent.RetValue = "value";
    emit(retValEvent);

- writing the return value into the variables of an asset or participants. For fine-tuning the access rules, it might be possible to define a separate asset containing only the return values of the different transactions:

  asset ReturnValueAsser identified by retId {

    o String retId

    o String retValTransaction1

    o String retValTransaction2

    --> RelatedAsset relatedAsset

 }

Top Blockchain applications making waves in commercial real estate

A guest article republished from RealAtom written by Karl Utermohlen.

What Is Blockchain?

Blockchain technology is a way to store and transfer information in an encrypted manner by distributing data instead of copying it in a central location. Blockchain does so through a cloud, peer-to-peer network that eliminates the need for a third party, which ultimately reduces transaction fees. A digital ledger is then created and updated with each financial transaction in blocks.

There are plenty of benefits to making transactions and transferring data using blockchain as the technology is not controlled by one central entity, such as a central bank. This means that breaching these blocks is extremely difficult, maintaining the sanctity and transparency of its transactions and data.Blockchain is the backbone of cryptocurrencies such as Bitcoin, which offer speedy and low-cost ways of sending and receiving money.

Faster Transactions

One of the most exciting ways blockchain is disrupting the CRE world is in the form of smart contracts. The industry currently relies on an inefficient system of old-school verification of property ownership by conducting research to ensure the property belongs to the party who is selling it.

Blockchain can reduce the speed in which the chain of custody regarding CRE properties takes place as a property’s title would be stored on a public ledger. This would remove the need for another central repository, thus reducing transaction, state, city and legal costs. The same principle would apply for leases that would be recorded via blockchain.

More Transparent Deals

Blockchain can also ensure that real estates assets are more liquid and the terms of the agreement are fully understood by both sides as every piece of data regarding a property would be stored publicly. This includes data surrounding former owners, construction done on the property, past maintenance costs and records regarding former inspections.

Having all this information available would give the investor a more comprehensive idea of the property they are investing in. Blockchain essentially ensures that everyone is on the same page and both sides are fully aware of what they’re getting into as every piece of information is out there for anyone to access.

Digital Paper Trail

Another challenge with the CRE industry is the fact that public records can be outdated, unreliable or not available. Following a property’s paper trail can be time-consuming and frustrating as a lot of this information is lost due to poor organizational skills from industry workers and legacy systems that lose data when updated.

With blockchain, every piece of information on a property would be available in the same place rather than in multiple physical and digital domains. Blockchain would also help to eliminate the type of fraud that sometimes exist in the industry as deeds and titles can be counterfeited easily.

Buying Property With Cryptocurrencies

As previously mentioned, Bitcoin is a cryptocurrency that relies on blockchain to complete financial transactions online in a matter of seconds. Some investors and real estate firms have started adding Bitcoin to the industry, including Ivan Pacheco, who bought a two-bedroom condominium in Florida for $275,000 in Bitcoin.

In the residential space, you can buy a condo on the Lower East Side of Manhattan with Bitcoin. Meanwhile, some apartments in New York City are allowing their tenants to pay for rent using Bitcoin. Cryptocurrencies have been historically volatile and they’ve been on the decline since peaking in December 2017, but some investors believe that the future of real estate will be closely tied with Bitcoin and other digital coins.

Nevertheless, blockchain’s role in the CRE industry is becoming more prevalent each day. The technology’s potential to speed up transactions with smart contracts, its ability to add transparency to a deed or title and the fact that it dramatically decreases the chance for fraud suggest that more investors will flocks towards firms that use blockchain for CRE transactions.

Smart browsers: on web browser and crypto-blockchain integration

The next stage of the blockchain-crypto adaptation might be if we imagine strong integration possibilities between web browsers and the blockchain crypto space. One similar example is metamask that provides several useful functionalities that can be used with decentralized applications driven by ethereum. Metamask is however only a plugin for chrome. Web browsers should support blockchain - crypto applications in a native way. Actually, there should not be very much difference between a web browser and a crypto-wallet. Instead a new concept should be introduced, Web3 browser or perhaps smart browser, that integrates crypto-blockchain functionalities with classical web browser elements. As there are already initiatives in this direction, like Mist wallet, however Mist is pretty much a geek tool without having too much support for standard users. Successful smart browser, or Web3 browsers should be initiated by traditional browser providers.  

Identity is a scarce resource in consortium blockchain

To avoid a naive sibyl attack in most of the decentralized consensus protocols there is a scarce resources that needs to be use in order to take part in the consensus mechanism. This resource is computational power at proof of work and it is a kind of a cryptocurrency at proof of stake. Actually, consortium systems do not differ very much from this idea. In consortium systems, the scarce resource is the identity: only nodes with a special distributed identity are able to participate in the consensus. In this sense it works similarly as the public blockchain networks : the scarce guarantees that none with a huge bot network, but without the scarce resource can influence the consensus voting. 

Fabric composer tips and tricks - item with ID already exist but not visible

Sometimes if you work with the Fabric Composer online playground and you create an item from a transaction you get the error message that the given id already exist even if it is not directly visible in the asset list. This is actually a "feature" of the online playground, it happens if the old item with the old id already existed but it was deleted. For some reasons it is sometimes cached somewhere that can not be explicitly deleted. What you can do in such situations that you redeploy the business network archive file:

- Make sure that the latest version of the .bna (business network archive) is downloaded.

- Delete the existing business network in the online playground.

- Rdeploy the business network from the downloaded .bna file.

On the need of zero knowledge order book matching algorithms

There are many ideas for implementing a decentralized exchange protocol on blockchain. As it might be realized naturally with the help of a quorum consensus, it is not so much easy with a Nakamoto one. The problem is that in a Nakamoto consensus, a leader is choosen in each round to create and start propagating the next block. This leader will act as a dictator for the certain block, meaning that it can influence the transactions that will be minded into the block. It might be a DEX realization idea to create sell and buy orders and transactions and realize the matching algorithm with the help of mining, however it can be "gamed" very strongly in a Nakamoto consensus by the given miner. Hence, buying and selling orders can be "gamed" by the rest of the network, like the transactions themself can be delayed or censored. A solution to these problems might be the definition of zero knowledge order matching algorithms, where the creator of the order, and the exact amounts or other order details are hidden by cryptography. Certainly, it is an open question if efficient order book matching algorithms can be defined in such a way.    

Azure Workbench tips and tricks - error log

Azure Workbench is really cool, however if something goes wrong, you do not get too many information from the error details in an easy way. What you have to do, is to use the following  powershell script to download a detailed log and error information:

collectBlockchainWorkbenchTroubleshooting.ps1

The script downloads detailed logs and analytics both for the workbench itself and the underlying blockchain. 

Notes on blockchain technology and market segmentation

Having a lot of competing blockchain platforms it is pretty much difficult to identify which platform to use for a certain use-case. The following directions can be considered:

- B2B market: typically consortium blockchain platforms, like Hyperledger. 

- Inter-banking B2B market: here special platforms need to be considered that can satisfy the requirements of the banking sector, like Corda or Ripple. 

- B2C market: here both consortium and public networks can be used. If the users could have a direct access to the blockchain platform than typically public networks, if the technological details are hidden, than consortium ones. 

- C2C market: on a fully decentralized customer to customer market, only public platforms can be used. 

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.