0bsnetwork relies on “data transaction” feature for vast majority of use cases. Data transactions have been specifically developed to facilitate use cases involving large scale data processing for real world business. They are incomparably easier to understand, develop and utilise, much faster and cheaper from resource utilisation perspective.

Our firmly held belief is that smart contracts are not an appropriate tool for the development of real-world business blockchain applications.

1. Smart contracts are a highly complex programming paradigm, requiring highest end expert developers, which significantly increases the costs of development and especially future maintenance and feature additions
2. Danger of vendor lock-in due to complexity
3. Smart contracts fix the business logic “in stone” due to immutable nature of blockchain
4. Real-world business relationships and requirements change over time, requiring the business logic to remain flexible and easily adjustable in the future – extremely difficult with smart contracts
5. It is impossible to predict all possible types of future interactions between stakeholders in any multi-party business system
6. It is next to impossible for a lay person to read data stored in a smart contract directly from the blockchain, which defies the promise of transparency
7. Smart contracts are expensive from resource utilization perspective, contributing to the image of blockchain as slow and resource-hungry technology (electricity…)
8. Querying data from a smart-contract-based solution is difficult and slow; verification of returned data is difficult for the vast majority of users
9. All of the above results in the necessity of a middle-person / middleware / translator / central point of contact as the source of truth, which is directly opposed to the promise of blockchain as the open, transparent and trustless technology

As you can see, Data Transactions rely on the “key – value” pair concept, which is super easy and takes way less time to implement for the developer, yet is amazingly flexible and powerful. Anything can be a “key”: “Temperature”, “User ID”, “Product Type”, “Product Unit ID”, “Seller ID”, “Manufacturer ID”, “Use By Date”, “Approved By”, “Approved For Country”, … And “value” gets assigned to these keys either by platform users, IoT devices, or in an automated way based on some business logic.

Querying the data stored in such a way couldn’t be simpler. An example of a query would be “Return all [Product Types] approved by [Approved By (X)] for [Approved For Country (Y)] during the period between [Date(A)] and [Date(B)”].
More to the point of real world projects, queries such as “How many days have passed since [User ID (A)] last purchased [Product Type (X)] and is [Product Unit ID] purchased in that transaction still valid/approved in Approved for [Country (Z)]?” and “Has [Product Unit ID (M)] been stored in [Temperature of less than (Y)] during period [Date(A)]-[Date(B)]?” when products are pharmaceuticals, may indeed save lives.
Multiple data transactions can be nested, stacked or combined in any number of ways to get as wide, or as fine-grained record/view of the data valuable to your business.
To further illustrate our point, here is an actual 0bsnetwork blockchain record, not “prettified” in any way, of a data transaction from an actual Agricultural Commodities Trading Platform running on 0bsnetwork and used by multiple types of corporate users (commodity traders, banks, insurance companies, warehouse management companies, goods quality certification companies, logistics and transportation companies, etc.). We are confident that even without an explanation, the non-techie members of your team will be able to understand what the content of this data transaction is, which cannot be said for pretty much any smart contract on any platform:

[
{
“key”: “filename”,
“type”: “string”,
“value”: “signed
–
contract
–
TF
–
20200109
–
877
.pdf”
}
,
{
“key”: “filehash”,
“type”: “string”,
“value”:
“bf1ab4eb191b700d2cfde50344f93cce1f24e01a772c7d853f6bd141a06dd3c6”
}
,
{
“key”: “product”,
“type”: “string”,
“value”: “Corn”
}
,
{
“key”: “product_quality”,
“type”: “string”,
“value”: “By specification”
}
]