智能合约之支付(payment)合约解读

最近一股冷空气从南极吹到了墨尔本，整个周末，狂风暴雨，没完没了，狂风中还隐隐约约听到龙吟之声，暴雨还导致家里一扇窗户都漏水了，紧急联系了builder，他说下周来修，这个四级封锁，每天200多人感染的时候叫人过来干活，心中怯怯焉。现在反正也出不去，没啥事情好做，在油管上把鬼吹灯系列都看完了，在孩子的要求下，购买了netfix，最后连电影都看腻了，整个人觉得无比惆怅，只好来研究下智能合约，聊以度日。

我要分析的是‘openzeppelin-solidity’这个库里面的'payment'文件夹下的内容，这里聚集了几乎所有跟众筹中支付相关的项目文件。 先看看‘PaymentSplitter.sol‘这个合约，这个合约非常适合分赃，比如，几个朋友一起搞ICO众筹资金，收款账号不是一个以太坊的外部账户（就是钱包里通过私钥控制的账户），而是一个基于PaymentSplitter合约的智能合约，通过这个合约把收到的以太坊再次分配给各个外部账户，由于每个人贡献不一样，所以分钱多少也不一样，通过这个合约中的’share'来设定。

这个合约在初始化时候，就有一个分赃账户的地址和份额的设定：

constructor (address[] memory payees, uint256[] memory shares) public payable {
        // solhint-disable-next-line max-line-length
        require(payees.length == shares.length, "PaymentSplitter: payees and shares length mismatch");
        require(payees.length > 0, "PaymentSplitter: no payees");

        for (uint256 i = 0; i < payees.length; i++) {
            _addPayee(payees[i], shares[i]);
        }
    }

当然，如果有更多人参与项目中来，并且希望成为‘股东之一来分钱，这个合约还有个方法：

function _addPayee(address account, uint256 shares_) private {
        require(account != address(0), "PaymentSplitter: account is the zero address");
        require(shares_ > 0, "PaymentSplitter: shares are 0");
        require(_shares[account] == 0, "PaymentSplitter: account already has shares");

        _payees.push(account);
        _shares[account] = shares_;
        _totalShares = _totalShares.add(shares_);
        emit PayeeAdded(account, shares_);
    }

我们注意到，这个方法是一个private的，意味着不是外部可以直接调用的，那么就需要继承这个合约的继承者来调用，当然，调用者要通过modifier来满足各种规则的限制，比如必须是合约所有者，或者几个人都同意才行，你想加入，可不是随便能加入的。

再看看这个合约中另外一个最重要的函数---release，这是个需要外部调用的函数，在收到以太后，大伙分赃的时候，需要自己主动调用这个函数，才能把钱分到自己手里，以太坊的智能合约，在钱的问题上，一般都采用pull，而是push的方法，意思是不会在收款函数中主动调用分钱函数，把钱分到股东手里，而是要自己去调用收钱函数，这主要是为了防止我之前提起过的重入攻击（re-entry），如果你在这里主动发钱，对方收款账户很有可能是一个智能合约地址，坏人就可以通过智能合约，再次调用你的发钱函数，或者block在那里，让你难受，你就需要额外小心。所以不如这样，你要钱，自己来收。

function release(address payable account) public {
        require(_shares[account] > 0, "PaymentSplitter: account has no shares");

        uint256 totalReceived = address(this).balance.add(_totalReleased);
        uint256 payment = totalReceived.mul(_shares[account]).div(_totalShares).sub(_released[account]);

        require(payment != 0, "PaymentSplitter: account is not due payment");

        _released[account] = _released[account].add(payment);
        _totalReleased = _totalReleased.add(payment);

        account.transfer(payment);
        emit PaymentReleased(account, payment);
    }

在钱的问题上，还有个需求，就是需要个地方把钱托管起来，以后想要就能拿出来，于是有了’Escrow.sol‘ 托管协议，它继承了ownership文件夹下的’Secondary.sol'合约，我看了一下，这个合约的主要好处就是可以随便转移合约所有权。

function transferPrimary(address recipient) public onlyPrimary {
        require(recipient != address(0), "Secondary: new primary is the zero address");
        _primary = recipient;
        emit PrimaryTransferred(_primary);
    }
}

托管嘛，简而言之，就是解决两个问题，一个是存钱，一个是取钱，请看存钱函数:

function deposit(address payee) public onlyPrimary payable {
        uint256 amount = msg.value;
        _deposits[payee] = _deposits[payee].add(amount);

        emit Deposited(payee, amount);
    }

其实它就是对‘谁’存了多少钱做了一个记录而已，真正收到的钱（就是以太）是自动被这个合约锁定了，在这个合约账户名下。

