Re: [閒聊] IOTA真的能實現足夠的算力嗎
看板DigiCurrency (數位貨幣)作者grapherd (NULL)時間6年前 (2018/01/23 08:21)推噓8(8推 0噓 28→)留言36則, 11人參與討論串16/22 (看更多)
※ 引述《MRjk ()》之銘言：
: 做為一個和您一開始就有同樣問題的人 說真的我還是沒辦法被說服
: 或許您能用比較相近的語言在幫我解釋一次
: 我看了您在FB的討論
: 您覺得最大的收穫是tangle網路在拓樸的兩端可以容納兩筆互為衝突的交易(雙花)
: 但我覺得這改變並不會影響我們原先討論的本質
: 因為當網路拓樸的兩端合併以後 勢必會取權重的一筆生存 另一筆則被孤立
: 這確實跟Bitcoin的主鏈不同
: 但ETH即有這uncle block(叔塊)的概念
: uncle block仍然是主鏈的一部分 但uncle block裡的交易是不被承認的
: 先複習一下原先的題目
===================================
: =================================
: "在IOTA網路中 沒有coordinator的狀態下
: 惡意攻擊者從一個IoT裝置所發出的交易A (經過PoW驗證了前兩筆交易)
? ? ??????
: 如何能不被惡意攻擊者手上的另一個超強硬體所建構出來的雙花交易B(也經過了PoW驗證
????????
: 了前兩筆交易 且還附加了更多交易在其後增加權重)蓋過去?"
: =================================
==================================
1. IoT 裝置。
大家都覺得所有事情都要在 IoT 裝置上跑才是正解。但是 IOTA 不想這樣。
(應該說，在 JINN 完成之前，不想要這樣)
回頭參考這篇文章：https://goo.gl/pckfc2
整件事情，IoT devices 需要親身參與的部分只有：
簽名
其他的事情：建立 bundle, 找 tips, 算 PoW。「「通通可以外包」」
2. 發出的交易Ａ
建立好 transaction bundle 後，IoT devices 還是要透過 full-node 來 broadcast 他的 transaction。
3. 經過 PoW 驗證
PoW 在 IOTA 裡面，就是一個 transation (不是一筆 transaction) 要去計算 nonce 而已。
算出特定 nonce 之後，可以讓 transaction hash 後面出現多少 9 來符合全網需要的 min weight magnitude.
而 PoW 這件事情只能在 transaction 所有 slot 都填完之後才能夠做。
4. 超強硬體
這裡就是 IOTA 的算力比拼，也是 IOTA 野心所在。
4.1 超強硬體的能力？
我不知道你所謂的超強硬體強到多少，根據這邊的實驗：
https://github.com/chenweiii/dcurl
拿 GPU 通算 8 個 PoW 還要 33 秒左右。
4.2 IOTA 的算力比拼
IOTA 的做法下，一個被 confirmed 的交易，在 tangle 中還會持續的被其他
交易給 indirect reference，這裡是重點，因為你會認為一個被 confirmed
的交易就這樣結束了，感覺他的 weight 就不會再動。實際上是會一直加大
加大上去的。
那攻擊者的交易呢？如果全網的普通節點多數存在，當他們看到攻擊交易的時候，
就會因為他與帳本不符合，因此不會在 tips selection (MCMC) 的時候選用他，
變成攻擊者的交易權重，只能夠自己增加，而得不到其他全網算力的支持。
全網算力支持 v.s. 攻擊者的超強硬體
這裡就是 IOTA 對一個想要超前的 double spending 做的算力比拼。
4.3 IOTA 的野心
回到原標題 「IOTA 如何湊足算力」。
這才是 IOTA 面臨的問題，4.2 的說法，很明顯就需要持續的算力提供，
持續的 (in)direct 指向被 double spending 的交易，要不然就會被攻擊者追過去，對吧？
所以這專案才會推啥 data marketplace，推跟 Bosch，fujitsu 這種公司合作。
透過這種需要常常發送 tx 的東西，來增加 IOTA 的 transaction per second，進而保護整體網路。
你會 argue 外部成本太高，怎麼可能為了 IOTA 讓 IoT devices 都外接一個 full-node，
或是為了 IOTA 大量部署 full-node。
所以這專案還想做硬體，JINN 這個三進位處理器還有在開發。恩...
: 這題以ETH來說明 就會變成
: 惡意攻擊者發送了一個交易A 被主鏈X區塊所確認
: 但攻擊者構建了一個雙花交易B 用更高的算力包裝成X'->Y'->Z'等3個區塊
: 原先的X區塊變成Y'的uncle block, 資料仍在鏈上 但A交易是無效的 大家只會承認B
: 但BTC/ETH等為什麼不會需要Cordinator來對抗這種51%攻擊
: 因為block chain的獎勵機制讓大家會讓主鏈上的算力高到攻擊者很難獨自去發起
: 回歸到IOTA的問題上來 縱使IOTA網路能讓兩種雙花交易存在拓樸的兩端
: 但一當他們接軌之後 權重的選擇下還是只會留下一邊
對，留下一邊。可是對 node 來說有先後之分啊。
假設 Ａ 交易已經在多數普通節點成立，讓這些節點的帳本狀態改變，收到 B 的時候就被當作 invalid
反之，Ａ, B 交易都還沒有成立，B 交易透過 heavy weight 取得共識，而且沒有破壞帳本規則的話，
普通節點就會接受 B 交易，改變帳本狀態，在看到 A 交易的時候，就會把 A 當作 invalid
最後，Ｂ交易先成立，那帳本狀態改變，收到 A 就會變成 invalid
: 權重的本質還是POW (我知道是很多交易互相累積啦 不過還是POW)
權重的本質不是 PoW，倒不如說是 PoW 的累積。
: 所以上述問題變成了 只靠誠實的IOT裝置
: 所累積的POW是不足以讓合流後的權重高於另一邊刻意所構築的
: 無論IOTA再流行 全球IoT裝置都加入恐怕也很難保證安全
: (原因前面討論文章有講過 貧弱的硬體 只計算交易時少少的運算時間...)
沒有要讓 IoT 裝置自己算的意思。
我用我的 i7-7700 跑 pure-python PoW implemention，15 weight 要跑 10分鐘吧。
放到 IoT devices......恩.......有人提到 JINN 嗎ＸＤ
: 當然您說的(2)POW改交由代理節點運算 或許可以拉近上面的鴻溝
: 但這樣整個網路交易本體就變成是代理節點了而非是IOT裝置
: IOTA主打的IoT交易特性就不見了
: (感覺就像是味增湯都不放味增與豆腐改放菜頭排骨酥用肉燥提味)
: 既然都必須連上代理節點了 那代理節點要run區塊鏈還是tangle網路差別就不大了吧?
野心！數量！IoT！
工廠或是公司或是想要應用 IOTA 技術的人，都勢必要架起 full-node 來讓
自己的 IoT devices 使用這些技術 (PoE, data transfer...etc)
在目標放在全球 IoT devices 的情況下，就能夠獲得一定數量的 full-node 來確保帳本，
加上 IoT devices 透過 full-node 送很多的 tx，
如果節點塞車，勢必就要引入 swarm node 或是更多的 full-node
透過這種推廣方式來保證 IOTA 的安全性。
: ※ 引述《kugwa (苦瓜)》之銘言：
: : 認栽了
: : 真的是跟區塊鏈完全不同的解法
: : 有點瘋狂 以至於我之前完全沒有往那個方向思考
: : 感謝好多人不厭其煩地提出和我認知完全衝突的觀念
: : 太多人就不一一點名了
: : 反正就是之前我一直戰的那些人
: : 之前的文我都留著
: : 就讓大家笑笑吧
: : 好吧我承認IOTA的解法應該是神技
: : 為什麼說是應該呢
: : 因為我還沒完全搞懂！
: : 總之一切都在這裡了
: : https://www.facebook.com/groups/897485720426082/permalink/926697757504878/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.12.46.231
※ 文章網址: https://www.ptt.cc/bbs/DigiCurrency/M.1516666863.A.821.html
推
01/23 08:55,
6年前
, 1F
01/23 08:55, 1F
→
01/23 08:55,
6年前
, 2F
01/23 08:55, 2F
→
01/23 09:10,
6年前
, 3F
01/23 09:10, 3F
→
01/23 09:13,
6年前
, 4F
01/23 09:13, 4F
jinn 是拿來加速 curl 的。
存取用cpu就夠，目前底層用 rocksdb
※ 編輯: grapherd (223.141.50.255), 01/23/2018 09:15:52
→
01/23 09:20,
6年前
, 5F
01/23 09:20, 5F
沒錯，這種出不來的支票，看看就好 XDDDDDDD
※ 編輯: grapherd (223.141.50.255), 01/23/2018 09:24:00
→
01/23 09:23,
6年前
, 6F
01/23 09:23, 6F
→
01/23 09:35,
6年前
, 7F
01/23 09:35, 7F
→
01/23 10:14,
6年前
, 8F
01/23 10:14, 8F
→
01/23 10:30,
6年前
, 9F
01/23 10:30, 9F
推
01/23 10:40,
6年前
, 10F
01/23 10:40, 10F
推
01/23 14:01,
6年前
, 11F
01/23 14:01, 11F
→
01/23 14:09,
6年前
, 12F
01/23 14:09, 12F
→
01/23 14:09,
6年前
, 13F
01/23 14:09, 13F
→
01/23 14:09,
6年前
, 14F
01/23 14:09, 14F
推
01/23 14:59,
6年前
, 15F
01/23 14:59, 15F
→
01/23 15:03,
6年前
, 16F
01/23 15:03, 16F
→
01/23 15:10,
6年前
, 17F
01/23 15:10, 17F
→
01/23 15:10,
6年前
, 18F
01/23 15:10, 18F
推
01/23 15:35,
6年前
, 19F
01/23 15:35, 19F
→
01/23 15:35,
6年前
, 20F
01/23 15:35, 20F
→
01/23 15:35,
6年前
, 21F
01/23 15:35, 21F
→
01/23 15:35,
6年前
, 22F
01/23 15:35, 22F
如果你的資金分散在不同的地址，不會傳一筆卡住全部，我不知道wallet有沒有這麼聰明就是了 XD
→
01/23 15:35,
6年前
, 23F
01/23 15:35, 23F
→
01/23 15:35,
6年前
, 24F
01/23 15:35, 24F
推
01/23 16:08,
6年前
, 25F
01/23 16:08, 25F
→
01/23 16:10,
6年前
, 26F
01/23 16:10, 26F
推
01/23 16:23,
6年前
, 27F
01/23 16:23, 27F
※ 編輯: grapherd (223.141.50.255), 01/23/2018 16:35:04
→
01/23 19:04,
6年前
, 28F
01/23 19:04, 28F
→
01/23 19:05,
6年前
, 29F
01/23 19:05, 29F
→
01/23 19:06,
6年前
, 30F
01/23 19:06, 30F
→
01/23 19:07,
6年前
, 31F
01/23 19:07, 31F
→
01/23 19:08,
6年前
, 32F
01/23 19:08, 32F
→
01/23 19:10,
6年前
, 33F
01/23 19:10, 33F
推
01/23 19:11,
6年前
, 34F
01/23 19:11, 34F
→
01/23 19:13,
6年前
, 35F
01/23 19:13, 35F
→
01/23 19:13,
6年前
, 36F
01/23 19:13, 36F
討論串 (同標題文章)
DigiCurrency 近期熱門文章
PTT數位生活區 即時熱門文章
