Blockchain and sustainability

Blockchain and sustainability

In terms of blockchain algorithms and platforms, sustainability can be interpreted in many ways. On the one hand, anyone who has ever heard about the energy demand of the Bitcoin network can rightly think that the system is pretty far from being considered as sustainable or environmentally friendly. This extreme energy requirement is not necessarily similar however with other blockchain platforms. On the other hand, a number of initiatives have been taken over the past few years to address sustainability or environmental issues with decentralized applications. In this article, we analyze the topic of blockchain and sustainability from these two relatively different point of views.

Consensus and energy consumption

One of the most important components of decentralized platforms is the consensus mechanism. The consensus mechanism is responsible for ensuring that the system is always in a consistent state, meaning that all nodes contain the same information. With other words when someone creates a new transaction, the consensus mechanism ensures that the entire system reaches a single state: either each node finds the transaction valid, or each node finds it invalid.

In public blockchain algorithms, the implementation of the consensus algorithm may be particularly difficult. With such systems, there is always the possibility of a so-called sybil attack, where an external attacker creates a large number of hacked nodes and tries to influence the consensus of the system. Therefore, in such systems, the consensus algorithm is not based on the number of nodes, instead on some other economically scarce or expensive resource. Early day consensus algorithms implemented this resource with computational power (Proof of Work). As a participant in such a consensus compete with each other on a market basis, the total computing power can grow to an extremely large extent to maintain the system and the consensus.

Figure 1, the computational capacity needed to maintain the Bitcoin consensus

