吸收了一些新论文的想法，对原访问控制系统功能做了补充，添加了恶意行为检测（或者称为动态访问控制），目的是减少恶意行为，增加合法行为在区块链中得到确认的几率。所有调整总结查看 附录I。

1. 背景与相关工作

基于智能合约实现的系统中，恶意的行为（如短时间频繁的调用）可能产生过量的交易，从而降低合法交易被区块链收集的概率，或者使得确认时间延长，而区块链本身无法对这类行为做出规避。初步的思路是吸收动态访问控制的思想，基于操作的严重性、资源的敏感性、用户的访问历史记录等信息，对决策做出动态的调整 ，从而完成对恶意行为的惩罚和合法行为的奖励。

目前，只有少数 Blockchain-IoT 访问控制的论文结合了动态访问控制的思想1 2，可以作为该方向的参考。

我们计划采用信誉机制来解决恶意行为处理问题，该思路来自于Huang等3的论文，他们在论文中设计了一个基于信誉的 PoW 共识机制来取得效率与安全的平衡。首先为节点 $i$ 设置一个信誉值属性 $Cr_i$，该值会随着节点的行为实时的变化。合法的行为，如遵守系统规则发送交易，会随着时间的推移使信誉值逐步增加，与之相反，节点产生异常行为会导致信誉值下降。PoW中的难度值会根据每个节点的信誉值自调整，信誉值越低，运行 PoW 算法花费的时间越长。因此，诚实的节点消耗的资源更少，恶意节点攻击所需的花费更多。

在该论文中，作者定义的攻击模型有两个（即两种恶意行为）：

  1. Lazy Tips：懒惰的节点指那些总是验证固定的以前的交易，而不去验证最新的交易的节点。例如，恶意实体可以通过发出许多验证固定交易对的交易来人为地扩大提示tips的数量。这会使其它节点有更高的概率选中这些提示，而丢弃属于诚实节点的提示
  2. Double-spending：通过在前一次花费被验证之前提交多个交易，恶意节点希望将一枚代币花费两次或多次，这就是双花问题。尽管这样的行为会被共识机制检测到并撤销，但它降低了系统效率，因为其它相关的交易也会被撤销重新执行。

更具体的信誉值增减算法的设计，可以参考 附录II。不过这里作者设计的算法与 PoW 结合程度较深，对恶意行为的惩罚依赖于难度值的调整，无法在 BFT 类共识算法中继续得到使用，同时，对于智能合约中由于函数调用产生的一些恶意行为，也难以阻止。

Mohammed等2 在 RBAC 中结合了信誉机制来消除恶意行为的影响，但该方案依赖于一个中心化的证书权威，恶意行为主要指的是证书的不一致和证书过期。

其它参考文献待补充…

2. 方案

第一步是调整整个合约系统的架构，这里会详细介绍调整后的架构是怎么样的，以及每种合约所调整的功能，最后介绍所设计的信誉算法。

2.1 合约架构

将原系统中的注册合约（Register Contract, RC）更名为管理合约（Management Contract, MC），将原系统中的判决合约（Judge Contract, JC）更名为信誉合约（Reputation Contract）。因此，当前系统中的三种合约分别为：管理合约 MC，访问控制合约 ACC 和信誉合约 RC，这几种合约间的调用关系如下图

合约架构
合约架构

管理合约 MC 负责管理其它合约和管理设备属性。ACC 在进行访问控制决策时，会首先从 MC 获取访问者的相关属性，然后和定义的策略进行匹配。在 MC 中注册的所有设备都新增了一个endBBN 固定属性，用于设置终止阻塞的区块号，该字段只能被信誉合约更新，用户和管理者都无法改动。

访问控制合约 ACC 负责管理 object 属性、访问控制策略和执行访问控制决策。对 ACC 相关函数的调用，其行为日志会提交给 RC 供分析。在执行访问控制决策时，会首先从 MC 读取访问者的 endBBN 字段，查看是否大于当前区块号，如果大于则直接阻止该请求，不会进入区块链网络。

信誉合约 RC 负责根据 ACC 提交的行为记录计算信誉函数的值，并根据该值计算阻塞区块数，最后调用 MC 的相关函数更新对应设备的endBBN 字段，做出惩罚。

之前有一个版本是使用时间作为惩罚的，但是 Solidity 提供的时间戳实际上是区块被挖掘时的时间戳，和区块号无异，反而区块号更能表示这种线性关系，所以最后选择使用区块数量作为惩罚标准。

