Factom vs. OriginTrail — A Brief Comparison of Blockchain-based Database Management Systems

Database management is arguably blockchain technology’s natural use-case, due its inherent immutability vis-à-vis hashing (i.e. a digital fingerprint that can never be erased or redone).

However there are two issues that arise, namely:

(1). Ensuring authenticity of the uploaded data — i.e. How do we know the data being uploaded is legitimate? (also known as “data spoofing”)

(2). Preventing collusion amongst actors involved with storing the data

My most recent piece on OriginTrail revealed how its decentralized network can inherently hold corporations accountable in regards to supply chain management. Essentially, OriginTrail’s protocol incentivizes corporations to maintain the highest standards when providing product transparency (from the source to the shelf).

As explained, two sets of nodes oversee data management — Data Creators and Data Holders. In total, 2n +1 nodes must validate the uploaded dataset, with “n” being the number of participants (i.e. food producers/suppliers) involved in the original dataset. All nodes must accept the dataset as valid before it can be uploaded into the system. Most notably, an odd number of nodes is used to prevent collusion.

To clarify — OriginTrail provides no concrete way for the data to be verified (i.e. “Did this piece of lettuce come from this specific farm, on this specific day and time, etc.”), rather, the presence of OriginTrail’s immutable blockchain protocol incentivizes Data Creators (corporations and other institutions) to upload authentic data, which can be subsequently checked and verified by all relevant entities involved.

This is the innate nature of blockchain technology, and OT incorporates this concept excellently while establishing an anti-collusion incentive structure. Thus, corporations are held accountable, and the consumer can be assured that they are not reading fraudulent information on food labels when shopping at their local grocery store.

When scrutinizing another notable database protocol — Factom (FCT) — I came across several issues — in particular their inherent consensus/incentive structure (or lack thereof):

· Factom uses “Federated” (read centralized) data servers and data auditors

· There is no known incentive structure in place to prevent collusion

· Factom essentially does the same thing as R3 (https://www.r3.com/) since it’s strictly for enterprises

Factom has a partnership with the Department of Homeland Security, which obviously reveals its professional competence as a database management system using blockchain technology, but, seeing that its protocol operates on central servers with no anti-collusion measures, as well as its emphasis on enterprise database management, I do not see an inherent need for its inherent cryptocurrency (Factoids).

In fact, I see them more as a competitor to R3.