There are two common approaches or strategies for storing business data on a programmable blockchain (e.g. Ethereum, NEO, and possibly others). The approach that gets the most attention uses a blockchain smart contract to represent data on the blockchain. I use the word “represent” very specifically because the data itself is never actually written or persisted into the blockchain — rather, a list of opcodes (computer instructions) is written to the blockchain as a part of each transaction. These lists of opcodes are capable of recreating (regenerating) the smart contract data if asked to; however, the data that is saved by a smart contract is never actually written into or included in the secure, immutable blocks and transactions of the blockchain. Let’s label this approach Smart Data.

The second approach, which I’ll label Dumb Data, is a more secure and more reliable way to store data in the blockchain (compared to Smart Data).

There are 2 ways to store Dumb Data directly into the blockchain. The first is to use one of the “extra” data fields in a blockchain transaction. In the Ethereum blockchain, a transaction has a “Data” field (sometimes called “Input Data”) that can be used to store arbitrary data as an array of bytes. Because the Data is a part of an Ethereum transaction, it is signed and becomes secure, immutable, auditable, historized, permanent data stored in the blockchain. The Data field is also used in another scenario: passing parameter values as part of an Ethereum smart contract method call (i.e. the Smart Data scenario). The Data field can be used to: (i) store Dumb Data (resulting in the data being written directly into a signed transaction in a block in the blockchain) or (ii) invoke a method in a smart contract using the Data field to pass in the method signature and parameter values. Below is an example of an Ethereum MainNet transaction that uses the Data field to invoke a method in an Ethereum smart contract.

Figure 1. Output from https://etherscan.io/tx/0xbb6dead2426f092f0d2e0d78a8083b19fa28cfacba6aca7f15439363c0e90ce5

On the NEO blockchain, NEO transactions have a similar Remark field that can be used to store data and, by implication, causing the data to be directly persisted into the NEO blockchain.

The second way to store Dumb Data is to pass the data to be persisted as a parameter value in a method invocation transaction that calls a method in a smart contract — almost any smart contract and any method — as long as the method isn’t actually executed or the call executes a trivial smart contract method that simply returns to the caller. Similar to the previous approach of using Ethereum’s transaction Data field or NEO’s transaction Remarks field, the data will be persisted directly into the blockchain and becomes secure, immutable, auditable, historized, permanent data. Below is an example of a 36x36 pixel NEO Logo stored in PNG format (957 bytes of image) along with selected metadata such as the image name and image version. The data is encoded with the SerentityData v0.2 Runtime using the SerentityData ImageLedgerEntry v0.2 schema standard.

Figure 2. Output from https://neoscan.io/transaction/61fac524e8c716d796a4e5c53b6f6cc94f74834c90c0cab06b4fdf0a60a521bb

Conclusion

Dumb Data is not so dumb. Dumb Data persisted into the blockchain is more secure, immutable, auditable, historized, and permanent than Smart Data represented on the blockchain using a smart contract.

Smart Data, on the other hand, can easily be lost or become unavailable for long periods of time during hard forks, bug fixes, and/or unreliable blockchain platform upgrades because Smart Data depends on the successful execution of smart contract byte codes. Dumb Data can be more easily read back directly from the transactions stored in the blocks of the blockchain.

Resources