首页 科技正文

usdt钱包官方下载(www.payusdt.vip):“状态数据膨胀” 问题的手艺路径:无状态性

约稿员 科技 2021-06-25 00:00:41 105 1

USDT第三方支付平台

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

一. 弁言

本文的目的在于向人人先容一种解决 “状态数据膨胀” 问题的手艺路径 —— “无状态性(statelessness)”。“状态数据膨胀” 是所有允许用户自主写入状态数据的公链都市面临的问题,指的是由于用户及合约的不停增添,在全节点处保留的状态数据会越来越多。不停增添的状态数据会带来一系列风险,包罗:抬高全节点的运行门槛;使链上操作的订价失衡。

在本文中我主要拿以太坊区块链来举例,这是由于我对以太坊最熟悉,但状态数据膨胀问题是普遍的,不是以太坊独占的。我同样也会举出我所知的其他项目对这个问题的思索。

为使人人充明晰白 “无状态性” 的意义,我少不了要在开篇交接一下问题的靠山。然后我会先容以太坊社区为此提出的几个观点,以及相关的 开放问题/权衡取舍。最后,我会再回到最初的问题,以期通过对问题的多样形貌(以及引出来的解决方案思绪),拓宽对该问题的思索。

二. 状态数据膨胀问题

可以把 “区块链协议” 明晰为一种让不定数目的盘算机的行为统一步骤成一台盘算机的协议。那么,其运行会在介入相关协议的盘算机(即 “节点”)处发生两种数据:一种是区块数据,即我们常说的区块链,这部门数据纪录了这个网络(这台盘算机)在已往发生的所有事情;另一种是状态数据,即代表当前整个网络的状态的数据,对以太坊来说,“状态” 的内在包罗:哪个账户有若干余额、已经发出过若干笔事务(不包罗曾经发出的事务的内容,那是区块数据);哪个合约的代码是什么,其内部的哪个存储项的值是什么;尚有一些与共识机制运行相关的数据。

状态数据的特殊性在于:一方面,状态数据是历史区块(所包罗的事务)执行之后的效果;另一方面,它又是执行新区块的条件。因此,在当前的以太坊区块链上,全节点必须保留状态数据,这样才气(通过执行区块来)验证新收到区块的正当性。

可以想象,由于用户和合约的数目会不停增添,若是不施加一些控制,状态数据的规模是会不停增大的。这就是状态数据膨胀问题。

状态膨胀问题带来的影响是确定的:它会让区块验证变得越来越难题。由于同样是读取和写入一个状态工具,在状态工具有 10 万个的时刻,比之状态工具只有 1000 个的时刻,资源开销是上升的。也正因此,状态膨胀会使运行全节点的门槛提高(单元时间内,资源的开销 —— 主要是硬盘随机读写 —— 不停上升),还会使 EVM 各操作的 Gas 开销比例逐渐失衡,发生对节点的 DoS 攻击向量。(注:资源开销的上升幅度与客户端软件的实现有关。)

但状态膨胀问题的缘故原由为何(因此应当若何纠正),则有许多种差其余角度。好比,Vitalik 对该问题的归因 [1] 是:

换言之,问题的泉源是支付和成本的不匹配 —— 当前的以太坊协议既做不到能够合理地删除状态来给区块链 “瘦身” [2],又做不到让用户延续为保留自己的状态付费。假设能做到,这个问题就能获得控制,不会这么严重了。因此,他倾向于 “状态保质期” 偏向的改善:用户确立或更新某个状态工具之后,只能保证全节点会在一段时间内存储这个工具;逾期则必须接纳分外的手段(因此是分外的支付)来 “复生” 这个工具。

对问题的其他归因和 “状态保质期” 观点,我们后文还会讲到。现在我们先转向 “无状态性(statelessness)”。

注 1:Vitalik Buterin

https://ethfans.org/posts/a-theory-of-ethereum-state-size-management

注 2:在当前的以太坊协议中,简直有操作(SELFDESTRUCT)可以做到删除合约的存储项,也为该操作码的使用提供了一种粗拙的激励机制(返还 Gas 机制)。但事实证实,返还 Gas 机制不仅没有改善状态膨胀问题,还促成了 Gas Token 的泛起,加剧了状态膨胀问题;而 SELFDESTRUCT 则导致了其余一些问题。 

