以太猫的启示(1)—智能合约的权限控制

原创 by 七镜@无退社区编辑部
原文 永久地址

区块链被发明出来之后都是被称为去中心化的账本系统。确实,区块链目前最为人所知的就是作为记账系统,并由此而衍生出的各种电子货币。不过去年出现的以太猫(CryptoKitties)却给大家展示了另一种可能。以太猫是运行在以太坊之上的 DApp,不夸张的说,以太猫引爆了接下来的 DApp 热潮。如果想要研究一下 DApp,作为开先河者的以太猫是一个不可多得的样本。

DApps 全称是 Decentralized Application ,即去中心化的应用程序,其中的去中心化是经常被人拿来说的概念。去中心化比中心化的优势在于对单点故障的防御性,对于传统的中心化系统,如果服务器宕机,那么整个服务也就会被终止。而去中心化则没有这个问题,因为世界各地有无数的电脑都在运行这个系统,及时其中的一部分宕机,也不影响其他的电脑继续运行。不少人因此认为 DApps 就是完全的去中心化,没有人可以控制,也没有可以拥有这个 DApp。事实上这是对 DApps 的一个极大的误解。确实,DApp 是运行在以太坊这种区块链系统上,但是 DApp 在去中心化这件事上不一定比以太坊本身更为强壮。以太猫就是一个非常有意思的例子。

在讲去中心化的问题之前,我们先来看一个开发中常见的问题。如果程序出了bug怎么办?传统的中心化服务只需要把修改过的版本直接部署到服务器上就解决问题。但在区块链的世界里这却是不行的,因为区块链有不可篡改的特性,当你 DApp 部署到以太坊之后一切就成为了永恒,这时候如果发现 bug 需要修改是完全不可能的,你能做的就是部署一个和之前的 DApp 完全无关的一个新的 DApp。虽然以太坊提供了 Selfdestruct 的方法来销毁一个智能合约,不过以太猫并没有使用这种破坏旧的 DApp 的 方式来进行 DApp 的升级。

以太猫的合约被分成了很多个子合约,最终作为接入点的合约 KittyCore 继承了这些子合约。其中最顶层的合约 KittyAccessControl 给我们演示了如何更温和的终止一个 DApp。KittyAccessControl 中有一个 pause 的方法。其代码本身很简单,就是把 paused 变量设置为 true。完整的源码如下:


function pause() external onlyCLevel whenNotPaused {

  paused = true;

}

而在以太猫的其他方法中,在运行前都会先检查 paused 这个变量,如果为 true,那么就不会继续执行下去。所以顾名思义,当 pause 方法被调用的时候,整个以太猫就真的被暂停了。

这时候我们就需要问一个问题,是不是谁都能调用 pause 方法,因为如果谁都可以调用的话,岂不是意味着随便一个人都能停掉以太猫。从代码中我们可以看到 pause 后边有 onlyCLevel 这样的部分。这部分其实就是权限控制,对应的代码同样来自于 KittyAccessControl :


modifier onlyCLevel() {

        require(

            msg.sender == cooAddress ||

            msg.sender == ceoAddress ||

            msg.sender == cfoAddress

        );

        _;

    }

代码也很简单,就是检查发起这个调用的以太坊的地址是不是 coo,ceo 和 cfo 的地址,如果不是就无法调用成功。这种方式是一个非常好的权限控制方式。在以太猫的其他部分,在必要的时候都会使用类似的权限控制来保证安全。

再看一下这些 ceo,coo,cfo 的地址来自于哪里。在以太猫入口的合约 KittyCore 的构造方法中有下边这样的代码:


function KittyCore() public {

        paused = true;

        ceoAddress = msg.sender;

        cooAddress = msg.sender;

        _createKitty(0, 0, 0, uint256(-1), address(0));

    }

这段代码是整个 DApp 的入口,只有在合约被部署到以太坊的时候会执行一次。这时候就会把 ceoAddress 设置为部署这个合约的以太坊地址。所以部署者就自动成为了以太猫的 ceo,他将有权限暂停整个以太猫。

最后,为什么不简单的使用 Selfdestruct 销毁旧网络而是使用这种方法呢?主要目的是如果升级了新的 DApp之后,由于新 DApp 和旧的 DApp 本质上是完全不相关的。为了让他们之间能留下一点关系,以太才使用了这种做法。在以太猫的合约中有一个 newContractAddress 的变量。如果升级了新的 DApp,旧的以太猫 DApp 暂停之后就会把这个 newContractAddress 给设置为新的以太猫的地址。这样使用旧以太猫的人就可以通过这个新地址去使用新版的以太猫。这就变成了一种直接内嵌在 DApp 内部的公告机制。

总结
以太猫的这种实现方式确实有很大的参考意义,在有类似需求的场景完全可以拿来使用。不过我们也要知道这种机制所带来的风险。其最大的优势同时也就带来了最大的风险,作为 ceo 的以太坊地址本质上控制了整个以太猫。在这一点上,以太猫已经变成了一个中心化的系统。单点故障问题就有可能出现,比如有人如果以非常规手段控制了这个 ceo 的以太坊地址,那么他也就能破坏以太猫网络。这就回到我们开头所说的,在去中心化这件事上 DApp 并不一定比其基础设施以太坊更安全。

你可能感兴趣的:(以太猫的启示(1)—智能合约的权限控制)