TokenGazer一問到底 | 第九期:研究員 vs Nervos

買賣虛擬貨幣

前言

TokenGazer《一問到底》是一檔辨析區塊鏈領域一級市場專案優劣的優質欄目。每一期將針對區塊鏈領域早期的一級市場專案,邀請專案負責人做客現場,和社群內百餘名研究員深度問答、科學辨析。旨在透過專案方與研究員高質量的對弈問答,打造專業級別的專案評析平臺,釐清專案價值,探尋早期優質專案。同時,讓社群使用者真正參與價值評析,傳遞評析方法,在“問與答”中獲取價值資訊。

本期專案:Nervos Network

活動時間:9月13日 20:00

Nervos致力於構建一個分層架構的分散式應用網路。它把區塊鏈底層基礎設施分為兩層,分別是Layer1和Layer2。Layer1不關注效率,只關注安全及為上層鏈做最佳化,Layer2關注效率效能和易用性。

本次邀請專案方嘉賓:呂國寧Daniel,關於Daniel,可以用一個 Daniel 四件套來簡單解釋:如果你在雲幣(貔貅)交易所買過幣,我曾經是雲幣的CTO。如果你用過imToken錢包,我曾經是imToken的聯合創始人兼CTO。如果你曾經在星火礦池挖過礦,那麼我曾經是星火礦池的管理員。如果你現在關注並準備使用Nervos專案,那麼我現在正在做這個專案。

TokenGazer不久前撰寫過Nervos專案研究報告,點選“閱讀原文”即可檢視。

以下為互動文字整理版:

 01.TokenGazer研究員-L:Nervos採用的是PoW共識,模型設計時是否會有預挖礦的考慮?

Nervos Daniel:Nervos的底層Layer1,這一層會首先採用PoW共識演算法,並且支援挖礦。後續的計劃是準備走混合共識這條路,會兼顧平衡PoW的靈活性和BFT共識的高效。

你問到有沒有預挖礦,其實是有的。我們有一定比例的Token是用於Private Sale的,而Private Sale已於今年6月份結束了。另外有一部分Token作為基金會保留,會被用於包括比如團隊激勵、社羣激勵、以及挖礦獎勵,而挖礦獎勵將會佔大頭部分。

我們認為BTC這種從創世區塊開始,所有的Token都透過挖礦產生,這個模型最公平,也最優美。問題是如果現在採用這個模式,恐怕時間上、資源上都等不到能發展出來的那一天就死了。所以我們有社羣激勵、團隊激勵、Private Sale,並且藉助資本的力量早期加速發展。

02.HD@TokenGazer: 呂總啊,雲幣當年可挺卡的啊......

Nervos Daniel:雲幣非常卡的這個鍋我並不是沒有責任...

https://github.com/peatio/peatio

這是雲幣在github上的開源版本,在15年年中我們離開雲幣之前,其實線上版本跟github上程式碼是完全一樣的。但是雲幣的主要實現用的是Ruby語言,而Ruby語言最擅長的是快速開發,快速原型實現,當流量上來的時候,對系統的擴充套件性挑戰是極大的。

可以這麼說,如果不是用Ruby語言,不會有之後的雲幣,也是因為Ruby語言,我跟Jan(秘猿的CEO,Nervos的架構師)不會以兩人之力就能做出一個交易所。如果當時的技術團隊的人力資源夠強,我們是有實力做出更好的交易所的。

03.HD@TokenGazer:呂總聊聊你們對於PoS/PoW的思考吧,MIT Micali教授(Aglorand創始人)等很多美國學術界認為PoW的能耗問題是需要解決的,ETH也在走這條路,雖然PoS歷史上有很多不安全的問題,你們覺得PoS的改進努力有沒有突破的機會? 

Nervos Daniel:這一點我跟反對PoW耗能的人的觀點角度不同,或者說Nervos團隊對於PoW的能耗問題有自己的看法:

https://www.jianshu.com/p/2dfed83fee1f

