2 月 8 日，EOS 創始人 BM 接受 Ivan 直播專訪，前兩趴譯文我們已在發佈在公衆號上：

第一段
&
第二段
（戳藍色鏈接回顧）

老規矩：灰字是譯者註記，讓你的理解如絲般順滑；採訪鏈接附在文末，需要科學上網才能領略哦 ~

今天是：

第三段 · 初二

問 16：Vitalic Buterin 正牽頭對以太坊動大手術，你怎麼看待這場改進？目前他們計劃用 Casper 解決現存問題，你是否認爲這會有效？

BM：Casper 能影響的層面在於共識，對於執行層面並沒有幫助。

以太坊註定要經歷一個艱苦漫長的升級，因爲手術涉及很多底層技術架構，包括計算資源管理和核心要素間的交互。

我認爲把以太坊轉向全新架構的難度不亞於把 Bitshare 變成 Steemit，Bitshare 社區不會支持開發者，以太坊礦工也不會支持整個社區。

所以這幾乎不可能做成，因爲以太坊的任何改動本質上塗着利益分配的底色。

如果這一系列事情不斷髮酵，人們終將認識到：任何微小改動（比如比特幣區塊大小）都極其艱苦，就更別提修改共識、虛擬機或整個安全理念了。

· · ·

問 17：有人認爲分片（Sharding）能將一種狀態切分爲多種子狀態，而這些子狀態相互間無需知曉彼此情況，這樣能增強以太坊的性能。你認爲這種方式是否太過複雜，你有什麼建議？

譯者：分片是把一個數據文件切分成的多個部分放到不同的數據庫上，從而提升單一數據文件的性能，相當於你把一週五天的課程表剪成五條，每天揣一條上學。

BM：分片在性能方面類似這樣的場景：

有人把一捆 286 處理器接到一個 14K 的調制解調器上，然後指着這說：“你看，這堆東西可牛逼了，性能可以媲美 Intel 的 20 核處理器，因爲我們會做分片。”

分片容易，但分片後的通信卻很難。

即使理論上分片能提升交易處理性能，但卻面臨着一對內生矛盾：量和質。

也就是說，也許分片能增加某類交易的吞吐量，但是不可能增加交易的類別，而恰恰是交易類別的多樣性（即：質）纔是 Dapp 開發者真正關心的東西。

反之，如果分片支持了交易類型的多樣性，那交易吞吐速度一定上不去，這就是一對不可調和的矛盾。

另外，分片之後，片與片之間的通信會大大降低處理速度。所以，我不認爲分片（Sharding）是一個好辦法。

· · ·

問 18：以你做 Bitshare 和 Steemit 的經驗，你看出以太坊的上述問題，這些問題是你做 EOS 的理由嗎，或者還有其他什麼理由？

BM：我起步做 EOS 時的確有很多經驗，我也知道去中心化系統開發者真正的需求。我學了很多模式和設計思路，不斷重複打磨。最終，我並不只想做 Bitshare 或者 Steemit 那樣功能單一的應用，我要做的是一個通用系統，這就是我做 EOS 的緣由。

EOS 是一個動態通用型區塊鏈平臺，能建類似於 Bitshare 和 Steemit 的應用。它彙集了我們之前所有的開發經驗，EOS 的性能水平更高，因爲 80% 的功能都通過本地代碼實現。

此外，EOS 還引入 Web Assembly （由谷歌、微軟、蘋果等幾家大公司合作發起的項目，這個項目是面向 Web 的通用二進制文本格式，已在改變 Web 生態），這能讓開發者使用 C++語言，而 C++有着極其豐富的類庫，這樣你能實現你想到的任何功能，而這些都能被用到智能合約上來。

可如果用自有語言 Solidity 寫智能合約，你就得重頭開始自己寫類庫，重新發明一遍輪子。坦率地說，我們把 EOS 的代幣發佈合約建在以太坊上，後來發現程序竟然不能超過 300 次迭代，因爲 Gas 會被消耗完。

