Hey, everyone.
Welcome back to the course.
So till now, we have discussed three major classification for design patterns.
The fourth important design pattern classification is contract structural patterns.
The contract structure patterns are more related to the smart contracts and how you are going to structure
and design the integration of smart contracts with your legacy or enterprise applications.
Essentially, smart contracts are programs running on blockchain.
Thus, some of the existing design patterns and programming principles for conventional software environments
are also applicable to smart contracts.
If a public blockchain is used, the structural design of the smart contract has large impact on the
execution cost.
The cost of deploying a smart contract depends on the size of the smart contract because the code is
stored on the blockchain resulting in a data storage fee that is proportional to the size of the smart
contract.
Thus, a structural design with more lines of compiled code costs more money.
A private or a consortium blockchain does not necessarily have currency.
Therefore, monetary cost is not a typical for such blockchain solutions.
However, blockchain size is still a design concern because the total size of the blockchain keeps on
growing as more blocks are appended to it and no block can ever be detached from it.
And every participant stores the full replica of blockchain.
Besides, different structural design of smart contracts may affect performance because more or less
transactions may be required to achieve a function contract.
Structural patterns help you to tackle the problems related to upgradability and cost associated with
the deployment of smart contracts.
Now let's go and study in detail about different contract structural patterns.
The first contract.
Structural pattern is about contract registry.
Smart contracts deployed on blockchain cannot be upgraded because the code of the smart contract are
stored immutably on top of blockchain.
But as in any software application, blockchain based applications also require to be upgraded to new
versions to do so.
The on chain functions defined in smart contracts need to be updated to fix the bugs as well as fulfill
new requirements and contract registry pattern.
Help you design the contract in such a way that the upgradability can be factored inside your applications.
Some of the forces which led to the creation of contract registry pattern.
The first one is immutability.
Every bit of data, including deployed smart contracts stored on blockchain are immutable.
So we need a design pattern to establish that.
How we are going to work with the immutability of blockchain and still provide the upgradation of the
functionalities.
The second one is upgradability.
There is a fundamental need to upgrade all but short lived application and their smart contracts over
time and contract registry pattern is designed to achieve the same.
The third force is contract identifiers.
The identifier of a smart contract on blockchain platforms like Ethereum is more or less a hexadecimal
address which is not human readable.
And with contract registry pattern, we can create a human readable identifier for the smart contracts
which can be mapped to the hexadecimal address.
The solution provided by the contract registry pattern is to maintain an on chain registry contract,
which is used to map between user defined symbolic names and the blockchain addresses of the registered
contracts.
The address of the registry contracts need to be advertised off chain.
The creator of the contract can register the name and the address of the new contract to the registry
contract and after the new contract being deployed, the invoker of the registered contract retrieves
the latest version of the new Smart contract from the registry contract.
The corresponding functions provided by the registered contract can be upgraded by replacing the address
of the old version contract in the registry.
Contract with the address of the new version without breaking the dependency between the upgraded new
contract and other smart contracts that depends upon its functions.
The address of a contract is stored as a variable inside the registry contract.
The value of contract variables can be updated.
The registry contract can have a permission control module to maintain the writing permissions to Not
only that, we can also maintain the previous values of the variables to maintain auditability with
the registered contract.
So in a way we are creating a mapping table within the smart contract definition language where one
of the smart contract will act as a mapping table and store the key value pairs for other contracts,
and we can update the addresses of other contracts regarding the mapping contract, which we are also
calling as the registered contract.
The benefits provided by the contract registry pattern are related to human readability.
As the registry contract maintains, a mapping between human readable names and the hexadecimal addresses
of the smart contracts, a human readable form of smart contracts names is desired.
For example, if you want to expose the smart contract to a user interface, even the developers might
require the human readable name to map the contract with the registered contract on top of blockchain.
The second benefit provided by contract registry pattern is related to a constant contract name.
The smart contract associated with the registry name can be updated without changing its name.
In this way, the dependency is relying on the name of the smart contract.
Do not get broken.
The third benefit we can get from such a design pattern is related to transparent operability.
The smart contract associated with a registered name could be replaced by a new version without breaking
the dependencies based on the human readable name.
Another benefit provided by such a design pattern is to maintain the version control.
Version control can be integrated in the registry contract as well as to allow a lookup based on the
name and version of the smart contract.
Old versions of a smart contract that are no longer needed can be flagged within the version control.
There are also some drawbacks related to contract registry pattern.
One of the major drawbacks related to this pattern is about limited operability.
Although we have taken in the factor that now you are easily able to upgrade the new contracts which
you are designing and you can store the mapping inside the registry contract.
Still, the upgradability is limited because the functions defined in the smart contract are called
by other contracts.
Although the implementation of the function can be upgraded, the interface that is the function signature
cannot be modified without breaking the link to dependent smart contracts.
Another drawback is related to cost.
There is an additional cost to maintain a registry that contains the mapping between the contract names
and their addresses.
Furthermore, all the inter contract function calls require a registry lookup to find the latest version
of the smart contracts to be invoked.
Some of the known implementations for contract registry pattern is with Inez.
Inez is a name service on Ethereum Blockchain, which is implemented as smart contracts and maintains
a mapping between both smart contracts on chain and resources, off chain and simple, human readable
names.
Inez can be viewed as a contract registry built in a blockchain platform which is accessible to everyone.
A blockchain based application can also maintain a separate registry contract for the application.
Another known implementation for contract registry pattern is with Regis.
Regis is an in browser application that makes it easy to build, deploy and manage registries as smart
contracts on Ethereum blockchain.
It allows user defined key value pairs and it can also be used to create a contract registry.
In this image, you can see the contract registry pattern in action.
On the left hand side, we have shown the on chain activities and on the right hand side we have shown
the off chain inside contract registry pattern.
Everything is happening on chain because we are creating a mapping contract which is also known as registry
contract over the blockchain itself.
We don't have any event or activity happening off chain for this pattern.
As you can see that we have a registry contract maintain where we are creating a key value pairs for
name and address of all the contracts which are part of our blockchain projects.
So in this way we are creating a mapping and a upgradable functionality with the registry contract where
we can easily upgrade just the address of the contract to a newer version and we will have much more
functionality and flexibility available to us.
The next important design pattern under contract structural patterns is data contract design pattern.
Now let's go and see the details about data contract design pattern.