這裡有一篇我們的架構師謝晗劍寫的文章,專門解釋了這個問題,在此就不贅述了。 

CKB自身使用PoW共識,透過PoW將CKB與現實世界中的能量錨定。選擇PoW是因為這是目前已知的最為可靠的開放網路共識協議。Nervos網路由此形成一個樹狀的信任傳遞網路:

能量 -> Layer1(CKB) -> Layer2(AppChain etc.) -> DApp

關於PoS,在一條主鏈的情況下,PoW演算法將會成為這條主鏈的瓶頸,而現有的基於算力競爭的PoW演算法,其實已經被最佳化到了效能的極限。如果還想走擴充套件主鏈的道路,那麼就必須在公式演算法層面上替換成更高效的演算法,比如PoS,並且新一代的Sharding演算法和方案都是基於PoS作為基礎的。

但是Nervos的場景不同,Nervos走的是L1+L2方向,效能擴充套件是L2這一層的問題,所以L1的職責是安全和去中心,以及將安全能有效傳遞到L2,所以在L1上首要考慮的是安全而非效能,只要安全能傳遞到L2,效能並不是最高優先順序需要設計考慮的,選擇PoW也是順理成章的。

04.HD@TokenGazer:理解PoW錨定能量的觀點,我想問的是,你們是不是認為PoS在可以預見的時間裡看不到足夠安全的可能性 ?

Nervos Daniel:PoS其實帶來的問題更多,而且很多問題其實是無解的,展開講篇幅過大。我們並不是不看好PoS,而是如前面所說的原因,在Nervos的L1體系設計中,PoW可以很好的滿足我們的需求,並且非常可靠。而PoS一方面缺乏外部依賴性,導致在經濟學安全方面總是備受質疑。另外一方面是沒有在大規模生產環境下經歷多年的驗證,這對我們一個創業創新的團隊來說,是太大的挑戰和風險。

05.TokenGazer研究員-HK:Nervos的L1初始版本用PoW,在現有硬體條件下,如何儘可能提高TPS?

Nervos Daniel:PoW演算法其實有很多種,比如BTC的PoW演算法跟ETH其實並不相同。而最佳化PoW的最關鍵是主鏈的Context,也就是上下文環境。在Nervos場景下,L1的設計思路是儘可能將一切能夠抽離出L1的功能全部抽出來,只保留最後不能抽離的部分,並且我們在L1上採用的是鏈下計算,鏈上驗證,並且執行驗證的VM虛擬機器是圖靈不完備的,刻意這樣設計,以及L1的功能只做到最小的去支援L2... 這些都是限定,有了足夠的限定,就非常容易去定製最佳化PoW的演算法和引數,以榨取出所有的硬體/網路效能。

我們會在10月或者11月左右釋出我們的PoW共識演算法白皮書,屆時大家會看到我們是如何在一個限定的主網下充分最佳化PoW演算法,以及我們在PoW演算法實現中一些新的idea是如何去最佳化,實現更好的共識演算法效能的。

06.TokenGazer社羣成員 林燚:對於公鏈開發,目前有一種說法,公鏈在開發時,處理速度、社羣共識等方面,難以做到全而美,咱們的專案是怎麼考慮這個問題的?又是如何處理的?

Nervos Daniel:一切都在我們的白皮書中都有描述,我們是透過技術手段把當前的區塊鏈底層基礎設施向前推進一步,解決大規模商業應用場景落地的擴充套件性問題,並且採用L1/L2分層設計這條路。具體的展開實在太大,容我以後還有機會拆成幾個不同的話題來回答吧,謝謝。

07.TokenGazer社羣成員 林燚:同樣也是分為兩層,這與區塊鏈基石專案有何不同?

Nervos Daniel:目前的區塊鏈擴充套件分三條路:

① 擴充主網路,用更高效的共識演算法,以及Sharding分片,代表是ETH;

② 分層,用二層擴充套件,代表是Nervos;

③ 放棄去中心化,放棄安全性,代表是EOS