2.2 新添加的功能

我们为访问控制系统（Access Control system, ACS）增加了两个新的功能，主要为了完善原系统没有考虑到的问题。

首先是策略冲突的解决机制，指的是当定义的众多策略条目产生冲突时，如何决定最终的结果。我们在 ACC 中为设备增加了一个算法（algorithm）字段，该字段可选的值有两个：denyoverrides 和 allowoverrides。前者表示只要有一条策略结果为 deny，最终的结果就是 deny，后者表示只要有一条策略结果为 allow，最终的结果就是 allow。在核心的访问控制决策函数中针对算法字段做出了相应的处理。该思路来自4，我们先前的方案相当于默认使用 allowoverrides 冲突解决机制。

其次是无策略定义时的处理方式。依靠管理员定义策略的一个问题是，总有可能出现遗漏，比如说，针对设备的某个资源没有定义策略，那么访问控制决策时就没有凭借。在之前的决策逻辑中，这种情况会被直接算作访问通过，然后给予授权，显然，这种处理方式是不合理的。我们在决策逻辑中，处理 deny 和 allow 两种结果，额外增加了一种名为 NotDefine 的结果，用作标识这种没有定义策略的情况。

2.3 恶意行为检测与处理

根据背景部分所述，为了处理区块链本身无法抵御的一些恶意行为，在吞吐量有限的情况下尽可能为合法行为提供更高的打包机会，我们添加了恶意行为检测和处理机制。采用信誉算法的原因是，不同的恶意行为严重程度不一致，我们不仅需要完成惩罚和奖励的基本功能，也需要提供一定的容忍。

3.3.1 信誉算法

设备 $i$ 的信誉值由两部分组成，合法行为的正面影响和恶意行为的负面影响。公式如下，其中，$Cr_i^P$ 为正面影响部分，$Cr_i^N$ 为负面影响部分，$\lambda_1$ 和 $\lambda_2$ 分别是它们的权重。 $$ Cr_i = \lambda_1Cr_i^P - \lambda_2Cr_i^N $$ 信誉值的负面影响部分 $Cr_i^N$ 也可以称为惩罚函数，其值与历史恶意行为的数量和类型（历史行为记录和操作严重性）有关，每个恶意行为的影响随着时间的推移逐渐减小，但不可以变为 0，具体的函数如下 $$ Cr_i^N = \sum_{k=0}^{m_i-1} \frac{\alpha_k }{m_i-k} $$ 其中 $m_i$ 表示设备 $i$ 当前的恶意行为总数，$k$ 表示历史恶意行为的索引顺序，$\alpha_k$ 表示第 $k$ 个恶意行为的惩罚系数，该系数在 0-1 内取值。$k$ 的最大取值为 $m_i-1$，因此分母最小值为 1，不会导致值过大；$k$ 从 0 开始取值是为了保证所有的历史恶意行为都会对当前结果产生影响。恶意行为种类包括如下三种，这里两种恶意行为不可能同时发生，因为策略检测失败必然导致设备受处罚，从而无法触发短时间高密度的请求，但以后添加其它恶意行为需要重新考虑。

  1. 短时间高密集的请求，行为 ID 为 1；
  2. 策略检查失败（非法访问），行为 ID 为 2；
  3. 重要策略检查失败。我们可以标识某条策略条目为重要，当违反该策略时，会作为恶意行为进行记录，比如，某个设备的访问目标一直都是固定的，突然发生了改变，说明可能是恶意的，又或者访问者的位置突然发生了改变等。这一类恶意行为优先级高于普通的策略检查失败（非法访问），计算时权重更高，行为 ID 为 3。

信誉值的正面影响部分 $Cr_i^P$ 可以称为奖励函数，其值与合法行为数量正相关，定义如下 $$ Cr_i^P = min({Cr_i^P}\text{max}, (l_i-k_1)\omega) $$ 其中，${Cr_i^P}_{max}$ 是 $Cr_i^P$ 的上界，防止奖励无限制积累，$l_i$ 为设备 $i$ 的合法行为总数，$k_1$ 是上一次做出惩罚时计算的最后一个合法行为索引，因此，$l_i-k_1$ 其实相当于当前计算奖励值的一个滑动窗口大小。合法的行为只有一种：访问通过，$\omega$ 是合法行为的权重。

