solidity智能合约中有什么许可方法

介绍
在写智能合约时，我倾向于采取引导方式。即使它们旨在用于生产环境，我也使它们尽可能易于理解。我写的智能合约是可重用的，但是通常会针对每个特定的业务案例重新编写智能合约。
在本文中，我将讨论solidity智能合约中的三种许可方法。讨论这些方法的复杂性从高到低，这是您在项目中应考虑的顺序。我提供了可用于每种方法的代码。
本文假定您可以轻松地编写智能合约，并使用继承和传递合约地址等功能作为参数。
简单方法— ownable.sol
openzeppelin的ownable.sol合同必须是最重用的合同之一。它在77行中实现：
1. 断言某人是智能合约所有者的逻辑。
2. 限制函数调用以继承智能合约的所有者的逻辑。
3. 将所有权转移到其他地址的逻辑。
在编写智能合约时，您会经常从ownable继承。让我们来看一个如何使用ownable的示例。想象一下，您想在智能合约中保留一个地址列表，但是您想成为唯一可以添加更多地址的列表。可以将其视为您信任的人的注册表。您可以执行以下操作：
contract whitelist is ownable {
mapping （address =》 bool） members;
constructor（） public ownable（） {
}
function addmember（address _member）
public
onlyowner
{
members［_member］ = true;
}
}
从ownable继承并在您的ownable上调用其构造函数可确保将部署智能合约的地址注册为所有者。如果未通过注册为所有者的地址调用，则onlyowner修饰符会使函数恢复。
部署此智能合约后，只有您或您指定的人可以将新成员添加到其中的列表中。
尽管有用，但很多时候ownable还不够。在给定时间只有一个地址可以成为所有者，只有所有者可以决定谁可以成为新所有者，您只能检查您是否是所有者，而不是其他人。
中级复杂方法— whitelist.sol
whitelist.sol保留一个地址列表，然后可用于限制功能或任何其他目的。它在功能上与openzeppelin的roles.sol非常相似，尽管有一些重要差异。
whitelist.sol仅具有三个功能：
function ismember（address _member） public view returns（bool）;
function addmember（address _member） public onlyowner;
function removemember（address _member） public onlyowner;
例如通过该智能合约，您可以保留一份已批准的利益相关者列表，这些利益相关者可能是令牌转移的唯一接收者。您可以执行以下操作：
pragma solidity ^0.5.0;
import “@openzeppelin/contracts/token/erc20/erc20.sol”;
import “。./access/whitelist.sol”;
contract erc20whitelisted is erc20 {
whitelist whitelist;
constructor（address _whitelistaddress） public {
whitelist = whitelist（_whitelistaddress）;
}
function transfer（address account， uint256 amount） public {
require（whitelist.ismember（account）， “account not whitelisted.”）;
super._transfer（account， amount）;
}
}
在上面的示例中，您还可以使erc20whitelisted继承自erc20和whitelist。我很乐意讨论一些折衷方案。
简单的白名单功能可能非常强大。openzeppelin使用它们实现了许多erc20和erc721变体，并设法提供了超出我们大多数人所需的更多功能。在techhq，我们也仅使用白名单实施了cementdao。
但是有时候，白名单也会落空。您可能需要有多个所有者才能拥有白名单。或者您可能需要管理许多重叠的白名单。对于这些情况，我们具有分层的角色合约。
高级复杂方法-rbac.sol
我们开发了rbac.sol，旨在提供与现代共享系统一样的多用户功能。
1. 有些角色不过是地址组。
2. 组成员资格只能由某些管理员角色的成员修改。
3. 可以在运行时创建新角色。
4. 可以验证角色成员身份。
在低层，我们使用用户选择的bytes32参数来标识角色。通常，这些是可识别的短字符串，但是您也可以使用加密的值或地址。
角色本身是一组成员地址和admin角色的标识符。有趣的是，我们不需要将角色的标识符存储在其自己的结构中。
struct role {
bytes32 adminroleid;
mapping （address =》 bool） members;
}
现在有两种方法可以添加新角色并验证角色是否存在：
function roleexists（bytes32 _roleid） public view returns（bool）;
function addrole（bytes32 _roleid， bytes32 _adminroleid） public;
并且管理成员的功能是相同的，只是现在必须指定相关角色：
function ismember（address _member， bytes32 _roleid） public view returns（bool）;
function addmember（address _member， bytes32 _roleid） public;
function removemember（address _member， bytes32 _roleid） public;
仅当调用者属于我们要添加成员的角色的管理员角色时，addmember和removemember才会成功。
仅当调用者属于将管理所创建角色的角色时，addrole才会成功。
这些简单的规则将允许创建角色的层次结构，然后可将其用于实现具有不同权限级别或区域的复杂多用户平台。
进阶学习
为了进一步深入兔子洞，我建议从openzeppelin的这个问题开始。他们的代码库与我们的代码库没有什么不同，即使在我们选择采用其他方法的情况下，您也会发现大多数设计决策的透彻推理。他们在诸如erc20mintable之类的合约中使用roles是一个很好的例子，可以替代whitelist。
勇敢者的另一个资源是aragonos acl合约。界面一眼就可以看出他们决定走得更远：
function haspermission（address who， address where， bytes32 what，
bytes how） public view returns （bool）;
对于我们自己的@ hq20 / contracts包中的示例，我们使用本文中描述的三个级别的访问控制，因此，您也应该注意这一点。
结论
对于智能合约的实现，最好仅实现所需的复杂性，而无需再实现任何复杂性。在许可方面，存在三种不同的复杂性级别：
· 单用户
· 用户群
· 用户组的层次结构
您可以将ownable.sol用于单个用户允许的系统。您可以将@ openzeppelin/roles.sol或@ hq20/whitelist.sol用于需要组中权限用户的系统。对于需要组层次结构的系统，我们过去已成功使用@ hq20/rbac.sol。
您将有自己的要求，并且需要权衡取舍。了解每个实现背后的设计决策将使您可以使用现有合约，也可以修改合约以供自己使用。