12月27日，Conflux受邀參與TokenGazer舉辦的在線問答活動，Conflux CTO伍鳴博士與參與活動的百餘名研究員進行了深度問答、科學辨析。此次活動讓大家深刻的瞭解到Conflux的技術優勢和發展潛力，也讓更多人對Conflux的未來發展堅定了積極的信念。
（以下爲此次活動的文字整理版）
問題1：Conflux使用的有向無環圖（DAG）跟比特幣、以太坊的區塊鏈結構有什麼具體不同，優勢是什麼？
伍鳴@Conflux： 這個問題是一個非常本質的問題，我願意展開來談一談，這要從比特幣的效率侷限性談起。根據一些論文，在比特幣協議中，無論如何調整出塊速度和區塊大小這兩個參數，速度與安全不可兼得。
這其中的原理是什麼呢？我們想象一下，如果兩個區塊都是由誠實節點生成的，但是因爲網絡延遲，他們在生成的時候互相沒有看到對方，那麼在兩個不同的分叉上，那麼它們就會在不同的分叉上。一旦進入到不同的分叉上，二者便是你死我活的競爭關係，最終有一個區塊被丟棄。誠實節點的區塊被丟棄，損失的誠實節點的總算力。
分叉越多，好人區塊的內訌越多，壞人的攻擊門檻越低，比特幣越不安全。爲了安全，比特幣必須維持一個低的吞吐量。
Conflux使用有向無環圖結構 (DAG)，我們允許每個區塊引用多個區塊作爲自己的祖先區塊，可以避免好人之間的這種競爭，從而打破比特幣的矛盾，在提高效率的前提下不犧牲安全性。
以太坊與比特幣相比特殊一些，以太坊其實有了DAG的雛形。關注區塊鏈技術的朋友可能知道，以太坊中有叔塊的概念。一些區塊選一個父塊，幾個叔塊，看似也構成了一個DAG。但是，以太坊的叔塊只是爲了給沒有進主鏈的區塊發一點鼓勵安慰的系統獎勵，叔塊中的交易依然會被丟棄。如果將以太坊的出塊速度提高，導致分叉過多，其有效吞吐率依然很低。
下面有圖可以更好地展示優勢，這張圖展示了4MB大小區塊下不同出塊時間下被保留區塊的數量。Conflux保留了所有區塊，比特幣和Ghost (以太坊協議改自這個協議) 則由於分叉丟失了大量的區塊。
總結一下：
①Conflux是和比特幣、以太坊類似的PoW公鏈，但允許一個區塊引用多個區塊作爲祖先，從而構成一個DAG。
②比特幣、以太坊的實際吞吐率很低，即使你嘗試減少出塊間隔或者增加區塊大小，也無法得到一個安全性和效率兼得的公鏈。
③和比特幣、以太坊相比，Conflux可以在不犧牲去中心化和安全性的情況下，提高吞吐率。
問題2：基於DAG的智能合約會遇到“交易順序問題”，比如誰先預定到某航班的座位跟交易順序有關，Conflux有沒有比較好的設計解決這個問題？
伍鳴@Conflux： “預定航班座位”是一個很好的例子，從這個例子可以看到，在DAG中，如果不同的交易需要競爭合約中的資源（比如航班座位），區塊排序與交易排序是一件十分必要的事情。這將決定誰的交易在前，誰的交易在後，誰最終得到了這個座位。
也是因爲這一點，我們需要對DAG中的區塊設計一個拓撲排序算法，將所有區塊排一個順序，然後根據區塊的順序決定交易的執行順序。而且這個拓撲排序需要滿足以下幾點：
· 一致性：不同礦工節點排的結果是一致的。如果一些礦工告訴你選座成功，一些礦工告訴你選座失敗，你就會很困惑。
· 安全性（不可更改性）：排序結果不能被壞人的攻擊更改。比如說，你選了一個座位，5分鐘後，這筆交易確認成功了，你很開心。三天後你登機的時候，發現排序發生了更改，你的座位沒了。這也是很嚴重的公鏈安全事故。
Conflux設計了一個滿足上述要求的安全拓撲排序算法，算法輸入一個DAG，輸出DAG中區塊的一個拓撲排序。每個礦工（全節點）將本地機器的DAG上輸入這個算法，就可以得到區塊排序，根據這個結果，就知道了應該先執行誰，後執行誰。
“一致性與安全性”可能比較抽象，我們舉個例子。今天，這個DAG中有10000個區塊，9900個區塊裏的交易已經被確認。明天，這個DAG有20000 個區塊，那麼把明天的DAG和今天的DAG分別作爲算法的輸入，前9900個區塊應當是一樣的，哪怕有壞人在做雙花攻擊。這就是一致性與安全性。
Conflux 的算法設計可以保證一致性與安全性。關於這個排序算法具體是如何設計的，感興趣的夥伴們可以閱讀我們的論文或者科普文章。
總而言之，Conflux通過設計安全的拓撲排序算法，解決“交易順序問題”。
問題3：如何解決不同區塊內的打包交易的交易衝突問題，瞭解到當交易衝突時時間稍後的衝突交易會被“discard”掉，這個被丟棄的交易是怎樣和有效交易進行狀態區分的？
伍鳴@Conflux： 在問題2中，我們已經解決了交易順序問題。那麼當所有節點對DAG得到一個一致的區塊排序時，只要遵循一個規則：“發生重複或衝突者，排序居後的交易無效”，就可以判斷哪些交易是無效的交易，然後自己在本地標記一下就行。區塊排序的一致可以保證“無效交易標記”的一致。
額外說一點，由於每筆交易是否有效是每個礦工自己做出的判斷，而沒有持久化寫在區塊中，所以無法實現像比特幣那樣，通過Merkle Path向輕節點證明一個交易在區塊中，因爲你無法通過Merkle Path知道它是有效的還是無效的。但是，Conflux採用賬本模型，每個區塊頭會存儲當前賬本狀態的哈希值。通過這個哈希值，很容易向輕節點證明指定地址的餘額等。
總結一下：
①被丟棄的交易由全節點本地進行標記，一致的排序結果保證一致的標記。
②基於這一點，Conflux輕節點的交易驗證與比特幣有所不同。
問題4：那無效的交易會被追加一個狀態麼，或者說我在區塊瀏覽器只查看交易哈希時，能否看出這兩筆交易（有效和無效）的區別?
伍鳴@Conflux： 交易是否無效可以看成是交易執行的某種結果，這種結果狀態是可以記錄在區塊中的，這樣，在區塊瀏覽器中就可以查到這種狀態。
問題5：這個交易執行結果是標記在本地還是在鏈上？
伍鳴@Conflux： 標記是在本地，但鏈上也會有所提現。之前的回答中其實提到，每個區塊頭會存儲當前賬本狀態的哈希值，通過主鏈區塊的賬本狀態，會體現歷史區塊中每筆交易是否有效。
問題6：跟其他鏈不同，無效的交易不會記錄在鏈上，Conflux是需要對無效交易本地打標，這是否可能對不瞭解的用戶有學習成本，以及利用這一點來混淆用戶的可能?
伍鳴@Conflux： 通過瀏覽器提供標記，可以幫助普通用戶判斷一筆交易是否有效。
問題7: DAG結構中不存在“叔塊”問題，網絡中是否會存在過多的空塊或者區塊中的交易重複導致區塊數據冗餘，從而對節點的網絡和硬件配置帶來壓力？
伍鳴@Conflux： 首先，DAG中每一個區塊都是需要消耗算力才能生成的，所以網絡中各種區塊，無論是正常的區塊還是空塊，其數量受挖礦難度的制約，是有一個上界的。所以，對節點的網絡和硬件不會帶來額外的壓力。
其次，空塊或重複交易過多確實會影響利用率和實際的交易吞吐率。所以我們需要爲礦工們設計一個交易選擇算法，從交易等待池中，根據交易費加權隨機抽取交易，以最大限度避免交易重複。這個算法的設計應當考慮激勵兼容性 (Incentive Compatible)，以從經濟激勵上鼓勵礦工遵守這個算法。
問題8: 這個算法是否已經完成？
伍鳴@Conflux： 這個算法的設計和理論分析已經有了，現在在我們的系統中開發實現，還沒有完成。
問題9：理論基礎就是姚教授的新論文？
伍鳴@Conflux： 姚老師的論文是基於比特幣進行分析的，對我們這個算法的理論基礎有一定的啓發。
問題10：項目是否會進行預挖？主網啓動後礦工獎勵是否會有變化，樞軸鏈和分叉鏈上的區塊的區塊獎勵是否一樣。
伍鳴@Conflux： 和以太坊一樣，創始塊會分配一定比例的代幣。每個區塊的基礎系統獎勵開始比較多，時間長了以後會逐漸減少。
在 Conflux 中，每個區塊的系統獎勵不是一個固定值，是根據一個規則算出來的。樞軸鏈和分叉鏈的區塊獎勵計算規則是一致的。
（小編注釋：在介紹這個規則之前，我們先來考慮一下一種情形。在Conflux 規則裏，每個新的區塊應該選擇一些引用邊，使所有已經存在的區塊成爲它的祖先。(具體的選邊規則參見我們的文章)。但是一個壞人可能會出於某種目的，在挖出一個新的區塊時，假裝沒收到或沒看見一些區塊，以獲取更多的交易費。我們就要懲罰壞人這種行爲，假裝沒看到的區塊越多，這個區塊的區塊獎勵越少。）
如果要具體地描述這個規則，就要先講一個概念：“光錐外區塊”(anticone-block)。什麼是“光錐外區塊”呢？在DAG中，如果兩個區塊之間沒有一條路徑，這兩個區塊的互爲對方的 “光錐外區塊”, 比如在下圖中，B和C互爲對方的光錐外區塊。
一個區塊的系統獎勵會與基礎系統獎勵和它的光錐外區塊的數量有關，光錐外區塊越多，其獎勵越少。（小編注釋：當壞人挖出一個新區塊時，那些假裝沒收到沒看見的區塊，都會成爲新區塊的“光錐外區塊”。）如此設計，是爲了鼓勵每個礦工遵守選擇引用邊的協議。
問題11：項目預挖的比例是多少呢。還有區塊減少的規則（比如比特幣每隔4年減半）？
伍鳴@Conflux： 這些具體的數據會在我們主網上線之前公佈，大家可以關注我們的公衆號。
問題12：這個設計的會讓區塊內的獎勵會有不同，礦工要額外技術要挖快的預計獎勵對吧？那這樣的話，幣的數量是否會有不確定性？因爲區塊的獎勵不確定，導致一年之後挖的幣的數量不可控？
伍鳴@Conflux： 這個設計會讓區塊內的獎勵有不同，但是，在正常情況下，這個差異不會很大。我們希望用這個差異，來鼓勵礦工們遵守協議。
問題13：Conflux預計主網上線是什麼時間，TPS能達到多少。
伍鳴@Conflux： 我們的測試網預計在明年3月份上線，主網上線預計在明年Q3或Q4。
---
小編：
在這次在線問答中，我們發現很多關心區塊鏈的小夥伴對獎勵機制和挖礦規則很感興趣，我們會在後期特別推出一篇關於此話題的技術文章，歡迎小夥伴們關注我們的公衆號來隨時掌握更新狀態！
