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

  • A+
所属分类:数字货币

在《你对钱的认知已经严重落伍了》这篇文章里,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),但为了简单起见,我们在这里先不列进去。

工资 订阅 咨询公司 cdp 租金 停车 众筹

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事件那样。

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

现在列举的几个应用场景似乎都不够理想(中心化的月结、按次收费的模式可能更好),有没有更合适的新场景?以前不存在的场景? 欢迎讨论。

  • 我的微信
  • 这是我的微信扫一扫
  • weinxin
  • 我的微信公众号
  • 我的微信公众号扫一扫
  • weinxin
漫兮

发表评论

:?::razz::sad::evil::!::smile::oops::grin::eek::shock::???::cool::lol::mad::twisted::roll::wink::idea::arrow::neutral::cry::mrgreen: