1. Centralization vs decentralization
1.1. Disaster Recovery
The first question any responsible manager usually asks before approving a new IT system for production use is “who shall I call if things go terribly wrong?”
In a case of a centralized system the answer is very obvious – call the 1st/2nd/3rd level support, wake them up if necessary, and let them deal with the issue.
In a case of a fully decentralized system this option is not easily available as decentralization assumes different parts of the system to be controlled by different entities from support perspective with unavoidably required coordination between them for system integrity level actions.
From this perspective even Bitcoin is not a fully decentralized system. At the end of the day it is one network.
1.2. Deployment, monitoring, production support
Same logic applies to other standard operations jobs.
Software releases should follow established procedures.
Users must have dedicated points of contact.
1.3. Data storage
Decentralized validation assumes decentralized data storage.
For a case of a large enough organization this require separate Database provisioning and management every node or cluster of distribution. With all the associated burden.
2.1. Proof of Work vs Proof of Stake
Direct use of a separate Proof of Work implementation for an in-house system even in a global multinational organization looks like a massive overhead with quite limited business benefits.
That is actually one of the reasons why many Proof of Stake projects has arisen recently. Most of them are way less computationally intensive comparing to PoW based ones but the fact of their variety by itself tells us that none of them solves issues like “nothing to stake” completely. And we probably can expect to see more of “Proof of XXX” algorithms be announced in nearest future.
For more information, please read the Bytecoin article by Ray Patterson:
As an alternative a combination of PoW and PoS can be used (e.g. Proof of Activity - https://bytecoin.org/blog/proof-of-activity-proof-of-burn-proof-of-capacity/) or combination of the Bitcoin and Sidechains (please see Avalanchain Bitcoin nailing section for further details).
2.2. Consensus in general
Existing Blockchain implementations select network level consensus mechanisms with common parameters for every application, user and scenario.
In reality this fact creates quite interesting situation when blockchain developers effectively making decisions about how End User’s business should operate.
On these grounds it looks like a reasonable expectation for an Enterprise level Blockchain system which is expected to survive for years to have Consensus mechanism selected for it pluggable or swappable depending on actual business needs and scenarios.
Let’s be honest, within a real organization it is quite difficult to find a rationale to make one department to pay another one some amount of virtual currency for validating their transactions.
Such applications are naturally limited to currency exchange/trading, and different types of order entry applications.
More commonly used patterns usually rather involve renting of real or virtual machines with time-based billing in real department budget currency.
Bitcoin, Etherium and pretty much all other ones, every operation requires some amount of home-brew virtual currency get attached to that operation in order to let it proceed (and intensify people owning processing/validating machines, also allowing priority execution). The problem is in deciding how this virtual currency in distributed among departments in the first place and why people owning the machines should care about getting any amount of it. So effectively it's a way of creating parallel internal economy aside of regular budgeting.
An alternative approach is to use normal budgeting currency and normal internal accountancy (in say USDs) for the resources charging.
All at least make fees optional and/or pluggable.
(to be continued ...)