(source: https://www.blockchain.com/de/charts/hash-rate?timespan=all)

Of course, the computational capacity that might be extremely high in some places has significant energy consumption, which does not affect the sustainability or the environment positively. It is difficult to explicitly measure this energy consumption, but it can be estimated in  two ways. The so-called bottom-up estimation calculates the energy consumption, cooling, and production energy requirements of computing hardware in detail. The other, so called top down approach, takes into account that the participants in the consensus receive profit or reward for their activity. Given that there are many players on the market and that market is pretty competitive, participants can only realize an estimated normal profit and the rest of the revenue can be considered as direct or indirect energy cost. In both cases however, the total amount of  estimated energy is significant.

Figure 2. Energy consumption of the Bitcoin network compared to countries.(source: https://bitcoinist.com/huge-wind-farm-to-power-bitcoin-mining-will-be-built-in-north-africa/)

Fortunately, the Bitcoin consensus mechanism was merely the first working mechanism and it is almost certainly not the last. Many research and development focuses on developing faster and more efficient consensus mechanisms that require less energy. In one solution, the critical resource involved in the consensus is not the computational capacity but directly the cryptographic currency. In such so-called proof of stake systems, nodes intercept a certain amount of cryptocurrencies, which is lost if it turns out that they tried to hack the system. Other approaches, called layer 2 scaling solutions, execute most of the transactions not directly on the blockchain but on a separate off-chain transaction channel. Considering that usually every hundreds transaction is executed or synchronized with a blockchain, the overall efficiency is enormously increased.

The area of ​​consensus mechanisms is very actively researched area. Even if the currently most widespread solution are energy demanding, this will most likely not a problem for future blockchain platforms and consensus mechanisms.

Sustainability applications on the blockchain

There are on the other hand a lot of applications and initiatives that try to support or solve  sustainability and environmental issues with the help of a blockchain. Of course, many of these initiatives are still in the early stage, so it is too early to evaluate which of them is will be real killer sustainability application. Most of these initiatives can be summarized by the following categories:

“Green” energy distribution: One of the applications sustainability and blockchain focues on the  efficient distribution of locally produced “green” energy. Suppose that some residents in a local community install solar cells, and in the case of overproduction of energy they share the extra energy with their neighbors. The blockchain can be used here to accurately and automatically accounting the distributed energy. From a technical point of view, early implementations use Ethereum integrated with local energy IoT devices, creating a so-called smart meter.

Figure 3, “green” energy distribution in a local market

(source: https://microgridknowledge.com/blockchain-siemens-lo3-energy/)

Supply chain trancparency: The next major area of ​​sustainability applications is to improve the transparency of supply chains and value chains. The first applications come from the area of ​​food production and food distribution, where it is particularly important to keep track of the exact lifespan and raw materials of a food product. For example, if it is found that an agricultural area has been sprayed with harmful substances, all the products directly or indirectly affected should be withdrawn. The technology also provides the opportunity to aggregate certain properties in the supply chain and display them on end products. For example, it is possible to say about a food product that it is made from vegetable ingredients or does not contain gluten, considering the entire production chain. In addition to properties directly related to food, other sustainability parameters can be also measured and aggregated along the supply chain, such as greenhouse gas emission or the proportion of recycled materials used.

Incentivies: Blockchain-based incentive systems generally reward some kind of environmentally conscious activity. A classic example is getting a token reward for collecting and recovering recyclable materials. The environmentally conscious activity can be glass recycling, plastic garbage collection or the purchasing services that have an positive overall environmental impact. The motivational token can also be implemented in different ways. It can function as a collectible token, it can work as a local currency to buy different special products, or it can also be a full scale cryptocurrency.

There are a number of other examples and initiatives how blockchain can be used in sustainability or environment protection. Examples include a transparent "green" point system for companies, or a transparent block chain accounting system that tracks charity cash flows. Of course, it is not yet possible to see which application will be a real “killer app” in the area. However, there is a strong chance that many sustainability issues canl be better solved with transparent global blockchain systems and decentralized automated organizations than in the current system, which is usually dominated by short-term financial decisions and other local political interests.

Using blockchain platforms in sustainability

There can be many ways of using blockchain in sustainability, including public and consortium blockchain platforms. Examples might be:

1. using consortium blockchains for supply chain modelling to aggregate environmental properties of different products, like greenhause gas emission parameters. 

2. using public tokens and public chains to encourage the P2P usage of environment friendly technologies, like green energy. 

3. Gamification badges and collectable tokens: customers could gain different kinds of a non-tradable tokens as badges for consuming and buying environment friendly resources. It is similar to standard gamification 

4. Locally tradable tokens: The gained tokens could be tradable but only in a local environment. As an example, tokens gained for consuming local “green” environmental goods could be used for purchasing other similar goods of local companies.  

5. Full scale “green” cryptocurrency: The gained motivation or gamification token could work as a cryptocurrency having the possibility to be traded against other crypto or standard currencies. 

6. “Green” markets: there could be tokens that represent directly some kind of a direct environment improvement. Examples might range from planting a tree or explicitly reducing the CO2 emission of an area in terms of a negative carbon credit. These tokens could be tradable on an open decentralized market, perhaps with standard cryptocurrencies. 

7. “Green” transaction fee: The previously mentioned possibilities could be combined with the help of a special transaction fee on either standard payment transactions or cryptocurrencies. This “green” transaction fee can be automatically and transparently redirected to activities supporting sustainability. 

  

Notes on decentralized business logic platforms

The disruptive technological ideas behind the blockchain applications gives the possibility to design better middleware frameworks as well for business logic. An architecture might have the following proprieties:
- Elements of the business logic are separated into transactions an atomic processing units.
- Transactions are signed by end-users providing authentication and maybe privacy in the whole system.
- Processed transactions are signed by the processing units as well providing a defense mechanism against tampering.
- Processing units can be configured with different combinations, like on the same computer or on different machines.
- Processing units can be configured with different scaling strategies, like scaling for performance, or scaling for security, like having different Byzantine fault tolerant algorithms.
- Service level agreement for a service should be defined and measured as well.
- Processing of a processing unit might be guaranteed by security deposit, that can be somehow automatically payed out if the service level agreement is not matched.
- Special consideration has to be taken for processing units making serialization, like writing something into a database or ledger. 

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.  

Blockchain: the new trust layer of the internet

Cryptocurrencies and blockchain technologies are among the best hyped technologies all around the world. Although the technology first appeared in 2009 first as an initiative of a mysterious person called Satoshi Nakamoto the real strengths of the technology hasn't been recognized for a while. The major reason for the recent hype is that the world is getting aware of the technology and trying to understand which use-cases can be efficiently covered by blockchain apart from cryptocurrencies and Bitcoin.  

To understand the real potential of blockhain, the best was is to compare with an old classical protocol internet protocol, like TCP / IP.. Although it sounds technical pretty technical, the TCP / IP protocol is nothing more than a technical cooperation way between different computers for reliable  data transfer. The protocol appeared around fifty years ago, got a little bit more widespread thirty years ago. At first sight it seemed to be a pure technical game for scientific people or tech geeks to exchange information. However nowadays we can already conclude that the TCP/IP protocol has basically changed the world. It is the basic backbone of the internet itself, practically everything that is regard currently as internet or web is based on this technology. It is important to note from a business or marketing perspective that there are many applications of the technology wasn't foreseen thirty years ago. Examples are Facebook or Twitter that are based on this protocol but no-one could predict previously that the become million dollar industries.

From a practical point of view blockchain or distributed ledger technologies are similar to the TCP/IP. They are simply IT, collaboration protocols but instead of reliable data transfer, they realize a trust protocol between different actors. Let we just imagine the situation that there are several actors throughout the world who want to collaborate with each others and exchange value. As an examples, they want to exchange or transfer a currency. These actors are geographically decentralized, they do not know each other, they do not trust each other and actually they do not want to trust each other. Hence they are not necessarily humans, but for examples different IoT devices communication and transferring value with each other. blockchain protocols simply guarantee from an algorithmic level that these actors can exchange value with each other even with such a circumstances.

Traditionally, trust based services were provided by centralized institutes like banks or insurance companies. They provided a working model for many years, however they suffered from many problems, like inefficiency, slowness or sometimes from censorship. Blockchain technology simply disrupts this institutional business model and provides a much faster, cheaper and fairer way for exchanging value or to realize trust based services on the internet.  

There are two major, a little bit controversy applications of blockchain nowadays: cryptocurrencies and token based platform funding (called ICO at the moment) that are disrupting traditional money transfer and corporate funding. It is important to note however, that they are just applications on the protocol. One of the major reason of the Hype that the world is experimenting currently which other classical trust based services can be realized in a more efficient way with the technology.

Certainly, we are pretty much at the dawn of distributed ledger technologies: there are still many technological drawbacks, due to the lack of regulation many scams, and of course classical institutional trust based industries managing billions of dollars won't adapt so easily. Which fields and use-cases will reach the real mainstream adaptation is something that we will probably see in ten-twenty years.

Notes on decentralized artificial intelligence

Current trends in artificial intelligence, like Singularity.Net, Neureal or Pandora having a little bit the wrong direction. Overall is the idea, that different artificial intelligence components can be somehow marketed and sold with the help of a marketplace which is realized with the help of a blockchain solution and some tokens. However this idea is not really optimal. Distributed ledger should actively help the integration of the different artificial intelligence component, effectively realizing a hierarchical pattern recognition structure. Tokens should not only represent an economic incentive but they should actively carry information among the different pattern recognition components to effectively function as a data bus of the architecture. Certainly classical architectures like blockchain can not really scalled up to carry such a huge amount of information, however with technologies like Hashgraph functioning solution might be carried out.

Certainly, it is a major question if distributed ledger technology is really required, or possibly there is the chance to put everything to a centralized data bus. 

Two-phase commit on blockchain

Two-phase commit is a classical way to record highly reliable transaction into a classical database system. It makes however sense to implement in a Blockchain context as well as a basic blockchain protocol. In such a protocol on the one hand transactions and somehow the committing phase as well are supported by cryptography like all information processing phase are signed by a private key of the node that initiates, resulting that the whole voting process can be much less hacked. On the other hand transaction manager is usually a centralized role that can be easily imagined by a decentralized P2P network working with a consensus protocol providing Byzantine fault tolerance. If the transaction is committed both by the voters and the blockchain network it can be saved into the transaction database. Certainly it is a question if both voters and validators are required or we might as well mix somehow the two roles. Another interesting question might be how much more security does such a system provide comparing to other solutions.   

Questions on DAI (Decentralized Artificial Intelligence)

Considering the hype around blockchain and the different decentralized technologies and decentralized business models, the question raises slowly if there is a way to create artificial intelligence on a decentralized way. Certainly, it is a question how exactly an artificial intelligence algorithm can be made to decentralized. 

- Should it be somehow similar to the autunomous agents ? 

- Is it possible to capitalize the blockchain or the distributes storage as well ?

- What should be the communication interface around the nodes ?

- Which functionality should be realized by the nodes themself ?

- Is it possible to create a real decentralized algorithm ?

- It it possible to create a model somehow the same way as with decentralized storage or computation ?

- Like with SWARM, or GOLEM ?

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.

Serializing state into the Blockchain in Decentralized Business Process Management

Well serializing state for Decentralized Business Process Management (or simply DBPM) does not seem to be very complicated for the first sight If we consider Ethereum as a Blockchain solutions. Let we assume that we have custom workflow for approving a project budget, having the following properties: ProjectName, ProjectType, ProjectBudget.The first intuitive realization is a simple smart contract, called WF_ProjectBudget having the three properties as parameters and having a set get function for each: 

contract WF_ProjectBudget
{
 string ProjectName;
 string ProjectType; 
 int ProjectBudget;
 
    function setProjectName(string _ProjectName)
    {
        ProjectName = _ProjectName;
    }
    
    function getProjectName() constant returns (string)
    {   
        return ProjectName;
    }

    function setProjectType(string _ProjectType)
    {
        ProjectType = _ProjectType;
    }

    function getProjectType() constant returns (string)    {
        return ProjectType;
    }
    
    function setProjectBudget(int _ProjectBudget)
    {
        ProjectBudget = _ProjectBudget;
    }

    function getProjectBudget() constant returns (int)    {
        return ProjectBudget;
    }
}

There is a problem however with this intuitive approach. As the parameters can be set one by one, there is no guarantee that they will be set in an atomic action, meaning that either all of the values change or none of them. Supposing that atomic action is required saving the workflow state, the following code might describe the situation better:

contract WF_ProjectBudget
{
 string ProjectName;
 string ProjectType; 
 int ProjectBudget;
 
    function getProjectName() constant returns (string)    {   
        return ProjectName;
    }

    function getProjectType() constant returns (string)    {
        return ProjectType;
    }
    
    function getProjectBudget() constant returns (int)    {
        return ProjectBudget;
    }

    function setWFState(string _ProjectName, string _ProjectType, int _ProjectBudget) {
        ProjectName = _ProjectName;
        ProjectType = _ProjectType;
        ProjectBudget = _ProjectBudget;
    }
}

It is important to note that although the construct seems to be pretty simple, it guarantees that the three values are set in an atomic transaction independently of any kind of possible errors, like network outage, validation node failure or heavy cyber attack.

In real life scenarios we should consider that not always the whole state but only a part of it is saved in a transaction. As a consequence, it might make sense to explicitly define atomic groups: group of variables that should be serialized together. Another drawback is that this model assumes the one contract - one workflow model. A more general model might be to work with structs instead of individual variables, in this way one general solidity contract can contain the storage interface for several different workflows:

contract WF_State
{
    struct ST_ProjectBudget{

     string  STProjectName;
     string ProjectType;
     int ProjectBudget;

    }

    ST_ProjectBudget LatestProjectBudget;

    function WF_State(string _ProjectName, string _ProjectType, int _ProjectBudget)
    {
        LatestProjectBudget = ST_ProjectBudget(_ProjectName, _ProjectType, _ProjectBudget);
    }

    function getProjectName() constant returns (string)    { 
        return LatestProjectBudget.ProjectName;
    }

    function getProjectType() constant returns (string)    {
        return LatestProjectBudget.ProjectType;
    }

    function getProjectBudget() constant returns (int)    {
        return LatestProjectBudget.ProjectBudget;
    }

    function setWFState(string _ProjectName, string _ProjectType, int _ProjectBudget) {
        LatestProjectBudget.ProjectName = _ProjectName;
        LatestProjectBudget.ProjectType = _ProjectType;
        LatestProjectBudget.ProjectBudget = _ProjectBudget;
    }
}







  

Blockchain as a storage

From a technical point of view Blockchain can be regarded as some kind of a special storage system. It is much slower as for instance a replicated database system, however due to the P2P architecture the availability can be actually higher as at a replicated database. Certainly the 'hacking resistance' is much higher at a Blockchain solution as with other solutions, and of course a Blockchain is far less efficient (Figure 1).

Figure 1. Blockchain as a storage.

Ways of decentralization for Decentralised Business Process Management

Considering Decentralized Business Process Management (or simply DBPM), one of the major question is which part of the framework should be decentralized and which should be not. The system has at least three layers (Figure 1), so let we see which one should be decentralized:

- Data Layer: Data is the state of the system tha has an initial state and a final one between all transitions. That must be saved into the Blockchain, it is one of the key characteristic of the  Business Process Management solution. However, it might be considered if all state between all transitions are saved or only certain ones, working as a checkpoint of the system. As an example, it can be imagined that cross-company decentralized processes save states of transitions in the Blockchain only if they deal  with cross-company communication. Local steps that are internal for a company can be realized independently from the Blockchain. 

- Workflow and Rule Engine: Well it is the major question of only storage should be decentralized or computation as well, like workflow or business rules. Having decentralized storage only without computation provides us clearly the advantage that workflow transitions run efficient. However, if the system is hacked in a way, then perhaps a state is written into the Blockchain that is already 'hacked'. It would be certainly a tragedy. On the other hand, keeping the computation decentralized might provide an enorm computing capacity. 

- Low code editors and API-s: Low-code, no-code editors are usually user interface components that should not be considered to keep decentralized. However, it is an open question how it is possible to avoid that the system is hacked and a wrong state transition is simulated. 

Figure 1. Possibilities for decentralization.

As a conclusion, the best option should be to provide a customizable solution, in which both elements of the state and types of the transitions could be individually parametrized if they should be saved into the Blockchain and validated by a decentralized consensus or not.  

Notes on Blockchain privacy and private Blockchains

Blockchain applications like Bitcoin or Ethereum are highly secure by design, despite some of the data that is stored in the Blockchain are actually far from being private. Even in the Bitcoin Blockchain practically every pieces of transaction and account are visible even with a simple browser, like Bitcoin Block explorer. That is certainly not a desired functionality, professional Blockchain 2 Customer or Blockchain 2 Business services would require extended information privacy. Let we just summarize some of the possibilities.

- decentralized public ledger: that is the most basic model, all accounts and all transactions are publicly available, all mining and validating nodes of the network run public as well.  

- private identity: all transactions and accounts are visible in the blockchain however identity behind an account is practically impossible to identify. There are attempts for such a mechanism in Bitcoin protocol with the always newly generated addresses. 

- private transactions: well it is pretty difficult question. On the one hand all transactions have to be validate by all nodes, on the other hand it is a normal customer requirement that certain transactions should be fully analysed only from theirs owner and not from other third party users. If the two requirements technically satisfiable in the same time is questionable.  

  

- private network nodes: processing and mining of information is not available for everyone, but only a certain group has got the privilege to do. 

- private blockchain: the whole blockchain is not available for everyone and does not contain every transactions but only transactions of a certain application and party of member companies are recorded and certainly the information is only for this group visible. 

The major question is certainly if it makes sense to create such a private blockchain applications or is it better to use for such a scenarios classical client server models. 

Cloud Storage versus Dezentralised P2P Storage

Current trends of the decentralized software development makes new applications and platforms to appear every day. One exiting direction is to build decentralized or P2P storage systems on the top of exiting Blockchain technologies, like SWARM on the top of Ethereum. Certainly these technologies are pretty much in the experimental phase, despite it is interesting to evaluate which advantage or disadvantage can have a P2P storage system for example comparing with a classical cloud storage. 

- Zero downtime: well cloud systems have got surely the high availability characteristic. The same property can be found however  at a P2P storage as well. Copies of a document or data is generally stored on a lot of nodes: if an adequate distribution algorithm is implemented to store copies based on availability and geographical location of the nodes, than high availability can be guaranteed.  

  

- Fault tolerance: The same is true for fault tolerance. Adequate distribution of the copies of different pieces of information on different nodes can realize a highly fault tolerance system, similarly as at a Cloud storage. 

- Scale up - Scale down: well from the point of scaling up or down the two systems have got more or less the same characteristic. One can always get some more storage with a couple of clicks, one can set some storage free similarly.

- DDoS resistance: Well Cloud is more or less centralized or at least based on several huge centralized cloud center, as a consequent they are not so immune for a DDoS attack as a fully decentralized P2P network. 

- Censorship-Resistant: Possible censorship is a major characteristic even of a cloud storage system. As the cloud service itself is operated by a large company like Microsoft or Amazon, there is always an easy possibility for censorship. On the contrary on a P2P system for a successful censorship at least 51 or perhaps 100% of the resources are required that is economically pretty expensive.

- Security: Security is a big issues for a P2P storage system. As our data is stored overall of the world, the only way to provide professional service is that the data itself is so highly secured that even the hoster of the node can not make the decryption. As it is theoretically possibly to realize such a strong decryption mechanism, the question is if accessing the data remains performant enough. 

- Price: The second big question is the price of such a system that can be influenced by two factors. On the one hand a P2P storage can be more expensive than a Cloud storage as most of the data are stored in more copies. On the other hand, a P2P storage can be cheaper as well as most of the resources are extreme cheap, meaning that they are stored on resources that otherwise would not be utilized. 

As a conclusion, I would say the major risk is the security - performance characteristic. If these two properties can be realized in a way that is comparable with a Cloud storage or at least acceptable to the market, than there is a chance that in a year or two decentralized P2P storage services appear.  

Robots -> Softbots -> Corpbots.... Notes on automated cach-flow systems

ROBOT - "A robot is a mechanical or virtual artificial agent, usually an electro-mechanical machine that is guided by a computer program or electronic circuitry."

 Wikipedia.

SOFTBOT - "In computer science, a software agent is a computer program that acts for a user or other program"

Wikipedia

Well the question is what is the next step of the evolution. Combining the current trends of Blockchain and artificial intelligence technology there is a possibility to create automatic cach flow systems that practically run 100% without people, having both the value generation and the administrative tasks fully automated. So let we call such an automated cach-flow system, or rather fully automated corporation as Corpbot.

CORPBOT -  A Corpbot is a fully automated virtual corporation in which both the value adding process and the management and administrative tasks as well are being executed by computer algorithms.

Well it still does not exist, however it is expected to appear pretty fast....

22.05.2016 - BREAKING, It exist and the name is DAO..-.Forbes

Blockchain for everyone: is it time to have no code application development platforms on blockchain ?

Well, on the one hand, it seems the blockchain technology is starting to get into a hype phase, implying new starts ups with new ideas for each month and a lot of turbulence in media and press. As the technology is however disruptive, meaning creating new markets and destroying old ones, it is pretty difficult to predict what kind of a business models or ideas can be successfully implemented with decentralized ledgers and which do not have the chance. I guess it requires an extensive experimental phase in the next couple of years, implying a lot of small rather proof of concept and prototype projects.

On the other hand, the whole area looks like as the wild west, so finding a professional blockchain developer for each experimental project will be not so easy. First of all everything from a technological point of view is pretty huge, bitcoin, altcoin, ethereum, hyperledger,... and who knows what comes the next week. Secondly, developers who really have got the experience in one field are probably already hundred percent involved in one or more hot start-ups. Thirdly, there is not something like, official developer training or certification for a blockchain developer. As a consequence, it can be predicted that there is gonna be a relative big demand for blockchain developers in the short future that can not really be satisfied. 

A possible solution can be low-code or no-code development platforms on the top of blockchain. No-code or low code platforms provide generally the possibility for IT power or business users to build application pretty fast without having deep coding knowledge. These platforms are usually not Turing complete, meaning not general enough to build up every possible applications, but they provide a way to build a set of typical ones fast and efficient. So, typical proof of concept or experimental blockchain applications can implemented directly by power or business users.

Certainly, the major question is where the focus should be set. One way is to get a general blockchain development platform, like Ethereum, and build a no-code or low-code framework on top. Such a solution would provide the strong integration possibility with the blockchain technology, however integration with other technologies, like mobile apps, storage or data, might be difficult. The other way might be to get a classical low-code development platform, like K2, and extend for a a specific blockhain field, e.g. integrating the services of the bitcoin API. It would provide all the advantages of the existing low-code platform, but it would be rather an interface integration without the decentralized philosophy.