Algorand的带宽利用效率如何？Cardano的Ouroboros怎么样？Solana、NKN为什么能有那么高的TPS？以太坊将出块间隔缩短到15秒，为什么并没有比比特币吞吐量高出很多？这些问题，张韧博士都会在分享中一一回答。以下为韧博士演讲稿整理。阅读本文对读者的区块链基础知识储备有一定要求：比特币共识协议基本概念以太坊共识协议基本概念孤块、叔块、自私挖矿等概念整理：Ryan、万涔涔视频链接：https://v.qq.com/x/page/g0837...自我介绍一下，我是张韧，Nervos&Cryptape的研究员，目前我在鲁汶大学COSIC(ComputerSecurityandIndustrialCryptographygroup)读博士，师从BartPreneel。如果你对COSIC不熟悉的话，不知道你是否听说过AES，它是我们所有人的手机中使用的加密标准。当然如果你熟悉BartPreneel的话，会知道他是RIPEMD160的设计者。RIPEMD160是比特币公钥转化为比特币地址时使用的哈希算法。NervosCKB是一个公有链，能够支持各种编程语言的智能合约，以及各种各样的Layer2协议。在NervosCKB上你可以用任意资产支付交易手续费。在NervosCKB中智能合约的执行和验证是分离的，从而达到更好的隐私和性能。最后，在NervosCKB中采用了NC-Max——一个NakamotoConsensus的变体——作为共识协议，拥有更高的吞吐量。声明：本次分享内容仅着眼于Layer1共识协议的分析，我将不会谈到LightningNetwork这样的Layer2方案。这里是我本次分享的大纲，首先我会告诉你为什么我们会那么喜欢NakamotoConsensus。然后我会给出我们为什么不采用其他共识协议的理由。最后我会给出我们NervosCKB的共识协议NC-Max的设计思路。为什么我们喜欢比特币的NC？
先来回答一个问题，为什么我们喜欢比特币的NakamotoConsensus？有很多的理由，首先NC的性能优化做的非常好，它能够节约每一个传输的每一个字节，以及每个计算周期。举例来说，它使用CompactBlock来加快区块的传播，可能在未来使用Minisketch来节省交易广播所需要的带宽资源。同时比特币的开发者提出了Graftroot，你可以认为它能够通过压缩比特币上的智能合约从而获得更好的隐私性和更好的性能。或许我们还能够看到签名聚合技术应用在比特币之上。知识点：CompactBlockRelay，在比特币改进协议152中提出，能够减少P2P网络节点广播区块所需的带宽数量。Compactblock是完整区块的「概要」，包含下面三部分信息：1、新区块的区块头2、交易ID3、发送方节点预测的但是接收节点不具备的完整交易接收方会尝试根据收到的信息以及在其内存池中的交易来重新构建完整区块。若仍然缺失某些交易，它将会请求广播节点。喜欢NC的另一个理由是它的通用性。UTXO模型加上全局交易顺序能够支持各种分片技术和Layer2方案，以及复杂的智能合约。相比来看，以太坊的Account模型进行分片的难度更高；并且如果你没有一个全局交易顺序的话，比如像许多DAG类型协议那样，那么就很难支持复杂的智能合约，关于这一部分会在后面谈DAG的时候详细描述。我们也喜欢比特币NC的安全性。比特币网络经历了很多的攻击，还是稳定运行了十年。而且严格意义上来说，目前没有任何一个已知的工作量证明共识机制在整体上超越NC。如果你对这个话题感兴趣，可以看这里。然而在NC中有两个地方我们希望做出一些改变。首先在带宽利用方面，比特币的NC在采用隔离见证之后，人为设定了最大为每十分钟4Mb的吞吐量，然而现实情况是，比特币公共节点的带宽水平在过去的几年里获得了大幅度的提升。对于NC我们有哪些地方需要做出改变？
《芭比》女主：比特币是独特的，有其存在的意义:金色财经报道，近期热播电影《Barbie 芭比》女主角Margot Robbie在接受 Fandango 采访时称比特币是“such a Ken”。such a Ken是该电影中的一句经典台词，指代某人或事物是“独特的，有其存在的意义”。Robbie没有继续定义它，这可能代表比特币是一件好事。
软件公司 Microstrategy (MSTR) 首席执行官 Michael Saylor 在社交媒体转发了这条采访视频，称\"Bitcoin is Big Ken Energy\"。[2023/8/1 16:10:01]
如同上图中这个研究所指出的，链接到网络中的比特币IPv4节点在2016年时带宽中位数为33Mbit/s，在2017年2月，这个数字达到了56Mbit/s。我们很容易想到的改进方式就是，协议自身是否能够动态地调节吞吐量来适应带宽水平的变化？BitcoinUnlimited做了一个糟糕的尝试，它希望能够动态地调节比特币的吞吐量，但是它失败了，引入了多种新的攻击方式让它的协议变得不安全。上面是在Coindesk上发布的一篇关于BitcoinUnlimited安全性研究，我也是这项研究的参与者之一。另一个我们希望在NC中做出改变的是它的激励问题，也就是出现自私挖矿攻击的问题。自私挖矿攻击者会扣留发现的区块，希望在网络中获得更大的领先优势。当其他诚实矿工发现区块的时候，攻击者会向网络广播这个被扣留的区块，寄希望于这个被广播的扣留区块会在诚实区块之前，被大部分诚实矿工接收到。如果攻击者足够幸运，下一个块是在攻击者的块上面进行挖矿的，那么诚实的块将会成为孤块。如果攻击者运气好到能够连续挖到多个区块，那么它将能够非常安全地让一个诚实矿工的区块失效，因为攻击者会有更长的链。为什么自私挖矿是有利可图的呢？我们举一个具体的例子，假设自私挖矿攻击者有全网30%的算力，诚实矿工控制剩下的70%。如果没有自私挖矿攻击出现，那么攻击者在10个区块中能够找到3个，诚实矿工找到7个，大家都拿到应有的报酬。如果攻击者发动自私挖矿攻击，那么它能够找到3个区块，诚实矿工只能找到4个区块，因为另外3个诚实矿工找到的区块经过前面提到的攻击方式变成了孤块，原本能够产生10个区块的时间现在只产生了7个区块，主链增长速度减慢。在下一个难度调整周期，由于协议发现主链增长速度减慢，会降低挖矿难度，从而攻击者能够用同样大的算力获得更多的奖励，这是自私挖矿有利可图的原理。要注意的是，矿工获得的收益是根据单位时间内获得的币的数量而不是获得币的比例来计算的。在下一个难度调整周期，由于链增长的速度下降，协议会降低挖矿难度，此时矿工在单位时间能够获得更多的币，才有收益。因此，自私挖矿在第一个难度调整周期中是没有收益的，只有在挖矿难度调整之后自私挖矿才会有收益。其他替代性共识协议
那我们为什么不选择其他替代性的共识协议呢？目前有三种替代NC的方式，它们分别是PoS，DAG和两种区块类型的共识协议。注意这三种方式并不是相互排斥的，是有可能同时应用它们之中的2-3种的。下面我们来进一步分析这些协议的安全性、功能性和吞吐量。首先是PoS，实际上所有的PoS协议引入了新的安全前提。拿Algorand举例来说，它要求大部分诚实用户发送的消息能够被大部分其他诚实用户在一个已知的时间范围内里面接收到。这意味着当你持有Algorand的Token时，根据协议最初的设计你需要时刻保持在线来接收消息。如果你不在线你就不是一个合格的Token持有者。Cardano的共识协议Ouroboros则假设所有用户有一个弱同步的时钟，并且所有消息都能够在一定时间间隔内被送达。这实际上是提出了一个非常强的假设。有很多攻击方式能够让你的挖矿设备，你的公共节点或者手机上的时钟产生偏差。并且这个方案在现实环境中实现起来也非常困难。另外SleepyProtocol也要求用户拥有大致同步的时钟。当这些安全性假设被违反，会为这些PoS协议带来灾难性的后果。并且PoS协议引入了一些新的攻击方式，如Nothing-at-stakeAttack，GrindingAttack，Long-rangeAttack，这些攻击方式在PoW协议中是不存在的，在这里我不对这些攻击方式进行详细描述。那么DAG协议怎么样呢？所有DAG协议都有交易排序的问题，如像DAG协议那样让区块同步产生，那么不同的矿工或不同的公共节点对交易顺序的判断会有不一致：我认为这一些交易被确认了，但是其他人可能认为另一组交易是被确认的。这时候你会有两种解决问题的思路。一种是在区块链拓扑排序完成之后对交易进行排序，这意味着你需要等待很长的交易确认时间。另一种是不去确认交易顺序。合约的输入需要全局的交易顺序，如果不同矿工判断的交易顺序不同，那么每个矿工对合约逻辑执行顺序的理解就是不一样的，特别是对于复杂的合约。这会限制合约的功能性，复杂合约不能执行，合约中包含的Token会卡在合约中。那么那些有两种区块类型的协议如何呢？两种区块类型的协议，顾名思义，它采用一种和NC中的区块一样的关键区块来保障交易确认的安全，同时在两个关键区块之间广播微区块来提高吞吐量。这些协议通常和DAG协议一样会有较长的确认延迟。BitcoinNG就采用了上述的方案。在BitcoinNG的论文中明确表明，若用户需要确保交易确认，在BitcoinNG中他们就需要等待数个关键区块的确认，忍受较长的交易延迟。。声称的TPS？
所有采用这些替代性共识协议的项目都声称它们有很高的吞吐量，那么这些项目的吞吐量究竟如何呢？Solana声称能够每秒能够处理710000笔交易。如果你能够有这么大的突破，理应获得图灵奖。我迫不及待地想听到他们获奖的消息。还有这个名为NKN的协议，他们声称他们能够在全网拥有10000个节点的同时每秒处理100万笔交易，目前我还不知道他们是如何做到的，但是我对他们实现的方式非常好奇。我也很好奇为什么Stellar和Ripple也将自己的协议归类为NC，我也非常好奇10000个节点如何实现每秒处理100万笔交易的。而如果你想做个梦的话，你最好做一个伟大的梦，比如这个协议。它声称能够在低于1秒的最终确认时间内拥有1000000000000TPS。嗯，我真的觉得地球对他们而言已经不够大了，他们真的需要另找一个更大的星球来部署他们的协议。我们要注意的是，自称的TPS是没有可比性的。因为它们是在不同的网络环境中做模拟，某些模拟甚至使用1Gbit/s的带宽，显然这和现实网络情况相差甚远。并且这些协议都忽略了真实的情况。他们之中没有一个考虑到交易的同步。对它们来说似乎所有的交易都是已经在区块中同步好的一样，共识协议只是用来对交易进行排序的。而且一些模拟假设委员会成员之间有直接的连接，但事实是，在公有链网络中所有的消息都是通过广播进行的，而广播消息会占用公共节点的带宽。知识点：FreshTransaction，为什么说要考虑交易的同步呢？要认识到，在比特币中一个用户从钱包客户端发起的交易并不是被所有矿工都接受到，而是相邻的几个矿工。这些矿工在接受到用户发起的交易的时候会对交易进行验证才能放到交易池中，以便在未来将这些交易打包出块。因此若一个矿工成功挖到一个块并广播CompactBlock，其他矿工在检查CompactBlock中交易ID的时候若发现对应的有些交易并不在自己的交易池中，则需要向发送方请求完整交易进行验证来保障区块中所有交易都是合法的，这些交易就是「FreshTransaction」。若不进行验证就在收到区块之后挖矿，一旦完整区块广播后被发现有非法交易，将不会被矿工认可，在这个非法区块之后挖出的区块都会作废。FreshTransaction的概念我们会在后面用到。比较吞吐量的简易模型
这里我们有一个评估TPS的模型。如图所示，首先我们相信所有公共节点的带宽是有一个上限的，最多能够使用100%的带宽，你不能使用超过100%的带宽。在这里带宽的占用有三个组成部分。如上图所示，第一部分是用于同步最终确认的交易所占用的带宽比例，这一部分是真正的TPS。交易首先要被同步，之后才能进行交易确认。第二部分是被共识协议「浪费」的带宽所占的比例。第三部分是未被利用的带宽。所以如果想要提高TPS，能够做的只有两件事。1、降低共识协议占用的带宽比例2、降低未被利用部分的带宽比例能做的只有这两件事情，对，没有其他的方式了，并且对于Layer1的协议带宽占用不能超过100%。那我们先来看看其他替代性共识协议的带宽占用。事实上，很多协议将它们珍贵的带宽资源浪费在委员会成员之间的通信上。Algorand存储区块证书以此来向新用户证明一个区块被提交。每个区块证书的大小是300KB，独立于区块容量限制之外。如果你按照一个区块1MB的大小来计算，那么这意味着大约25%的带宽会永远被用于同步这些证书。因此我非常好奇为什么它们声称他们的吞吐量比NC更好，这根本不合理。另外一种在共识协议中浪费带宽的方式是区块型DAG和孤块中的冗余交易。如上图的论文中所说，如果所有的节点在区块中选择包含同样的一组子交易，任何两个平行创建的区块将可能出现冲突，并且吞吐量就不会很高。而目前所有的区块型DAG协议对这种情况视若罔闻。如何突破中本聪共识困境？
从上面的分析中看到，显然目前的吞吐量不能满足我们，因此，NervosCKB的共识协议NC-Max对NC做了一些改进：NC-Max有三个主要的创新采用两步交易确认来降低孤块率动态调整区块间隔和区块奖励来更好的提升带宽利用率在难度调整的时候考虑周期中的所有区块，来抵御自私挖矿攻击。接下来我会进行详细解释。NC有一个天然的吞吐量限制，因为想要提高NC中的吞吐量，只能做两件事情：第一件是更大的区块，就如BitcoinUnlimited和BitcoinCash那样，还有很多其他的项目也这样做；第二件是降低出块间隔。但是由于区块广播需要时间，广播期间若其他节点发现区块并广播，会和正在广播的区块产生竞争，其中之一会成为孤块。更大的区块会需要更长时间广播，降低出块间隔实际上是降低出块难度，节点更容易发现区块。这两种方案容易带来的结果是孤块率变高了。这些孤块占用更多的带宽，但是它们并不为交易确认做出贡献。当孤块率提高时，系统的安全性会降低并且吞吐量也会降低。因此对于这两种方案最终会达到一个平衡，当区块大小或出块间隔调节到一定程度时，孤块率会高到一定程度，即使你进一步增加区块大小或者降低出块间隔，吞吐量也不会得到提高。为什么太多的孤块会对网络的安全和性能产生负面影响呢？在上图中我们能够看到，当孤块率非常高时，攻击者能够非常轻易地私自构建一条更长链。攻击者只需要拥有比全网算力的51%低很多的算力，就能够覆盖掉区块链。并且孤块会消耗公共节点大量的带宽，这会对整个系统的吞吐量造成很大的负面影响。那我们如何打破NC吞吐量的限制呢？经过上面分析，如果我们想要打破这个限制，就必须降低孤块率。如果孤块率下降，那么网络的安全性和吞吐量都能够提高。如何降低孤块率呢？孤块的出现是由于区块广播的延迟，若在一个区块广播的过程中，有另一个区块被发现，那么其中一个区块就注定会成为孤块。如果区块广播能够瞬间完成，自然不会有孤块出现。那我们如何确保区块能够足够快速地被广播出去呢？比特币的开发者已经投入了非常多的资源和精力来加快区块的广播速度，我们需要进一步找出哪些区块的广播速度较慢，或是出了问题。我们来详细看看这是如何发生的，请看下图。目前的比特币网络，如果一切顺利的话，一个区块是通过一个CompactBlock中继协议来广播的。在CompactBlock中，并不会将整个交易广播出去，而是广播CompactBlock中的交易ID。这些交易ID组成了CompactBlock，这些CompactBlock比实际的区块小很多，因此速度会快很多。当节点A广播CompactBlock给节点B的时候，节点B检查这些交易ID，如果对于节点B这些交易都不是FreshTransaction，节点B能够立刻转发这些CompactBlock给相邻节点，这种情况非常棒，过程很顺利。然而如果在CompactBlock中有FreshTransaction，节点B将首先需要从节点A那边同步FreshTransaction，然后验证这些交易的签名，这些步骤都很耗费时间。只有当整个区块都经过验证无误之后，节点B才能继续广播这个区块。这个过程避免收到的区块非法，这样矿工才会在这个区块之后挖矿并广播，若不经过验证万一之后发现是非法区块，那么在这个非法区块之后的区块都是无效的。同步FreshTransaction的过程是比特币区块广播延迟的主要原因。所以，以太坊是一个糟糕的尝试，我来分析一下他们是怎么做的。以太坊简单地缩短了出块间隔，但是以太坊有一个问题，就是它不能够在收到区块之前验证交易的有效性。因为在以太坊中一个交易的有效性依赖于区块中交易的顺序，因此如果你想要验证一个交易的有效性你必须等到整个区块都被接收到才行，这样的话每一个区块实际上都是FreshTransaction。并且以太坊的网络协议维护得非常差，自从2015年开始就没有任何的迭代。而且在交易广播过程中也有大量的冗余。以太坊客户端会将同一笔交易向不同的节点广播7次，这意味着每一个节点将会收到同一笔交易7次。而且不同类型的客户端之间有不一致性，两个主要的以太坊客户端之间基本都是独立的。因此能够链接两个不同的网络的节点非常少，这也是为什么以太坊孤块率有时会高达30%，并且交易吞吐量非常低。而且大矿工没有加快区块广播速度的激励。因为如果我的区块能够更慢地广播出去，意味着我实际上能够实现「自私挖矿」。这对我来讲是好事，为什么我要加速区块广播呢？以太坊中的叔块奖励也没有提供任何帮助，毕竟如果产生了的孤块，矿工还是能够获得奖励。因此小矿工会采用先广播区块头和空块的方式，因为广播区块头的速度会快很多。并且由于不知道下一个区块中会包含哪些交易，因此矿工通常会挖一个空块来确保区块中不会包含和之前区块交易产生冲突的交易。这非常糟糕，因为空块并不为交易确认做出贡献。下面是我们的设计，来缓解上面提到的一些问题。这张图是区块的结构，我们在比特币区块结构的基础上增加了几个字段。上图是我们的完整区块的区块结构。首先我们有一个交易提案区。只有交易提案区可包含FreshTransaction，而传统的交易确认区只能包含前几个区块的交易提案区的交易，若当前区块高度是h的话，那么就是h-m到h-n区块的交易提案区内的交易。只有这些交易能够被确认，FreshTransaction不能被交易确认区确认。交易提案区不包含完整的交易，只包含交易ID，因此交易提案区会非常小。在叔块头区可以包含任意数量的叔块，叔块应该包含它们的区块头和交易提案区。叔块头区不计入区块大小，因而不受区块大小的限制，所以不会限制矿工添加叔块。下面我进一步来解释交易提案区。这个区域非常小，因为它只包含交易ID。完整的交易与区块同步广播，因为这是一个并行的过程，所以交易的广播不会影响到区块的广播。并且节点在收到广播的交易后只需要验证哈希，不会影响区块的验证过程。尽管这意味着在交易提案区可能会有无效的交易，双花交易以及矿工可能不愿意接受的交易，但是这都没有关系。类比之前提到的比特币区块广播过程，在我们的协议中，发现区块的节点会先广播CompactBlock，CompactBlock较比特币的稍微大一点，包含交易提案区和若干叔块的区块头和叔块的交易提案区。但由于CompactBlock本身足够小通常会立刻广播给相邻的节点。新提出的交易，如果有一部分不在节点的交易池中，它们会在发出CompactBlock之后进行广播。这些都是并行过程，不会相互影响。节点收到交易，经过哈希验证后广播给相邻的节点。这很自然地会有几个问题：如果矿工拒绝提供提案交易的完整版本怎么办？我把这个交易放到我的交易提案区，但是当你问我要完整的交易的时候，我装作不知道。实际上这个对区块广播不会有影响，因为不论交易提案区是否有FreshTransaction，区块都能够广播。并且其他矿工也会继续挖矿，因为总是有足够的提案交易需要确认。该矿工也没有必要挖空块，因为之前区块的交易提案区包含了它将打包的这些交易ID，已经被发现的区块在CompactBlock中都广播了打包进的交易确认区的交易ID，矿工都知道哪些交易被打包了哪些没有，不会选择和被发现区块交易确认区内相冲突的交易，因此矿工会选择继续打包交易出块并获得手续费，为交易确认做贡献。那么如果矿工在他们最新的区块中包含了这些提出但未广播的交易，以获得一个类似自私挖矿的优势怎么办？在比特币的NC中，矿工减慢区块广播速度可以获得挖矿优势。矿工通常能够在挖出一个区块时，只广播区块头，而在广播完整区块的时候放慢动作。在这个过程中只有该矿工能够挖矿。但是在我们的协议中，采用这种方式只会减慢n个区块之后的区块广播速度。因为提出但未广播的交易只有自私矿工知道，也只有自私矿工能以此作为优势。然而这个不能被用在下一个区块中，因为在我们的协议中只能挖n个区块之前提案区中包含交易，中间需要有一个间隔。矿工只能够挖h-m至h-n个区块内的提案交易，但是不能挖前一个区块的提案交易，除非这个区块也是被攻击者挖到的。如图所示，这是我们的共识协议和比特币NC的对比。在比特币NC中当自私的矿工找到区块h，它能够立刻开始挖区块h+1，此时诚实矿工只能够在收到完整的区块h之后才能开始挖矿，因为其他矿工需要知道区块包含的完整的交易并验证来确定区块是合法的，而自私矿工能够通过减慢区块h传输的速度来让其他矿工更晚收到区块。在区块广播期间就是自私挖矿者的优势期。然而在我们的协议中当一个自私矿工找到一个区块h，广播了包含区块头和交易ID的CompactBlock，诚实矿工能够立刻开始挖h+1。如果自私矿工想要利用这些提出但未广播的交易，它必须找到n个区块之后的区块，这样他们才能利用这个优势。然而这很难发生，你不能确定在n个块之后的那个块是你挖出来的，这个非常难预测。为了更好地利用带宽，我们的协议使用了另一种不同的难度调整机制，设定一个固定的孤块率。如果孤块率在上一个难度调整周期低于设定的孤块率，挖矿难度会降低，出块间隔将降低，吞吐量会提高。也就是说，更少的孤块意味着当前的网络状态实际上有能力更快地同步交易，我们能够在提高吞吐量的同时不损害网络的去中心化。反过来看如果难度提高，那么出块间隔会增加，吞吐量也会降低。如果孤块率很高那么意味着当前的网络在这个难度调整周期内并不能处理那么多的交易，那么协议就会降低吞吐量。同时出块奖励会和1/成正比，因此在每个难度调整周期中预期的总出块奖励是固定的。这意味着假设我们每十分钟出一个块，每个块中有12.5个比特币，如果难度调节变成每5分钟出一个块的时候，每个块会有6.125个比特币。因此货币的发行率也是保持恒定的。最后，抵抗自私挖矿攻击。前面我们提到我们的协议和NC的一个区别在于，我们的难度调整机制是根据难度调整区间中出现的所有区块来计算的，在估计总算力的时候也会包含叔块。在NC-Max中，假设攻击者占总算力的30%，诚实矿工70%，如果没有自私挖矿攻击，在10个区块中攻击者能够找到3个区块，诚实矿工找到7个。如果进行自私挖矿，攻击者在7个区块中能够找到3个区块，诚实矿工找到4个，3个诚实区块会成为孤块，主链会增长缓慢。前面也提到自私挖矿在第一个难度调整周期内是没有收益的，那么在第二个难度调整周期会出现什么？在下一个难度调整周期，难度会保持不变，攻击者并不能用同样的算力找到更多的区块，因此自私挖矿不再有利可图。也就是说，我们假设币价在短时间内维持稳定，由于自私挖矿攻击者是短视的，他们的奖励是根据单位时间内获得的奖励来定义，可以等价于同样的电力消耗能够获得的奖励。在比特币中，自私挖矿攻击者能够通过降低链增长速度，「迫使」协议降低出块难度，从而在难度调整之后单位时间内能够获得更多的奖励。而在NC-Max协议设计中，出块难度会根据所有区块来计算，包括孤块，攻击者让诚实矿工的区块成为孤块，却并不能「迫使」协议降低出块难度，以在单位时间内获得更高奖励。最后总结一下，我们的协议会很好地利用孤块：我们希望能够通过两步交易验证来降低孤块数量，在孤块数量降低之后，我们利用孤块率作为一个带宽利用水平的指标来动态地调节吞吐量。并且孤块信息被写在了区块链中，我们在挖矿难度调整算法中利用这个信息从而让自私挖矿无利可图。NC-Max是NervosCKB的PoW共识协议。NC是NakamotoConsensus的简称，也就是比特币的共识协议。如果读完这篇文章，你觉得这个共识协议应该有一个更好的名字，欢迎告诉我们。推荐阅读：张韧博士的共识安全性分析文章《制定通用的标准：评估PoW共识协议的安全性》
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。