Re: [問題] 幣的交易驗證順序
看板DigiCurrency (數位貨幣)作者DarkerDuck (達克鴨)時間5年前 (2019/02/27 03:08)推噓23(23推 0噓 31→)留言54則, 23人參與討論串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
02/27 09:36, 10F
→
02/27 09:38,
5年前
, 11F
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
02/27 12:07, 17F
→
02/27 12:08,
5年前
, 18F
02/27 12:08, 18F
→
02/27 12:09,
5年前
, 19F
02/27 12:09, 19F
→
02/27 12:11,
5年前
, 20F
02/27 12:11, 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
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
02/27 13:56, 26F
※ 編輯: DarkerDuck (118.171.108.32), 02/27/2019 16:14:25
→
02/27 17:02,
5年前
, 27F
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
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
02/27 21:42, 32F
→
02/27 21:42,
5年前
, 33F
02/27 21:42, 33F
→
02/27 21:42,
5年前
, 34F
02/27 21:42, 34F
→
02/27 21:42,
5年前
, 35F
02/27 21:42, 35F
→
02/27 21:42,
5年前
, 36F
02/27 21:42, 36F
→
02/27 21:42,
5年前
, 37F
02/27 21:42, 37F
→
02/27 21:42,
5年前
, 38F
02/27 21:42, 38F
→
02/27 21:42,
5年前
, 39F
02/27 21:42, 39F
→
02/27 21:42,
5年前
, 40F
02/27 21:42, 40F
→
02/27 21:42,
5年前
, 41F
02/27 21:42, 41F
→
02/27 21:42,
5年前
, 42F
02/27 21:42, 42F
→
02/27 21:42,
5年前
, 43F
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
02/27 21:49, 46F
→
02/27 21:49,
5年前
, 47F
02/27 21:49, 47F
→
02/27 21:50,
5年前
, 48F
02/27 21:50, 48F
→
02/27 21:51,
5年前
, 49F
02/27 21:51, 49F
→
02/27 21:52,
5年前
, 50F
02/27 21:52, 50F
→
02/27 21:52,
5年前
, 51F
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
討論串 (同標題文章)
DigiCurrency 近期熱門文章
PTT數位生活區 即時熱門文章