首页 > 编程学习 > BSN-DDC 合约研究01---权限合约

BSN-DDC 合约研究01---权限合约

发布时间:2022/10/1 7:14:24
权限功能合约代码主要是: IAuthority.sol、 Authority.sol文件, 本文从以下3个方面进行分析研究:
数据结构分析、功能模块分析、合约调用流程分析
1 数据结构分析
1.1 理想的数据机构
要想研究清楚权限合约,必须理清楚权限控制的设计思想和数据结构,这样才能真正理解合约代码这样写的背后意图。
最普通的设计思想是“控制什么人能调用合约的什么方法”,拆解成三步骤:
  1. 划分BSN平台上的各方角色,
  2. 划分合约中的函数访问权限,
  3. 执行合约函数时检验调用者的权限
上面的思想可以用下图表述:
使用3层Map数据结构能完美表达出上图的映射关系,最终map的值表示权限有无。
1.2 BSN的数据结构
BSN的权限合约看来看去,我终于知道了BSN的思想意图。没有使用3层map容器,把合约-函数的映射修改成了复杂的数组+映射。
优缺点:大大增加了结构复杂度和代码数量, 如果用3层map就能大大缩减代码量。
2 功能分析
2.1 角色定义、权限
       用以进行对某个账户进行角色判定的逻辑实现,权限角色分为三种:运营方、 平台方、终端用户,不同角色拥有的权限各不相同,一个现实中的实体可持有多套 链账户用以对应 DDC 中的多个角色,如 BSN 可作为运营方存在于 DDC 中,三种 角色分别为下级角色的 leaderAddress,可管理该下级账户。
 用户方权限:经与平台方绑定以后可进行整个 DDC 的生命周期的管理操作。
 平台方权限:包含 DDC 的整个生命周期的管理以及本平台内用户方账户的增 删改查操作。
 运营方权限:包含用户方账户及权限、平台方账户及权限以及运营方账户和 权限的增删改查操作,同时对 DDC 相关流转操作进行定价(DDC 发行、转移 等操作需扣除相应的费用)以及对平台方账户及用户方账户的充提操作。
enum Role {
        Operator,
        PlatformManager,
        Consumer
    }
struct AccountInfo {
        // @dev The user's private key address.  DDC 账户对应的 DID信息(普通用户可为空)
        string accountDID;
        // @dev The user's account name.   账户名称
        string accountName;
        // @dev The user's identity role.
        Role accountRole;
        /* @dev The upper-level manager of the user. This value is required only for Consumer.
         * For ordinary users Consumer, this address is the associated platform manager PlatformManager.
         */
        string leaderDID;   //用户才有上级管理员
        // @dev The current status of the account, only the platform can operate this status.
        State platformState;
        // @dev The current status of the account, only the operator can operate this status.
        State operatorState;
        // @dev Redundant field.
        string field;
    }
enum State {
        Frozen,
        Active
    }
2 账户增删改查
 // @dev Used to store account information for different roles.
    mapping(address => AccountInfo) private _accountsInfo;
账户信息保存在 _accountsInfo 这个Map容器中,key是账户地址
功能1: 添加账户
添加运营账户 addOperator,合约owner才能调用,也就是BSN方控制着运营者账户。
平台方添加账户 addAccountByPlatform, 这个函数在手册中有,代码中被屏蔽。默认把调用者(平台方)作为上级
运营者添加账户 addAccountByOperator, 运营者添加 用户账户,
   没有指定上级就是平台方,默认把调用者(运营方)作为上级。
   指定上级就是普通用户方。
功能2:查询账户,检验账户
getAccount, 根据账户地址返回AccountInfo元组数据,外部函数
_getAccount, 根据账户地址返回AccountInfo结构体,内部函数
checkAvailableAndRole 检查账户是否是指定角色,账户应该存在、激活
accountAvailable  检查账户应该存在、激活
功能3: 修改账户
updateAccountState  修改账户的状态, 只有上级领导和运营者才能调用该函数,内部把调用者作为上级领导。
    调用者是平台方: 修改用户的平台状态
    调用者是运营方: 检查参数changePlatformState,决定修改的是平台状态、运营状态
3 授权访问合约函数
// @dev Account DID authorization collection.  平台授权
    mapping(string => mapping(string => bool)) _didApprovals;
功能4: 函数授权:添加、删除 、读取 、校验权限
addFunction  运营方增加角色可调用的方法
delFunction  运营方删除角色可调用的方法
getFunctions 读取角色+合约的可调用函数数组
hasFunctionPermission : 指定账户+合约的函数校验
4 跨平台授权与检验
功能5: 跨平台授权
crossPlatformApproval   运营方通过调用该 API 进行跨平台之间的账户授权
  调用者必须是运营方。
  from、to两者必须都是平台方,不能相同。
  map中存储的结果是 true/false, 表示有授权/无授权
  
onePlatformCheck  查询两个账户是否属于同平台账户。
   a 都是平台角色, 两者的上级id、账户id都相同
   b acc1是平台角色,acc2是用户角色: acc1是acc2的上级。
   c acc1是用户角色,acc2是平台角色: acc2是acc1的上级。
   d 都是用户角色, 两者的上级id相同。
   
crossPlatformCheck  查询两个账户是否属于不同平台账户
   a 都是平台角色, 两者的上级id相同, from给to授权。 这种情况实际属于同一平台。
   b from是平台角色,to是用户角色: from为to的上级授权。
   c from是用户角色,to是平台角色: from为to的上级授权。
   d 都是用户角色,from的上级为to的上级授权
   
猜测:  BSN的每条链是运营方, 链上的项目方、发行方、开发方作为平台方, 消费者是用户方。
  平台方控制用户的状态(激活、冻结)
  运营方控制 平台方、用户的状态(激活、冻结)
3 合约调用流程分析
功能6: NFT跨平台转移,允许从一个项目平台转到其他项目平台。
调用流程:
  ERC721、ERC1155合约   转账函数 transferFrom、 safeTransferFrom
 --->       检查项: _isOnePlatform、_isCrossPlatformApproval
      ---> Authority.sol合约      onePlatformCheck、 crossPlatformCheck
功能7: 调用合约铸币、转移、授权等函数进行权限检查
在这些关键函数的第一行就检查调用者是否具备调用权限,整体流程图如下:
approve()
   ---> _requireSenderHasFuncPermission()
       --->  _authorityProxy.hasFunctionPermission( _msgSender(),  address(this),  msg.sig )
           --->  return  _funcAclList[accountInfo.accountRole][contractIdx].sigIndexList[ sig ] > 0
                    

Copyright © 2010-2022 mfbz.cn 版权所有 |关于我们| 联系方式|豫ICP备15888888号