把錢變成一個關於時間的函式
在《你對錢的認知已經嚴重落伍了》這篇文章裡，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
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事件那樣。
放到智慧合約上執行，是不是意味著收款人和付款人的金錢關係完全透明公開、沒有隱私了？比如用這種方式發工資，全世界都知道我的薪水多少錢了？
現在列舉的幾個應用場景似乎都不夠理想（中心化的月結、按次收費的模式可能更好），有沒有更合適的新場景？以前不存在的場景？
歡迎討論。
宣告：登載此文出於傳遞更多資訊之目的，並不意味著贊同其觀點或證實其描述。