Blockchain revisited

[Niclas Hedhman <ni...@hedhman.org>]

Gang,

I have been very quiet for a long time, and part of that reason is that I
have too many jobs at the moment, although some of them overlap in the
blockchain space.

I would like to draw attention to
https://github.com/apache/polygene-java/blob/develop/artwork/blockchain-architecture.png

I have a usecase for a decentralized business application, where each
user's data is kept outside the central systems of the provider. It is also
a matter of slightly more transactions than Ethereum can handle, so I have
focused the approach on EOS[2], which is both much faster as well as free
from  transaction fees. Instead, one has to stake EOS tokens for CPU and
bandwidth, as well as buy RAM for storage. And that "storage" is expensive
(1970s price of RAM).
So, I need to get off chain for most of the data, and only hold a small
number of references to IPFS[1] objects, and IPFS holds the bulk of the
data.

So how is this supposed to work?

First of all it is important to understand that Blockchain is an Eventually
Consistent store. And the eventuality is so far into the future, that
applications must be reactive rather than prescriptive when it comes to
data storage. This means that a stored value may never be stored, even
after the UnitOfWork has completed and

*Crypto SPI* - A generic SPI that the UnitOfWork implementation will use if
present, to encrypt/decrypt any "encrypt" tagged data types.

*BlockChain Entity Store* - the is a great deal of commonality across
blockchain types to be able to put most the work in a ES implementation.
This is similar to the K/V entitystores that implements the JsonEntityStore
SPI.

*Blockchain SPI* - The SPI for interacting with blockchain. This primarily
includes "listen to transactions on chain", "lookup values on chain",
"create transactions" (they can execute until signed) and call arbitrary
contract methods/functions. This SPI will also back the "Blockchain API'
which is not with scope for work, but basically is about direct calls to
the blockchain.

*EOS Impl* - is the first implementation where we (I and Jiri) have the
most experience.

*ES(kv) SPI* - The Blockchain ES should be able to use any Key/Value entity
store, but it may require some small changes for this.

*IPFS ES* - A regular EntityStore for IPFS. IPFS has one property that may
require a slight change to the ES SPI, because the user will not be able to
set its own Identity. It is defined by the hash of the content stored, so
it is not known until after the object has been stored.

*MessageSink SPI* - The Blockchain ES needs to deliver the transactions to
the "current user", for signing them and the push those to the blockchain.
How that is to work needs to be up to the application developer, as many
different approaches may be suitable. But, the concept is simple; Some data
is to be sent to some destination. That could be via email, http/websocket
or USB stick. The Blockchain needs a SPI for "Deliver this chunk to that
recipient" and the developer is responsible to not only get that data to
the user, but in a way so the user can sign the transaction and push that
transaction to the blockchain.



*Interesting observation;* None of these parts are particularly hard to
make, and it would position Polygene as the only platform for making
business applications, specifically designed to handle multiple back-end
storage systems, of which blockchain is one. And it is the only system with
potential of being on-chain or off-chain decided at boot time, for
different deployment scenarios (say, dev/qa/staging/prod environments).




[1] https://en.wikipedia.org/wiki/InterPlanetary_File_System  - Effectively
a permission-less, distributed hashtable across the world.

[2] https://en.wikipedia.org/wiki/EOS.IO

Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java