Bitcoin blockheader and on-chain governance information

The bitcoin header contains many information. Most of them are responsible to maintain the consistency of the bitcoin blockhcain. However,  there is one that is a little bit exceptional and that is the difficulty target. Difficulty target is actually related rather to on-chain governance and not strongly to the consistency of the chain. The model can be actually extended in a way that there is more than one piece of on-chain information in the block header apart from difficulty. As a general extension there can be a specific data area only for on-chain governance information for which there are special rules how they can be changed and which information is secured with the help of a merkle tree which root is written into the block header. 

Double spending and replay attacks in different distributed ledger systems

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

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

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

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

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

Notes on Bitcoin Script and data flow programming

It is usually not well-known but bitcoin has a built in language called the bitcoin script which is a non-turing complete language to implement custom logic and payment control flow. As examples, locking and unlocking scripts are implemented by the bitcoin script language. The language itself is executed sequential with the help of a stack, simply consuming the exiting state and combining the unlocking script which is the input with the locking script that can be regarded as a business logic itself behind the computation. 

Ethereum extended the basic idea of bitcoin to a general programmable framework extending the internal script language to a Turing complete virtual machine. However, we can imagine the opposite extension possibility as well. Bitcoin script can be imagined as a set of if-then statements or a set of rules where the execution should not necessarily be defined in a sequential way. The working mechanism of script can be defined parallel as well giving the possibility to several parallel but not necessary Turing complete computational paradigms. Such paradigms might be for example:
- any data-flow programming language or environment

- simple knowledge base of it then rules. 

- and-or networks of direct electrical or digital circuits

- computation models of quantum computing, like quantum circuits

- artificial neural networks or similar learning structures

- biological inspired computation models, like low entropy model specification or NeuroML 

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. 

Types of blockchain governance

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

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

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

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

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

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

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

Bitcoin difficulty and on-chain governance

In the bitcoin protocol there is a part which automatically adjust difficulty in a way that the block time is always fine-tuned to 10 minutes blocktime. If the current rate of blocks is faster than 10 minutes, than the difficulty is increased, if it is slower, the difficulty is decreased. Similar ideas can be found in other blockhain solutions as well, like Ethereum or Monero. This mechanism can be thought as a kind of a on-chain governance method where practically the miners with computation as a scarce resource vote for the change to take place or not. 

Notes on Nakamoto Consensus

From a theoretical perspective in a blockchain protocol a Nakamoto consensus works as a lottery game, the one who wins the lottery gets the possibility to create the next block. If the next block is faulty or there is a cheat, than there is a huge possibility that the new block will be not propagated successfully to the network, so the winning node does not get a reward. The winning lottery combination or "ticket" is actually a nonce value of the block that is both consistent with the previous block hashed and with the difficulty of the system.

The analogy is actually not 100%, in a blockchain style lottery system the winning ticket might be different or individual for each miner because the coinbase transaction is different for each of them. There should be on a long term always one winning ticket, in short term however it is possible that winning tickets are competing to become final one, it is practically called as standard forking. 

Notes on decentralized and automatic monetary politics

Bitcoin and other cryptocurrencies function at the moment relative badly as a currency, simply because the price volatility is too high. It is certainly caused by some different phenomena that might be improved in the future, like the market is too small, most of the material things are denominated in cryptocurrencies but actually in dollar, there is a huge interest of the cryptocurrencies that causing fast price changes. The real open question is if there is possible to create a cryptocurrency that can behave stable in changing price comparing to another another currency. There are some experimental ideas in this direction, like SchellingDollar or Seignorage Shares. In all realization is however the major point is to automatically adjust the monetary basis in a decentralized way. As it is pretty easy to increase the monetary basis with mining new coins as an example via a mining process, it is much more difficult to make the monetary basis smaller.      

Blockchain FAQ - Immutability of a transaction

Question: Can I change transaction that has been already registered in a block ?

Answer: Basically no. In most of the Blockchains, like Ethereum or Btcoin, transactions are immutable, meaning that if they are registered successfully into a block they can not be modified or deleted again. There might be way to create an inverse or a modifying transaction as well, however it means that the database will store both the original and the inverse transaction and the rest is only interpretation. There might be on a long run under the Hyperledger foundation project some solutions that might have a pluggable storage mechanism making eventually possible to explicitly delete a transaction, however such a special algorithms will be probably not regarded as Blockchain, rather as general distributed ledger solutions. 

Blockchain FAQ - Privacy

Question: How private is my transaction or information on the blockchain ?

