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