作者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/cn.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