为何ABC的CTOR无助于扩容 by Bitcoin Unlimited Andrew Stone

联合译者:Amy, Wendy, Lise


紧随Bitcoin ABC开发人员Shammah Chancellor之后,Bitcoin Unlimited核心开发人员Andrew Stone发布了一篇名为《Why ABC’s CTOR Will Not Scale》的文章进行了回应。

以下为译文:

 

为何ABC的CTOR无助于扩容


Bitcoin ABC提出的分片技术有两个问题。首先,它提出的交易排序方式是不必要的。其次,也是更重要的一点,分片(将数据分布到多台机器上从而达到扩容的目的)在实际中并不可行。

造成混淆的原因是工程师没有检查整个网络堆栈,并且这个提议忽略了两个重要的操作:

1、对交易输入的确认

2、终端用户钱包的交易信息请求

交易输入的确认(为什么CTOR对于区块扩容来说是不必要的)

交易ID是伪随机数,如果用S代表总分片数量,只有1/S祖先会在局部化的分片当中,而(S-1)/S祖先则在远程分片中。也就是说,当S > 2时,大部分祖先需要向远程分片发送信息。

对于数量为8的保守总分片而言,⅞的祖先需要远程确认。每笔交易至少有一个祖先(e除了单个币基交易),所以最少有⅞的交易需要远程请求。但就目前的平均输入数量而言,每笔交易有两个祖先是更为合理的数量。也就是说,考虑到区块中包含N个交易,为了确认区块,需要7N/4个远程请求,每个分片做7N/4S个远程请求。

如果平均每笔交易的祖先数量是P,计算总远程请求次数的公式是(S-1)/S * PN,每个分片的请求次数是(S-1)/S² * PN。

关于瞬时切换,CTOR声称的扩容优势是能够轻而易举地拆分区块,并将传输交易到分片上,因为区块基本就是按顺序拆分,即第一部分N/S交易划分到分片1,第二部分到分片2,以此类推。

然而,假设一个没有排序的区块按照相似的方式拆分,同样划分N/S交易到“API请求处理器&交易路由器”节点(根据Chancellor的分片提议中的图2)。节点按路线发送交易到合适的UTXO分片。这意味着N条信息将遍布S个节点,所以每个分片的负荷是N/S。

所以这个“顶层”路由要求每个分片处理N/S条信息,而“验证路由”只需要每个分片处理(S-1)/S² * PN条信息。

假设S(分片数量,比如大于等于4)和P(每笔交易祖先数量,比如大于等于2)取值合理,验证路由(3/8N)相比顶层路由(1/4N)要求每个分片处理更多信息。

如果分片方案可以路由负荷的确认进行处理,那么它也可以处理未排序交易的顶层路由。因此,CTOR是完全不必要的。

此外,CTOR分片结构将分片算法共享给每个人。这很容易导致攻击,攻击者只需要确保打包区块中包含的交易ID全部存储在一个单独的分片中(矿工可以锻造现有交易或者创建自己的“有特殊标识”的交易)。虽然还不确定这对于一个要求分布式处理的系统有何影响,但肯定不是很好的影响。(关于攻击,引自Tom Zander)

终端用户钱包的交易请求(为什么分片提议漏洞百出)

Chancellor的分片提议忽略了轻钱包(SPV钱包、移动钱包等等)获取交易信息的功能。但BCH架构的重心就是能够通过轻钱包访问获取信息,其扩容方案应该建立在终端用户不需要运行全节点这个理念上。当前,轻钱包与全节点的比例与当今电子邮件用户与电子邮件服务器的比例相当——我们保守地假设,每一个全节点要服务1000个轻钱包。这个数量级对比显然是扩容中最需要考虑的一点。节点每接受一个新区块就会向它的轻量钱包发出1000条信息,或者是1000次信息获取,而这个提议里并没有提及这一点。

轻钱包需要获知它们感兴趣的、与相应交易地址匹配的交易信息。而实现这一点是通过MERKLE_BLOCK 信息,为轻钱包提供了一个去除了它所有不感兴趣交易信息的区块。

根据Chancellor的提议,UTXO集是按照交易ID分片的,与地址无关。所以如何创建MERKLE_BLOCK 的信息呢?

在他的提议中,轻钱包用户的请求必须通过“API请求处理器和交易路由器”节点发送到每个分片。然后每个分片必须搜索对应部分的区块来匹配交易地址并响应。“API请求处理器和交易路由器”节点则把所有信息聚合起来,形成MERKLE_BLOCK。如果一条普通的信息需要牵涉每一个分片,则谈不上扩容。

值得注意的是,即便移走MERKLE_BLOCK 信息,我们仍然需要搜索每一个分片,来寻找与涉及兴趣地址有关的交易。也许大部分的钱包在过去10分钟没有任何交易,但是我们仍然需要搜索每一个分片,产生“没有你感兴趣的东西”的回应。

唯一的解决办法是把轻钱包需要的数据放到一个分片中。钱包能在一个分片中生成“有特殊标识”交易(具有共同ID前缀的交易)吗?不幸的是,发送钱包负责产生交易,而接收钱包负责搜索和列举交易前缀。那么发送到多个地址的交易会怎样呢?

为了解决轻钱包数据传输这个问题,这也是最重要的一个问题,需要应用另一川完全不同的分片机制。如果部署了CTOR,那么为了部署真正能够帮助分片区块链的技术时,就很难撤销CTOR了。

附录A:对石墨烯等区块有何影响?

在讨论分片和扩容之前,已经有一些关于CTOR的论点,那些观点不在本文的论述范围。但总的说来,我们应该使用非硬分叉、非强制的排序规则,而不是非要矿工主导的(CTOR)排序规则。

让我们看看石墨烯(Graphene)——只要有一种排序方式存在,它并不在意排序方式的。矿工可自行选择石墨烯可以理解的排序方式来为交易排序,而石墨烯可以接受多种排序方式。所以如果我们找到了一个能真正有助于扩容的排序方式,可以升级石墨烯来支持它。

非强制性的、非硬分叉的、非共识强制执行的交易排序可以提供与CTOR同样的好处。如果它没那么必要,我们是否需要冒着重大共识改变产生意外分叉的风险来实施它?

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,907评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,987评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,298评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,586评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,633评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,488评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,275评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,176评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,619评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,819评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,932评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,655评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,265评论 3 329
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,871评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,994评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,095评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,884评论 2 354

推荐阅读更多精彩内容