The decentralized world is growing exponentially in terms of user adoption. Companies are building hundreds of innovative dApps every year on Ethereum to fulfill various market demands. At the core of these dApps we have EVM compatible smart contracts, primarily written in Solidity. While learning the syntax and method of solidity is not difficult, but to build a scalable, accommodative and secure contract, one has to understand proper design patterns. Why Care About Design Patterns? To understand is to perceive patterns - Isaiah Berlin One of the major differences between a noob coder & a pro developer is the understanding of appropriate design patterns. These patterns are tried and tested solutions for common problems, and can become your most powerful tool. Compared to other verticals in software development, programming robust smart contracts is a sophisticated task. The distributed state machine runs your deployed program 24/7, giving access to the entire world, this is a double-edged sword. To make sure your business logic runs in a secure, reliable & deterministic way, one has to follow the best design practices. On a platform, where the smallest bug can cost you millions of dollars, would you dare to risk it? Solidity Authorization Patterns Though smart contracts are easily accessible over the network by anyone, that may not be the desired objective of a program. There may be certain functions that should be utilized only by certain user groups. Failing to properly handle that, may lead to unpredictable use-cases. Some objectives that authorization patterns can achieve: Allow execution of function post-authorization by a group of users Allow the execution of a transaction after caller authentication. Restrict features of a contract to the creator I’ve identified 4 types of authorization patterns. 1. Access Restriction Before execution of a function logic, there are certain conditions the caller must fulfill. These conditions can be related to the caller’s identity, input parameters, contract state etc. The function gets executed once all the requirements are met. Concept: In case the requirements aren’t met, the EVM handles the error by reverting the state, making no changes for the function call. If a similar restriction is needed across multiple functions, a guard check can be utilized with modifiers. Also, if you don’t want variables and functions to be available publicly, then protect their state data by opting for private visibility. Code Sample: pragma solidity ^ ; contract AccessRestriction { address treasury = msg.sender;
   uint256 creationTime = block.timestamp;
   uint256 minimumDonation; address winner; modifier onlyBefore(uint256 _time) { (block.timestamp < _time);
       _;
   } modifier onlyAfter(uint256 _time) { (block.timestamp > _time);
       _;
   }
 
   modifier isHigherDonation() { (msg.value > minimumDonation, );
       winner = msg.sender;
       minimumDonation = msg.value;
       _;
   } {
       payable(treasury).transfer(msg.value);
   } { winner;
   }
} // SPDX-License-Identifier: MIT 0.8 .0 /**
    * An incremental time-bound donation receiver
    */ @title /**
    * public variables in global, visible to everyone
    */ @dev public public public /**
    * private visibility of winner address
    */ @dev private /**********Modifier Blocks********/ /**
    * check if donation period has started
    */ @dev require /**
    * check if donation period has ended
    */ @dev require require "Please send higher amount" function sendDonation () external payable onlyBefore (creationTime + weeks) 1 isHigherDonation function revealHighestDonor () external view onlyAfter (creationTime + weeks) 1 returns (address) return 2. Multi Authorization There are situations when a transaction or function call might require the acknowledgement of multiple users. So if the pool of authorizers is of size X and we require a subset of Y no. of authorizations(where X≥Y), to execute the transaction. This is a useful approach where multisignature based payment transactions are involved.The challenge in this approach is that the members in the authorization group have to be predetermined and the minimum number of authorizers must be available during the time of execution for signing. Also in case of a key is compromised/lost, that authorizers account becomes useless. Concept: Code Sample: A simple implementation for multi authorization that I found interesting was written by . Checkout his SimpleMultisig implementation . Relatively most secure, audited reference and implementation can be found in the . It’s advisable not to use any multi-auth code without audit for such pattern implementations. Christian Lundkvist here Gnosis safe repo 3. Ownership & Role Based Access Control A deployed contract can have dedicated role-based operation & access, like in any traditional system. The roles allocation and administration can be done by enforcing ownership & role based access control rules. Role based access can help design feature specific modifiers that allow the dedicated group only. Concept: The standard implementation for this pattern is available in the OpenZeppelin . Code Sample: library 4. Off-Chain Secret Enabled Dynamic Authorization Unlike pre-authorized groups and role-based members, there can be situations where the authorization party is unknown for a given situation. Dynamic binding of an address isn't done by default, they need to be authorized in the first transaction/contract deployment, as typically the access control lists are predefined. For such a situation, we can generate an off-chain secret from the client side for the dedicated function purpose. This secret will be hashed(SHA-256) and registered on the contract. An operational binding will be made against the secret, so that any user who sends the transaction along with the secret as parameter, will be authorized. These secrets can be shared with a standard key-exchange protocol with the intended addresses. are useful for payment state channels, atomic swaps escrows. Also, the secrets are best for one transaction as verification on-chain will have it revealed. Concept: Hashlocks This is a simple secret registration that can be used along with any hashlocks. The secret is passed down to the contract for revelation and reference. For time lock events, the revelation block and expiration block can be compared. Code Sample: pragma solidity . ;
 
 
contract SecretRegistry {
   mapping(bytes32 => uint256) secretToBlock;
 
 
   event ; register public returns ( ) {
       bytes32 secrethash = sha256(abi.encode ); (secretToBlock > ) {
           return ;
       }
       secretToBlock = block.number;
       emit ;
       return ;
   } get public view returns (uint256) {
       return secretToBlock ;
   }
 
} // SPDX-License-Identifier: MIT 0.8 7 private SecretRevealed( , ) bytes32 indexed secrethash bytes32 secret /**
    * @dev Register the secret that's been used for validation
    */ function Secret( ) bytes32 secret bool Packed( ) secret if [ ] secrethash 0 false [ ] secrethash SecretRevealed( , ) secrethash secret true function RevealedSecretBlockHeight( ) bytes32 secrethash [ ] secrethash End Notes On-chain authorization through roles and ownership management has become a necessity for contract-based asset management. Also, be extremely careful with off-chain secrets and the way you share them. Try using one of these patterns in your next dApp. You can find the sample code snippets in this . repo Oh look, Obi-wan has something to say In the next part of this series, I’ll be talking about “Control Patterns”. References Used: Design Patterns for Smart Contracts in the Ethereum Ecosystem-Wohrer,Zdun CSIRO Research OpenZepplin Contract Docs Solidity: 0.8.9 documentation

Too Long; Didn't Read

Making security fun one episode at a time

Solidity Tutorial: Understanding Design Patterns [Part 1]

Too Long; Didn't Read

Tirtha Sarker

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Solidity Tutorial: Understanding Design Patterns [Part 1]

Too Long; Didn't Read

Tirtha Sarker

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES