Hey, everyone, welcome back to the course.
So now we have gone through two different categories of the patterns.
The first one was external world patterns, which was dealing with the external services which are going
to interact with the blockchain applications.
The second one was data management patterns, which deals with how you are going to manage the data
within your projects.
The third category of the patterns which we are going to learn now is about security patterns.
Security patterns are used to deal with the security aspects of the blockchain applications.
So the first pattern under security patterns is multiple authorization pattern In blockchain based applications.
Activities might need to be authorized by multiple blockchain addresses.
For example, a monetary transaction may require authorization from multiple blockchain addresses.
The major problem arises that the actual addresses that authorize an activity might not be able to be
decided due to the availability of the authorities for such a problem.
Statement Multiple authorization pattern provides a set of blockchain addresses which can authorize
a transaction as predefined.
Only the subset of the addresses is required to authorize the transaction.
Instead of using all the addresses, there are few forces which led to the creation of multiple authorization
pattern.
The first one is flexibility.
The actual authorities who authorize the transaction can be formed of a set of predefined authorities.
So this flexibility can be used with multiple authorization pattern.
The second one is the tolerance or loss of private keys.
Authentication on blockchain uses digital signature.
However, blockchain does not offer any mechanism to recover a lost or a compromised private key, losing
a key results in a permanent loss of control over the account and potentially smart contracts that refer
to it.
But with multiple authorization pattern, you can have an approach where multiple addresses are assigned
to a transaction, and only one of the address associated Private Key is used to sign the transaction.
Even though if you lose one of the private key, you can still sign the transaction with the other private
key.
The solution for such a problem to provide multiple addresses for the authentication of transaction
is provided by multiple authorization pattern.
Multiple authorization pattern defines that it would be more dynamic if the set of blockchain addresses
for authorization are not decided before the corresponding transaction being submitted into the blockchain
network or the corresponding smart contract being deployed on blockchain.
On the Bitcoin blockchain, a multi-signature mechanism can be used to require more than one private
key to authorize a Bitcoin transaction in Ethereum.
Smart contract can mimic multiple signature mechanism more flexibly.
An M of n multisignature can be used to define that m out of n private keys are required to authorize
the transaction.
M is the threshold of authorization.
This is on chain mechanism enables more flexible binding of authorities.
For example, if you are working in a big corporation and you have five different managers, so your
multi signatures can authorize in a way that out of five, at least two managers need to sign the transaction.
Only then the transaction can be uploaded on top of the blockchain.
The benefits offered by this pattern are related to flexibility.
This pattern enables flexible binding of authorities, but depends on the ability of the authorities
when the activity is being processed.
The second benefit provided by this pattern is related to lost key tolerance, where one participant
can own more than one blockchain address to reduce the risk of losing control over the smart contracts
due to the lost private key.
There could be a function that can update the list of allowed authorities and the threshold of the authorization.
There are also few drawbacks related to this design pattern.
The first one is related to about that.
We are going to list authorities as predefined.
Although the pattern enables flexible binding, all the possible authorities still need to be known
in advance of any decision or update.
The second drawback related to this design pattern is about lost key.
Instead of now securing one single private key, we need to secure at least m private keys among the
n private keys which will be used to sign the transaction.
Another drawback related to this design pattern is about cost.
If a public blockchain is used, updating the list of authorities costs money, as does deploying the
logic for multiple authorities.
Besides its cost more to store multiple addresses as the possible authorities, then storing only one
sum of the known implementations for multiple authorization pattern is with Bitcoin, where we use Multi-signature
mechanism to provide M addresses out of N addresses.
Another known implementation is with Ethereum blockchain where we provision multi-signature wallet written
in solidity, which is running on Ethereum blockchain and is also used with Dapp browser missed.
In this image, you can see the multiple authorization pattern in action.
On the left hand side, we have described the on chain activities, which is the blockchain itself.
On the right hand side, we have the option activities, which are the participants.
Here, if we are going to confirm a transaction or sign a transaction, you can see that we have three
private keys or three participants here on the right hand side.
And out of these three participants, only two participants need to sign the transaction to confirm
the transaction over the blockchain.
This makes our solution much more flexible.
Also, it provides us a way to safeguard our private keys because now we have multiple private keys
available and we can store in a way that even if one of the private key get lost, still the other two
private keys can be used to sign the transaction.
The next design pattern under security is off chain secret enabled dynamic authorization design pattern.
Now let's go and see the details about off chain secret enabled dynamic authorization pattern.