每一次行为提交都会更新行为列表，合法行为添加到合法行为列表，恶意行为添加到恶意行为列表，然后分别计算惩罚函数和奖励函数的值并得到最终的信誉值。当信誉值小于 0 时，会计算阻塞区块数并更新 MC 中设备对应的终止阻塞区块号属性， 同时更新计算使用的最后一个合法行为索引，当下次统计合法行为时，该索引之前的合法行为将不会被再次计算。与之相对的，恶意行为记录永远不会清空，虽然它们产生的影响随着时间的推移变小，但不可能消失，因此每次惩罚函数计算都会读取所有恶意行为。

惩罚手段是阻塞设备的访问请求，意思是计算一个阻塞区块数，从当前区块开始的这一段区块内，来自该设备的所有访问请求都被拒绝。阻塞时间根据如下指数函数来计算，可以看出，惩罚函数的值越大，阻塞时间越长。 $$ T_{Blocked} = 2^{-Cr_i}, Cr_i \le 0 $$

3.3.2 一些考虑

将设计方案时的一些考虑和存在的问题总结如下

  1. 设备信誉值不应当与设备活跃程度有关，某种设备可能短时间一次请求都不发起，但这种情况不应当对设备信誉值产生影响；
  2. 如果设备一直遵守规则，信誉值会保持不断增长，最终可能导致超限。因此需要为信誉值设置上限，不需要设置下限是因为当数字大到一定程度，相当于该设备被永远阻塞。
  3. 设备前期累积的信誉值不应当与设备产生的特定恶意行为抵消，也就是说，设备产生了某种特别恶劣的行为，即时它前期积累了很高的信誉，也必须惩罚；
  4. 以太坊智能合约语言 Solidity 不支持浮点数定义和运算，因此公式中涉及的除法运算和浮点数定义需要调整，我们设计了一个整数信誉算法供使用，可以参考附录 III；
  5. Solidity 中时间的计算单位是 s，以时间作为衡量的话，可能由于两次行为间隔太久导致结果过大，因此将行为数量作为窗口而不是时间间隔；
  6. 有一版方案合法行为包括普通的增删改，但是设备、属性、策略的增删改都是由设备的管理者完成的，不能作为设备本身的行为判断。

参数设置出于直觉，我们暂时设置为

  1. 惩罚函数中，$\alpha_0 = 0.2, \alpha_1 = 0.2, \alpha_2 = 0.3$，因为第三种恶意行为是前两种的综合；
  2. 奖励函数中，$\omega = 0.3$，奖励函数中，${Cr_i^P}_{max} = 30$

我们最后没有使用整数信誉算法，而是直接使用了这个涉及浮点数定义和运算的算法，方法是使用了一个提供四精度浮点数运算的库，同时，为了输入需要的参数，我们采用10进制移位的方法，比如，想输入 0.1，采用 1/10 的方式，输入 1.34，采用 134/100 的方式，通过两个整数计算得到最终的值。

4. 合约测试

首先在 Remix 中测试代码的可用性，编译配置开启 Enable optimization（可以大幅减少 gas 消耗5），部署和调用的 gas 消耗统计如下

操作transaction costexecution cost
MC deploy2787467 gas2053591 gas
RC deploy1922683 gas1433235 gas
ACC deploy3899979 gas2889159 gas
ABDKMathQuad deploy76861 gas17297 gas

下面是测试时执行的步骤，顺序不能改变

4.1 准备工作

  1. 系统管理者部署MC

    1
2
3

    MC部署账户(系统管理者)：0x4542ED8d83107Db8e9Cab06d9A8D7a02b896f7d9
返回：
 MC合约地址：0x1f1e534ff105d9e697a1c9afabcd02560de55bbe

  2. 监管机构部署RC

    1
2
3
4
5

    RC部署账户(监管机构)：0x5521Ba0bC012bE5dC12855f4972c48505Dc88c4A
传入：
 MC合约地址：0x1f1e534ff105d9e697a1c9afabcd02560de55bbe
返回：
 RC合约地址：0x644e0e3b47ad746be213e1553928f96f70a2655c

  3. 系统管理者调用 MC中的 setRC() 进行设置

    1
2
3
4

    调用账户(系统管理者)：0x4542ED8d83107Db8e9Cab06d9A8D7a02b896f7d9
传入：
 RC合约地址：0x644e0e3b47ad746be213e1553928f96f70a2655c
 监管机构账户：0x5521Ba0bC012bE5dC12855f4972c48505Dc88c4A

  4. 设备管理者部署 ACC

    1
