7. Blockchain as an Event Sourcing System
All Blockchains are actually Event Sourcing systems.
They all work with streams of transactions coming from different sources into limited number of actual chains.
Unfortunately no available implementations (as of now) actually consider Blockchains as streaming systems, nor try to turn this natural feature of Blockchains into a business benefit.
The concept of Sidechains has arisen from the general understanding of the fact that Bitcoin doesn’t fit it all use cases, in particular it cannot stretch indefinitely to satisfy all very different business scenarios.
One- and two-way pegs were introduced to let custom chains to communicate with Bitcoin and each other.
For the enterprise environment, the ability to physically split information between different chains whilst permitting referencing between them is extremely attractive, not least for security and regulatory reasons (e.g. “Chinese Walls”, geographical restrictions, etc.).
Anonymity and full traceability are a trade-off. Anonymity can create complications with KYC (and other regulations) whilst be desirable, indeed necessary for others (e.g. Swiss banking). From this perspective, anonymity mechanisms originally proposed in the Bitcoin community show promise in cases of controlled use in variety of environments.
9.2. Multi-signature transactions
Modern cryptography can now require cryptosystems requiring unavoidable collaboration of a specific number of separate parties (e.g. 3 of 12 company directors) to confirm the decision (or access to some information).
9.3. Role-based security
All the following operations in an Enterprise level system are expected to be role-based (and no existing implementation of Blockchains currently provide this).
A user recently joined the organization should be able to get access to the system (and be able to get recognized by the system).
They should lose this access on leaving the organization.
Depending on their role(s) within the organization they should have access to different parts of system’s functionality. The set of functionality accessible should follow changes in the set of roles assigned to the user and their authorizations.
9.3.3. Data encryption
Ability to encrypt and decrypt some data based on requirements of a role covers a variety of data protection use-cases starting from simple “user lost his key” to more complex cases like “information available only for company Directors”.
9.4. Cryptographically strong proofs
Blockchains naturally allow creation and validation of cryptographic proof of facts.
10. Scripting (aka Smart Contracts)
A legitimate expectation of any database user (for decades) is an ability to atomically validate a transactions input or rejection of the transaction if an input has a chance to put the system into a logically inconsistent state. Users need to be provided with ways of not only validating but also actively reacting to inputs and state changes.
Another legitimate expectation is an ability to move the code, or the logic, as close to the data as possible instead of moving data to the code. This ability in itself can create a huge performance improvement, but if combined with the option of saving the result back to the database with full audit, performance improvements are dramatically enhanced.
Yes, we are talking about Triggers and Stored Procedures.
In Blockchain world these are addressed in two ways:
- by hardcoding processing logic (e.g. payment transaction processing in Bitcoin-like networks), or
- by adding scripting option to the protocol (rather functionally limited op_codes in Bitcoin and full Turing-complete languages in platforms like Ethereum and Codius).
There are of course legitimate reasons for using any of these options but an important point is that the enterprise level Blockchain systems that don’t provide convenient and user-friendly triggers and stored procedure functionality will be at a massive disadvantage compared to any (distributed) database or calculation framework.
(to be continued ...)