Hey, everyone.
Welcome back to the course.
So now we have seen the first category of data patterns, which is the external world pattern.
External world pattern helps us to interact the blockchain with external services.
The next category of application patterns for blockchain are the data management patterns.
Data management patterns are important because they help us to manage data and also create interaction
capabilities with the data either be off chain or on chain.
There are multiple common problems related to management of data with enterprise blockchain applications
and we are going to discuss the same in detail throughout this lecture.
The first pattern under data management patterns is the encrypting on chain data pattern.
This pattern ensures confidentiality of the data which is stored on the blockchain by encrypting it.
For some applications on blockchain, there might be some commercially critical data that should be
only accessible to the involved participants.
For example, there could be a special discount price offered by a service provider to a subset of its
users.
Such information should not be accessible to the other users who do not get the discount.
And in those contexts we are going to use the encrypting on chain data pattern.
The lack of data privacy is one of the major limitations of blockchain.
All the information on blockchain is publicly available to the participants of the blockchain.
There is no privileged user within the blockchain network, no matter the blockchain is public consortium
or private.
On a public blockchain, new participants can join the blockchain network freely and access all the
information recorded on the blockchain.
Any confidential data on the public blockchain is exposed to the public.
How should we manage the public data in a way that we are able to provide the access to only a specific
subset of users and encrypting Onchain data pattern?
Help us to answer this query.
There are few forces which has led to the creation of this pattern.
The first one is transparency.
Every participant within a blockchain network is able to access all the historical transactions on blockchain,
which is required to enable them to validate previous transactions.
The transactions on a public blockchain are also accessible to everyone with the access to the internet
simply using the tools like Blockchain Explorer with Bitcoin or Ethereum.
The second force, which led to the creation of this pattern is lack of confidentiality.
Since all the information on blockchain is publicly available to everyone on the network, commercially
sensitive data meant to be kept confidential should not be stored on the blockchain, at least not in
a plain form.
So this led to the creation of a pattern where we will encrypt the data and then store it on top of
the blockchain.
The solution for such a pattern is to preserve the privacy of the involved participants by using symmetric
or asymmetric encryption to encrypt the data before inserting the data into the blockchain.
One possible design for sharing encrypted data among multiple participants could be related to involvement
of participants who creates a secret key for encrypting the data and distributes it during the initial
key exchange.
When one of the participants needs to add a new data item to the blockchain, they first symmetrically
encrypted using the secret key and only the participants are allowed to access the transaction who have
the secret key and can decrypt the information.
The benefits of such a design pattern is that it provides encryption to the publicly accessible information
on blockchain.
People who don't have access to such information will only see the encrypted data, and this encrypted
data will be useless for them as they don't know how to decrypt this data.
But there are also drawbacks related to this pattern.
One of the major drawbacks is related to management of keys.
Both symmetric and asymmetric encryption require off chain key management, and if the key management
is not done properly, it can lead to the compromise and disclosure of the private keys or secret keys.
If the required private key or secret key is compromised.
The encryption mechanism does not generate the confidentiality which is desired with the system.
Another drawback related to this kind of pattern is that you are not able to revoke the read access
for the data because data on the blockchain is stored immutably for indefinite period of time.
Thus, as long as the participant keeps the secret key used to encrypt the data, they have the access
to the encrypted data forever.
Another drawback related to this kind of design pattern is that the data is stored indefinitely on top
of the blockchain, although we have encrypted the critical information.
But still the data is available forever.
It could be a possibility that in future the breakthroughs with technology led to quantum computing
and might render some kind of encryption which is able to beat the system which we have stored on top
of the blockchain.
So even if the data is considered to be secure with a given key size and stored on top of the blockchain,
it might still be broken in the future.
Another major drawback with this design pattern is about key sharing.
The encryption key needs to be shared off chain before submitting any relevant transactions to the blockchain.
Although blockchain can be used as a software connector to communicate data, secret keys cannot be
shared through blockchain because the shared key would be publicly accessible to everyone and everyone
will be able to see the data which has been encrypted using the key.
Some of the known implementations for this kind of design pattern is oracles.
Oracles is a smart contract running on Ethereum public blockchain.
This service provides the access to state from external world oracles, allows smart contract developers
to encrypt the parameters of their queries locally by using a public key before passing them to the
smart contract.
The only one who can decrypt the call parameters is oracles with the paid private key.
Another example is related to crypto digital signature, which is suggested by blockchain.
This signature is used to encrypt data and share the data between the parties who interact and transmit
data through blockchain.
In this image, you can see the encrypting onchain data pattern in action.
On the left hand side, we have Onchain, which is the blockchain itself.
On the right hand side we have Offchain, which are the key management and key generation activities.
So you can see here that we have the key management and key generation, and these are used to generate
the symmetric keys which are going to be shared between different participants.
These keys will be used to encrypt the data and that data will be stored on top of the blockchain.
If somebody wants to validate the data, they are going to take the encrypted data and decrypt the same
data using the symmetric key which has been shared between the participants.
So this is one of the example for using the encrypting on chain data pattern within your blockchain
enterprise architecture.
The next design pattern under data management is the tokenization.
Now let's go and see the details about tokenization pattern.