Re: [問題] 幣的交易驗證順序

看板DigiCurrency (數位貨幣)作者 (達克鴨)時間5年前 (2019/02/27 03:08), 5年前編輯推噓23(23031)
留言54則, 23人參與, 5年前最新討論串2/2 (看更多)
※ 引述《waakye (明天的太陽)》之銘言: : 剛入比特幣不久,一開始自己轉來轉去交了不少手續費(學費) : 後來發現一個問題,如果我轉錢給兩個不同的錢包 : 後轉的會要前面先確認過才能確認嗎? : 還是各自不影響? : 剛才稍微爬文不過不知道關鍵字怎麼下沒找到 加密貨幣主要就兩種交易系統,一種像是BTC, BCH, LTC, DOGE這類的 他們是UTXO系統,一筆交易可以有多個input,多個output。 https://i.imgur.com/FrHTSM5.png
另外一個是account交易系統,智能合約平台幾乎都這樣設計,方便VM實作。 譬如ETH, ETC, EOS 交易就只會有一個source address和一個destination address。 除非用專用智能合約地址,才有可能多個私鑰共同發出一筆交易。 先講account制系統,因為比較簡易,大家比較容易懂。 它的操作幾乎就跟銀行帳戶一樣直觀。一個錢包基本上就一個私鑰、一個接收地址。 所有操作都會重複利用本來的"account"的私鑰和地址 所有發出的交易基本上是EVM的操作,藉由nonce值讓網路能確認操作的順序。 所以不會發生後面的交易先被確認,但前面的交易還沒被確認。 在EVM的架構下,要在同一個區塊內確認是可行的, 只要區塊內的交易是按照順序排列,沒有nonce被跳過 比如說你短時間依序發出了三筆交易,A, B, C。 那是可以達到A, B, C在同一個區塊內被確認。(感謝Ayukawayen說明) 而且ETH 15秒產生一個區塊,所以一般使用上並不會有太大的延遲感覺。 但假如你交易A的gas price給的太低,就有可能造成後面的交易B和C卡住pending。 因為ETH平台被設計成是一個圖靈完備的虛擬機,有相依性指令一定要循序執行。 同時也避免了雙花情形的發生。 https://kb.myetherwallet.com/transactions/what-is-nonce.html 再來回到中本聰設計UTXO交易模型。 講實在的,我覺得中本聰設計的UTXO模型就是金流區塊鏈最棒的模型了。 無論在隱私、擴容上都有顧到。 首先一筆交易會由一個以上的input和output組成。 input就是某一個私鑰擁有操控權未花出比特幣。 output則是要送給某一個接收者的比特幣輸出。 https://i.imgur.com/OrAX3PE.png
所以比特幣是可以達成一筆交易,從多個地址進來的比特幣,再轉給多個比特幣接收者。 這對於一些需要大量同時交易的應用非常方便 (Core: No no no 比特幣是黃金.....) 同時也方便於混幣,提升隱私性。 因為從input和output就已經構成了交易的順序,所以也不需要額外的nonce去確認。 而比特幣也沒有什麼相依性智能合約要執行, 所以UTXO類型的比特幣也可以達成同時確認多筆的未確認交易, 譬如你短時間依序發出了三筆交易,A, B, C A的input → A的output接收者a ↘ B的input → B的output接收者b ↘ C的input→C的output接收者c 假如A的change output就是B的input,B的change output就是C的input 那麼這三筆交易仍然可以在被同一個區塊內確認。 不過也是有個上限值,我記得是一百筆用同一個input的串列交易可以被同一個區塊確認。 當然依照input和output相依順序,後面的交易無法先於前面的交易被確認。 所以交易A的手續費假如付太少,仍然會卡住後面B和C的交易。 但是假如這三筆交易沒有用到有相依性的input就有可能互相獨立。 A的inputs集合 → A的output接收者a B的inputs集合 → B的output接收者b C的inputs集合 → C的output接收者c 譬如說你的錢包都是收小額捐款,所以有非常多的小額input。 那就可能會有這樣的狀況發生:後發的交易C假如手續費較高可能還會先被確認。 在這種狀態下也不會有一百筆同時確認的限制值,可以同一個確認區塊塞到上限為止。 若要實驗的話可以用BCH,手續費便宜多了,也不會塞車。 -- simpleledger:qzsn8qeupph6pf8kyn2x79afff7pygzfvqlf9hzmu9 http://tinyurl.com/y3f9r3wo Bitcoin: 1GxtyprMfcxE366BDUsg1skQyuAnxktZjc http://tinyurl.com/y6gtg5zn Bitcoin Cash: bitcoincash:qzsn8qeupph6pf8kyn2x79afff7pygzfvqnjwvhmzm http://tinyurl.com/y2wgj642 Ethereum: 0x4A2B1e35eb64141bbad4C58cB7D79692bC5Dbbc2 http://tinyurl.com/y5kdt5tc -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.171.108.32 ※ 文章網址: https://www.ptt.cc/bbs/DigiCurrency/M.1551208137.A.972.html

