1. 程式人生 > >聽聽Vitalik對token設計的看法

聽聽Vitalik對token設計的看法

文章轉載於:Ethfans 以太坊愛好者

本文記錄 Vitalik 10/28 於 Maicoin 的演講。活動有直播,影片從 23:00 開始。我也把 Vitalik 演講的部分剪接出來,上傳到 YouTube 上。

Vitalik演講視訊連結:

https://www.youtube.com/watch?v=F1yJ8PuSyCM

這場演講雖然題為 interactive coin offering ,但 Vitalik 從更廣的角度去談代幣設計這件事。內容也其實是 Vitalik 最近幾篇部落格和推特文章的總結,可能有些新結論但也有可能是我沒追蹤到的部分。

主要是以下幾篇文章,但還有幾篇其他文章比重較小就不列了,大多文章 Ethfans 也有中文翻譯:

  • 6 月 Analyzing Token Sale Models

  • 9 月 interactive coin offering 這篇論文。

  • 10 月 On Medium-of-Exchange Token Valuations

現在的 ICO 為何瘋狂?

簡答:因為現在主流以 「交易媒介(Medium-of-Exchange)」 形式設計的代幣,其經濟價值不會向穩定的均衡收斂。或無法用簡單淨現值折現得到穩定估值。

詳答:

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

從代幣的一種簡單定義來看:

  • 可以轉移

  • 具有經濟價值:人們願意付出努力或犧牲去增加他們的餘額

640?wx_fmt=jpeg

人們要為了某些好處,才會願意付出努力或犧牲。這個好處可以來自「花費代幣」或「持有代幣」。其中花費主要有:「交易媒介」與「手續費」兩種模式。

640?wx_fmt=jpeg

Vitalik 在投影片中以兩種購買服務的模式做解說。左欄的使用情境是現有常見「交易媒介」模式,右欄是代幣使用後將不存在的「手續費」模式。

在右欄的情況中,在代幣消失後,故事就結束了。如果整個系統突然崩潰了,大家也沒什麼好損失。但反觀左欄,服務提供商 Bob 在取得 Alice 的代幣後,Bob 期待從那 100 個代幣取得些什麼,否則 Bob 不會接受 Alice 的代幣。但如果系統突然崩潰了,那些已經提供服務並持有代幣的人將會不開心。

而那 100 個代幣提供給 Bob 的價值,在於 Bob 覺得下個人會覺得代幣有價值,或 Bob 覺得下個人會覺得下個人會這麼想,以此類推。這便是「交易媒介」模式造成估值困難的原因。

640?wx_fmt=jpeg

更甚者,「交易媒介」模式代幣的價格走勢容易形成無法走向穩定的正回饋。代幣會因為人們預期上漲而持有、因而更加速上漲,或者是人們預期會下跌、因而又賣出而更加速下跌。

細節 On Medium-of-Exchange Token Valuations 一文會有更多說明。

這裡值得補充的是「持有代幣」得到好處的功能目前還很少人實驗。一種使用情境是入場券。想象假設有個機場貴賓室,你不需要花代幣才能進入,而是證明你持有至少一個代幣才能進入。經常旅行的人可以一直持有這個代幣,隨時進入機場貴賓室。如果是偶爾旅行的人,也可只持有兩個小時,然後再賣給別人。

另外一種是當股利發放。當你花費代幣時,有一部分進到提供服務的公司口袋,另一部分發放給所有代幣持有者。這是另外一種讓持有代幣可以帶來好處的設計。

這兩個方式好在代幣的價值可以從以下簡單方式得到:

  • ㄧ個代幣期望使用貴賓室總次數的現值

  • 股利淨現值

640?wx_fmt=jpeg

640?wx_fmt=jpeg

-財務學上常用的淨現值折現公式-

代幣的賣法

好的賣法:
人人能參與,買得到自己願易承受的代幣總估值

  • Reverse dutch auction: 壞處費時

  • nteractive Coin Offering: 少了前者的壞處

壞的賣法:
壞的賣法中失去、或第三方可取得的那些經濟利益,在好的賣法中應該是給賣方的。

  • Capped 限量:代幣秒殺,少數人才買得到。有錢人賄賂礦工打包交易

  • Uncapped 不限量:大家不知道總估值多少,因此不知道自己佔總估的比例而不敢買。

  • 接受兩種幣別支付:價格變動時被套利

  • 提供優惠給大量購買或親朋好友:這些有優惠價的人拿去轉賣給其他人。

注:提供優惠給提早購買的人則不算壞的賣法,因為提早買的人有承受相應早買風險。

Analyzing Token Sale Models 一文與 Interactive Coin Offering 的論文有更多說明。

