Published: Aug 2, 2023 by Dust Lee

这个模式解决的问题是在你的系统中如何(how)告诉哪些人是管理员，或者更通俗地说，在你的系统上下文中如何告诉一个有权限去执行某个动作。如果你来自Ethereum世界，你的第一直觉可能是用这个调用者的地址执行验证检查，如果调用者的地址在白名单中，那么他们的调用是有效的，否则不授权去执行这个调用。这是基于钱包地址的方案，然而，这种方法远非最优，因为它引入了组合性问题，实施过程中的最小错误都可能造成最大的后果，甚至导致用户失去访问权。它存以下问题：

1. 它假定公钥和钱包地址是一对一对应，也就是说，这种方法假定一个密钥对只能控制一个帐户。这在Ethereum上是正确的，但是在Radix上却不正确，在Radix上一个帐户就是一个组件，并且一个密钥对可以控制多个账户。因此，授权我所有的组件帐户(复数)中的一个去执行操作，而不授权其它帐户，显然既奇怪也笨拙。
2. 这要求在智能合约上实施额外的方法，允许添加，删除，替换等额外授权或白名单地址。如这些不能正确执行这些功能，就可能意味着合约的所有者被永久锁定，永远无法更改。如果帐户被黑客攻击，dApp被出售或者合约所有者希望在过去只有一个管理员的合约中添加其它管理员，这就会成为一个问题。
3. 除非合约上存在所需的功能，否则这种方案要求合约的所有者绝不能迁移到新账户–即便是在黑客攻击的情况下也不行，