All the smart contracts running on blockchain can be accessed and called by all the blockchain participants
and other smart contracts by default because there are no privileged users.
And in the case of public blockchains, every participant can join the network to access all the information
and code stored and running on blockchain.
A smart contract by default has no owner meaning that once deployed, the author of the Smart contract
has no special privilege on the smart contract.
A permissionless function can be triggered by unauthorized users accidentally.
Such a permissionless function becomes vulnerable for blockchain based applications.
For example, a permissionless function which is discovered in a smart contract library used by the
parity Multi-signature wallet cost the freezing of about 500 k ethers.
7% of the total smart contract on public Ethereum can be terminated without authority.
Embedded permission pattern provides a solution for the same smart contracts.
Use an embedded permission control to restrict access to the invocation of the functions defined in
the smart contracts.
There is an important point to notice for this design pattern.
This design pattern is related to more towards Ethereum and Bitcoin.
Blockchain Blockchain platforms like Corda and Hyperledger supports the membership service provider
functionality through which we can easily provide the permissions to the participants for calling the
functions over the smart contract.
The forces which led to the creation of embedded permission pattern is related to security.
The functions defined in the smart contracts should be called only by the authorized participants due
to the transparency of public blockchains.
All the smart contracts are also publicly available to everyone connecting to the Internet.
In contrast, in a conventional software system, the internal logic is normally not visible to the
end.
User's interaction with the software system is either through a user interface or API, where it is
possible to enforce access control policies.
The solution provided by embedded permission pattern is by adding the permission control to every smart
contract function to check permission for every caller that triggers the function defined in the smart
contract based on the blockchain addresses of the caller.
This can be done by checking the authorization of the caller before executing the logic of the function.
Unauthorized calls are rejected and the execution of the function terminated before reaching the core
logic of the function.
Some of the benefits provided by this design pattern are related to security as only the participants
and smart contracts that are authorized by the smart contract can call the corresponding function successfully.
Thus, security is maintained with the smart contract.
Another important benefit provided is related to secure authorization.
Authorization is implemented in a smart contract running on blockchain, which leverages the properties
provided by the blockchain.
There are also drawbacks related to embedded permission pattern.
One of the major drawback is related to cost.
On public blockchain extra code that implements the permission control mechanism also has additional
deployment and runtime cost.
In Ethereum, every function call requires the corresponding amount of gas to be provided with the function
call to make it executable.
Another drawback related to this pattern is about flexibility.
There is a lack of flexibility because such permissions are defined in the smart contract before its
deployment.
Therefore, they are difficult to change.
Even if we want to define the dynamic permissions, we need to design a mechanism which can support
dynamic granted and removal of permissions with our blockchain projects.
Some of the known implementations for embedded permission pattern is with the restrict access pattern,
which is defined with the solidity tutorial which uses modifier to restrict who can make modifications
to the state of the contract or call the functions of the contract.
Modifier is a mechanism to add a piece of code before the function to check certain conditions.
Modifier can make such restrictions highly readable.
In this image, you can see the embedded permission pattern in action.
On the left hand side, we have shown the on chain services and on the right hand side we have the option
services.
On chain is the smart contract where we are defining the permission, control and off chain are the
participants who are going to access the smart contract.
Let's say this smart contract is present with the blockchain project related to managers and developers,
and we have created a function where only managers are able to call up this function.
So whenever any user is calling up this function, there is a permission check to verify whether the
user is a manager or not.
If the user is not manager, then the logic is defined in a way that it will automatically exit the
function without performing the core operations.
If the participant is a manager only then the core operations will be performed by the function.
Similarly, if a developer calls the function, then they are only able to access the logic where they
are defined as the users who have authority to call upon the functions.
If they don't have the authority with the function defined under smart contract, they won't be able
to call the logic for those functions under the contract.
The next important design pattern under contract structural design patterns is factory pattern.
Now let's go and learn in detail about the factory contract pattern.