Conflux0.5秒出块不科学?2.88G怎么计算处理的?

有点质疑这组数据,交易量2.88G怎么计算处理的?一笔交易按1KB计算(实际不到),那么一4M的区块有交易4千笔交易,按五秒一个区块计算,…好吧,认为这组数据不合理,不继续打了…文档是我刚下载的。你们0.5秒出块,完全是在搞TPS啊。那么主网也是这个出块速度?根据你们的最重链选择再加上一个块达到全网需要12秒,这个时间太短太短

0.5秒出块其实不是为了搞tps,主要的作用是降低确认延迟,另外,上面那个数据,2.88G不是交易量,是byte数,就是有效传输的区块的总大小。

Conflux研究组 | 最重链规则的优势与隐患(1)
这篇文章里讲了提高出块速度对于减少确认时间的作用,如果只是为了提高tps,其实bsv的超大区块路线也是可以的,但是确认很慢非常蠢。

一笔交易差不多100字节,而不是1KB。

2.88Gb的区块容量,约737个区块。则一小时最大交易量737*4000,那么tps是819。加速出块速度确实能加快区块稳定速度,你们实验室环境是内部环境。完全忽视了广域网网络广播延迟,你们已经在测试网中采用0.5秒出块吗?
另外亚马逊服务器,我问过他们没法设置带宽上线的,不知道你们怎么做的限制的。
1kb是很大,但也不止100byte。

有不少工具,可以在不同的层面做流量控制,不仅仅是在AWS服务器层。比如TC。
模拟公网的难度在于要流量控制,还要有latency的simulation…

普通交易(非合约),100出头吧,to address 32,签名65,value,nonce,gas price和gas limit加起来没多少。

32+32+8+8+8+8+65,然而,假设网络中平均有 n 个区块处于正在广播、但还没有传遍所有节点的状态,诚实节点自己打破这个困局需要的时间是 n 平方。在给定的网络延迟下,每加快一倍的出块速度,n 相应地也会翻倍,而诚实节点自行打破困局的时间就会成平方量级上升。

比如AWS ec2 in us-east-1 是ms (毫秒)级的,最多20ms的latency (已经很差了,可以open ticket to complain 了)
但是from us-east-1 to us-west-2 就要至少200-300 ms… 一个round trip 就是600ms…
如果有日本,香港的就是3-4秒级别的了。
0.5 秒出块就是500 ms… 大洋两端的full node 还没有收到上一个block.

这个是两个节点的延迟,要看全网的,特别你们实验用的的一万个节点,测试网会用0.5秒吗?这个和eos的0.5秒逻辑是差异很大的,真实环境能控制在6秒出块就不错了。

我觉得不用特别钻研实验室数据,实验室的数据通常是用来做系统的上限和下限的。真正的数字需要从testnet和mainnet里面出来,这也是为什么public blockchain project需要大众参与的最重要因素。

实验中模拟的20Mb带宽,节点间latency在300ms以内,真实的网络环境,尤其是普通用户的网络肯定有很大的差异。

而从这个测试本身的价值来看,我觉得非常之:ox:。因为一般人都只看tps… 这个0.5 出块指引的方向是confirmation time… 当大家各个方向的数字都有了,可以做的改动和提议就很多了。

这一万个都是miner吗?

addr是20不是32,刚说错了,另外,from addr不需要,对,都是miner。

那就make sense… 因为miner 是需要 “well connected”?

实验中不仅仅0.5s出块,还试了32, 64, 125, 250毫秒出块,当然tps恒定,就是为了降低交易确认时间。

32 ms… 一个块被full node process的时间(assume full of transactions) 有吗?it might be too fast for some smaller full node to handle…

因为conflux 不要求链式结构。所以不必等收到上一个区块后才出新的区块。这点和比特币、EOS等等的出块逻辑都有着本质的不同。
在 conflux 最终确认时间半分钟以内是足够一个区块广播到全网绝大部分节点的。
另外@QB 确认一下,现在的实验中的广播是使用了致密区块(Compact block)技术吧?实际需要广播的数据量远小于一个区块的实际大小。

明白了,最终确认时间有半分钟很靠谱了。不过会不会在0.5秒出块时,交易重复率上升,特别是交易量很低时。