如何讓代幣重回理智?

  • 代幣發行機制、使用模式尚有許多設計空間,沒被現有的團隊實驗過的。人們應該多嘗試、研究新代幣。

  • 不應該苛責那些創新、實驗新代幣的人或團隊。

  • 讓經濟學家分析過,設計簡單淨現值折現公式能得到穩定估值的代幣。

640?wx_fmt=jpeg

更小心實驗 DAO

大部分來自 Thinking About Smart Contract Security

誘因對齊(incentive alignment)

ICO 的發行團隊設定禁止交易的閉鎖期。可每個月逐漸解鎖一些。這樣設計可以避免發行團隊捲款潛逃。

類似創投一樣,分 ABCD 期融資。讓小團隊在證明自己能做更大時,再募更多的錢。現行的發行機制,募資團隊習慣把一輩子要花的所有錢都先募完了。但更好的做法是,先募一筆小錢,等到達到某種目標了,在募更多的錢。

要做到這件事,可先募一筆 Capped sale ,再募一筆 Uncapped。

前者得要設計避免代幣秒殺的方式。如果募資的個人是有註冊的話(注:大概類似 PICOPS 的服務),便可以限制每個人的上限。設定一個未知個人上限,利用每人期望估值互動式得到該上限,使得人人都可投,但募資總額剛好在總額上限。(見下文 Bonus)

和願意分期取得募資的團隊比,在前期想把所有錢募完的團隊,等同於釋放團隊對中長期缺乏信心的訊號。

如果有 Excess demand ,可以拿去做公益。細節應該是這篇:http://vitalik.ca/jekyll/general/2017/03/11/a_note_on_charity.html

結論

這場演講總結 Vitalik 近幾年來對代幣的看法。目前代幣還有許多令人興奮的設計空間與實驗方向,傳統金融也依然提供不少智慧可以採用。希望短期內能看到加密貨幣社群往理智的方向去嘗試各種新的實作。

Bonus

對於初期團隊要設計一個人人可參與,又具有上限的募資。 Vitalik 對這套機制做了額外的解說,並附上一個不太有效率的演算法,但足以說明這套機制的精神。見下圖說明。

募資結果個人投入以太幣加總不超過募資上限,則人們都買到他們想要的量。

如果加總超過上限,演算法會得到個人投入上限。假設個人上限是 10 eth。我一開始投入 12 eth 就只能買到價值 10 eth 的代幣,2 eth 退還;如果我投入 5 eth ,則我能買到價值 5 eth 的代幣。

640?wx_fmt=png

原文連結: https://medium.com/taipei-ethereum-meetup/vitalik-on-token-90466332c25a
作者: Chih-Cheng Liang(樑智程)

相關推薦

聽聽Vitaliktoken設計看法

文章轉載於:Ethfans 以太坊愛好者本文記錄 Vitalik 10/28 於 Maicoin

如何使用async和await這組合設計統一的取Access Token的函式

最近我在使用SAP雲平臺的機器學習API做和SAP系統的整合,因為SAP Cloud Platform Leonardo上的機器學

面向設計原則

封裝 int 變化 事物 倒置 訪問權限 抽象類 帶來 理解 一、單一職責原則: 全稱:“Single-Responsibility Principle” 說明:就一個類而言,應該只專註於做一件事和僅有一個引起它變化的原因。所謂職責,我們可以理解他為功能,就是設計的這個類功

面向設計:共性VS個性-------繼承的粒度和聚合的粒度以及類的重構

兩個 結構 味道 純粹 提取 職責 問題 one 質量 共性和個性 依據面向對象的原理。類是對象的抽象。也就是說。類是一系列的既有共性又有個性的對象的高度概括,類的屬性和方法代表了隸屬於該類的全部對象的共性,類的每一個對象實例都能夠有不同的屬性值

面向設計(OOD)七大原則

蓋房子 出了 也不能 說我 開放 華麗 white 盡心 -a 這篇文章我會不停的維護它,它將會越來越長,但它是關於我在面向對象中的一些學習的思考心得。希望對自己對各位都能實用處。 開篇前,說明一下寫這篇文章的原因。原因是由於設計模式。由於設計模式裏的

PHP面向象-設計模式 單例模式 簡單工廠模式 工廠方法模式

單例 nbsp 私有化 {} 意義 pan php代碼 get fun 1.單例模式   單例模式是一種常用的軟件設計模式。在它的核心結構中只包含一個被稱為單例的特殊類。通過單例模式可以保證系統中一個類只有一個實例。即一個類只有一個對象實例。   要實現每一個類只有一個實例

面向設計