02/27 03:12, 5年前 , 1F
推優文
02/27 03:12, 1F

02/27 03:25, 5年前 , 2F
先推再看
02/27 03:25, 2F

02/27 05:49, 5年前 , 3F
02/27 05:49, 3F

02/27 06:11, 5年前 , 4F
先推
02/27 06:11, 4F

02/27 07:59, 5年前 , 5F
02/27 07:59, 5F

02/27 08:22, 5年前 , 6F
02/27 08:22, 6F

02/27 09:00, 5年前 , 7F
02/27 09:00, 7F

02/27 09:35, 5年前 , 8F
優質文
02/27 09:35, 8F

02/27 09:36, 5年前 , 9F
02/27 09:36, 9F

02/27 09:36, 5年前 , 10F
不過我覺得UTXO模型下一樣可以有智能合約架構
02/27 09:36, 10F

02/27 09:38, 5年前 , 11F
就讓每個合約有自己的UTXO(或說一UTXO可能是某個合約的)
02/27 09:38, 11F
這個確實有人在做了,不過account交易模型還是有效率和簡潔的優勢, 不然V神也沒必要大改從UTXO架構改成account架構。 https://komodoplatform.com/crypto-conditions-utxo-based-smart-contracts/ https://goo.gl/7AcDji https://goo.gl/R228K6 https://counterparty.io/docs/faq-smartcontracts/ 中本聰很顯然早就想到比特幣必須平行化擴容,才會設計出UTXO。 每一個input串下去的UTXO都可以被multi-thread平行化驗證,這是擴容上極大的優點, account制要擴容只能用非常複雜的方案譬如sharding才能處理。 其實還有另外一個方向就是UTXO和account混和制。

02/27 09:53, 5年前 , 12F
02/27 09:53, 12F

02/27 10:03, 5年前 , 13F
認真推
02/27 10:03, 13F

02/27 10:42, 5年前 , 14F
謝謝回覆 我在多看看了解
02/27 10:42, 14F

02/27 11:54, 5年前 , 15F
原來!
02/27 11:54, 15F

02/27 11:56, 5年前 , 16F
推優文
02/27 11:56, 16F

02/27 12:07, 5年前 , 17F
ETH區塊内的Tx是有序的 同帳戶多筆Tx進同一區塊是可以
02/27 12:07, 17F

02/27 12:08, 5年前 , 18F
的 只要在區塊內沒有違反順序就好(例:A,B都在區塊1000
02/27 12:08, 18F

02/27 12:09, 5年前 , 19F
,且A在B前,這樣是可以的)
02/27 12:09, 19F

02/27 12:11, 5年前 , 20F

02/27 12:14, 5年前 , 21F
感謝樓上補正,因為我有自己實際測試
02/27 12:14, 21F

02/27 12:15, 5年前 , 22F
之前測試都會多一個區塊,可能是我發交易速度不夠快
02/27 12:15, 22F

02/27 12:18, 5年前 , 23F
而且我還故意第一筆交易給很低的gas price來卡交易
02/27 12:18, 23F

02/27 12:42, 5年前 , 24F
02/27 12:42, 24F

02/27 13:10, 5年前 , 25F
02/27 13:10, 25F

02/27 13:56, 5年前 , 26F
TRON的ACCOUNT系統好像不支持nonce保證前後順序
02/27 13:56, 26F
※ 編輯: DarkerDuck (118.171.108.32), 02/27/2019 16:14:25

