From 533bfa1a808d0d280e74e381707531d3bc3b4672 Mon Sep 17 00:00:00 2001 From: yjjnls Date: Mon, 29 Oct 2018 16:58:01 +0800 Subject: [PATCH] update --- Basic/account.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/Basic/account.md b/Basic/account.md index 8c9caf7..96b52fe 100644 --- a/Basic/account.md +++ b/Basic/account.md @@ -9,16 +9,16 @@ 区块链网络中有两种记账模式，除了 UTXO 模型还有 Account Based 结构，也就是普通账户模型，也叫账户余额模型，**前者在比特币系的数字货币中被广泛使用，后者更多是用在智能合约型的区块链上**。 ## 普通账户模型 -我们先从传统的账户模型出发来聊聊是如何记账的，假设我们现在有一个支付系统，在这个支付系统中有村长和张三两个账户，村长账户里有 100 万，现在要转账给张三 10 万，这其中涉及的操作是这样的： -1. 检查村长的账户余额是否大于 10 万； -2. 把村长的账户扣除 10 万变成 90 万，然后发送一笔转账消息给张三的账户； -3. 张三的账户接受到转账消息，将张三的账户余额加 10 万。 +我们先从传统的账户模型出发来聊聊是如何记账的，假设我们现在有一个支付系统，在这个支付系统中有Alice和Bob两个账户，Alice账户里有 100 万，现在要转账给Bob 10 万，这其中涉及的操作是这样的： +1. 检查Alice的账户余额是否大于 10 万； +2. 把Alice的账户扣除 10 万变成 90 万，然后发送一笔转账消息给Bob的账户； +3. Bob的账户接受到转账消息，将Bob的账户余额加 10 万。 -我们可以发现，无论是村长还是张三，都具有一个余额作为状态，即当前余额是记录在某个地方的，只需要读出来即可，这种设计我们叫做账户余额模型。 +我们可以发现，无论是Alice还是Bob，都具有一个余额作为状态，即当前余额是记录在某个地方的，只需要读出来即可，这种设计我们叫做账户余额模型。 **如果以上三个步骤是在一个中心化系统中，甚至在同一个数据库中，那将非常简单，会直接退化成一个事务**，我们见到的银行账户、信用卡系统、证券交易系统、各种电商类应用，理财类应用基本都是一个中心化系统中的，最多也就是跨表跨数据库。 -如果以上的步骤中，村长和张三的账户分属两个不同的系统，例如从 A 银行到 B 银行，就需要经过人民银行支付系统，即可信任的中心化第三方来做中介。 +如果以上的步骤中，Alice和Bob的账户分属两个不同的系统，例如从 A 银行到 B 银行，就需要经过人民银行支付系统，即可信任的中心化第三方来做中介。 你可能发现了，在跨行转账的这种情况下，是没有办法做事务的，所以 **1 和 3 是不同步的，如果 3 操作失败，还需要从 2 倒退到 1 的状态，这个情况叫做冲正交易**。 @@ -35,21 +35,21 @@ UTXO 全称是：“Unspent Transaction Output”，这指的是：未花费的 下面我们按照按照普通账户中的例子来重新讲解一遍。 -如果要记录交易本身，那么我们可以构造一笔交易，这笔交易中村长转账 10 万给张三的同时，90 万转给自己。 +如果要记录交易本身，那么我们可以构造一笔交易，这笔交易中Alice转账 10 万给Bob的同时，90 万转给自己。 如下所示： ``` -　村长　100 万 --> 张三　10 万 　 -　　　　　　　 --> 村长　90 万 +　Alice　100 万 --> Bob　10 万 　 +　　　　　　　 --> Alice　90 万 ``` 这里其实有三条子记录，左边一条，右边两条，左边叫做输入，右边叫做输出。 输入和输出组成了交易，输入和输入需要满足一些约束条件： 1. 任意一个交易必须至少一个输入、一个输出； -2. 输入必须全部移动，不能只使用部分，所以才产生了第二个输出指向村长自己； +2. 输入必须全部移动，不能只使用部分，所以才产生了第二个输出指向Alice自己； 3. 输入金额 = 输出金额之和 + 交易手续费，这里必须是等式。 -对于村长来说，首先构造交易的输入输出，满足上述条件，然后广播到全网，接收方自行判断交易是否属于自己。这里满足约束条件构成的交易模型，也就是村长记录的三条转账事件就是 UTXO 模型。 +对于Alice来说，首先构造交易的输入输出，满足上述条件，然后广播到全网，接收方自行判断交易是否属于自己。这里满足约束条件构成的交易模型，也就是Alice记录的三条转账事件就是 UTXO 模型。 ## 账户余额模型与 UTXO 的比较 我们可以归纳出 UTXO 与普通账户模型的一些区别。 @@ -85,7 +85,7 @@ UTXO 似乎天然是为数字货币设计的，具有 **较高频次跨账户转 这是区块链上一笔真实交易的例子，它记录了一笔 450ETP 的转账记录。 -左边是输入，右边是两笔输出，其中第二个输出是给自己的账户，这和我们村长转账给张三的例子是一样的。 +左边是输入，右边是两笔输出，其中第二个输出是给自己的账户，这和我们Alice转账给Bob的例子是一样的。 下图是交易解码为 JSON 格式的样子，可以看到 Previous_output 是放到 Inputs 数组里的，意思就是前向输出作为本次的输入。 @@ -140,13 +140,13 @@ UTXO 似乎天然是为数字货币设计的，具有 **较高频次跨账户转 ![](https://github.com/yjjnls/blockchain-tutorial-cn/blob/master/img/16.3.png) -这一笔比特币交易包含 6 个输入，几十个输出，交易一共 3.5kb，交易的输入输出会影响交易大小，比特币的交易费是根据字节收费的，交易尺寸越大越贵，而交易尺寸主要和输入输出的个数有关，也就是说，算法上并不规定输入输出的个数，而只有区块尺寸限制。 +这一笔比特币交易包含 6 个输入，几十个输出，交易一共 3.5kb，交易的输入输出会影响交易大小，比特币的交易费是根据[字节收费](https://zhuanlan.zhihu.com/p/38479785)的，交易尺寸越大越贵，而交易尺寸主要和输入输出的个数有关，也就是说，**算法上并不规定输入输出的个数，而只有区块尺寸限制**。 -在比特币中将小于 100kb 的交易称为标准交易，超过 100kb 的称为非标准交易。它的前向 input 以及生成一个 out 约占用 161~250 bytes 。所以在比特币中，大约的 inputs/ouputs 的最大数目限制为 100KB/161B ~= 600 个。 +在比特币中将小于 100kb 的交易称为标准交易，超过 100kb 的称为非标准交易。它的前向 input 以及生成一个 out 约占用 161~250 bytes 。**所以在比特币中，大约的 inputs/ouputs 的最大数目限制为 100KB/161B ~= 600 个**。 ## UTXO 的特性及缺点 -从计算的角度来说，**UTXO 具有非常好的并行支付能力，也就是我们上文中所说的如果没有尺寸限制，一笔交易可以包含任意笔输入输出，同时也没有次序要求**，在一笔交易中哪一个 UTXO 在前，哪个在后面不影响最终结果。 +从计算的角度来说，**UTXO 具有非常好的并行支付能力，也就是说如果没有尺寸限制，一笔交易可以包含任意笔输入输出，同时也没有次序要求**，在一笔交易中哪一个 UTXO 在前，哪个在后面不影响最终结果。 从存储的角度来说，UTXO 具有较好的可裁剪特性，可裁剪性指的是 UTXO 类型的交易，如果从最老的那一笔 UTXO 开始截断数据库，那么之前的数据可以删除掉了。