三. “无状态性” 诸观点

(一)无状态性

“无状态性” 背后的看法是:状态膨胀问题之以是是一个问题,是由于验证区块的节点必须先有状态数据(先得知道某个账户有若干钱),然后才气验证区块(然后才气知道该账户花 X 元到底合不正当);但若是我们能做到无需在内陆存储状态数据就能验证区块,那就无需郁闷这个问题了。

详细做法是,在广播区块时,附带流传一份对该区块内所有事务所接见状态的证据,一个完全不保留任何状态的节点,也可以依附这些证据恢复出正好足以验证该区块内所有事务的状态树,而且验证之后可以把这些状态数据都抛弃。这里的 “所接见状态的证据”,通常称为 “见证数据(witness)”。

无状态性代表着对状态膨胀问题的釜底抽薪式解决方案,彻底免去区块验证对状态数据的需要,自然就不需要郁闷状态膨胀的问题了。另一方面,各节点还可以自行选择存储哪些状态,允许开发者为自己的使用场景定制所需的客户端。

然则,从节点的角度看,这意味着一种交流:以增大带宽开销为价值,来节约硬盘的读写和存储开销(只管读写开销确实是当前全节点的成本中最大的一部门)。那么见证数据到底有多大?

若是纰谬以太坊协议作任何改变,见证数据的巨细会在 MB 级别 [3])。相比之下,当前(区块 Gas 上限为 1250 万)的以太坊区块数据量约为 45 KB [4]。由此看来,见证数据的带宽开销是异常大的。已往两年中,无状态以太坊研究的主要偏向,就是思索若何才气降低见证数据的巨细,偏向有:(1)代码默克尔化,削减需要包罗在见证数据中的合约代码数据 [5];(2)改变以太坊状态树的名堂,好比将十六进制树改为二进制树 [6],或者将默克尔树改为 KZG 准许树(也就是所谓的 Verkle Tree [7]);(3)以区块为单元提供见证数据,而非以事务为单元,这样可以免去一些重复的证据。改为二进制树可以节约一半的带宽开销甚至更多;而 Verkle Tree 可以发生牢固巨细的见证数据。

除了带宽开销增大以外,无状态性还带来了一种革命性的转变:网络中可能大部门节点都不会保留状态数据,至少不会保留全量的状态数据。那么以往我们习以为常的属性,在无状态客户端为主的网路中就纷歧定能实现了。这些问题都要重新思索:

  1. 若是一个节点是无状态的,仅保留了区块数据,虽然它能介入历史区块广播和历史事务广播,但它没设施介入新事务的广播。准确点来说,TA 是没法验证新收到的事务的有用性的。那么这样的节点要若何在 P2P 网络中存在(其他对等节点会把它当成一个无用的节点而中止链接)?事务要若何在网络中流传?这是否意味着我们岂论若何都需要某种以事务为单元提供见证数据的机制?照样说无状态节点只能在一个专门的次级网络中生计?(基于后者的解决思绪是形成一个可以按需请求状态数据的次级网络 [8],就像我们常用的 BitTorrent 种子下载网络一样;固然,为广播中的事务增添见证数据也是一个设施)

  2. 若作甚见证数据指定 Gas 开销?又或者说,若何限制见证数据的巨细?

上面这个清单仅仅是当前的研究功效,它仍有可能变得更长。这些运行假设的转变,极有可能比它的带宽开销上的影响更为主要;若是不剖析清晰这些假设,就没有设施判断无状态性是否真的值得实现,或者何种实现方式更好。

当前,有一种对无状态性的分类是:

在我看来,两种偏向存在短长,但不应以为网络的最终形态可以被计划出来。从节约带宽的角度,弱无状态性是更优选择;但响应地也要面临上文所述新事务流传问题。后文我们还会回到这个分类。

下面我们进入第二个观点:“准-无状态性”。

注 3:Alexey Akhunov

https://ethfans.org/posts/state-availability-getnodedata-dht-approach-dev-update

(二)准-无状态性

