Notes on Blockchain an clocktime

From a computer theoretical perspective block generation of a Blockchain system is practically the same as the clocktime of a classical computer architecture. As soon as a new block has been generated a new round starts, the value of the Blockhcain itself is the previously executed actions. The only big difference is that both the block generation and the previously executed set of transctions are based on a consensus mechanism of different P2P nodes. 

Notes on work 4.0 and digital disruption

In every branch in which people work in a process oriented, KPI and performance measured structured way based on job descriptions, there is a enormous chance that one has to compete in 5 years against machines and intelligent algorithms. 

That makes about 98% percent of the current jobs. 

Cloud technology and the network effect

I must admit, cloud technology has become clearly a winner because of the network effect. Surprisingly not just because of the economy of scale, economy of scope and cost factors but due to the network effect between the different technologies. As an example there is an efficient machine learning algorithm in the Azure cloud, the technology is used in analyzing security breaches of the basic infrastructure to improve security working with data sets from all around the world. The improved machine learning assisted security is used to improve the whole infrastructure of every services, even for the infrastructure of the machine learning part. That is a real network effect of technology integration.

Prognoses for the enterprise collaboration software market

I think the market of enterprise collaboration software has achieved its peak, from this point I would expect only decline. On the one hand, several solutions and vendors simply over-engineered the different solutions for company internal social communications, I have seen actually examples, where the overload of different communication channels resulted actually a big amount of "noise", a lack of concentrated focus and corporate inefficiency. On the other hand, the trend will be in the future more and more to set up the value chain of a company with less human-resources and more automation, like with machine intelligence, robots or with Blockchain solutions.   

The future of IT

The future of IT is simple....

Blockchain

Cryptocurrency

Artificial Intelligence

Machine Learning

Machine assisted human intelligence

Social phisics

Data Mining

White Paper

MVP

Company

Any other thing is just illusion...

Creating simple name service on the Ethereum Blockchain

Let we implement a simple name service on the Ethereum Blockchain. The service is manifested by one smart contract, called NameService, providing functions to register a name for an address, getting an address for a registered name and rewriting the address of an already registered name. The accessibility is pretty simple, everyone can create a new DNS entry but an existing item can only from the owner of the address overwritten.

Testing the service can be done for the first run simply in Ethereum Studio sandbox, like registering a name and testing if the name can be read back.

Let we test the case from javascript side as well, extending the app.js side of the project with two simple javascript functions to read out and write the name service and some html code that integrates the code on the user interface.

Testing the result from the Javascript side, we get the same result as from the Ethereum Studio.

Deploying Ethereum Studio with Azure Blockchain as a Service, a step by step Approach

So let we create an environment for the Ethereum Studio directly via the azure.portal.

01. The first step is to find the necessary template under the Azure templates. Just search for Blockchain after clicking "New".

02. The first thing is as usual is to configure the basic elements of the virtual machine itself; in this case only one virtual machine as a development sandbox will be initiated.Parameters as resource group, name of the image, user access and location will be defined.

03. The next step is to select the size of the virtual machine, at the moment only one size is available.

04. The next step is to configure the additional features if the vistual machine itself, like network settings, storage account, monitoring or diagnostics.

05. If everything was working fine, we can just confirm in a brief summary windows, and purchase the machine. The virtual machine is created with the preconfigured Ethereum Studio Sandbox. Unfortunately, the Ethereum Studio license is not part of the Azure subscription, so on will be billed for that separately.

It is important to note that there is at the moment the possibility to get a free Integrated Development Environment via ether.camp: ether.camp.

Deploying a Consortium Blockchain with Azure Blockchain, a Service step by step approach

So let we create an Ethereum consortium Blockchain solutions by Azure. It means practically either clicking together the solution on the Azure portal or initializing the creation by powershell. Let we see how it looks like on the Azure portal. 

01. The first thing to is to search for the either the Ethereum or the Blockchain templates them-self. There are 10 pieces of them, we want to use the first one "Ethereum Consortium Blockchain".

02. We can find a brief summarizing about the Ethereum Consortium Blockchain solution under the following link. The configuration itself is carried out in three major steps, as a first step we have to define basic parameters like resource groups, authentication, location, or subscription. 

03. The next part is the structure of the network, we can configure here parameters like number of consortium members, number of mining nodes for a consortium member, number of transaction nodes, that are practical gateways of the users to produce transactions. For all nodes, there is a possibility choose the choose the size of the virtual machines and the redundancy of the storage.   

04. Last but not least, Ethereum node ID has to be set, it defines the common ID of the network, practically only nodes with the same ID can communicate with each other. On top password of the default Ethereum account and passphrase of the private key generation must be defined. 

05. If everything correctly set, the general terms must be accepted and the consortium blokchcain starts to be being deployed. 

06. If everything was working without errors, the consortium Blockchain has been created. 

07. You find under deployment / Microsoft.Azure.Blockchain ... both the link for the Admin site and for RPC endpoints as well.

How secure is Blockchain?

Well, that is a difficult question to be answered. It is regarded actually more secure as a classical client server model, however I guess there is still no explicit study or comparison on that. It is actually a question as well if the regard security rather from a theoretical or a practical point of view. 

NODE SECURITY: First of all the wallets are regarded pretty secure, as they are protected by cryptographic algorithms, like SHA-256 for bitcoin. However this construct has a practical trade off, if you your private key is not leaked or lost, the system is secure. However at both previously mentioned cases your money is probably lost, which gives many different constructs of storing your keys redundant but secure. As a conclusion, yes the system is from a cryptographic point of view secure but it must be really payed attention at the practical usage to behave secure. Typical examples scandals of the last couple if years, where investors stored Bitocoin in Web Wallets, in which coins and private keys were stored in a central server. Having hacked the central server, the private keys were leaked and the money was stolen. 

NETWORK SECURITY: On the other hand, we should consider the Blockchain and the transaction validation. Hacking the system basically mean elements like hacking a transaction, like making a double spending, hacking the Blockchain itself, like modifying an old transaction in the Blockchain or simply causing performance issues in the chain itself. As examples a 51% attack can cause double spending for Bitcoin, actually less than 51% can be enough if the attack is combined with a sybil attack, meaning partly of the communication of  the nodes are disabled. Considering the size of the current Bitcoin network and the Proof of Work consensus mechanism a successfully 51 attack would cost as much energy as small nuclear plant. There might be other attacks as well that are rather Denial as a Service trying to destabilize the network or hard-fork the ledger. 

CONSENSUS SECURITY: The situation is getting more and more complicated if we consider different consensus mechanism like, Proof of Stake or Proof of existence and beside public different other style of networks, like private or corporate networks. As a rule of thumb, we can say that the size of the network matters. Small networks are more unstable by design. At private or corporate networks, the main question is always how difficult is to hack a certain node. There are some opinions, that only the long-living public networks are secure enough simply because surviving long-enough many hacking attempts in a public domain provides a certain immunity.  

SMART CONTRACT SECURITY: The situation is getting complicated with smart-contract systems, like Ethereum as well. As these solutions are "self-programmed" in a certain way further question is how secure is the smart-contract itself that is running on the Blockchain. As an example The DAO project was hacked not because of problems of the Blockhain itself, but because the smart-constract code was simply not designed secure enough.