Answer: Well, it depends actually on the Blockchain, but in most cases all transactions are visible to everyone. Only the value for which address or for which person does a specific transaction related is hidden in several different ways. As an example Bitcoin uses generated one time addresses to hide that a certain amount of transactions are related a wallet. It makes however not impossible to make an implication on that a certain number of transactions were probably initiated by the same account. There are blockchain platforms that makes this implication easier, like Ethereum with not using many different addesses, or more difficult, like Monero, with built in mixers or or two levels of one time addresses. Certainly an address is not really associated with a personal information, however it is something that is usually not impossible to identify. True privacy can be probably reached only by off-chain private channels only between two endpoint working similarly as the payment channels or lightning network.  

Supply demand analysis of the Bitcoin transaction fee

Recent events showed an extreme increase in the bitcoin price especially at the end of summer, implying situation in which the transaction fee itself was sometimes bigger than the amount to be transferred. Certainly with the SegWit and SegWit2x activations, the situation will be better, however the basic problem will not be solved. 

Transaction fees are basically priced on the market based on supply and demand (Figure 1). Demand curve seem to be relative simple, if the transaction fee is high, people tend to send as little amount of transactions as possible. If the price is low however, than a big number of microtransactions can be carried out without a huge cost implication. Supply curve however is a little bit special. On on hand, it might make sense to carry out transactions even if the transaction fee is zero or negative, because the miners reward is not only based on the transaction fees, but on a block reward as well. On the other hand, because of the block limit, the possible number of transactions is limited to around 7, meaning that the supply curve will change to vertical at this point, meaning that the supply is perfectly inelastic.     

Figure 1, supply demand curve for the Bitcoin transaction fee.

Figure 1, shows that cause of the fast increase of the transaction fee pretty well. As Bitcoin is slowly reaching the mainstream adaptation,  the demand curve will generally increase, slipping to right and high. As soon as the demand curve reaches the vertical part of the supply curve, even a small amount of change in the demand results a huge increase in the transaction fee.

The situation will be better, but actually will not be solved by the SegWit activation, as the vertical point of the supply curve will only be at a higher value but do not disappear totally. As a consequence, we will face with the same problem probably in a year as the general demand for Bitcoin transaction increases. 

What is the difference between a real estate and a cryptocurrency

This was actually a general question in of of the community blog, however it is interesting generally, so I try to answer it generally.

Both cryptocurrencies and real estates are assets. The only difference is that a cryptocurrency is digital asset meaning the ownership is guaranteed by network protocols and cryptography. On the other hand, a real estate is a physical asset, meaning that even if they are administrated by a Blockchain protocol, the value of the ownership of the asset is guaranteed by the government.   

It is important to note however, that in both cases only the ownership of the asset is guaranteed, the value itself is not guaranteed. In both cases the value of the asset is based on pure market mechanism, namely on supply and demand. It is certainly true that at the moment the price volatility of a real estate is much smaller than at a cryptocurrency, however this might change on a long run because of the network effect, as cryptocurrencies will be reaching mainstream adaptation.

Does Cryptocurrency mean the end of Fiat money ?

Perhaps the question itself is a little bit provocative, however we might as well consider the appearance of the cryptocurrencies simply from an evolutionary perspective. As barter was replaces by primitive, following coinage, then paper money and fiat currencies, perhaps cryptocurrencies are simple the new stage of the financial technology evolution. Certainly for the first run Bitcoin and other technologies provide rather a simple money transferring technology. However, there not seem to be any reason why the technology could not extend to a broader area, providing general financial services besides money transfer. One example for that is the appearance of cryptograhicaly funding services, like ICO-s that have the chance to replace the whole venture capitaslim. In this sense, we might as well easily imagine that in a twenty years, fiat style currencies will hundred percent replaced by crypto style financial services.    

Notes on purchasing power of a cryptocurrency

As cryptocurrencies are getting into the mainstream, we might as well start to think over if there is a meaningfully definition of purchasing power of a cryptocurrency.

"Purchasing power is the number and quality or value of goods and services that can be purchased with a unit of currency." - Wikipedia.

However, we need some differentiation here. For the first run, the question is what goods and services can you buy directly with the given cryptocurrency. Certainly there is always the possibility to exchange the given crypto into some other crypto or some fiat currency, however it is pretty much the question if we want to consider purchasing power this indirect way as well. On the other hand general price volatility is somehow feel to be somehow pretty high.

Considering these facts, I think we should distinguish two different measures: 

1. Cryptocurrency coverage: A measure that show what, how many goods or services, can you buy for a given cryptocurrency. It is certainly not so easy to formulate it exactly, however we can argue that Bitcoin has certainly a bigger coverage than Litecoin, which has surely a bigger price coverage than the other noname cryptos. 

2. Cryptocurrency purchasing power: it should look similar to the classical purchasing power, like we might as well interpret as the purchasing power of the crypto after changing it to US dollar for example. Certainly the US dollar choice is pretty arbitrary, the reason for that is that most services and goods that are sold by crypto at the moment are usually denominated in US dollar. However on a long run, perhaps better measures can be found as well.      

