作者:Rocco
翻譯:clockworkprince@橙皮書志願者
加密貨幣及區塊鏈技術已經蓬勃發展了十年有餘,在取得了巨大成就的同時,其面向的用戶量卻十分局限。目前區塊鏈主要的用戶群體,依然是由密碼朋克和技術派主導的「極客群體」,主流人群仍然被排除在體系之外。
對於這個現狀,本文提出了一個較為系統的觀點:加密貨幣及區塊鏈技術的堆棧化(即文中的「抽象化」)是其走向普羅大眾的關鍵一步,讓不同的堆棧層去適應不同用戶群體的需求,才能讓技術實現物盡其用、精準服務的目標。當然,文中也提到:不同的堆棧層(抽象化)伴隨著不同的風險等級。越是底層的堆棧,意味著對財產和服務越牢固的控制權,但相應地,也要面臨越大的個人責任和交易摩擦。
上面這段話可能聽起來有點難懂,用大白話解釋一下:
技術堆棧有點像在建一座房子,通常要一層一層的往上搭,搭成毛坯房,再裝修一下,這樣才能變成可以直接賣給用戶的產品。如果不搭這麼多層,直接讓你住在地基上,你肯定受不了。
現在區塊鏈的產品就是讓用戶直接住在地基上。但這些用戶很多自己就是建築學的狂熱教徒,所以對他們來說,住地基根本不是事(讓極客保管自己的私鑰並不會有太大的問題),相反,他們或許更享受直接在地基上DIY的過程。
當然,對主流用戶來說,這肯定就是一座世界上最爛的房子了。毫無疑問,區塊鏈需要往上繼續疊加更多的抽象層,造出更舒服的房子,但每往上添加一層新的材料,用戶其實也會面臨多一層的風險。
因為這種所謂的抽象化,有點像把複雜的地基、水管、電路都埋在地下,讓用戶只看到水龍頭和插座介面。這樣肯定方便了很多,但多數時候它們是由中心化供應商提供的服務,每加一層,意味著你需要多信任一個供應商,信任包工頭不會偷工減料、信任裝修公司不會甲醛超標,等等。
理解了這個比喻,再回頭看看上面那段話,是不是好懂了很多?
值得一提的是,堆棧化(抽象化)或者中心化的取捨,本身並無過錯,這個領域的目標是給與用戶選擇的權利,更多的在於用戶的選擇與偏好。因此,信息和個人認知是所有問題的關鍵所在。所以不斷學習知識,不斷充實自我才能更好的認識安全與風險,真正保護好神聖的私有財產不受侵犯。
正文
加密貨幣的抽象化是其大規模應用的關鍵一環。越是簡單的用戶體驗通常是以中心化為代價的。技術派用戶可以跳過抽象化,而在本地化層面解決技術及其相關的摩擦問題,但是對於普通用戶來說,他們更願意有個第三方在此過程中提供幫助。
目前,我認為,迄今為止絕大多數已建立的體系(無論是全球貨幣體系還是NFT DApp)大多純粹是為了一小撮技術狂熱分子服務的。當然,這並不是一件壞事——因為設計思想將重點放在了將新用戶引入體系內。技術組件的抽象化顯然也面臨著風險。抽象化程度越高,中心化就越強,終端用戶的使用風險就越高。但如果從系統中除去並打破抽象化,那麼,伴隨的風險就掌握在用戶自己手中,同時用戶也將面對與之相關的所有摩擦。
抽象化伴隨著風險,去抽象化意味著個人責任與摩擦
這個領域的目標是給與用戶選擇的權利:選擇加入中心化的抽象服務還是選擇控制自己的財務狀況和應用交互。我想簡單介紹一下我目前對抽象化範圍層級的看法以及每一層所關聯的服務。
抽象化堆棧
抽象化堆棧有五個不同的層級:生命周期層(lifecycle)、交換層(exchange)、託管層(custody)、基礎設施層(infrastructure)和基本協議層(base protocol)。列表頂部的抽象層是生命周期層,它向終端用戶隱藏了所有內容,以便為他們提供儘可能最好的用戶體驗。中心化的交易所通常能控制資產的生命周期,並捕獲交換、託管、基礎設施和基本協議等元素。這其中可能包括消費服務,比如基於資產情況提供相應的借記卡。一些交易所甚至可以提供更具擴展的抽象形式(進而上升到生命周期層),比如幕後交易(hiding the trading 『behind the curtain』),以及作為在線經紀人為散戶投資人提供交易經驗。像Robinhood和Circle這樣隱藏所有內容的服務歸類於生命周期層,而一般的加密貨幣交易所則屬於交換層。
鑒於投機行為仍然是這些資產中最廣泛的用例,交換體驗的抽象化對於加密貨幣的大規模應用至關重要。由於本地化服務增加了更多的摩擦、不確定性和風險,中心化的交易所將繼續成為人們獲取和使用加密資產的出入口。最成功的中心化交易所可以提供足夠的交易深度,以實現簡潔順暢的交易體驗和交易安全性(有時以保險的形式)。
在生命周期層和交換層之下,我們還有中心化的託管服務商,他們代表用戶持有資產。在這個抽象層中,有包括像Xapo和Bitgo等託管服務商。這些託管服務商主要以機構投資者為客戶,因為機構也希望通過第三方降低投資風險。大型機構並不會將區塊鏈錢包密鑰管理作為核心競爭力,而許多服務商都擁有自己的責任保險業務。如果客戶希望最終出售自己的資產,這些託管服務商通常還提供資產轉移服務,以便在短時間內將資產快速轉入交易所中。
如果中心化錢包提供商不允許用戶選擇連接到特定的網路節點,那麼他們有時也可能歸屬於這一抽象層級。只要用戶使用錢包提供商的節點連接網路,他們實際上就是允許錢包提供商代表他們驗證交易。錢包提供商也許允許用戶控制自己的私鑰,但是驗證交易的過程仍然隱匿在用戶的視野之外。然而,允許用戶連接到私人節點的錢包服務商給用戶開放了更大的控制權和更少的抽象化(基礎設施現在處於用戶的控制之下),但考慮到對於用戶方面的技術需求,這也會增加一定的摩擦。
DApps仍然隸屬於基礎設施層,它們為用戶提供了更多「點對點」的使用體驗,但仍然默認使用可信的驗證者,如Infura。例如,運行Augur時用戶可以連接到自己的節點,但通常默認只連接到其中一個節點,這樣用戶的使用體驗就好得多了。然而,這一過程訓練著用戶安於「被」提供可信驗證者的服務中——這也不算是件壞事,只是在去信任化(trustlessness)抽象上做出的一些權衡與妥協。像MetaMask這樣的服務在幾乎所有的,基於Web的DApps中使用,它非常依賴Infura連接到以太坊主網。
最底層的抽象層表現為:完全本地化運行個人節點,並從個人節點進行交易。當然,從零售用戶(retail users)角度來看,這種方式越來越受技術派用戶歡迎,因為這通常要求使用者精通技術知識,也渴望獲得極端的控制權。我寫這篇文章的目的不在於批判抽象化或者缺乏抽象化,而是為了說明不同用戶可以通過不同的方法使用網路。我們也不應該排斥那些通過中心化服務使用網路的用戶,或者把他們視為局外人。
有些人可能永遠都不會運行自己節點,抑或離開專註於易用性的抽象層。雖然認識到使用這些服務所面臨的風險很重要,但「做自己的銀行」並不是一件那麼吸引人的事情。銀行業如此繁榮是有原因的,即使他們參與了所有的經濟騙局。這也是為什麼大多數人在知道這種服務背後的隱私風險後,仍然更願意進行數字交易的原因。人們自然而然地會用所有權來換取便利性。
但是,這些系統存在的意義在於,如果用戶願意,可以選擇退出中心化服務。首先,我要表揚一下致力於開發減少抽象層摩擦的各位開發人員,但未來的系統可能將由聚合服務和抽象網路的提供商組成。
抽象化帶來的風險
使用中心化服務可能可以簡化網路的使用體驗,但隨著抽象層級的升高,隨之而來的風險也在增加。以下是一些與抽象堆棧層相關的風險,在特定便利性條件下應考慮這些風險:
安全風險及受損資產
隨著新交易所不斷湧現,肯定也會有許多交易所因為安全問題而關門大吉。他們持有資產數量之多,導致他們一直是黑客攻擊的目標。僅在2019年,我們就已經看到了紐西蘭著名交易所Cryptopia因黑客攻擊而破產,同時最近幣安也因黑客攻擊損失了4000萬美元。儘管這兩家公司都有各自的補救措施,但它們不斷提醒著人們,交易所並不是萬無一失的,有時當交易所受損後,資產可能會徹底丟失。但是,如果用戶打破抽象層,在交易時間前充當自己的託管人,並在交易之後繼續託管自己的資產,就可以有效避免損失。
身份風險和黑名單
任何中心化服務都會有身份數據泄露的風險。今年2月,加密貨幣交易所Coinmama遭遇了數據泄露危機,45萬用戶的用戶名和賬戶密碼遭到泄露。考慮到大多數用戶安全管理意識較差,存在例如賬戶密碼重複使用等問題,這種安全事件的破壞性通常被低估了。過去其他服務的數據泄露還包括KYC記錄泄露。此外,使用可能接受了涉及暗網市場或黑客攻擊的資產的地址,可能導致交易所屏蔽賬戶或者禁止轉賬等問題。
完全停止服務
抽象化、中心化的服務在任何時候都可能會停機並停止提供現有的服務。
基於用戶在不同堆棧層與不同實體交互所面臨的風險而最終構建一種評估框架,將是一項意義重大的舉措。在用戶和上述實體進行交互時,這樣的框架可以給用戶灌輸更多信心,同時也會鼓勵服務實體儘可能地管理好自己的風險評級。當人們沿著抽象堆棧下移時,隨著實體能夠提供的服務越來越有限,風險問題的範圍也隨之縮小。
但更重要的工作是,讓終端用戶認識到他們可以以多種方式下探抽象堆棧。例如,通過鼓勵從個人錢包中提款用於加密貨幣的交易,而將生命周期層降低到交換層。甚至鼓勵用戶建立自己的節點,並用它們來驗證自己的錢包交易。
信息是所有這一切的關鍵所在——見多識廣的用戶即使在最高的抽象層也可能會感到安然自若。
(完)
原文鏈接:
冷萃財經原創,作者:Awing,轉載請註明出處:https://www.lccjd.top/2019/07/31/%e5%8d%81%e5%b9%b4%e4%ba%86%ef%bc%8c%e5%8c%ba%e5%9d%97%e9%93%be%e4%bb%8d%e7%84%b6%e6%98%af%e6%8a%80%e6%9c%af%e5%ae%85%e7%9a%84%e7%8e%a9%e5%85%b7%ef%bc%8c%e4%bd%86%e8%bf%99%e5%b9%b6%e4%b8%8d%e6%98%af/?variant=zh-tw
文章評論