side Tangle 的問題
===

# issue 背景

[Tip-Selection freezes when stitching sidetangle to the maintangle](https://github.com/iotaledger/iri/issues/846)


可以看到 blow ball 出現在 main Tangle 旁邊

然後出現上面 blow ball 時 , 一些統計的資料


可以看到突然有接近 4.5k 的 TPS , 以及將近兩個小時 , CTPS 都是 0 的情況

# getTransactionsToApprove

## IRI

[Coming Soon: IRI 1.5.2](https://blog.iota.org/coming-soon-iri-1-5-2-52114ca67a70)

[中國IOTA社群翻譯](https://www.iotachina.com/iri152.html)

從這兩份文件 , 可以知道是檢查交易的效能問題

## 官方的解法


想法是 random walker 不要走到 side Tangle 上的交易

方法有兩點

### 1

由於side tangle 是指向舊的 milestone
可以每筆交易紀錄最新指向的 milestone , 讓 random walk 時不去走到指向太舊 milestone 的交易

### 2

每個有檢查過的交易做上記號 , 下次檢查遇到就可以不用檢查

### 個人的疑惑

如果有人把 side Tangle 與 main Tangle 縫合 , 就是有一筆交易同時驗證到 main Tangle 的交易與 side Tangle 的交易 , 那 random walker 會選到這樣的交易嗎?

### IRI 1.5.2

[pull request]( https://github.com/iotaledger/iri/pull/889)

已經 merge 了 , 並 release

看一下跟 side Tangle 相關訊息
:::info
* bounded set wrapper
* below max-depth cached
* Fix WalkValidator
* change bounded set wrapper description
* add configuration for maximal number of transactions that may be analyzed by below_max_depth
* add below max_depth to check consistency api call
* add walk validator cache size to configurations
* Fix walk validator test
* fix cache size
* fix add all in bounded Set Wrapper
* BoundedSetWrapperTest
* add cli walk validator cache size config option
* API calls won't trigger solidity routines
:::

很顯然只有實作第二點

第一點每筆交易紀錄最近的 milestone 避免 walker 走到並沒有實作

關於第一點的修改 , 還有一個衍生的 [issue](https://github.com/iotaledger/iri/issues/890)

這關於一份[文件](https://hackmd.io/s/ryqBeI0ab) , 內有提到 offline 的 Tangle

根據紀錄的 milestone 影響 walker 會造成 offline 的 Tangle 不會被 main Tangle merge

## solution

有趣的是 , 不用管 $getTransactionsToApprove$ 有什麼問題

目前就有替代的解決方法

由[共識演算法與 IRI 的差異](https://hackmd.io/s/rJN51lGXQ)這篇

可以知道確不確認 , 都是由 milestone 決定

而 MCMC 選出來的 tip , 跟直接隨機選出來的 tip , 原則上是沒有差別的

所以對 IRI 修改的想法如下:

### getTransactionsToApprove

拿掉整個算法 , 只剩下從某個 list 拿出 tips 的組合(trunk與branch)

### add new thread

上文所提的 list , 是這個 thread 處理的結果

thread 內的算法分兩部份

#### 維護第15深 milestone 相關的 tips

#### 檢查 trunk 與 branch 組合

# CTPS

## discord spammer 的說法

TPS 越高 , coordinator 發起下一個 milestone 的時間越長

## 最近 mainnet 的 Tangle

7/19

2:34

:::info
Current TPS: 4.66
Five minutes ago: 4.79
Ten minutes ago: 4.57
1 hour ago: 4.81
Current CTPS: 1.78
Five minutes ago: 2.72
Ten minutes ago: 2.61
1 hour ago: 1.89
:::

15:07


中間看似相接的地方:


實際上是沒有連接

這代表說

CTPS會低 , 是因為有部份的 TPS

是接到另一個沒有 milestone 的 DAG 上的

而就發起交易確認的比例 , 應該要去除掉 side Tangle 的部份

所以確認比例低不一定是 Coo 的問題

有人洗 side Ttangle 或 飄在 main Tangle 外的交易 , 都會讓CTPS的比例是低的

對確認來講 , 不會有影響

但是硬體的資源可能會被耗盡

7/21

有人把 main Tangle 與 side Tangle 給縫合了

來看一下 7/24 的 mainnet 狀況


這圖可以看到像快分裂成兩半 , 但還是有連接


從圖上可以看到有許多沒有確認的交易


有密集黑點的是 milestone 會驗證的 subgraph , 另一個是別人洗的

## milestone

###### tags: `IOTA`