再看看取函数：

function withdraw(address payable payee) public onlyPrimary {
        uint256 payment = _deposits[payee];

        _deposits[payee] = 0;

        payee.transfer(payment);

        emit Withdrawn(payee, payment);
    }

看到这里，我不禁奇了，收款的fallback函数呢？这个需要在继承者那里或者调用这个合约的合约那里的fallback实现，如果外面有以太被转移给这个合约，我们在fallback里调用这个deposit函数就可以记录什么人送来了多少钱。同时我们还看到，withdraw和deposit都是需要宿主权限才能做的事情，所以，我们要么象最后说的PullPayment合约那样，创建一个Escrow合约的实例，要么继承这个Escrow合约，那么就自动有了宿主的权限。

这时候我突然想起了我那个“去中心化支付宝或者paypal”，完全可以使用这个合约来处理，在合约中放个时间变量，然后在withdraw里放个对时间的判断，就可以实现定时取款的功能了。以太坊的智能合约不会主动在timeout的时候做些事情，必须被动调动函数，在函数里判断是否到期可以执行接下来的步骤。

看完了Escrow托管合约，再看看继承了它的另外一个合约：ConditionalEscrow，顾名思义，就是满足一定条件的托管协议，在满足一定条件下取款，这个主要是这个函数来做的：

function withdrawalAllowed(address payee) public view returns (bool);

但是我们看到，这个函数并没有任何具体的实现，所以这就为继承这个合约的合约提供了无比巨大的想象空间。请看，它真的是啥也没做，就提供个接口而已：

function withdraw(address payable payee) public {
        require(withdrawalAllowed(payee), "ConditionalEscrow: payee is not allowed to withdraw");
        super.withdraw(payee);
    }

这个合约就这么一点，扫过就算了，看托管合约文件夹下最后一个合约：RefundEscrow，这个玩意估计应用很多，特别在ICO众筹中，有了这么个合约，就能保证国家一声令下，圈钱的人能相应号召，把钱还给投资人，避免了坐牢的危险；还可以在众筹失败后，良心发现，主动把钱还给投资人。

这个合约很有意思，在一开始定义了个枚举变量：

enum State { Active, Refunding, Closed }

这就决定了在托管的不同状态，可以做不同事情，托管协议生效，就是初始化状态“Active”，在此状态下，可以存钱，可以关闭托管，托管结束就是“Close”，或者把状态改成“Refunding”；在“Close"状态下，受益人才可以把钱取出来：

function beneficiaryWithdraw() public {
        require(_state == State.Closed, "RefundEscrow: beneficiary can only withdraw while closed");
        _beneficiary.transfer(address(this).balance);
    }

等等，说好的可以refund呢？咋在这里看不到一个refund的函数呢？开始我也纳闷，这也太黑了吧，但是仔细一看，它实现了这个函数：

function withdrawalAllowed(address) public view returns (bool) {
        return _state == State.Refunding;
    }

因为合约RefundEscrow 继承了合约ConditionalEscrow，所以也就继承了这个函数，那么调用这个函数，投资人就可以把钱取回去啦：

function withdraw(address payable payee) public {
        require(withdrawalAllowed(payee), "ConditionalEscrow: payee is not allowed to withdraw");
        super.withdraw(payee);
    }

前提是合约的状态被置成”Refunding"：

 function enableRefunds() public onlyPrimary {
        require(_state == State.Active, "RefundEscrow: can only enable refunds while active");
        _state = State.Refunding;
        emit RefundsEnabled();
    }

最后来看看这个合约：PullPayment.sol，这个合约就是创建了一个Escrow的合约实例，然后包装一下它的函数：

 Escrow private _escrow;

    constructor () internal {
        _escrow = new Escrow();
    }

别的没啥特别好说的，就是这个内部函数，结合Escrow的那个被调用函数，这个调用方式真是solidity独特的：

function _asyncTransfer(address dest, uint256 amount) internal {
        _escrow.deposit.value(amount)(dest);
    }

function deposit(address payee) public onlyPrimary payable {
        uint256 amount = msg.value;
        _deposits[payee] = _deposits[payee].add(amount);

        emit Deposited(payee, amount);
    }

看完和理解这些合约后，以后关于支付方面的智能合约，可以不用自己从头造轮子了，完全可以继承或者生成以上这些合约。比如如果搞去中心化支付宝，支付一块就可以继承“ConditionalEscrow”这个合约，重写“withdrawalAllowed“这个函数，增加一个时间的变量，说明什么时间到期，每次调用取钱函数时候，都判断一下当前时间跟设置那个时间，这样就解决第三方资金托管和到期支付的功能了。