作者DarkerDuck (達克鴨)
看板DigiCurrency
標題Re: [問題] 幣的交易驗證順序
時間Wed Feb 27 03:08:55 2019
※ 引述《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://webptt.com/m.aspx?n=bbs/DigiCurrency/M.1551208137.A.972.html
1F：推 sismiku: 推優文 02/27 03:12
2F：推 d15388david: 先推再看 02/27 03:25
3F：推 silverado: 推 02/27 05:49
4F：推 remia81: 先推 02/27 06:11
5F：推 ketao: 推 02/27 07:59
6F：推 kidneyweakx: 推 02/27 08:22
7F：推 itsdelovely: 推 02/27 09:00
8F：推 dali17dali17: 優質文 02/27 09:35
9F：推 kugwa: 推 02/27 09:36
10F：→ kugwa: 不過我覺得UTXO模型下一樣可以有智能合約架構 02/27 09:36
11F：→ kugwa: 就讓每個合約有自己的UTXO（或說一UTXO可能是某個合約的） 02/27 09:38
這個確實有人在做了，不過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混和制。
12F：推 Fice: 推 02/27 09:53
13F：推 ReanoX: 認真推 02/27 10:03
14F：推 waakye: 謝謝回覆 我在多看看了解 02/27 10:42
15F：推 john801110: 原來！ 02/27 11:54
16F：推 sweetalex: 推優文 02/27 11:56
17F：推 Ayukawayen: ETH區塊内的Tx是有序的 同帳戶多筆Tx進同一區塊是可以 02/27 12:07
18F：→ Ayukawayen: 的 只要在區塊內沒有違反順序就好(例:A,B都在區塊1000 02/27 12:08
19F：→ Ayukawayen: ，且A在B前，這樣是可以的) 02/27 12:09
21F：→ DarkerDuck: 感謝樓上補正，因為我有自己實際測試 02/27 12:14
22F：→ DarkerDuck: 之前測試都會多一個區塊，可能是我發交易速度不夠快 02/27 12:15
23F：→ DarkerDuck: 而且我還故意第一筆交易給很低的gas price來卡交易 02/27 12:18
24F：推 balancemask: 推 02/27 12:42
25F：推 vvind: 推 02/27 13:10
26F：推 TomSoong: TRON的ACCOUNT系統好像不支持nonce保證前後順序 02/27 13:56
※ 編輯: DarkerDuck (118.171.108.32), 02/27/2019 16:14:25
27F：→ DarkerDuck: 我查了一下TRON好像是UTXO和account混和制 02/27 17:02
28F：→ DarkerDuck: 待強者補充 02/27 17:02
※ 編輯: DarkerDuck (60.249.215.220), 02/27/2019 17:06:03
29F：→ DarkerDuck: 看起來TRON的基礎仍然使用UTXO機制 02/27 17:23
30F：推 john371911: 解說推。雖然原理看不懂。 02/27 17:37
31F：推 Jkx: 讚 02/27 19:49
32F：推 kugwa: 感謝板大回應～我之前研究過qtum白皮書，我說的作法就跟他 02/27 21:42
33F：→ kugwa: 的滿像的： 02/27 21:42
34F：→ kugwa: Blockchain state除了有當前utxo set，也有現存的所有合約 02/27 21:42
35F：→ kugwa: 。一個合約可以擁有多個utxo，而一個utxo只能屬於一個合約 02/27 21:42
36F：→ kugwa: ，或是不屬於任何合約但像原本比特幣一樣可以被script解鎖 02/27 21:42
37F：→ kugwa: 。合約要轉錢出去的時候，vm會動用該合約的utxo（刪除花掉 02/27 21:42
38F：→ kugwa: 的utxo並根據轉錢目的地產生新的utxo）。合約的utxo只能被v 02/27 21:42
39F：→ kugwa: m動到，使用者發的交易的input如果有引用到合約的utxo就會 02/27 21:42
40F：→ kugwa: 被拒絕。 02/27 21:42
41F：→ kugwa: 我猜所謂帳戶和utxo混用，應該跟這種作法是一樣意思：最底 02/27 21:42
42F：→ kugwa: 層是utxo，往上一層是帳戶；一個帳戶擁有多個utxo，而一個u 02/27 21:42
43F：→ kugwa: txo可以屬於某個帳戶也可以獨立使用（用script解鎖）。 02/27 21:42
44F：→ kugwa: 這樣混用的優缺點就是同時繼承兩者的優缺點。 02/27 21:49
45F：→ kugwa: 優勢：直觀的帳戶體系（反正使用者只要知道每個帳戶有多少 02/27 21:49
46F：→ kugwa: 餘額，這些餘額如何由utxo組成不重要）以及UTXO的優勢（要 02/27 21:49
47F：→ kugwa: 隱私就不要特地開一個帳戶，照原本比特幣那樣用就好） 02/27 21:49
48F：→ DarkerDuck: 看起來qtum和tron都是用同樣的方法實現智能合約平台 02/27 21:50
49F：→ DarkerDuck: 這樣的確可以整合兩者優點，提高UX、隱私和擴容性 02/27 21:51
50F：→ kugwa: 劣勢：其中一個就是blockchain state變頗複雜，utxo set和a 02/27 21:52
51F：→ kugwa: ccount set都要維護，還要互相指來指去。 02/27 21:52
52F：→ DarkerDuck: 感謝補充優缺點，可以來好好研究 02/27 22:00
53F：推 camellala: 快推，才不會被人發現我看不懂 02/28 00:07
54F：推 goldflower: 推個 02/28 19:09
※ 編輯: DarkerDuck (36.236.95.245), 02/28/2019 19:24:56
※ 編輯: DarkerDuck (118.171.110.179), 04/10/2019 03:21:56
55F：推 slayptter: 推文不錯 04/14 13:24
56F：→ slayptter: 讓我有新的靈感XDD 04/14 13:24