2.29 DAppSys Libraries

We now move on to a different set of libraries provided by the DAppSys teams at DappHub. These are used commonly in smart contracts as an alternative to the OpenZeppelin libraries that we have discussed.

DSProxy

The first one is the DAppSys DSProxy. This implements a simple Proxy that is deployed as a standalone contract and can be used by the Owner to execute the code the logic that is implemented in the implementation contract.

The user would pass in the contract byte code along with the function call data, the call data remember that it specifies the function selector of the function to be called along with the arguments for that function. This library provides a way for the user to both create the implementation contract using the bytecode provided, then delegating the call, to that contract, the specific function, the arguments as specified in the call data. There are associated libraries related to DSProxy that help implement a factory contract as well as some caching mechanism.

DSMath

DAppSys provides a DSMath library that provides math parameters for arithmetic functions. The first set of primitives are arithmetic functions that can be safely used without the risk of underflow and overflow. These are equivalent of the SafeMath library from OpenZeppelin. Here we can find the add , sub , mul functions. There is no div function because the Solidity compiler has built-in divide by zero checking. DSMath also provides support for fixed-point math.

It introduces two new types:

• The Wad type: for decimal numbers with 18 digits of precision.

• The Ray type: for decimal numbers with 27 digits of precision.

There are different functions that help one operate on the Wad and Ray types.

DSAuth

The DSAuth library provides support for developers to implement an authorization pattern that is completely separate from the application logic.

It does so by providing an auth modifier that can be applied to different functions and internally this modifier calls the isAuthorized() function that checks, if the msg.sender is either the owner of this contract or the contract itself. This is the default functionality.

This can also be specified to check, if the msg.sender has been granted permission by a specified authority.

DSGuard

The DSGuard library helps implementing an access control list (ACL). This is a combination of a source address destination address and a function signature.

This library can be used as the authority that we just discussed in the context of the DSAuth library. This implements a function canCall() that looks up the access control list and determines if the source address can call the function specified by the function signature at the destination address.

So it's a combination of the source, destination and the signature that determines the value of the bool that's either true or false: [src][dst][sig] => boolean.

When used as an authority by DSAuth, the source refers to the msg.sender, the destination is the contract that includes this library, the signature refers to the function signature.

DSRoles

The DSRoles library provides support for implementing role-based access control (this is something we discussed in the context of OpenZeppelin's AccessControl library as well). In this case it implements different access control lists, that specify roles and associated capabilities. It provides a canCall() function that determines, if a user is allowed to call a function at a particular address by looking up the roles and capabilities defined in the access control list.

RBAC is implemented via mechanisms, there is a concept of root users, who are users allowed to call any function regardless of what roles and capabilities are defined for that function. There's a concept of public capabilities that are global capabilities that apply to all users. Finally, there are role specific capabilities that are applied when the user is not the root user and the capability is not a public capability.