在②這條路上,如果只有Nervos 這一家,就顯得太過冷清了吧。

08.TokenGazer社羣成員 王備-Sofer:從投資的角度,我們不該注意專案是否夠好,而是要關注專案是否會被低估,實際上EOS等都不是差專案,但高價不會讓投資者受益。

Nervos Daniel:你們為什麼要關心投資啊?我們難道不應該關心下一代區塊鏈基礎設施應該怎麼發展?

TokenGazer 研究員:瞭解好技術本身才能更好地幫助我們做判斷去投資。

TokenGazer社羣成員 王備-Sofer:不過從反應來看, Nervos 今天完全沒準備問道投資價值的問題。

Nervos Daniel:我以為大家都是來懟白皮書的。

09.TokenGazer社羣 逍遙哥:輕節點和輕客戶端是否主要為移動端考慮而設計的?

Nervos Daniel:輕節點其實也是服務端節點,如果你是一個DApp服務提供方,你可能需要自己維護一個輕節點。這個輕節點不需要參與達成共識,也不需要儲存整個Cell的完整歷史資料,只需要儲存當前的整個“世界狀態”,就能很好的提供服務給DApp的客戶端,比如手機錢包等。對於DApp服務提供方來說,輕節點可能是必須的。或者網上可能會有一些人作為信任的第三方提供節點服務。

10.TokenGazer研究員-HK:L2有多種不同的方案,那麼跟L1之間的通訊方式也不會是一種。Nervos目前有沒有對這個的解決方案的考慮?

Nervos Daniel:L2有多種不同的方案,但是所有的L2的訴求其實都一樣,比如如何將L1的資產對映到L2,並保證在需要的時候安全的回到L1層清算,比如在使用者退出L2的時候如何保證使用者的財產不受損失。

從這個角度出發,其實是可以抽象所有L2的需求的。從Nervos的角度,所有的L2不管採用什麼方式去跟L1通訊,都可以抽象成在L1上提交資料、驗證、儲存。基於這一點,Layer1的設計目標就是對所有的L2的抽象層提供支援,然後再以各種adapter或者擴充套件的方式支援L2。

目前還沒有任何一個L2方案可以很好的去跑在目前的L1(BTC,ETH)上,一方面L2自己的方案還在迭代,並用各種奇技淫巧去想辦法適配現有的L1。我們的策略是在很早的早期去接觸各種L2的團隊,學習、理解他們的方案搞明白他們的需求,然後在我們的L1這一層設計的時候就直接支援他們。甚至請求這些L2的專案方能在早期就考慮支援Nervos的L1。尤其是開源的L2專案,對於重點專案,我們是有能力去直接參與到對方的開源開發流程中,幫助他們去完善對Nervos的支援,或者我們fork一份對方的程式碼,維護一份針對Nervos的L2來支援Nervos。

11.TokenGazer研究員-HK:L2的哪些資訊記錄在L1上由使用者決定,這個操作復不復雜?使用者如果不知道該把哪些重要資訊記錄在L1,Nervos會有相關指導嗎?

Nervos Daniel:其實,準確的說,L2什麼資訊存在L1上是開發者決定的。Nervos的經濟模型設計的一個核心要點就是想辦法迫使開發者不要針對L1直接開發DApp。雖然直接針對L1去開發DApp是可行的,但是這相當於你在北京的核心地區買了一塊地,但是選擇蓋四合院,而不是摩天大樓。針對L1直接開發DApp就是蓋四合院,針對L1跑一條L2的鏈,然後在L2這條鏈上做DApp並給使用者提供服務就是蓋摩天大樓。摩天大樓的空間效率更高,但是佔用更少的地皮。

一個道理,Nervos的經濟模型設計會迫使開發者在Nervos的L1上用更少的儲存去支援更高效的L2方案。而使用者最理想的情況是拿來就用,根本不要去關心你在用L1還是L2,以及L2上什麼會存到L1上,以及一旦出現L2上礦工作惡,或者對手方欺詐作惡,整套系統能從L2上退出,在L1上執行仲裁,並確保使用者的資產不受損失。