2
3
4
5
6
7

    ACC部署账户(设备管理者)：0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
传入：
 MC合约地址：0x1f1e534ff105d9e697a1c9afabcd02560de55bbe
 RC合约地址：0x644e0e3b47ad746be213e1553928f96f70a2655c
 设备管理者地址：0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
返回：
 ACC合约地址：0x19455cac7bd27705661d467e20ee82b1cc48737b

  5. 设备管理者调用 MC 中的 deviceRegister() 函数，注册自身

    1
2
3
4
5
6
7
8

    调用账户(设备管理者)：0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
传入参数为：
 设备地址：0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
 管理者地址：0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
 合约地址：0x19455cac7bd27705661d467e20ee82b1cc48737b
 设备ID：gateway33
 设备类型：gateway
 设备角色：manager

  6. 设备部署 ACC

    1
2
3
4
5
6
7

    ACC部署账户(设备)：0xB52fd79681f876af9dac92d1ED9a23Aac3fdBfa1
传入：
 MC合约地址：0x1f1e534ff105d9e697a1c9afabcd02560de55bbe
 RC合约地址：0x644e0e3b47ad746be213e1553928f96f70a2655c
 设备管理者地址：0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
返回：
 ACC合约地址：0x54d463eca95c313077815ce0a893b4036199e28e

  7. 设备管理者调用 MC 中的 deviceRegister() 函数，注册设备固定属性

    1
2
3
4
5
6
7
8

    调用账户(设备管理者)：0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
传入参数为：
 设备地址：0xB52fd79681f876af9dac92d1ED9a23Aac3fdBfa1
 管理者地址：0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
 合约地址：0x54d463eca95c313077815ce0a893b4036199e28e
 设备ID：pallat23
 设备类型：pallat
 设备角色：device

  8. 设备管理者调用 MC 中的 addAttribute() 函数，添加额外属性

    1
2
3
4
5

    调用账户(设备管理者): 0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
传入参数：
 设备地址：0xB52fd79681f876af9dac92d1ED9a23Aac3fdBfa1
 属性名：currentFruit
 属性值：apple

  9. 调用 MC 中的 get 类函数，查看设备属性，包括 getFixedAttribute(), getDeviceRelatedAddress(), getCustomedAttribute() 三个函数

  10. 设备管理者调用 MC 中的 updateAttribute() 函数，更改属性

    1
2
3
4
5

    调用账户(设备管理者): 0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
传入参数：
    设备地址：0xB52fd79681f876af9dac92d1ED9a23Aac3fdBfa1
    属性名：currentFruit
    属性值：peer

    调用 MC 中的 getCustomedAttribute() 函数，查看更改后的属性，确认无误

  11. 设备管理者调用 MC 中的 deleteAttribute() 函数，删除 currentFruit 属性

    1
2
3
4

    调用账户(设备管理者): 0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
传入参数：
    设备地址：0xB52fd79681f876af9dac92d1ED9a23Aac3fdBfa1
    属性名：currentFruit

    调用 MC 中的 getCustomedAttribute() 函数，会返回 Attribute not exist! 错误

4.2 访问测试

  1. 设备管理者调用 ACC 的 addResourceAttr() 函数添加资源属性

    1
2
3
4
5

    调用账户(设备管理者): 0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
传入参数：
 资源名：GPS
 属性名：currentLocation
 属性值：116.309551, 39.896559

    然后调用 getResourceAttr() 函数查看

  2. 设备管理者调用 ACC 的 updateResourceAttr() 函数更新资源属性，继续查看；最后调用 deleteResourceAttr() 函数删除资源属性，查看返回 Resource attribute not exist! 错误

  3. 设备管理者调用 ACC 的 addPolicy() 函数添加策略

    1
2
3
4
5
6
7
8
9

    调用账户(设备管理者): 0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
传入参数：
 资源名：truck
 操作：read
 属性所有者：subject
 属性名：deviceType
 操作符：=
 属性值：gateway
 重要级别：0

    成功后调用 getPolicy() 查看策略

  4. 设备管理者调用 ACC 的 accessControl() 函数，测试访问控制

    1
2
3
4

    调用账户(设备管理者): 0x8f3dA5cD93Eb378Cdd27631C1757075B25D65B18
传入参数：
 资源名：truck
 操作：read

以上为访问成功的测试，之后将所有可能的情况都测试一遍，包括：策略未定义、频繁访问、策略检查未通过、重要策略检查未通过。

