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
