Bitcoin Forum
December 12, 2024, 08:44:32 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Warning: One or more bitcointalk.org users have reported that they strongly believe that the creator of this topic is a scammer. (Login to see the detailed trust ratings.) While the bitcointalk.org administration does not verify such claims, you should proceed with extreme caution.
Pages: [1]
  Print  
Author Topic: [20150122]加文•安德烈森:比特币区块扩容测试结果  (Read 307 times)
bitba.org (OP)
Sr. Member
****
Offline Offline

Activity: 338
Merit: 250



View Profile
January 23, 2015, 05:28:12 AM
 #1

操作摘要:如果明天我们将区块容量增加到20M,并且每个矿工都决定开始生成容量为20M的区块,并且比特币网络的交易数量突然增加,以至于能够填满20M的区块容量……目前计划实现的0.10.0版本可以处理并应对这些情况。

你可以查看我所做的工作,从我测试用的大区块分支上获取细节信息(参见megablocks-notes.txt)

改用大区块,CPU和内存使用量会大幅提升,这点在意料之中。容量为20M的区块构成的区块链对CPU和内存的要求仍在我的标准之内,即“拥有一台相当好的个人电脑,并配有非常好的家庭网络连接的普通人,能够运行一个完整节点”。

让我感到吃惊的是,在我的VPS主机上同步20M的链:更大的区块比小区块的速度快四倍。我不知道为什么。可能是VPS上正在进行的其它事情,影响到了结果,或者可能是磁盘的I/O更适合更大的区块。

那么接下来该做什么?

我们需要一次软分叉(soft fork ),处理一些长期以来的与OpenSSL相关的问题(OpenSSL-was-willing-to-validate-too-much-stuff).Pieter Wuille 和Gregory Maxwell一直在做这方面的工作。

但是,关于究竟如何增加区块容量,我们需要一个具体的提议。下面是我的提议:

1、目前的规则是,如果没有block.nVersion来定义的绝对多数,
绝对多数会被定义为: 最新的1000个区块中有800个区块的block.nVersion == 4.
等到绝对多数的block.nVersion版本达到了标准,block.nVersion < 4 这些区块会被拒绝。

2、达成上述共识以后:区块容量MAX_BLOCK_SIZE 将更新,此数据是这样计算的:2015年1月1日(区块#336861),起始数据是

2^24字节(大约16.7MB),每过6*24*365*2个区块,数据加倍–大约每年增长40%。 经过10次加倍后停止。

3、完美的指数函数:

size = 2^24 * 2^((blocknumber-336,861)/(6*24*365*2))

近似于( using 64-bit-integer math):

double_epoch = 6*24*365*2 = 105120
(doublings, remainder) = divmod(blocknumber-336861, double_epoch)
if doublings >= 10 : (doublings, remainder) = (10, 0)
interpolate = floor ((2^24 << doublings) * remainder / double_epoch)
max_block_size = (2^24 << doublings) + interpolate

这是一个两次加倍间的分段线性插值,允许每一区块增加少量容量。

关于区块最大容量如何随着时间增加,我创建了一个数据表格和图表



但是……但是……这太疯狂了吧!

增加区块容量不存在技术障碍,对此我有信心——我已经表明,我们目前的代码能够处理更大的区块,假定电子工业和网络的进步不会突然停止,运行在将来的硬件上的现有代码能够应对我所提出的区块容量增长速度。

当然,我们将不会在将来的硬件上运行现有的代码。我们将运行更好的代码。当我们下次转换到Pieter的、用于确认交易的libsecp256k1库时,CPU的使用将降到目前的大约1/8. 当我们停止做最简单的事情和两次转播交易,网络的使用将减半。我确信,所有从事比特币项目或者与比特币相关项目的聪明的工程师将发现各种各样的优化软件的方法。

当然也包括减少初次下载区块链时间的方法,由数天减少到几分钟。

还剩下大区块的经济论证没有讨论–我认为我在《区块大小经济学》一文中已经解决了这个问题。

我将尽力重申那篇博文的一个要点:你不能通过简单地限制物品供给来将其价格最大化,尤其是当它存在可替代品时。

当区块奖励降到零时,人们想将支付给矿工的费用最大化——或者,至少对有足够的矿工保护区块链的安全,有一些信心。

人们相信实现这一点的方法是,人为地限制交易数量,使它少于网络的处理能力。

但是生产限额(production quotas)不起作用。限制交易的数量在比特币区块链上能够发生,人们会选择其它的支付系统,而不选择支付更高的费用。我不知道其它的选择是西联、竞争币、侧链还是古老的SWIFT电汇,但是我知道,如果存在成本更低的选项,除了中央政府,没人能够强迫人们使用成本更高的产品。

那么,未来维护区块链安全的费用怎么办呢?

我不知道。我想一个区块包含数以万计的交易,每笔交易支付几厘比特币(千分之一比特币,millibits)交易费用,就有足够的矿工奖励了,这是可能的。

也有可能是这样,对安全、功能好的区块链有强需求的大企业和交易所,将一起建立保险合同,奖励诚实的矿工。

我确信,如果比特币系统是有价值的,那么这一市场的参与者将确保比特币能够安全稳定地继续运行。

我非常确信,使得比特币更加有价值的最好的方式是,使得它既能很好地处理大额交易,又能处理小额交易。

比特吧整理载自:巴比特资讯
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!