除此之外，还要测试算法为 denyoverrides 和 allowoverrides 两种情况下对于冲突策略的处理结果，每一种测试都要注意返回的 event 中 behaviorID 和 finalResult 是否对应。

4.3 RC测试

暂时去除 reputationCompute() 函数前的 require 验证，测试该函数

4.4 其它

应当使用某种工具对合约进行审计，验证其安全性，本来打算使用曾用过的 Mythx，但 Mythx 已转为收费，其它工具类似，因此放弃了审计工作，仅使用 Remix 自带的安全性验证。

所有功能测试完成后，统计所有类型合约 deploy 所需要的 Gas 梳理，统计编译后元数据的大小，用于之后的结果对比与分析。

附录I 所做调整

下面是所作的调整总结

  • 功能-策略冲突解决机制
  • 功能-无匹配策略时的处理
  • 功能-恶意行为检测
  • 架构-策略定义拆分单独的合约（提供重用性）
  • 架构-部分函数迁移到单独的库文件 Utils.sol（for gas save）
  • 语法-匹配最新版本编译器
  • 语法-统一代码风格
  • 实验过程-去除合约审计（MythX 转为收费）
  • 实验过程-移除树莓派节点（在家的时候没有树莓派）
  • 实验过程-恶意行为的测试方案
  • 实验过程-测试新的性能指标（必要的）
  • 实验过程-利用 JavaScript 和 Bash 交互迁移到利用 Go
  • 思路-明晰背景（为什么做这件事）
  • 思路-信誉算法设计

附录II 参考的信誉算法

根据节点 $i$ 的行为，将其信誉值 $Cr_i$ 划分为两部分，公式如下 $$ Cr_i = \lambda_1 Cr_i^P + \lambda_2 Cr_i^N $$ 其中 $Cr_i^P$ 代表正面影响部分，$Cr_i^P$ 代表负面影响部分。$\lambda_1$ 和 $\lambda_2$ 分别代表各部分的权重系数，调节这两个值就可以调整两部分所占权重，比如，如果我们想要严格的惩罚策略，应该令 $\lambda_2$ 更大一点。

$Cr_i^P$ 与节点 $i$ 单位时间内正常的交易数量成正相关，即通过节点活跃程度定义，表示如下 $$ Cr_i^P = \frac{\sum_{k=1}^{n_i} \omega_k} {\Delta T} $$ 其中 $n_i$ 代表节点 $i$ 在最近的单位时间内有效交易的数量，$\Delta T$ 代表单位时间，$\omega_k$ 代表第 $k$ 个交易的权重，交易的权重指的是该交易被验证的次数。也就是说，如果节点 $i$ 在一段时间内保持活跃，$Cr_i^P$ 将根据活跃程度不断调整，保证活跃节点可以使用更少的算力更快地发布交易。如果节点 $i$ 在一段时间内没有发布交易，就认为它是不活跃的，甚至是不可信节点，所以系统不会为它降低 PoW 的难度，即 $Cr_i^P = 0$。

$Cr_i^N$ 与节点 $i$ 的恶意行为数量成负相关，可以表示为 $$ Cr_i^N = -\sum_{k=1}^{m_i} \alpha(\beta) · \frac{\Delta T}{t-t_k} $$ 其中 $m_i$ 表示节点 $i$ 的恶意行为总数，$t$ 表示当前时间，$t_k$ 表示节点 $i$ 造成的第 $k$ 个恶意行为的时间点，$\alpha(\beta)$ 表示恶意行为 $\beta$ 的惩罚系数，该系数定义如下，其中 $\alpha_l$ 和 $\alpha_d$ 可以根据对恶意行为敏感度的要求进行调整。 $$ \alpha(\beta) = \begin{cases} \alpha_l&\text{if β is lazy tips behavior;} \\ \alpha_d & \text{if β is double-spending behavior} \end{cases} $$ 从$Cr_i^N$ 的公式中我们可以发现，随着时间的推移，恶意行为对节点的影响在逐渐减小，但不同于 $Cr_i^P$，它无法减小到0，也就是完全消除。当一个恶意行为发生的时候，$Cr_i^N$ 的绝对值会很大，由于 PoW 难度巨大，攻击将无法持续，通过这种方式我们可以及时阻止恶意行为。