譯者插嘴：以太坊本爲執行智能合約而生，爲了抵禦黑客攻擊或被無限循環 bug 耗光全網資源，於是設計了 gas 的概念，即：執行任何+、-、×、÷都要消耗幾兩 gas，而 gas 是要論斤買的，於是表面上消滅了死循環的可能。

但沒想到按下葫蘆起了瓢，雨後春筍地冒出如山的問題，這一連串問題就像一個個青銅枷鎖一樣，套在以太坊的脖子上，BM 所說的“無法多次迭代”問題只是其中之一。

BM 總結：所以這些都註定以太坊上不可能建通用的大型應用，比如訂單系統，因爲它的語言和內存模型都難以支持簡單操作，比如索引或排序，即使能做也無法高效地做。

· · ·

問 19：EOS 最爲人矚目之處在於共識算法 DPOS，談談你發明 DPOS 的經過吧。

BM：我第一版做的 DPOS 鎖定了 101 個生產者，它們都經投票選舉產生，Bitshare 2.0 （以及石墨烯）把 101 這個數字調整爲可由用戶自定義，以便當人們投票時，在通過票數上可以自由調節。

這讓我們觀察到一個社區真正能被票選的節點數，我們發現，當一個社區處於可控狀態時，可票選節點數通常在 15 個左右。所以在做 Steemit 時，我決定把這個數字設定爲“略高於 15”的 21，這樣就能更加“去中心化”地運行。

在 Bitshare 最初的版本里有個問題：101 個不同的生產者其實可能是同一個人，但社區無法審查這點。

所以，儘管理論上有 101 個節點，但實際參與產塊過程的最多也就其中 20 來個節點，而這 20 個節點的背後也就 4-5 個實際控制人。所以在做 EOS 的時候，我們敲定的節點數是 21 （投票節點必須是奇數，否則會出現長期分叉）。

這 21 個節點的處塊順序選由系統隨機設定，並且隨時會變， 這樣既能有效率地升級，同時也能避免硬分叉。

Ivan 總結：我想現在大家都有點明白以太坊是如何工作的了：智能合約代碼需要在每個節點上執行，於是這自然就不是一個可擴展的方案，更不用提當網絡變大、節點變多的情況了。那時每個節點需要和更多節點通信，如果有些代碼只能在這臺電腦上跑、卻無法在其他節點上運行跑，那就慘了。

· · ·

問 20：EOS 上執行代碼是不需要過所有節點的，因爲如你所說，EOS 只有 21 個節點，所以請解釋一下，一個本來跑在以太坊上的 Dapp 應用，如何在 EOS 上執行？

BM：這裏要糾正一下你的誤解：

21 個指的是 21 個區塊生產者，但與此同時，全網有無數個驗證者，所有驗證者都運行全節點數據（run everything）。

· · ·

問 21：如果每個人都運行全節點數據，那和以太坊相比，EOS 的延展性如何？

BM：

What we\’re trying to do is scale the decision-making over who\’s running everything,

我們做的是擴大有權決策者的規模，而不是運行全節點的人才有權拍板。

以 POW 爲例，它的利益分配只會傾向於那些有錢、有算力的人，而錢和算力很容易獲取，比如政府補貼你一把就有了。但 DPOS 不同，每個持有權益者都有權投票，這使得全網很難被控制。

DPOS 讓每個人對正在發生的事情都有發言權，因此控制力將更分散，從而使系統更具可擴展性。同時，票選出來的 21 個區塊生產者將更專業，他們可以位於數據中心，這些數據中心擁有更高性能的硬件，甚至組成服務器集羣。

我相信大多數成功的 Dapp 應用最終都將變成網站，就像 Steemit。

所以說，正常情況是由一組服務器去支持一羣輕節點，這樣的商業模式才能讓服務提供商有更高性能的硬件。

礦工投了幾十億美元在硬件上，而硬件除了哈希運算之外什麼都不做，在這點上 EOS 的 DPOS 與比特幣的 POW 一樣——除了驗證區塊和輸出結果。

所以，EOS 上的生產者即使掌握了算力資源也無法作惡，作惡也沒有任何收益，所以它並不會像 POW 的系統那樣最終走向中心化。

第三段 · 完