02/27 17:02, 5年前 , 27F
我查了一下TRON好像是UTXO和account混和制
02/27 17:02, 27F

02/27 17:02, 5年前 , 28F
待強者補充
02/27 17:02, 28F
※ 編輯: DarkerDuck (60.249.215.220), 02/27/2019 17:06:03

02/27 17:23, 5年前 , 29F
看起來TRON的基礎仍然使用UTXO機制
02/27 17:23, 29F

02/27 17:37, 5年前 , 30F
解說推。雖然原理看不懂。
02/27 17:37, 30F

02/27 19:49, 5年前 , 31F
02/27 19:49, 31F

02/27 21:42, 5年前 , 32F
感謝板大回應~我之前研究過qtum白皮書,我說的作法就跟他
02/27 21:42, 32F

02/27 21:42, 5年前 , 33F
的滿像的:
02/27 21:42, 33F

02/27 21:42, 5年前 , 34F
Blockchain state除了有當前utxo set,也有現存的所有合約
02/27 21:42, 34F

02/27 21:42, 5年前 , 35F
。一個合約可以擁有多個utxo,而一個utxo只能屬於一個合約
02/27 21:42, 35F

02/27 21:42, 5年前 , 36F
,或是不屬於任何合約但像原本比特幣一樣可以被script解鎖
02/27 21:42, 36F

02/27 21:42, 5年前 , 37F
。合約要轉錢出去的時候,vm會動用該合約的utxo(刪除花掉
02/27 21:42, 37F

02/27 21:42, 5年前 , 38F
的utxo並根據轉錢目的地產生新的utxo)。合約的utxo只能被v
02/27 21:42, 38F

02/27 21:42, 5年前 , 39F
m動到,使用者發的交易的input如果有引用到合約的utxo就會
02/27 21:42, 39F

02/27 21:42, 5年前 , 40F
被拒絕。
02/27 21:42, 40F

02/27 21:42, 5年前 , 41F
我猜所謂帳戶和utxo混用,應該跟這種作法是一樣意思:最底
02/27 21:42, 41F

02/27 21:42, 5年前 , 42F
層是utxo,往上一層是帳戶;一個帳戶擁有多個utxo,而一個u
02/27 21:42, 42F

02/27 21:42, 5年前 , 43F
txo可以屬於某個帳戶也可以獨立使用(用script解鎖)。
02/27 21:42, 43F

02/27 21:49, 5年前 , 44F
這樣混用的優缺點就是同時繼承兩者的優缺點。
02/27 21:49, 44F

02/27 21:49, 5年前 , 45F
優勢:直觀的帳戶體系(反正使用者只要知道每個帳戶有多少
02/27 21:49, 45F

02/27 21:49, 5年前 , 46F
餘額,這些餘額如何由utxo組成不重要)以及UTXO的優勢(要
02/27 21:49, 46F

02/27 21:49, 5年前 , 47F
隱私就不要特地開一個帳戶,照原本比特幣那樣用就好)
02/27 21:49, 47F

02/27 21:50, 5年前 , 48F
看起來qtum和tron都是用同樣的方法實現智能合約平台
02/27 21:50, 48F

02/27 21:51, 5年前 , 49F
這樣的確可以整合兩者優點,提高UX、隱私和擴容性
02/27 21:51, 49F

02/27 21:52, 5年前 , 50F
劣勢:其中一個就是blockchain state變頗複雜,utxo set和a
02/27 21:52, 50F

02/27 21:52, 5年前 , 51F
ccount set都要維護,還要互相指來指去。
02/27 21:52, 51F

02/27 22:00, 5年前 , 52F
感謝補充優缺點,可以來好好研究
02/27 22:00, 52F

02/28 00:07, 5年前 , 53F
快推,才不會被人發現我看不懂
02/28 00:07, 53F

02/28 19:09, 5年前 , 54F
推個
02/28 19:09, 54F
※ 編輯: DarkerDuck (36.236.95.245), 02/28/2019 19:24:56 ※ 編輯: DarkerDuck (118.171.110.179), 04/10/2019 03:21:56
文章代碼(AID): #1STOx9bo (DigiCurrency)
討論串 (同標題文章)
文章代碼(AID): #1STOx9bo (DigiCurrency)