准-无状态性的观点来自这篇文章 [9]。其背后的直觉是:无状态性对见证数据的要求是能辅助完全无状态的节点从 0 最先建构出能验证响应区块的状态树,但这很有可能虚耗了带宽资源;由于一旦收到了见证数据之后,节点就已经有一棵希罕的状态树了,这棵树是可以重用的,犯不着把它全删了,收到一个新区块又从 0 最先建构。

因此,假定节点在收到一个区块前,其状态数据的存量情形是可知的,我们就可以借助见证数据为之提供一个状态增量,这个增量加上其初始存量,正好足以建构出能验证新区块的状态树。云云一来,我们就既能获得无状态性的大部门利益(通过附带见证数据,让区块验证的硬盘读写开销最小化),又不需要像无状态性那样,支出那么高的带宽开销。

而且,准-无状态性尚有一个分外的利益:当状态数据变得越来越多,状态树变得越来越深越来越密,无状态下的见证数据理论上来说也会不停增大,即带宽开销趋于上升;但准-无状态性的见证数据仅提供增量数据,以是其见证数据也是最小化的。

贫苦在于,这个 “节点的状态数据存量” 若何可知?理论上来说,除非我们从某个一致的存量最先执行准-无状态性,否则是无法对这个存量杀青同步的。但只需 “一致”,这个数目详细是若干,无关紧要。由此我们发现了准-无状态性的另一个优点:倘使状态数据已经变得过于重大,我们可以将它们 “清零”,从无状态重新最先,启动一次新的、由富状态节点(好比出块节点)向验证节点传送见证数据(和状态)的历程。

这就是 ReGenesis,定期重启以太坊这台盘算机。

注 9:Igor Mandrigin

https://ethfans.org/posts/semi-stateless-initial-sync-experiment

(三)Regenesis

ReGenesis 的构想最早由 Alexey 提出 [10],更仔细的解读可见此文 [11]。大意是:定期(好比每 100 万个区块)将协议设定为空状态,最先实行准-无状态的流程 —— 每一个区块在流传时,都必须附带一些见证数据,使得一个从上一次 regenesis 事宜最先清零了状态数据、并获得了自那以来所有区块附带见证数据的节点,都能验证该区块。

也就是说,每次触发 regenesis 事宜,一个只求验证区块、不求发生区块的节点就可以把内陆的状态数据清零,依附新收到的区块附带的见证新闻,建构起正好足以验证该区块的状态树;每个见证数据,都市带来增量的状态数据,只要节点缓存了自己的状态树,则见证数据都是正好够用的。当节点内陆的状态数据足够多,甚至有可能泛起无需附带见证数据的区块。然则,又不必郁闷状态数据的膨胀问题,由于节点会定期清零状态。

ReGenesis 是一个稀奇平衡的方案(现实上也是当今的 “无状态以太坊” 研究的主要偏向)。而且,由于它追求的是准-无状态性,虽然 ReGenesis 要求实现基于事务的见证数据,它绕过了基于事务见证数据的无状态性的一个瑕玷:需要频仍更新一笔事务的见证数据,每一次状态根更新(也即每一次出块),都要求更新未打包事务的见证数据;然则,在准-无状态性中,准-无状态节点每收到一个区块,内陆的状态就会多一些,而事务被打包的时间肯定晚于其广播的时间,以是事务在广播时附带的见证数据肯定足以应付验证的需要。

那么它的瑕玷在那里呢?

,

Usdt第三方支付接口

