Try   HackMD

我對共識演算法的看法與假設

共識演算法本質是一個分散式系統的演算法

所以有些關於分散式系統的知識必須先知道

從系統的實做上 , 可以知道下列事實

要求越強的一致性 , 效能越差

先回答幾個問題

  • 共識演算法要求的一致性 , 是什麼一致性?

如果一筆交易,在某個node是最大的權重

過一段時間後 , 在全部的node,也會是最大的權重(不考慮斷線)

講的更白話點

帳本有address餘額是負數 , 選衝突交易內最大權重
任意兩個node , 交易都是最大權重
並不代表最大權重的交易 , 權重一樣
所以
node是可以有很鬆的一致性
甚至資料完全不一致也沒差
0元交易的數量 , 各node不同
不是0元的, 大家都有 , 然後衝突內最大權重是一樣的交易
這樣就可以了

  • 白皮書內提到的tangle , 是一個node有的還是多個node有的?

個人以為,只有單一node

系統運作

分散式帳本 , 可以想到就是可以讀取與寫入

node的讀

目前推測是選權重最大的交易 , 在DB所組成的DAG內

tangle內部可以有互相衝突的交易

node的寫(接收別的node或自己發起的交易)

node發起新的交易與接收別node廣播的交易

都會做些檢查後 , 放入database

且不會刪除 , 直到node做快照(snapshot)後 , 才會把舊的交易清除

node接收交易的情況

新接收的交易 , 都有紀錄選取那兩筆交易的紀錄

所以可以分為:

兩筆選取的交易都在node原本的DAG上

例子:







tangle



a

c



b

b



a->b





a->b





c

a



b->c





b->c





d

d



d->b





d->c





e

e



e->a





e->d

藍色的 , 都是原本node有的交易

黑色的 , 是node剛接收的交易

其中一筆在node原本的DAG

例子:







tangle



a

c



b

b



a->b





a->b





c

a



b->c





b->c





d

d



d->b





d->c





e

e



e->a





f

f



e->f

藍色的 , 是原本node有的交易

黑色e , 是node接收新來的交易

黑色f , 這交易不在node裡面

至於這樣情況可能的原因 , 見node網路拓樸的討論

兩筆都不在node的DAG

例子:







tangle



a

c



b

b



a->b





a->b





c

a



b->c





b->c





d

d



d->b





d->c





e

e



f

f



e->f





g

g



e->g

藍色的 , 是node原來有的交易

黑色e , 是node接受新來的交易

f和g　, 是不在node的DB內有的交易

可能的原因 , 見node網路拓樸的討論

node接收交易的條件

node要不要接收一個交易放入到node本身的DAG , 有許多考量

node綜述

由以上的猜測
可以想像
網路上某個node上的tangle

可以有自己發起的交易 , 別人送的交易 , 有衝突的交易
tangle的有向邊
可以是自己node所選的驗證 , 也可以是別的node所選的驗證

node發起交易

白皮書的過程是這樣的

1.選兩筆舊的交易

2.檢查有無衝突 

3.做一次工作量證明(找出特定格式的hash value)

4.發送給其他node

可是再看過整個白皮書

個人以為是這樣的

1.檢查舊tangle , 有無自己發送的交易變成懶惰的tip(白皮書內有說明)

接下來分兩種情況

2.有的話,直接選擇驗證就是那個自己發起的懶惰的tip
3.做工作量證明
4.發送新交易給其他node

接下來是沒有的情況,就如同白皮書所寫的

2.沒有的話,選兩筆交易
3.檢查有無衝突
4.做工作量證明
5.發送新交易給其他node

當然 , 上面的新交易 , 也會加入發起交易的node的tangle裡面

一筆交易在node的生命週期

先從

Pending 開始

然後

Confirmation

最後

Local Snapshot 清掉

Pending

Pending 的交易不會拿來算帳

所以亂七八糟都沒關係

但會有衝突的交易 ,　需要檢查出來

至於發現後如何處理 , 目前有許多想法 , 不肯定如何實做

基本上是一定要孤立一些交易(不增加權重)

Confirmation(確認)

只有確認的交易 , 才能拿來算帳

所以這邊必須找出衝突的交易 , 而且要讓最大權重的交易維持最大權重

另外 , 依照本人的看法

一筆交易是確認 , 可由賣家定義確認的門檻

Local Snapshot

因為要用在IoT上

我們知道IoT的裝置

硬體資源很受限 , 所以對於帳本來說 , 真的無法存全部的交易 , 所以需要做清除交易的工作

原則上 , 這是各node自行決定的

當然也會有安全的問題

目前還沒仔細分析 , 只有一些想法

12/18會議補充　關於swarm node的討論

另外 , 由於交易會被刪除 , 所以node網路需要有node是負責存全部曾經出現過的交易

Last changed by 
 
blockchain
Blockchain 研究
0
735
Published on HackMD