所以Nervos對於未來整個生態上L2的設想,是L1作為所有L2的註冊器,以及提供針對L2的仲裁,在儲存方面只需要儲存L2的block hader或者Merkle Tree的Root。採用儲存Merkle樹的Root的方式,可以用非常小的儲存空間來證明整個樹的資料一致性。因為在L1上儲存資料是有成本的,而L1上的儲存空間是跟Token總量對應的,那麼如果整個系統的總價值越高,平均到每個Token單價會越高,那麼會迫使L2的維護者用更少的L1空間去支援L2。

綜上所述,Nervos透過經濟學的方式迫使開發者決定存什麼,不存什麼,而不是指導。

12.TokenGazer社羣成員 AV數字化教主|Viviyorg|周鵬:如果基於網路層角度看,Nervos是不是在中心化網路上做去中心化的?基於瞭解的深入,感覺Nervos在儲存理念上與市面上如IPFS/ELA等分散式儲存有些衝突,請問呂老大怎麼看? 

Nervos Daniel:我並沒有完全看懂這個題目。

Nervos是在當前的整個網際網路IT基礎設施上做去中心化的服務,這點跟BTC/ETH並無分別。

Nervos在儲存理念上跟IPFS區別非常大,首先IPFS上儲存的任何資料都不需要驗證,並基於驗證達成全部節點的共識,而Nervos的Cell中儲存任何資料都需要共識的參與。我覺得更簡單的回答是:Nervos的L1 做的事“達成共識並儲存”,IPFS是去中心化儲存。

13.TokenGazer研究員-L:在Nervos中,Token可以用來購買Cell儲存空間,Cell空間用於支撐L2擴充套件應用。如果Token價格劇烈波動或者Token聚集到了少數人手中,這對於開發者或者是商業應用非常不利,這個問題如何解決?

Nervos Daniel:其實在任何一個不成熟的市場,價格劇烈波動是因為供需不平衡,或者價格發現機制失效,透過制度,或者機制設計去平抑價格在所有過往的人類社會實踐當中,都是被證明是失敗的。

一個生態有投機者,有開發者,有使用者,所以在價格博弈層面是各種複雜的情況交織的,在這一點上我個人信奉自由市場經濟,我相信來自市場的調節,當然短期內的確有失效的時候,但是我看長期(不好意思我不是經濟學科班出身)。如果Token聚集到少數人手中,那麼會抑制商業的繁榮,然後會反饋到Token價格本身,並且未來Nervos一定會面對來自外部的競爭,這些都會對沖Token過於集中的問題,再加上Nervos會有大量的Token是透過PoW挖礦的方式distribute的,所以我並不擔心Token集中。

14.TokenGazer社羣成員 雨-林:我可以在Nervos上發自己的Token麼?如果可以,Nervos會不會有官方教學文件?Nervos鏈上的主要開發語言是什麼呢? 

Nervos Daniel:答案是可以,並且可能比在Ethereum上用ERC20協議部署一個合約來發Token還簡單。Nervos肯定會有官方教學文件,毋庸置疑。Nervos底層CKB鏈,以及Nervos自己的L2方案AppChain的主要開發語言是Rust,一門現代的、高效的、安全的系統級語言。

http://teahour.fm/2018/07/08/how-to-build-blockchain-from-scratch.html

這個連結是我、Terry、還有Kevin做了很多年的一檔硬核技術prodcast,這期就是我作為主持人採訪我們的核心架構師Jan,其中提到了他如何用Ruby自己手擼一條Ethereum鏈,以及為什麼他選擇用Rust作為區塊鏈的首選開發語言,特別推薦希望學習區塊鏈底層開發的朋友去聽。

15.TokenGazer社羣成員 雨-林:想知道從Solidity遷移到Rust會不會很難,Nervos CKB開源了以後開發者可以做些什麼? 