菜宝钱包(www.caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

,

(1)若是一笔事务在事先并不能确定自己会接见哪些生意(这被称为 “动态接见模式” [12] ),则有可能并不能提供足够的见证数据并因此失败。这并不是一个不能解决的问题,由于凭证准-无状态性,只需多次提议并弥补见证数据,总能乐成。但这总归意味着用户可能要多次发送统一笔事务。

(2)不确定 ReGenesis 下节点会不会也甩掉区块数据,以是 rollup 这样 layer-2 方案可能会受到影响。

从我们上面推论下来,ReGenesis 很像一种无状态或者准-无状态方案。然则,从另一个角度看,ReGenesis 也很像一种 “状态保质期”方案或者 “状态租金” 方案:每过一段时间,所有的状态工具都市过时、失活,而你为了让自己的状态复生,必须支付分外一笔价值;而用户的一次付费,也只能保证相关状态在节点处能存储一段时间,而无法保证能永远存储。

从这个角度看,ReGenesis 会晤临另一个所有状态保质期方案都市面临的问题:“复生冲突”。若是有人在已经失活的状态存储位置直接确立了一个新状态(而不是通过提供见证数据来复生这个状态),那就会发生冲突 —— 早年的富状态节点(存储着已经失活的旧状态)无法与无状态节点(存储着新建的状态)杀青共识。对应的 ReGenesis 上,就是 regenesis 事宜触发后,有人实验在原本已经有状态的存储位置上新建一个状态(好比直接给自己的账户存进 10 ETH),一直存储着状态数据的富状态节点,就将无法与刚清零了状态的无状态节点,对状态根杀青共识(由于余额对不上)。

Vitalik 为此提出的解决方案 [12] 是:给账户放置一个与其确立时期相对应的标识符(例如,统一个地址 0x1234,在第 0 个 regenesis 时段确立的账户就符号为 (0, 0x1234),而第 4 个 regenesis 时段确立的账户就符号为 (4, 0x1234) ),从而明确用户到底是想复生自己在早年时段确立的状态,照样想新建一个状态,从而解决复生冲突问题。

当前,ReGenesis 已经完全被当成一个状态保质期方案,与弱无状态性所代表的无状态性方案相竞争 [12]。但在我看来,由于其运行需要使用见证数据,而围绕见证数据使用的研究是从无状态性的研究中生发出来的,以是无状态性是一个不应被放弃的视角,尤其是准-无状态性的观点,异常富有启发性。

注 10:Alexey Akhunov

https://ethfans.org/posts/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state

注 11:Igor Mandrigin

https://ethfans.org/posts/37566

注 12:Vitalik Buterin

https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739

(四)总结

从无状态性和准-无状态性的观点出发,我们最终走向了 ReGenesis 这种较为平衡的方案。从状态保质期的角度出发,也可以得出 ReGenesis 相当有竞争力的结论。然则,这绝不意味着无状态性的研究已经完成或者已被镌汰。事实上,我们还未能确定无状态性带来的所有影响是否都已被剖析清晰了,因此,也无法断言已经泛起了绝对值得实现的方案。而且,就算方案确定了,工程上获得平安高效的功效,仍有待时日(好比,假设真的把状态树从默克尔树改为 Verkle Tree,工程上需要花若干时间?)。因此,对无状态性的实现,我并不那么乐观。

接下来,我们重新回到状态膨胀问题,看看对这个问题的差异表述,会不会给我们带来一些启发。

四. 问题到底出在哪儿?

状态膨胀问题到底意味着什么?它在何种意义上是一个问题?若作甚之归因并提出可行的解决方案?若何权衡一种解决方案是否有价值?

你至少可以从以下几个方面,来思索状态膨胀给我们带来的影响:

(一)它会使区块验证的成本不停升高,因此抬高全节点运行的门槛;

(二)它意味着一种只增不减的永远性肩负,对网络的耐久存续和 *** 化是一种威胁;

(三)它意味着链上操作的 Gas 订价有延续存在的失衡风险(也是 DoS 风险);

我们一个一个来。

(一)验证成本

为什么状态数据的增添会提高区块验证的成本?由于对以太坊来说,(1)区块的执行和区块的验证是一回事,都是完全执行所有的盘算历程;(2)区块验证要求内陆具备最新的状态数据;(3)状态数据的增添意味着对单个状态工具的读取和写入变得更难题。这三个条件中,任一因果关系被打破或被削弱,状态膨胀给区块验证带来的影响都市被削弱甚至消除。

若是区块的验证与执行不是一回事、区块验证的开销是个常量,则状态膨胀问题不会影响区块验证的成本;这就是 Mina 等新兴区块链接纳的思绪:每次出块,出块者都市为区块的执行历程天生一个盘算完整性的证实,验证方只需验证这个证实就可以验证相关区块的正当性,而验证的开销是个常量,这就打破了状态膨胀对区块验证成本的影响。理论上来说,以太坊也可以引入类似的手艺;而我们要支出的价值是:找出一种平安可靠的、能够为通用盘算实现盘算完整性证实的工程实现、可能完全改变应用开发者的体验、需要重新设计链上操作的 Gas 消耗量比例。

同理,无状态性就是在打破或说影响第(2)条因果关系。实现无状态性之后,区块验证就不再要求内陆存储最新的状态数据了,但它还留下了一种风险:随着状态数据的增添,见证数据增大(因此验证区块的带宽开销增大)的风险。

而(3)则向我们指出,优化客户端同样有助于削减这个问题对我们的影响。举例而言:Geth 客户端 1.10 版 [13] 实现了状态快照,该功效可以保证状态读取的开销是一个常量,也即消除了状态膨胀对状态读取的开销的影响;然则,纵然优化到极致,状态写入的开销仍然会随着状态数目的增添而增添。

注 13:Péter Szilágyi

https://ethfans.org/posts/geth-v1-10-0-introduction

(二)永远性肩负

从这个角度看,问题出在:(1)用户可强制要求节点存储自己的状态;(2)支付与成本在时段上的不匹配,一次付费永远存储。

无状态性的激进和革命之处就在于,它针对的是(1),而不是(2),也即它不把这个问题注释为一个经济机制问题,也不思量改变经济模子来解决这个问题。无状态性完全消除了节点与内陆的一部门特殊数据(状态数据)交互以验证区块的需要,从而完全免去了存储状态数据需要。实现了无状态性之后,存储部门照样所有状态完全由节点运营者自己决议,用户现实上无法强制所有节点来存储自己的状态,只能预期矿池或者钱包服务提供商这样的专业运营商会存储自己的状态,而这是完全公正的。

而针对(2)的解决方案可分为两类:一类的倾向是:一次付费、有限时段存储;无限时段存储、延续付费。前者的代表是种种状态保质期方案;后者的代表是 Nervos 区块链。

在 Nervos 区块链上,用户要存储状态时就必须绑定一定数目的区块链原生资产 CKB,绑定的代币数目与可写入的状态数据巨细是成恒定比例的;由此,用户在存储状态时,虽然没有钱币支出,但因资产绑定而蒙受的未便利(或者说损失的时机收益),就是一种延续的、与存储状态的时长逐一对应的成本。因此,这一模式约束了用户存储状态的行为;而且 CKB 的数目就组成了状态数据的上限,控制了状态膨胀。

而状态保质期方案,相比无状态性就显得有点半心半意 —— 在许多状态保质期方案中,它虽然能约束状态数据的巨细(由于给准时间段内能刷新的状态工具数目是有限的),但纷歧定能降低与特殊数据交互的需要,它需要分外的数据结构来纪录失活状态的信息,也需要与这一数据交互。解决复生冲突现实上也就是在解决这个问题。

另外,包罗 ReGenesis 在内的状态保质期方案也意味着,整个网络的事务处置容量,会被一类并不缔造经济价值、仅仅是为了缴纳租金(或者说购置保险)的状态复生事务给占去一块。这使人疑心状态保质期到底是不是一个耐久可延续的、能获得民意支持的偏向,究竟,用户是会越来越多的。

(三)操作码 Gas 订价失衡

链上操作的 Gas 消耗量的绝对值是没有意义的,一个操作消耗 100 Gas 并不意味着什么;有意义的是差异操作的 Gas 消耗量比例:一个消耗 100 Gas 的操作的盘算开销被以为是一个消耗 1 Gas 的操作的 100 倍。它的意义有两重:(1)它指导应用开发者优化代码的偏向,假设两个操作路径都可以到达同样的效果,而一条路径的 Gas 开销更低,开发者就会实现这个路径;(2)若是这个比例失衡了,那就意味着某种操作的名义开销(Gas 消耗量)偏离了其现实开销,而这样的操作码就更有可能被行使来提议对节点的 DoS 攻击。著名的 “上海攻击” 就是这样:攻击者在事务中包罗了大量 Gas 消耗量很低、但节点现实盘算开销很大的操作码,而处置这些事务会使节点负载过大而掉线。

状态膨胀就会引发这样的失衡问题:状态操作的 Gas 开销是一个常量,但状态读写的开销现实上并不是一个常量,它会随着状态数目的增添而增添。那为什么状态操作的 Gas 开销不能实时、动态转变呢?由于状态读写逻辑上是由 EVM 来实现的,但现实上并不是,它是由客户端软件的数据库来实现的,差异客户端的现实开销既不统一,也无法被 EVM 感知。

值得提醒的是:上述两种效果是会相互叠加的。若是相关操作的名义开销比例,正好指导着应用开发者使用这种现实开销被低估的资源,则问题就会变得更严重 —— 着实状态膨胀问题自己就是这样的一个例子,状态读写的名义开销定得太低了。

当前以太坊社区的做法是,通过硬分叉来调整差异操作的 Gas 消耗量。这就即是是说,以太坊当前的治理程序,充当了 EVM 感知状态操作开销的信息输入机制。这样做固然不能完善地解决这个问题,它同时也提醒了我们,以太坊这台电脑有何等依赖人类工程师的定期修理。

此外,合理的 Gas 订价还要面临的另一个挑战是:它要用统一个器量单元,来器量本质上需要差异资源的操作的开销比例。

谈到这一点,是由于无状态性也受该问题的影响。在当前,节点执行区块的主要开销并不是盘算,而是状态的读写;而使用见证数据取代了状态数据之后,主要的开销就酿成了带宽。固然,出块者天生见证数据需要盘算,但纵然我们不思量这一点,或认定当前的状态操作名义消耗量已足够准确,我们仍必须思量怎么约束见证数据巨细的问题。好的设施无疑仍是价钱,但其 Gas 消耗量应若何确定呢?(注:CALLDATA 类型数据的订价就有点像是凭证带宽消耗量来订价。这值得我们深思。)

(四)回到无状态性

领会了这些问题,我们也许更能明晰无状态性事实解决了什么问题,又留下了哪些问题守候解决。现实上,我们再回过头来看无状态性,其原理是很单纯的:以带宽开销换取硬盘读写的节约。然则,能截然以为这一定是值当的吗?假设我们生涯在一个硬盘读写就是很廉价,而带宽就是异常稀缺的天下里呢?或者说,假设日后两种资源的价钱会倒转过来呢?

换言之,无论选择无状态性照样保持原状,从事厥后看可能都是不够天真的选择 —— 最理想的情形,应该是节点能自己选择牺牲哪个换取哪个,并随时切换,而不是由一个治理程序强制人人选择某一种,这种选择再好,终究只是有限头脑的智慧的产物,而且都不能清扫要依赖治理程序(在日后把选择颠倒过来)的风险。

这是否意味着,最优的方案应该是一个跟当前的以太坊网络部门重叠、平行运行的无状态客户端网络?用户能自由加入,自由切换?我们能拥有这样的方案吗?

五. 结语

自 19 年 3 月领会了 “无状态性” 观点以来,我便认定,无状态性是以太坊最值得研究的底层协议演化偏向,唯有它能既解决状态膨胀问题,又维持以太坊的经济属性。今天我仍这么信托。只是,对状态膨胀问题的思索,会不停牵涉到以太坊的底层范式 —— 全局状态和链上盘算 —— 最终具象化为一个问题:若作甚链上操作制订名义开销比例(gas cost)?无论要对以太坊作什么改善,都绕不开这个问题。最终你也会获得跟我一样的结论:以太坊的设计失衡之处不是一处,而是两处。无状态性之后,我们仍有迢迢长路。

版权声明

本文仅代表作者观点,
不代表本站热搜网的立场。
本文系作者授权发表,未经许可,不得转载。

发表评论

评论列表(1人评论 , 105人围观)
  • 2021-06-25 00:00:41

    8月30日晚,国家主席习近平在北京水立方出席2019年国际篮联篮球世界杯开幕式。 新华社记者 黄敬文 摄 新华社北京8月30日电(记者李忠发、杨依军)国家主席习近平30日晚在北京水立方出席人物关系好清楚

站点信息

  • 文章总数:4026
  • 页面总数:0
  • 分类总数:16
  • 标签总数:764
  • 评论总数:1639
  • 浏览总数:1348563