区块链研究实验室|Solidity所有权和访问控制教程指南

  • 时间:
  • 浏览:49
  • 来源:区块链技术网

介 绍

在写智能合约时,我倾向于采取引导方式。即使它们旨在用于生产环境,我也使它们尽可能易于理解。我写的智能合约是可重用的,但是通常会针对每个特定的业务案例重新编写智能合约。

在本文中,我将讨论solidity智能合约中的三种许可方法。讨论这些方法的复杂性从高到低,这是您在项目中应考虑的顺序。 我提供了可用于每种方法的代码。

本文假定您可以轻松地编写智能合约,并使用继承和传递合约地址等功能作为参数。

简单方法— Ownable.sol

OpenZeppelin的Ownable.sol合同必须是最重用的合同之一。它在77行中实现:

1. 断言某人是智能合约所有者的逻辑。2. 限制函数调用以继承智能合约的所有者的逻辑。3. 将所有权转移到其他地址的逻辑。

在编写智能合约时,您会经常从Ownable继承。让我们来看一个如何使用Ownable的示例。想象一下,您想在智能合约中保留一个地址列表,但是您想成为唯一可以添加更多地址的列表。可以将其视为您信任的人的注册表。您可以执行以下操作:

contractWhitelistisOwnable{mapping(address=>bool)members;constructor()publicOwnable(){}functionaddMember(address_member)publiconlyOwner{members[_member]=true;}}从Ownable继承并在您的Ownable上调用其构造函数可确保将部署智能合约的地址注册为所有者。如果未通过注册为所有者的地址调用,则onlyOwner修饰符会使函数恢复。

部署此智能合约后,只有您或您指定的人可以将新成员添加到其中的列表中。

尽管有用,但很多时候Ownable还不够。 在给定时间只有一个地址可以成为所有者,只有所有者可以决定谁可以成为新所有者,您只能检查您是否是所有者,而不是其他人。

中级复杂方法— Whitelist.sol

Whitelist.sol保留一个地址列表,然后可用于限制功能或任何其他目的。它在功能上与OpenZeppelin的Roles.sol非常相似,尽管有一些重要差异。

Whitelist.sol仅具有三个功能:

functionisMember(address_member)publicviewreturns(bool);functionaddMember(address_member)publiconlyOwner;functionremoveMember(address_member)publiconlyOwner;例如通过该智能合约,您可以保留一份已批准的利益相关者列表,这些利益相关者可能是令牌转移的唯一接收者。 您可以执行以下操作:

pragmasolidity^0.5.0;import"@openzeppelin/contracts/token/ERC20/ERC20.sol";import"../access/Whitelist.sol";contractERC20WhitelistedisERC20{Whitelistwhitelist;constructor(address_whitelistAddress)public{whitelist=Whitelist(_whitelistAddress);}functiontransfer(addressaccount,uint256amount)public{require(whitelist.isMember(account),"Accountnotwhitelisted.");super._transfer(account,amount);}}在上面的示例中,您还可以使ERC20Whitelisted继承自ERC20和Whitelist。 我很乐意讨论一些折衷方案。

简单的白名单功能可能非常强大。OpenZeppelin使用它们实现了许多ERC20和ERC721变体,并设法提供了超出我们大多数人所需的更多功能。在TechHQ,我们也仅使用白名单实施了CementDAO。

但是有时候,白名单也会落空。您可能需要有多个所有者才能拥有白名单。或者您可能需要管理许多重叠的白名单。对于这些情况,我们具有分层的角色合约。

高级复杂方法-RBAC.sol

我们开发了RBAC.sol,旨在提供与现代共享系统一样的多用户功能。

1. 有些角色不过是地址组。2. 组成员资格只能由某些管理员角色的成员修改。3. 可以在运行时创建新角色。4. 可以验证角色成员身份。

在低层,我们使用用户选择的bytes32参数来标识角色。 通常,这些是可识别的短字符串,但是您也可以使用加密的值或地址。

角色本身是一组成员地址和admin角色的标识符。 有趣的是,我们不需要将角色的标识符存储在其自己的结构中。

structRole{bytes32adminRoleId;mapping(address=>bool)members;}

现在有两种方法可以添加新角色并验证角色是否存在:

functionroleExists(bytes32_roleId)publicviewreturns(bool);functionaddRole(bytes32_roleId,bytes32_adminRoleId)public;并且管理成员的功能是相同的,只是现在必须指定相关角色:

functionisMember(address_member,bytes32_roleId)publicviewreturns(bool);functionaddMember(address_member,bytes32_roleId)public;functionremoveMember(address_member,bytes32_roleId)public;仅当调用者属于我们要添加成员的角色的管理员角色时,addMember和removeMember才会成功。

仅当调用者属于将管理所创建角色的角色时,addRole才会成功。

这些简单的规则将允许创建角色的层次结构,然后可将其用于实现具有不同权限级别或区域的复杂多用户平台。

进阶学习

为了进一步深入兔子洞,我建议从OpenZeppelin的这个问题开始。他们的代码库与我们的代码库没有什么不同,即使在我们选择采用其他方法的情况下,您也会发现大多数设计决策的透彻推理。他们在诸如ERC20Mintable之类的合约中使用Roles是一个很好的例子,可以替代Whitelist。

勇敢者的另一个资源是AragonOS ACL合约。界面一眼就可以看出他们决定走得更远:

functionhasPermission(addresswho,addresswhere,bytes32what,byteshow)publicviewreturns(bool);对于我们自己的@ hq20 / contracts包中的示例,我们使用本文中描述的三个级别的访问控制,因此,您也应该注意这一点。

结 论

对于智能合约的实现,最好仅实现所需的复杂性,而无需再实现任何复杂性。 在许可方面,存在三种不同的复杂性级别:

单用户

用户群

用户组的层次结构

您可以将Ownable.sol用于单个用户允许的系统。 您可以将@ openzeppelin/Roles.sol或@ hq20/Whitelist.sol用于需要组中权限用户的系统。对于需要组层次结构的系统,我们过去已成功使用@ hq20/RBAC.sol。

您将有自己的要求,并且需要权衡取舍。了解每个实现背后的设计决策将使您可以使用现有合约,也可以修改合约以供自己使用。

猜你喜欢

solidity编程风格

Solidity编程风格的几条建议。

2021-12-31

如何部署Solidity智能合约到Solana

什么是Solana,你如何将Solidity智能合约部署到Solana?

2021-12-28

区块链红利吃饱后,这个巨头又想"征服"元宇宙?

据12月26日消息,百度与英伟达(NVIDIA)已达成协议,双方合作共建AI元宇宙。另外,在今日举行的百度AI开发者大会上,英伟达全球副总裁暨亚太区总裁 Raymond Teh将受邀出席,并发表主题演讲。

2021-12-27

2021年,区块链股权融资发生了怎么样的演变

过去一年,区块链行业融资井喷,在科技领域中独树一帜,A16z、红杉、老虎基金等等这些顶级机构在 2021 年的区块链行业肆意驰骋,在 DeFi、NFT、Metaverse 等领域扶持了一众创业项目。

2021-12-23

两个元宇宙的世界观,以及和区块链的关系

“元宇宙”这个名词音好听但义很难传达准确,想要更准确地理解义,取名为平行宇宙、竞争宇宙、山寨宇宙,更好。对应的,我们现在肉身所处的宇宙,我们称之为“肉身宇宙”。

2021-12-22