We’ve been testing several blockchains (public Ethereum, POA networks, Stellar, Cosmos Networks, and other variants such as GoChain, and assessing remotely Enigma) and the conclusion is that public blockchains are not yet ready for business logic with data privacy involved. There are both issues with the size of the data to be dealt with, the complexity of the algorithms that have to run onchain, and the difficult integration of smart contracts with data (IPFS helps a bit, but do not provide guarantees of file existence. FileCoin does, but then the issue is to manage correct on-chain access rights).
Finally, for businesses (either for internal use cases or business private consortium), it makes sense to run on a private blockchain as long as it can be audited real time by any consortium member, which is usually possible within a blockchain consortium. The transparency idea can even be extended to “open” networks, i.e. allowing anyone to audit operations without registration.
Deploying those decentralized infrastructure is a pain for businesses. That’s certainly the most costly part in any decentralized project for companies, and we could not propose our original approach (on demand private blockchain deployment with the dAppBox) to new customers without scalability issues. We therefore industrialized our decentralized infrastructure within the de-facto emerging standard for cloud operators, Kubernetes.
Kubernetes is now everywhere, on any cloud providers (AWS, Azure, Google, DigitalOcean…). We implemented Kubernetes both on cloud operators and BareMetal. We chose BareMetal options to have always highly competitive prices for individual dAppBox users. Our on-demand deployment is available on BareMetal our custom cloud, depending on the project choice. By default, it is BareMetal.
Decentralized infrastructure could not exist with only blockchains. Decentralizing logical process is not enough, we also need distributed file systems. Distributed file systems existed for decades, but what is lacking is a simple to use integrated stack where distributed file system operations are integrated with blockchain programmable logic.
Our dAppBox (dappbox.io) is integrated with the blockchain in many ways.
• The first integration is access rights management. Our private Ethereum-based blockchain manage access rights between dAppBoxes, and it is customizable (as a smart contract) for the dApp creator.
• The second integration is the proof system. All files added to IXXO networks are “audited”, i.e. their content hash is posted on the blockchain for “proof of existence” (also called “notarization”). Less usual, the dAppBox network also keeps track of files transfers in the blockchain.
• The third integration is in the content management identity. All dAppBox folders have blockchain identities, and those are owned by the dAppBox creator (and can also be viewable in plugins such as Metamask). This allow some custom logic on access right management directly using dAppBox folder addresses, including multisig, staking, etc.
The things that the dAppBox naturally handles:
• Network resilience (synchronizing back nicely after a network outage)
• Coordination of updates within distributed peers (adhering to the CRDT concept – https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type)
• Customizable content history backup (similarly to blockchain or git, with block structures of file content).
• Fast transfers of updates (only transferring the modified version of files).
Moreover, we adhere to the “merkelize everything” philosophy, leading to infrastructure with encrypted, recoverable data, that can be used cross-application. The dAppBox API provides an infrastructure layer to build some “dApp” (decentralized applications) on top of both a decentralized content layer and decentralized logic through Solidity smart contracts.
While it is not yet possible to subscribe publicly on on-demand IXXO clouds (working on latest public vulnerabilities issues), it is possible to request a private account for testing. Contact firstname.lastname@example.org.