提高ctps實驗

目標

1. 提昇 Tangle 整體的 CTPS
2. 縮短交易確認的時間

提昇 CTPS

Milestone是coordinator發的交易

以目前來講 , 只選兩筆交易去驗證

由於milestone最多選四個tip

所以加速的想法是 ： 減少tip到兩個以下

用圖來說明

假設

$\text{color}reda$ 是 milestone

下一個milestone

$\text{color}redf$ 出現的時候 , 可能會指向

$\text{color}blue32$ 與

$\text{color}blue42$

那

$\text{color}blue11$ ,

$\text{color}blue12$ 和

$\text{color}blue22$ 都不會確認

發交易讓

$tips$ 只剩下一個或兩個

綠色的

$\text{color}greeng1$ ,

$\text{color}greeng2$ ,

$\text{color}greeng3$ 是特別發起的交易 , 這樣就能使

$tip$ 只剩下一個

如此 milestone前的交易都能是確認

對 tangle 的影響

是不好的影響

洗到只剩下1個或2個交易

這代表有衝突交易的話 , 會都被指向

以基金會的確認度算法 , 衝突交易都是確認的

算法

這邊不確定的是milestone是如何選交易的 , 所以需要多個算法來驗證

第一種

直接的作法是:

1. 用

   $getTips$ 拿到全部的
   $tip$

2. 發交易 , 從

   $tip$ 選兩筆驗證並移除 , 重複直到
   $tip$ 為空

3. 重複1,2的動作直到

   $getTips$ 查詢只剩2個或1個的交易

這作法可能會讓衝突的交易被驗證

測試結果

先針對2.做測試

default_address="BXEOYAONFPBGKEUQZDUZZZODHWJDWHEOYY9AENYF9VNLXZHXBOODCOTYXW9MGGINTEJPLK9AGOPTPODVX"
result = open("result","w")
result.write("tip number:"+str(api.get_node_info()['tips'])+"\n")
start_time = time.time()
tipset = api.get_tips()
tip_number = len(tipset['hashes'])
i = 0
while i < tip_number :
    trunk_and_branch = {'trunkTransaction':tipset['hashes'][i],'branchTransaction':tipset['hashes'][i+1]}
    send_transfer("","",default_address,0,trunk_and_branch,0)
    print (i/2)+1
    i = i + 2
result.write("tip number:"+str(api.get_node_info()['tips'])+"\n")
end_time = time.time()
result.write("Duration: " + str(end_time - start_time) + " seconds\n")
result.close()

以下是一些數據

第一次

tip number:6934
tip number:9126

第二次

tip number:5024
tip number:6148
Duration: -3906.22797012 seconds

第三次

tip number:9992
tip number:9997
Duration: 7733.29529405 seconds

第四次

tip number:9930
tip number:9996
Duration: 7734.10981297 seconds

第五次

tip number:5048
tip number:6068
Duration: 3963.071908 seconds

會發現

$tip$ 的數目沒有下降

$tip$ 數目沒有下降的可能原因

• $tipset$ 不是最新的

在

$tipset$ 選兩筆被驗證的交易 , 這兩筆可能已經被其他

$node$ 發起的交易驗證了
所以

$tips$ 數目不會減少 , 反而會增加

• 其他
  $node$ 也會發起交易

其他

$node$ 發起的交易不會在

$tipset$ 裡面 , 所以也驗證不到

小結

可以看得出來 , 這方法需要的時間是比較長的 , 不是一個效率好的方法

第二種

從上面的實驗 , 削減整個

$tip$ 的數量不太實際

另外 , 最好的情況就是單位時間內發的交易都確認
由於 milestone 的發送頻率是 coordinator 控制的
所以最多就是讓單位時間內新發起的交易都確認

新的方法如下:

1. 用
   $getNodeInfo$ 拿到
   $lastestmilestone$ 的交易hash
2. 從
   $lastestmilestone$ 為起點 , 找出會直接或間接驗證到的
   $tip$
3. 發交易減少這些
   $tip$ 的數量

縮短交易確認的時間

一定不會被 milestone 驗證的 tips

由於 IRI 1.5.0 的更新 , Tangle Accelerator (iota-swarm-node ) 可以用

$getTips$ 而不會出現不被 milestone 驗證的情況

具體來說 , 修改 IRI 的 code , 讓

$getTips$ 內的 tip 都經過檢查

這樣 Tangle Accelerator 就不會發起永遠 pending 的交易了

參考實作

WalkValidator.isValid

TipSelector.getTransactionsToApprove

Pending tips 去除不會被 milestone 驗證的交易

這邊由於都是 pending , 連不是 tip 的交易也是

個人看法 , 需要實作共識演算法的一部份(沒有 Coordinator 的情況) , 主要是 trunk 與 branch 的選擇與檢查的問題

理論

驗證交易的選擇

最近的CTPS

這是上週三(8/22) , spammer 測試 mainnet 的結果

可以注意到 , TPS 上了 40

CTPS也來到 30 附近 , 相較之前 TPS 40 , CTPS 才 10~20 有 10 以上的差距

除去官方測試造成CTPS下降的問題 , 就這樣的情況 , 還需要做 CTPS 的實驗嗎?

tags: IOTA