One problematic issue facing our industry is off-chain dApp data storage options build silos that limit data’s use across the ecosystem, as well as lacking comparable on-chain immutability/proof. In general, the metadata isn’t easily accessible to the users and third parties, without inspecting every transaction. Off-chain data can be thought of as any non-transactional data that’s too large to be efficiently stored on the blockchain, or requires the ability to be edited or deleted. However, this data must still be shared. If every dApp developer were to individually decide how to get around this problem, it would result in a multitude of off-chain databases, ones that do not adhere to any common standard. In turn, this will make it extremely difficult to query data for analytical purposes, provide cross-app data sharing, and most importantly, to expect any standard of immutability.
The above could be described as somewhat of an oxymoron, a ‘centralized decentralized App’, where some parts of the dApp are on-chain and therefore immutable and trustable, while the off-chain metadata is not. Unfortunately, this may eventually lead to an erosion of trust in the Cardano ecosystem itself, as we have already witnessed with Ethereum. This was demonstrated in cases like the following, where an artist was able to modify his NFT images of an already sold collection, without any permission from the actual owner.
An Alternative Solution seems Required
The Cardano community have made concerted efforts to render scenarios like the above impossible, and should be credited as such. One idea was to store the binaries in IPFS (InterPlanetary File System) as a Merkle DAG, storing only a root CID of the DAG in the transaction metadata. However, this would only work effectively for trivial use cases of attaching binary files and documents to a transaction. In order for non-binary metadata to be aggregated for analytics, extracted with minimum latency, used as training data for AI or adhere to a standard, an alternative solution is required.
Fluree’s Plan for Action
Fluree intends to solve this problem by building a provable data-centric sidechain for dAPPS, using their immutable graph-ledger/DB, which leverages W3C semantic linked- data standards. They will provide the ability to link and share data across dApps, while systematically guaranteeing the same degree of integrity, trust and provable provenance as the on-chain data. They will address the 16kb limit of transaction metadata in Cardano, while also allowing for the entire ecosystem of dApps built on Cardano to flourish, with data that can later be harvested, analyzed and used for ontological reasoning by future AI systems. Fluree will provide an API to allow any dApp developer a universal means of storing extended metadata, while also guaranteeing that metadata stored outside of the Cardano chain will be as trusted as the Cardano network itself. This may be accomplished with a data-centric layer that is decentralized, immutable, versionable (traceable), shareable, queryable, standardizable and scalable. Essentially, Fluree is a decentralized semantic graph database, which uses a blockchain with ledgers consisting of blocks implemented as RDF++ triples, called ‘flakes’. In essence, this allows Fluree to be used as a side-chain to Cardano, which could be the first step on a roadmap, as mused here by Charles himself.
So, in relation to the factors detailed above, Fluree is
- Decentralized: Fluree can run across a network of servers that participate in transaction validation. There are two types of Fluree nodes: transactor and query nodes that can be run on the existing stake pool operators infrastructure + new DApp infrastructure that will adopt the metadata layer (which also can be SPOs). There should be some incentivization model worked out, which for now we would like to leave outside of the scope of this proposal. If the community considers this question essential and worked out before the voting, we will work on this and respond with the ideas.
- Immutable: Fluree combines transactions into immutable time-stamped ‘blocks’ and locks each block in via advanced asymmetric cryptography — making data completely tamper-proof. Traceability of changes are tied to digital signatures for complete proof and visibility into data lifecycle.
- Versionable (traceable): Fluree extends the RDF triple model with a time dimension and treats any update to data as a timestamped new version. This allows for both issuing queries against any moment of time and for “time travel” with complete historical data visibility. In NFT-DAO Discord there was quite a debate about if transaction metadata should be mutable or immutable. Fluree’s model allows it to be both: immutable at any given moment in time and mutate or evolve over time with complete traceability back to the original version.
- Shareable: Fluree embeds privacy and security permission logic as metadata alongside RDF data at the source and implements a security model based on “smart functions” that are triggered based on conditions and return true or false for either a transaction to go through, or in case of a query, if a particular flake (unit of data) should be included in the query results. This allows for data sharing, cross-DApps collaboration opportunities, and to create a monetized data subscription model.
- Queryable: For querying data Fluree supports industry-standard query languages SPARQL and GraphQL, and also FlureeQL, which is a Fluree own-language, based on JSON. It supports queries across different ledgers and network nodes, which makes it very powerful for AI applications that could build ontologies and derive semantic inferences across the whole DApp ecosystem. Fluree query peer can be embedded alongside your code and serve up sub-millisecond query responses. As a code-resident data source, Fluree can power no-fetch code with no downtime.
- Standardizable: Because Fluree implements RDF W3C standard, it can natively support existing semantic standards created and evolved over time for a multitude of domains. This gives a huge head-start to domain specific use cases, such as NFT marketplaces.
- Scalable: Fluree claims to be indefinitely linearly scalable as CDN (content delivery network) Watch this webinar to see how it achieves this.
Backed by a Team with a Wealth of Experience
Fluree was founded by Co-CEO and Co-Chairman Brian Platz. Brian was the co-founder of SilkRoad Technology, which grew to over 2,000 customers and employees, spanning 12 offices globally. He also serves on the board of directors for Fuel 50, one of the highest growth HR technology startups. The Fluree team consists of 17 professionals who will be assisting with development, in various capacities. This includes Dimitri Safine, Senior Solutions Architect with experience in cloud architecture, data engineering, R&D as well as prototyping in big data and analytics space. Dimitri has built numerous data lakes, ETL pipelines, multidimensional cubes and data analysis applications. He is passionate about identifying emerging technologies and composing them into cohesive, scalable solutions, which solve problems. Also on the team is Michael Yagi, a Senior Software Engineer with experience facilitating integration between different technologies across many facets. His interest has been described as “building the bridge between the ocean and the pond”, in this case, Cardano and traditional software engineering.
The Roadmap to Completion
The goal is to have the public sidechain mainnet launch in eight months time, i.e. January 2022. However, this will largely depend on the amount of resources they are able to attract.
A full roadmap is outlined below.
Project Milestones – Phase 1 (months 1-3):
Architecture of Cardano / Fluree integration points
Testnet / dev environment:
Create an AWS CDK application to automatically create infrastructure with a few nodes on AWS that will include Cardano block producers and relay nodes and Fluree transactor and query nodes.
Create CI/CD pipeline
Begin DApp Collaboration:
There are two proposals who showed strong support for this project-
- NFT-DAO Boxcar
Take two use cases from different NFT domains [e.g. art, music, real estate] and demonstrate ability to host “boxes” as Fluree ledgers.
The selected use cases should be linkable through some interesting context. This will allow us to demonstrate use of ontologies to connect two different business domains together.
We will be leveraging existing RDF standards already adopted by corresponding industries wherever we can.
- Indigenous Art Authenticity
A Fund 4 Proposal project, which covers use cases of physical art authenticity and rich cultural metadata. (Dmitri Safine is a co-proposer)
Implement back-end and API
GraphQL API
Based on architecture agreed upon by Fluree, IOHK, and developers
Will be hosted on AWS and emulate decentralized testnet
Phase 2 (months 4 – 6)
Implement RDF-Powered Web Forms:
Create a form generator to automatically create an interactive web form to collect data based on the corresponding RDF standard to make inserting into Fluree seamless
Implement security model:
Partial showing of data.
Data subscription by 3rd parties.
Zero-knowledge proof use-cases
Start engaging SPO community
Develop incentive system for the SPOs and start communicating the vision
Implement easily deployable bundle for side-chain hosting
Testnet hosted on network of volunteering SPOs
Phase 3 (months 7 – 12)
Mainnet launch
Advertise for more SPOs involvement
Support broader DApp ecosystem
Advertising for the broader DApps community
Cover more variety of use cases
The Cost for an Effective Sidechain
The team at Fluree has requested a budget of just $12,500 USD. However, they are intent on building the project regardless of funding. If successful, the $12,500 would contribute towards marketing and outreach, infrastructure and upkeep costs, while also providing a bounty/reward system in order to attract more developers to help them in their efforts. Even more importantly, being a selected proposal would grant them access to IOHK architects, who would oversee and consult on the design.
Final Thoughts of Fluree
As outlined above, Fluree proves to be a strong candidate for the standard off-chain layer, while still being decentralized. It paves way for the creation of private ledgers that allow for the splitting of data into a completely secure part, one that resides outside of the public, decentralized network. On top of this, the private ledgers can still be ‘linkable’ through multi-queries, with the data stored in public ledgers, granting the best of both worlds. Even more appealing is that this project can contribute to the further decentralization of the Cardano blockchain, by offering additional incentives to stake pool operators to host sidechain nodes and receive rewards from data subscriptions.
If you’d like to know more information or have questions/comments regarding Fluree’s proposal, check out the link. Log in – Project Catalyst (Ideascale.com)