Bittcoin - Ethereum and the cryptoderivatives

Although current Blockchain systems like Bitcoin or Ethereum clearly represent breakthrough technologies for realizing financial services without the need of central trust, they suffer with a basic problem to realize a wide range of financial services: They focus on instant payments and money sending. Most financial products however are not build on the instant payment but rather on a promise of a future payment. In this sense instead of the basic services, like a certain M amount of money, Bitcoin or Ether is transferred, the basic protocol should focus somehow on the fact that a certain amount of M money will be transferred in a future t time point. As a consequence atomic transactions should be rather build up with the help of <M,t> tuples. Certainly it is a very good question if the Blockchain can help somehow that the certain amount of M money is really or with a high probability will be really transferred at the t time point.    

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.

Notes on machine payable micro-services

With the appearance of the different cryptocurrency technologies, micro-payment services have become possible. So basically the next evolutionary step can already be predicted: cloud-micro services with the direct micro-payment possibility. There are some initiative for creating such an architecture for Bitcoin, like, https://21.co/, however I think the idea gets much more exciting if it changed to Ethereum. At Ethereum there is basically an amount of 'money' or gas that is payed for all of the execution that are validated by the Blockchain. It is not difficult to imagine an extended model where each execution independently if it is an internal call or a an external micro service cost a certain amount of 'money'. In this sense providing a backend service will be realized as a complex micro service integration task with complex financial impacts. 

Competitive Analysis for Decentralised Business Process Management

Competitor landscape has been analysed with the help of two frameworks. Figure 1 uses the classical ambition matrix positioning Decentrlised Business Process Management or simply DBPM as a rather further out than closer in innovation. We positioned multiply version of DBPM on the market segment, because creating a cross-company business process between two companies should not necessarily be regarded as a new market, perhaps not even emerging. However creating business processes between companies, individuals and IoT devices surely manifests as a new market segment.

Figure 1. Industry and competitive analysis with ambition matrix

Figure 2 summarises the competitors on a rather architectural way concentrating on two dimensions:

1.  At the dimension of high trust architecture the question is if the technology is based on Blockchain, providing a scalable high-trust architecture by design, or on a classical client-server framework (or perhaps old fashioned mainframe).

2. The diversity of actors analyses how many different parties should be considered for a business process, ranging from a one-company process to the processes of multiply companies, individuals or intelligent gadgets.

Figure 3. Solution segmentation

Based on the two orientation diagrams as well, we would argue that enterprise ready classical Business Process solutions should be regarded as direct competitors of DBPM. They do not necessarily focus directly on a cross-actor market, apart from some examples like Kofax, but enterprise ready basically means that they can be extended with some further development on a cross-company or even cross-intelligent gadget scale. For example some of the ‘big players’, like Oracle, IBM, or SAP implement cross-company functionalities as well. However on the one hand they are not based on Blockchain solutions on the other hand they require that the same solution is installed and licensed in all of the trusted companies, like SAP processes between subsidiaries of a company. Enterprise business process solutions can clearly compete on a markets where processes between a few previously trusted companies should be implemented, but they will have the weakness as soon as processes between a larger numbers of untrusted actors should be set up.

As indirect competitors we regard the whole smart contract market, including general platforms, like Ethereum, Counterparty (Bitcoin based smart contract system) and systems like Hyperledger. These platforms clearly provide the possibility to set up trust between different untrusted actors based on smart contracts and Blockchain, however they have rather a general focus and not a BPM specific one. As an example a specific decentralised business process can surely be implemented as a set of hard-coded smart contracts, but hard-coding one such a company cooperation is completely different from providing a whole platform on which such processes can be practically clicked together. Nevertheless the risk that someone develops a competing solution on top of these frameworks is surely bigger than zero.

Companies who do something in the direction of multi-party trust system or business rules can be regarded as potential competitors. The range is here pretty big, starting from business rule engines like Decision, through digital business logic platforms like Drools, to general IoT solutions, like Ritc. They seem to be pretty far from DBPM at the first sight however they have a similar and strong technology basis that can be further developed in the direction of decentralised business process management without too much effort.

Based on the previous analysis our competitive strategy is based on two major building blocks:

1.  Decentralised processes among large number of possibly different kind of untrusted parties, including companies, individuals and intelligent gadgets.

2.  Low code solution in cooperation with local consulting companies of different industrial fields, making possible that decentralised processes are set up directly by the local experts of a certain field or even by end-customers in a self-service way.

We see that the market is pretty much in the emerging phase, hence the strategy is based on segments, like IoT communication that are emerging markets themselves. As a consequence we see the market and our competitive strategy as a blue ocean one.

Financial Framework for Decentralised Business Process Management

