在网上观看一部电影时，我能不能随着播放进度条的进度来付费呢？比如每观看一秒钟就付一点点钱，而不是一次性买断电影单次的观看权？这样我在这部电影上享受了多久的时间，我就需要付出多少钱。
这是“可编程货币”的概念。
在《你对钱的认知已经严重落伍了》这篇文章里，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事件那样。
放到智能合约上执行，是不是意味着收款人和付款人的金钱关系完全透明公开、没有隐私了？比如用这种方式发工资，全世界都知道我的薪水多少钱了？
现在列举的几个应用场景似乎都不够理想（中心化的月结、按次收费的模式可能更好），有没有更合适的新场景？以前不存在的场景？
欢迎讨论。
来源：
发布人：橙皮书
声明：该文观点仅代表作者本人，不代表火讯财经立场。火讯财经系信息发布平台，仅提供信息存储空间服务。
如文章涉及侵权， 请及时致函告之，本站将第⼀时间删除⽂章。邮箱：840034348@qq.com
文章总数
浏览数
商务合作：840034348@qq.com
媒体合作：840034348@qq.com
投稿合作：840034348@qq.com
微信公众号
iPhone & Android
