Storing data on blockchain is expensive and there is a limitation on the amount of data and amount of
computation a transaction can contain in the context of upgrading smart contracts.
The upgrading transactions might contain a large data storage for copying the data from the old version
of the smart contract to the new version of the smart contract.
Porting data to a new version might even require multiple transactions.
For example, when the block gas limit on the Ethereum prevents an overly complex data migration transaction,
the need to upgrade a blockchain based application over time is ultimately necessary.
So as the smart contracts used by the application in general, logic and data change at different times
and with different frequencies and there is always a need to have a different way to store the data
on top of blockchain data.
Contract pattern provides us a storage mechanism where we can store the data in a separate smart contract.
There are few of the forces which led to the creation of data contract pattern.
The first one is coupling.
Smart contracts can live forever on blockchain if not being explicitly terminated.
If a smart contract is deactivated in this way, the data stored in the smart contract cannot be accessed
through the smart contract functions anymore, although it can still be accessed with some efforts to
provide provenance or auditability.
Another major force which led to the creation of data contract pattern is related to Upgradability.
The need to upgrade the application and the smart contracts.
Supporting the application over time is ultimately necessary for many software applications.
One more important force which led to the creation of this design pattern is related to cost.
If a public blockchain is used, storing data on the blockchain costs money, thus copying data from
an old version of smart contract to a new version should be avoided and minimized.
Data contract pattern provides the solution for the same to avoid moving data during upgrades of smart
contracts.
The data store is isolated from the rest of the code in the context of blockchain data could be separately
stored in a different smart contracts to enable isolation depending on the circumstances of the application,
how large of a data store it needs, and whether the data structure is expected to change over time.
The data store could use a strict definition or a loosely typed flat store.
The more generic and flexible data structure can be used by all the other logic smart contracts and
is unlikely to require changes.
One example of a generic data structure is mapping to store Sha three key value pairs.
In a way, with data contract pattern, we are creating a separate smart contract to act as a model
for our application, which will only deal with the data and the rest of the contracts will deal in
the logic and fetch the data from this contract which we have created over the blockchain.
This will separate the data from our logic and we will provide much more upgradability for the data
and the smart contracts.
Benefits provided by data contract pattern are related to upgradability By separating data from the
rest of the code, the logic of the application is able to upgrade without affecting the data contract.
Another benefit which we get is related to cost.
Since the data is separated from the rest of the code, there is no cost for migrating data when the
application is upgraded.
One more benefit which we can get from this design pattern is related to generality.
If the data can be cleanly separated and generalized, there would be an additional benefit.
The generic smart contract can be used by all related logic smart contracts.
But there are few drawbacks also related to this design pattern.
One of the major drawback related to data contract pattern is about cost.
If a public blockchain is used, storing a piece of data in a generic data structure costs more money
than a strictly defined data structure.
For example, as mentioned earlier, a generic data structure maintains a mapping between sha3 key and
value pairs.
But a more strictly defined data structure can be of smaller size.
Example not requiring the key to be stored.
Querying the data is also less straightforward with generalized data store because we need to provide
a solution to iterate through the data store to fetch the data.
Some of the known implementations for data contract pattern are with Chrono Bank.
Chrono Bank is a blockchain project that tokenizes labours and provides a market for professionals to
trade their labor time with businesses.
It uses a smart contract with a generic data structure as the data store used by all the other logic
smart contracts.
Another known implementation is colony.
Colony is a platform for open organizations running on Ethereum.
This is very similar to Chrono Bank.
Colony has a data contract with a generic data structure.
Apart from these non implementation, one of the famous implementations with data contract pattern is
with CryptoKitties, which creates and stores the data for the kitties in a separate contract.
In this image, you can see the data contract pattern in action.
You can see we have maintained on chain on the left hand side and off chain on the right hand side on
chain.
Other services which are present with blockchain and off chain are the external services.
Inside on chain, you can see that we have a generalized data contract available and all the other contracts
are retrieving data from this data contract.
There is no external or off chain services enabled with this design pattern.
Only the contracts are going to interact with each other and we will have a generalized version of data
contract to fetch the data.
The next important design pattern under contract structural patterns is embedded permission pattern.
Now let's go and see in detail about embedded permission pattern.