把钱变成一个关于时间的函数

在网上观看一部电影时，我能不能随着播放进度条的进度来付费呢？比如每观看一秒钟就付一点点钱，而不是一次性买断电影单次的观看权？这样我在这部电影上享受了多久的时间，我就需要付出多少钱。

这是“可编程货币”的概念。

在《你对钱的认知已经严重落伍了》这篇文章里，Andreas M. Antonopoulos 提出了这种真正意义上的programable money，叫做“streaming money”——把“钱”流量化。

当支付门槛足够低、支付成本可以忽略不计的时候，这种改变会把钱从「批量交换的媒介」变成「流媒体」。这跟音乐、视频的发展过程是一样的。它不止会改变金钱流通的方式，而且还会改变我们如何创造金钱、如何使用金钱，最终为金钱创造出一种完全不同的新格式。因为本质上我们已经改变了钱的“时间尺度”。

最近以太坊上有一个有趣的讨论，有人试图根据上面这种「流量化的金钱思维」，提出一种新的ERC标准。（关于什么是ERC标准，你可以简单地把它理解成一种特定类型的智能合约，或者看看这篇和这篇）。

这个新的ERC标准想要让人们创造这样一种智能合约，可以用来作为「货币的流媒体服务」，改变人们对传统货币的看法。

这种新的合约很有意思，它能做到一些传统金融与支付系统做不到的事情。

比如，想象这样一个任务：

我想预存100块钱，每隔十分钟就拿出2块钱去买一张彩票，直到买光为止。

或者这样一个任务：

橙皮书想拨出一笔1000块钱的预算，只要是志愿者，不论是谁，他／她在橙皮书后台的编辑器上写文章，每打一个字，这1000块钱就会实时地分配一块钱给他／她，作为回报。

两个任务在传统的金融支付系统下都很难做到，或者能做到、但是成本会很高。当然，你可能会说上面这两个任务是伪需求，没人会真的这么去做。关于这一点暂时无法反驳，但我觉得你可以读读这一篇文章。

以下是关于这个新的ERC标准的一些讨论，包括概念的提出、动机和技术规范。现在橙皮书把这些讨论翻译出来，供感兴趣的朋友了解。

简单概括

Money streaming 代表了在有限的时间内连续支付的概念。区块数量作为时间的代理变量来持续更新账内的余额。

摘要

下面试图描述一个标准，这个标准使用区块数量来度量时间，streaming 的流服务则通过智能合约来进行映射。

标准的流程是这样的：

开发者提前设置好一个 Money streaming 的智能合约。

付款人可以与智能合约进行交互，存入一笔选定时间长度所需要的资金，就可以立即启动这个流服务了。

收款人可以根据智能合约的持续偿付能力从中拿到钱。即：付款率 * (当前区块高度 - 起始区块的高度) 

Money streaming 的条款(付款率，时间长度，元数据)可以在任何时候更新，只要双方一起签名。

任何一方都可以在任何时间点关掉 Money streaming 的合约，不需要达成链上的共识。 

如果 Money streaming 的时间结束了，而且不是由任何一方终止的，那么收款人有权提取所有已存入的款项。

动机

这个 ERC 标准旨在改变我们对长期金融规划（long-term financial commitments）的看法。区块链的存在，让支付不必以「块」的形式进行(比如按月支付的月薪)，因为随用随付（paying-as-you-go）的支付成本已经降低了很多。把钱变成一个关于时间的函数，可以在很多情况下更好地协调激励机制。 

应用场景

下面只列出了一小部分的应用场景。还有其他一些令人“毛骨悚然”的想法值得探讨，比如依赖时间的反激励机制（time-dependent disincetivisation），但为了简单起见，我们在这里先不列进去。

1.工资 

2.订阅 

3.咨询公司 

4.cdp 

5.租金

6.停车

众筹

RICOs，或者叫“可逆ICOs”，是由@frozeman在Devcon4提出的概念，它的思路是让投资者可以根据项目的进展“反向”收回投资，从而赋予投资者更大的权力和安全保障。我们之前讨论过一个类似的概念，称为SICOs，或者「流服务化的ICOs」。 

钱不是一次性投资出去、交给项目方，而是以一种灵活的合约形式持有，根据时间的推移进行分配。项目方可以在合约活跃的期间每天提取一小部分的资金，而投资者则有权在项目停止时收回他们剩下的本金。

Spec

Structs

stream的数据结构应该如下：

sender: 往智能合约里存钱的人

recipient: 从智能合约里取钱的收款人

tokenAddress: 用来作为支付资产的ERC20 token的地址

balance: 整个流服务的合约里剩余可分配钱的余额

timeframe: 参考下面的定义

rate: 参考下面的定义

struct Stream { 

    address sender; 

    address recipient; 

    address tokenAddress;

    uint256 balance;

    Timeframe timeframe;

    Rate rate; 

}

timeframe

start: 流服务开始时的区块高度

stop: 流服务结束时的区块高度

struct Timeframe { 

    uint256 start; 

    uint256 stop; 

}

rate

payment: 从付款人到收款人转移了多少资金

interval: 从付款人到收款人多长时间转移一次资金

Methods

getStream

返回这个流服务的全部数据，如果id指向的是一个有效的流服务

function getStream(uint256 _streamId) returns (address sender, address recipient, address tokenAddress, uint256 balance, uint256 startBlock, uint256 stopBlock, uint256 payment, uint256 interval)

balanceOf

根据给定的流服务的id和地址，返回合约的可用余额。

function balanceOf(uint256 _streamId, address _addr)

create

在 msg.sender 和 _recipient 之间创建一个新的流服务。

MUST allow senders to create multiple streams in parallel. SHOULD not accept Ether and only use ERC20-compatible tokens.

Triggers Event: LogCreate

function create(address _recipient, address _tokenAddress, uint256 _startBlock, uint256 _stopBlock, uint256 _payment, uint256 _interval)

withdraw

从可用余额中提现。

只有收款人可以进行这项操作。

Triggers Event: LogWithdraw

function withdraw(uint256 _streamId, uint256 _funds)

stop

停止流服务，并且把剩余资金发给付款人和收款人。

需要允许收款人和付款人任意一方都可以进行这项操作。

Triggers Event: LogStop

function stop(uint256 _streamId)

update

更新流服务的条款。

需要允许任何一方都可以提出这项操作的请求，但必须双方全部签名后才能生效。

Triggers Event: LogUpdate

function update(uint256 _streamId, address _tokenAddress, uint256 _stopBlock, uint256 _payment, uint256 _interval)

Events

略。参见：

https://github.com/ethereum/EIPs/issues/1620

我的一些疑问

看完这个ERC标准的起草，我仍然有几点疑问：

用区块数量来度量时间，这个完全可行吗？有没有潜在的问题？

如果在很短的时间间隔里连续支付，比如一秒钟付一次，gas费怎么办，怎么保证交易确实打包成功？

假设在这种流服务的智能合约里存了一大笔钱，预计要在十年内慢慢支付出去，那么这一大笔钱在一个合约里会不会不断吸引黑客攻击？像the DAO事件那样。

放到智能合约上执行，是不是意味着收款人和付款人的金钱关系完全透明公开、没有隐私了？比如用这种方式发工资，全世界都知道我的薪水多少钱了？

现在列举的几个应用场景似乎都不够理想（中心化的月结、按次收费的模式可能更好），有没有更合适的新场景？以前不存在的场景？

欢迎讨论。