mil family 面向對象設計 span nbsp font 好處 spa 屬性 面對對象設計和開發程序的好處 1.交流更加流暢 2.提高設計和開發效率面向對象設計的過程 1.發現類 2.發現類的屬性 3.發現類的方法面向對象設計

[轉]八幅漫畫理解使用JSON Web Token設計單點登錄系統

漫畫 響應 嘗試 占用 tao 自己的 解碼 -a 發送 上次在《JSON Web Token - 在Web應用間安全地傳遞信息》中我提到了JSON Web Token可以用來設計單點登錄系統。我嘗試用八幅漫畫先讓大家理解如何設計正常的用戶認證系統,然後再延伸到單點登錄系統

面向設計原則之四:依賴倒置原則

ron 通過 發生 需要 系統 面向對象設計 啟動 模塊 == 依賴倒置原則 所謂依賴倒置原則(Dependence Inversion Principle )就是要依賴於抽象,不要依賴於具體。簡單的說就是對抽象進行編程,不要對實現進行編程,這樣就降低了客戶與實

面向設計模式

設計模式 observer abstract target strac font bstr 16px color 觀察者(Observer)模式 抽象工廠(Abstract Factory)模式面向對象設計模式

面向設計——抽象工廠(Abstract Factory)模式

protected wiki tsp 客戶端 direct eat cot 優缺點 https 定義   提供一個創建一系列相關或者相互依賴對象的接口,而無需指定它們具體的類。抽象工廠允許客戶使用抽象的接口來創建一組相關的產品,而不需要知道或關心實際產出的具體產品是什麽。這

面向設計——“泛型”的起步

rac -m sharp mil rabl dex 兩個 無法 ini 泛型是 2.0 版 C# 語言和公共語言執行庫 (CLR) 中的一個新功能。泛型將類型參數的概念引入 .NET Framework,類型參數使得設計例如以下類和方法成為可能:這些

面向設計原則一:單一職責原則(SRP)

能夠 實現 update 之間 關註 linq 好處 相互 並且 單一職責原則(SRP) 定義:系統中的每一個類都應該只有一個職責。 好處:高內聚、低耦合。 解釋說明: 單一職責也就是說我們應該讓一個類或一個對象只做一件事情,每個類所要關註的就是自己要完成的

面向設計原則二:開閉原則(OCP)

name 返回 展開 打開 設計原則 data turn acl int 開閉原則(OCP)定義:對擴展開發,對修改關閉。好處: 適應性和靈活性。 穩定性和延續性。 可復用性與可維護性。 解釋說明:開閉原則指的是兩方面:對功能擴展開發,對修改進

面向設計原則四:依賴倒置原則

設計原則 面向 dip 定性 穩定 要求 這樣的 覆蓋 通過 依賴倒置原則(DIP) 定義:高層模塊不應該依賴底層模塊,兩者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象。   好處:穩定性、可維護性、可擴展性。  概述:DI就是依賴倒置的意思,也可稱

面向設計原則八:迪米特原則

private 方法 pri ted 兩個類 對象 中一 成員 面向對象設計原則 迪米特原則(LOP)  定義:一個對象應當對其他對象盡可能少的了解。解釋說明:  LOP原則也叫最少支持原則,也就是一個對象應當對其他對象盡可能少的了解,反過來,其他對象也應當盡量少的知道我這

面向設計原則九:組合/聚合復用原則

示例 tex pub 意義 面向對象設計 優先 load 沒有 clas 組合/聚合復用原則(LSP)  定義:優先使用組合,使系統更靈活,其次才考慮繼承,達到復用的目的。重用的方式:  繼承、組合、聚合解釋說明:  繼承:在我們想復用代碼時,我們一般會優先想到繼承,但是具

Java程序員應當知道的10個面向設計原則

yourself 影響 準備 observe 及其 而是 equals 們的 格式 面向對象設計原則是OOPS編程的核心, 但我見過的大多數Java程序員熱心於像Singleton (單例) 、 Decorator(裝飾器)、Observer(觀察者) 等設計模式,而沒有把

(轉載)Java程序員應當知道的10個面向設計原則

程序 rep 開放 不同 單一職責原則 世界 企業項目 們的 ive 面向對象設計原則是OOPS編程的核心, 但我見過的大多數Java程序員熱心於像Singleton (單例) 、 Decorator(裝飾器)、Observer(觀察者) 等設計模式,而沒有把足夠多的註意力

[js高手之路]面向象+設計模式+繼承一步步改造簡單的四則運算

繼承 設計模式 到目前為止,我已經寫完了面向對象完整的一個系列知識,前面基本屬於理論,原理的理解,接下來,我們就用學到的知識來實戰下吧.看看理解原理和理論是否重要?例子從簡單到復雜一、單體(字面量)封裝加減乘除var Oper = { add : function( n1, n