Setting up a financial framework for analysing DBPM (Decentralised Business Process Management) we are going to use the following considerations: 

From a unit economical point of view the most important element that directly carries the cost and indirectly generates revenue is an atomic t transaction. A p process is set up as executing and validating a sequence of t transactions.

In the business model, we distinguish two levels of the business. Core platform is responsible for executing decentralised transactions and processes. On the top of the core platform industry specific solutions can be delivered with the help of partner companies. On a long run industry specific solutions could be implemented directly by partner companies, however it is probably not realistic on a short run. As a consequence initial financial models consider both the development of the core platform and some of the industry specific solutions.
Costs structure is based on the following elements [Figure 1]:

1.    Variable cost:

a.  CoGS is mostly based on executing and validating the transactions on a decentralised consensus. It can be easily scale up or down depending on the customer needs. As opposed to a general Turing complete Blockchain system where executing a transaction might be pretty expensive due to the possibility of the infinite loops, at DBPM runtime of the atomic transactions are always limited from above, implying O(|T|) execution cost for a set of T transactions. The exact cost pretty much depends on the consensus mechanism, implying different numbers at proof of work, at proof of stake or at majority voting.

b.  CoGS is also influenced by storing the states of the validated transactions of a p process. It is manifested as a general storage cost that will be increased as the process itself is used. It requires further considerations if the whole state between two transactions is directly and fully stored in the Blockchain itself or rather off-chain solution might be used and only hash of the state is stored in the Blockchain.

c.  Supporting the system to partner companies or end-users is manifested as an additional variable cost.           

2.   Fix cost factors are mainly the SG&A expenses for running the company itself. As the primary focus is on the partner business, the most important is the professional business development as CAC.

3.    Investment: For a successfully start both the core framework and the first two or three industry specific solutions must be ready. They requires a certain amount of development and initial investment.

Revenue structure has the following factors [Figure 1]:

1.   Core services: customers get the value of using a certain business process itself. As executing a business process practically means executing a set of state changing transactions, it makes sense to charge money after transactions.

2.     Extended services might be possible as well, as providing training or consulting. It might be however a possibility that the company concentrates only core functionalities and every extended service is provided only by partner companies.

Figure 5. General cash-flow schema.

Business Model for Decentralised Business Process Management

Decentralised Business process management or simply DBPM is intended to be a strong infrastructure oriented solution, business model is based on an intensive partner network. The platform is not planned to be sold directly to the end-customer, instead partner companies having the industry specific know-how set up solutions on the top of DBPM [Figure 1]. A more detailed description of the ten types of innovation is covered in chapter plan as general operation model.

Figure 1. Business Model with Ten types of innovation

As DBPM is based on a Blockchain protocol, both cost drivers and profit should be based on transactions. It is certainly a question which digital consensus is applied, at Poof of Work model each transaction or block validation cost directly a certain amount of energy and money called the mining. At Proof of Stake or at general consensus mechanism like voting at Ripple rather a general hosting and participation cost is manifested. In any case profit model should be based on charging the customers after usage for individual or branch of transactions.          

From the network perspective DBPM solution would not be offered directly to the end-customers, instead the service would be sold with the help of strong B2B cooperation via partner companies. Examples can be:

-   consulting companies for setting up cross-company contracts and processes
-   IoT solution providers for setting up decentralised processes between hardware devices, for example for smart-homes.

Structure and process of the DBPM company would be pretty much similar to the classical enterprise software vendors. The core solution is continuously developed; based on the core solution industry specific features are developed. Instead of internal development, a possible way is to work with a strong open source community and develop the framework either with freelancers or with partner companies, just as at Ethereum Foundation. Another aspect that must be taken into consideration is the Network of hosters or miners who actually run the whole system. Depending on the Blockchain solution miners and hosters are paid in either by an internal cryptocurrency system or directly based on revenue.

In the middle of the product performance the core platform can be found: A decentralised P2P process management platform, in which each workflow state transition is validated by a consensus of the whole network. Apart from the core, the product system will contain industry and branch specific solutions and features.

One of the most important feature from a customer point of view is that DBPM is a no-code solution. It means that business processes can be ‘clicked’ together; in most of the cases no software developer is required. It makes a strong impact both on the service and on the customer engagement side. As a consequence of no-code development, distributed business processes can be directly built and modified by the knowledge workers of a specific industry. In this way rapid solution development and continues process improvement can be realised, instead of having long-running development life cycles. 

As a consequence of no-code development, sales channels are the best to realise in cooperation with local consulting companies. As an example on of the Big Four or Big Three companies can be an excellent candidate to use DBPM with local consultants realising indirectly common sales channels as well.

Branding must suggest the core business idea in a way and must suggest a strong and stability. From a technology point of view, name of the core technology can remain DBPM however it is adequate only for strong technical audiences.