Nervos Daniel:Solidity是一門語言,是Ethereum上一種給EVM寫合約的語言,Rust是一門系統級別語言,用來做區塊鏈,或者任何高效能分散式系統的語言。 

兩者不能混為一談,Nervos CKB開源後,當然是吸引全世界最好的開發中,在全世界範圍內跟其他專案去競爭。

16.TokenGazer社羣成員 王備-Sofer: 巧舌如簧讓我產生了疑慮,也就是大多數人會高估nervos的價格。從投資的角度,我們不該注意專案是否夠好我的意見代表個人的投資建議,從迴避話題的經驗看,你是個老司機了,這更加劇了Nervos被過高期待的可能性,被高估的專案有很多,Nervos做得不錯,但我更傾向於歸結於價格容易被高估,投資者受損的那種。

Nervos Daniel:我不建議各位投資任何自己有疑惑,或者不理解的專案,我們是做基礎設施的,我們的關注點並不在投資層面,這些問題留給大家。

17.TokenGazer社羣成員 宋城:前幾天說圖靈獎攻克不可能三角問題,Silvio Micali教授及其團隊正式推出Algorand協議。其因突破區塊鏈“不可能三角”而備受技術人士的關注。呂總有沒有看到,可以聊一下嗎?

Nervos Daniel:前面我回答了,我對Micali的方案理解不深,我希望十一長假的時候,能抽一點時間去認真學習研究一下。但是我不信區塊鏈主鏈設計的不可能三角是可以突破的,這是哲理層面的問題,雖然有些形而上,但是我更願意相信是媒體和PR的需要,而不是這個不可能三角經不起推敲。

18.TokenGazer社羣成員 AV數字化教主|Viviyorg|周鵬:Nervos有沒有類似於HyperLedger開放各種API/SDK/CLI介面呢? 

Nervos Daniel:目前Nervos CKB還在開發中,我們預計下個月會全部開源,包括文件。目前Nervos的L2方案AppChain已經開源,包括鏈,手機錢包客戶端,區塊鏈瀏覽器,各種 SDK,CLI,以及文件,具體見:

http://appchain.nervos.org

19.TokenGazer社羣成員 逍遙哥:CKB中Cell capacity的設計是否有借鑑EOS的地方?

Nervos Daniel:Cell capacity的設計並沒有什麼地方借鑑過EOS,這是我第一次聽到有人這麼問,能否詳細問一下什麼地方你覺得有共通之處?我可以展開解釋。

CKB提出的Cell model的整體設計背後,其實是一整套完整自洽的設計哲學和邏輯,這些邏輯放在一起,推匯出Cell model是一件非常自然而然的事情,如果時間來得及,恐怕得用半個通宵來細細闡述......

20.TokenGazer社羣小群秘 場外提問:想知道Nervos對Algorand這個專案的看法?

Nervos Daniel:因為對Algorand理解的還不深刻,所以怕回答方向弄錯。我只能承認因為最近半年多,實在太忙了,研究其他專案的技術細節已經跟不上時代了,特別抱歉。

我冒死談談我對確定性隨機函式的看法,不成體系。首先隨機確定性函式,可以做到隨機的選擇全部節點中的一部分子集來達成共識,因為隨機子集在產生之前是不確定的,但是在之後又是可以驗證的。這裡跟我們在Layer1這一層追求的達成最廣泛的全域性安全共識有一定衝突。

我們認為,Layer 1的安全性是由全域性達成共識來保證的,而且目前以BTC等PoW主鏈為代表的主網,演算法和安全性經歷了多年的生產環境級別的檢驗,這才叫真正的安全讓人放心。而一種新的演算法,還未經過生產環境監測,並且其達成共識的範圍是一個子集,子集達成共識的範圍的安全性的極限是全域性共識安全性,所以我們需要最大範圍的共識安全性,所以我們願意保守一點,選擇在Layer 1這一層直接做全域性共識,並且使用經過多年驗證過的成熟方案。

責任編輯:ToeknGazer

本文為TokenGazer原創內容,轉載請註明出處。  

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;