该机制正常运行的需求是我们可以获取每个节点相关的所有交易，这样就可以计算出交易权重 $\omega$ 和 恶意行为记录 $\alpha(\beta)$，从而可以独立地计算出 $Cr_i^P$ 和 $Cr_i^N$，最终得到信誉值。作者在论文中将信誉值与 PoW 难度关联，具体来说，这两种成反比，定义公式为 $Cr_i = \delta \frac 1{D_i}$，其中 $D_i$ 为节点 $i$ 的 PoW 难度，$\delta$ 为比例系数。这样，信誉值高的难度低，信誉值低的难度高，难度的调整通过控制前缀0的最小长度完成，整个系统得以实现。

具体的实验中以上公式中的相关参数如何设置，作者给出了一些描述。交易权重 $\omega$ 可以直接计算，两个权重系数设置为 $\lambda_1 = 1,\lambda_2 = 0.5$，因为 $Cr_i^N$ 的值可能相对比较大，如果想要更严厉的惩罚措施，$\lambda_2$ 可以设置的更大。考虑到 IIoT 系统的请求频率，单位时间设置为 $\Delta T = 30s$，一个不是太长的间隔。对于 lazy tips，设置 $\alpha(\beta) = 0.5$，对于 double-spending，设置 $\alpha(\beta) = 1$，因为双花对系统造成的损害更严重。

附录III 整数信誉算法

改进后的方案中，惩罚公式如下 $$ Cr_i^N = -\sum_{k=1}^{m} max \{\alpha(\beta)-(m - k), 1 \} $$ 其中，$m$ 为设备 $i$ 当前的恶意行为总数，$k$ 是第 k 个恶意行为发生时的恶意行为总数，$\alpha(\beta)$ 表示恶意行为 $\beta$ 的惩罚系数，在1-10内取值,该系数定义如下，可以根据对恶意行为敏感度的要求进行调整。 $$ \alpha(\beta) = \begin{cases} \alpha_1 & \text{如果 β 非法的访问控制请求; } \\ \alpha_2 & \text{如果 β 代表短时间发起大量请求} \end{cases} $$ $max \{\alpha(\beta)-(m - k), 1 \}$ 的含义是，每发生一个新的恶意行为，旧的恶意行为惩罚系数就减一，底线是惩罚系数的最小值1，这能保证随着时间的推移，旧的恶意行为的影响不断减小，但不会减小到0。

奖励函数 $Cr_i^P$ 定义不变， $\omega_k$ 代表第 $k$ 种操作的权重，$n_k$ 代表第 $k$ 种操作的数量，但权重的取值范围限定在 1-10 $$ Cr_i^P = max \{ Cr_{imax}^P , \sum_{k=1}^4 \omega_k n_k \} $$

最终的信誉值计算公式如下 $$ Cr_i = Cr_i^P + Cr_i^N $$ 阻塞时间的计算依然是以 2 为底的指数函数，但这里会进行判断，当恶意行为是短时间发起大量请求时，立刻进行处罚，否则只有在信誉值低于某个值$\gamma$ 时才进行处罚。阻塞时间函数如下 $$ T_{blocked} = 2^{Cr_i}, if \ \text{频繁请求恶意行为} \ or \ \text{(信誉值} < \gamma) $$

  1. ZHANG Y, KASAHARA S, SHEN Y, 等. Smart Contract-Based Access Control for the Internet of Things[J]. IEEE Internet of Things Journal, 2019, 6(2): 1594–1605. DOI:10.1109/JIOT.2018.2847705. ↩︎

  2. AMOON M, ALTAMEEM T, ALTAMEEM A. RRAC: Role Based Reputed Access Control Method for Mitigating Malicious Impact in Intelligent IoT Platforms[J]. Computer Communications, 2020, 151: 238–246. DOI:10.1016/j.comcom.2020.01.011. ↩︎

  3. J. Huang, L. Kong, G. Chen, M.-Y. Wu, X. Liu, and P. Zeng, “Towards Secure Industrial IoT: Blockchain System With Credit-Based Consensus Mechanism,” IEEE Trans. Ind. Inf., vol. 15, no. 6, pp. 3680–3689, Jun. 2019, doi: 10.1109/TII.2019.2903342. ↩︎

  4. WANG P, YUE Y, SUN W, 等. An Attribute-Based Distributed Access Control for Blockchain-enabled IoT[C/OL]//2019 International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob). Barcelona, Spain: IEEE, 2019: 1–6[2020–04–02]. https://ieeexplore.ieee.org/document/8923232/. DOI:10.1109/WiMOB.2019.8923232. ↩︎

  5. difference between transaction cost and execution cost ↩︎