大家好，上次分享我們講解了區塊大小和出塊時間跟擴容的關係， 我們特別的闡述了在區塊鏈的系統中這兩個變量是如何互動和製約的。今天我們會詳細討論在DAG的系統中這兩個變量的關係，以及在Soteria DAG的設計裡，我們是怎麼處理這個問題的。
並發下的親子關係
上一篇我們講到，在BlockDAG區塊圖的大背景下，因為沒有贏者通吃的這一限制，於是礦工們可以並行的挖礦，並及時的把挖出來的區塊廣播出去。網絡的傳輸導致了延遲，所以在網絡的任何一個地方我們能聽到的其他礦工的廣播也可能是不一樣的。不過沒關係，對於我們收到的塊，我們想盡辦法把他們納入到我們的區塊圖裡就行了。而我們下一個要挖的新塊一定要引用我們區塊圖裡的每一個還沒有被引用的塊（也就是葉子節點）。燃鵝，你會發現我們可能收到下圖這樣的一些區塊，他們的引用都不一樣，而且他們都是誠實節點挖出來的合法區塊。這是怎麼回事兒呢？這正是由我們之前談到的區塊大小，傳輸時間和出塊時間所導致的。
假設上邊這個狀態是下圖裡節點B所觀測到的狀態。那麼之所以每個收到的區塊的父輩鏈接不同是因為信息在網絡上傳播耗時不同所導致: 假設網絡因為地理或者邏輯的鏈接被切分成三個傳播區域，綠色的區域夾在紅色的和藍色之間，信息從綠色區域傳到紅色或者藍色區域有一定的延遲，藍色和紅色區域之間傳送信息要經過綠色區域所以延時更大。為了簡單，我們就認為這種跨區域的延遲是臨區域延遲的兩倍。節點A，節點B和節點C分別生成了區塊a，區塊b和區塊c（這幾個區塊的父輩鏈接暫且不討論），他們馬上把區塊向網絡的所有方向廣播出去。在紅色區域的節點D和在藍色區域的節點E和節點F都會在不同時間收到這些區塊。因為節點ABC在網絡上相對於節點D和節點E/F的網絡位置，帶寬，延遲都不一樣，所以他們收到完整的區塊abc的時間也不一樣。所以在某個時刻，節點D只收到了區塊a和區塊b 而區塊c還在傳播的路上；節點E/F只收到了區塊b和區塊c，而區塊a還在路上。節點B最為和出塊的節點最近的節點，除了他自己生成的區塊b以外，所有其他的區塊也都收到了。
當節點D，E，F開始挖下一個區塊的時候，根據“包容”的原則，他們會把新的區塊的父輩鏈接鎖定在他們剛剛收到的這些區塊上，然後再馬上廣播出去。也就是，節點D生成了一個鏈接在區塊a和區塊b的區塊d，節點B生成了一個鏈接在區塊a,b,c上的區塊b'，而節點E和節點F分別生成了鏈接在區塊b，c的區塊e和區塊f。這恰恰是之前我們看到的BlockDAG的狀態。很明顯，區塊a，b'，e，f之間不可能有任何鏈接，也就是說他們都是一代的，或者說他們都是兄弟姐妹。跟之前區塊鏈的構造裡“獨生子女”的政策比起來，在區塊圖的環境下會出現“多子多福”的情況了。我們沒有調整區塊大小和出塊速度，就自動擴容了。而兄弟姐妹的數量就反映著我們擴容的能力。我們暫且叫它K。為了科學地描述K，我們給出如下的表述：對於任何一個節點，當它在時間t的時候產生了一個區塊b；而網絡對區塊的最大傳輸延遲為Dmax，即在任何兩個節點完成傳輸一個標準大小的區塊所需的時間；那麼在如下這個區間：
[t-Dmax, t+Dmax]
也就是
(t+Dmax) - (t-Dmax)
——————————
r
也就是
2Dmax
———
r
所以，擴容能力仍然是被網絡傳輸延遲和出塊速度所製約的，但是這一次，沒有了之前的那些限制了。真的沒有這些限制了嗎？當然不是了。首先，上邊的描述是非常近似的結果，更加嚴謹的結果大家可以參考Phamtom的paper的第四章；另外更重要的是即使是嚴謹的結果放在工程實現的環境下就會出現更多的限制條件，比如接收區塊的處理時間，區塊圖鏈接的時間，區塊的驗證時間。這些時間都直接的影響到實際運行中區塊圖的鏈接特性。所以真正能夠實際操作的並發擴容參數比理論值可能會小一個數量級。從工程的角度上，我們採用了根據應用場景反推K的方法：首先確定一個吞吐量的要求範圍，然後根據系統運行環境的網絡傳輸性能的範圍，確定一個Dmax，之後在Dmax的基礎上認為添加一些軟件方面的延遲，最後把上述幾個參數通過在仿真係統裡多次運行得出一個優化的係數。
