如果测试老是失败，我相信应该不是单纯的代码问题，可以反向思索一下当下的网络硬件环境

[angrywinds]

bts还是太复杂了，分布式的最好还是解决简单问题，甚至不能去指望它高效。健壮，透明，公平是它的优势，稳定是基础

[gyhy]

分布式的应用，就是复杂啊。要处理的情况好多

[PTS中国]

下面是BM和Toast 对我们2个建议的回复，看来我们“浅薄”了

BM认为分叉不是由于网络速度和代表机器不够强大造成的。是由于DPOS网络层代码中的一个bug造成的，而且很快就能解决。

Toast认为多代表竞争同一块会导致有的代表为了赶速度出空块 。 同时指出EPaxos无法解决目前DPOS问题。

For the 1st suggestion, wouldn't that incentivize delegates to pump out empty blocks?

For the 2nd one, I don't think any paxos variants solve the problems we're trying to solve. We are not trying to replicate a large dataset where all our replica nodes are trusted. We're trying to propagate 1 small piece of data (512kb block) across a peer-to-peer network.

How would Bytemaster implement any idea unless he invented it and coined the term? Lulz this is starting to look like a circus

The issue with forking is not because of slow systems or network problems.  It is almost entirely due to implementation bugs.  I am fairly certain we have narrowed it down to a blocking socket write hat prevents other sockets from being sent data until a TCP timeout.

初始阶段的应用需求，终端机器未必要很强大，只要稳定耐攻击即可，但网速却是客观需求的，时延太大的（某种情况下，要考虑短时间断网的可能性）；软件设计上必须有这种容错设计吧。

[sfinder]

下面是BM和Toast 对我们2个建议的回复，看来我们“浅薄”了

BM认为分叉不是由于网络速度和代表机器不够强大造成的。是由于DPOS网络层代码中的一个bug造成的，而且很快就能解决。

Toast认为多代表竞争同一块会导致有的代表为了赶速度出空块 。 同时指出EPaxos无法解决目前DPOS问题。

For the 1st suggestion, wouldn't that incentivize delegates to pump out empty blocks?

For the 2nd one, I don't think any paxos variants solve the problems we're trying to solve. We are not trying to replicate a large dataset where all our replica nodes are trusted. We're trying to propagate 1 small piece of data (512kb block) across a peer-to-peer network.

How would Bytemaster implement any idea unless he invented it and coined the term? Lulz this is starting to look like a circus

The issue with forking is not because of slow systems or network problems.  It is almost entirely due to implementation bugs.  I am fairly certain we have narrowed it down to a blocking socket write that prevents other sockets from being sent data until a TCP timeout.

[sfinder]

国内搭了一个服务器当代表 出块全部missed 怎么破？

用信用卡在amazon上申请个免费运主机。几乎没有延时

[sfinder]

硬件确实需要注意，但是如果像你说的个人需要达到硬件条件才能做到代表，那么可能会出现一种情况，几个代表一种用很NB的服务器运行，突然有一天那几个服务器突然发疯了，那么作为支撑整个网络的这些一部分代表是不是会给整个BTSX系统带来很糟糕的影响呢？ 其实如果一个软件非常出色，那么它对硬件的需要真的不会太高。
倒不如从另一个角度考虑，不是硬件的，也不是软件设计的错，而是BTSX这个整体机制的有缺陷，这样才会在软件设计上暴露出来。或者说BTSX整体设计理念出现缺陷了，所以软件才会体现出来，而这些缺陷将会在往后的测试中越来越多的暴露出来

1）说得有道理，大部分代表的硬件已经足以处理运算业务，90年代美国最繁忙的空港肯尼迪机场的飞机调度是用一个4k内存的Z80芯片。 我们目前的台式机都比当时登月用的计算机要强大上万倍。

2）目前最大的瓶颈是网络速度，我发现我香港的主机运行代表居然延时达“30028” 而我美国家里的笔记本电脑用wifi接入bell网络居然延时小于10.

3）我赞同由10个代表同时出块，最快的那个代表获得出块权。。。。（会导致网络基础差的地区无法获得出块权）

[Webber]

国内搭了一个服务器当代表 出块全部missed 怎么破？

[sfinder]

不懂技术的路过
但是看起来很有道理，转BM批阅

昨天转了，BM应该看到了

今天专门开个贴，你们去看看是否 BM有答复

https://bitsharestalk.org/index.php?topic=5367.0

[cdryan]

大家的思维还在停留在做山寨币的思维上，其实BM上次引起争论的言辞，已经表达了其节点竞争想法。

目前代表们的单PC根本无法承载其未来某个时刻处理 金融服务的要求，数据和网络的吞吐都不够。

[PTS中国]

就bts的这点数据量，现在根本就考虑硬件影响，就是中国到美国，网络延迟也是毫秒级的（极少数受限的网络可能延迟更长些）。感觉现在的分叉是机制问题。

毫秒级难了，中美之间的两个受托人之间，应该至少是十台路由器（三层路由器也算）以上，时延是只多不少的。当然软件架构自身的问题应该是大头，但众多硬件的延迟也不能不考虑，更需要考试的，硬件的暂时性阻塞，可能会导致网络时延大大增加，这种情况分叉能否通过代码控制？

[mmlmmlmml]

就bts的这点数据量，现在根本就不需要考虑硬件影响，就是中国到美国，网络延迟也是毫秒级的（极少数受限的网络可能延迟更长些）。感觉现在的分叉是机制问题。

[00091lacer]

硬件确实需要注意，但是如果像你说的个人需要达到硬件条件才能做到代表，那么可能会出现一种情况，几个代表一种用很NB的服务器运行，突然有一天那几个服务器突然发疯了，那么作为支撑整个网络的这些一部分代表是不是会给整个BTSX系统带来很糟糕的影响呢？ 其实如果一个软件非常出色，那么它对硬件的需要真的不会太高。
倒不如从另一个角度考虑，不是硬件的，也不是软件设计的错，而是BTSX这个整体机制的有缺陷，这样才会在软件设计上暴露出来。或者说BTSX整体设计理念出现缺陷了，所以软件才会体现出来，而这些缺陷将会在往后的测试中越来越多的暴露出来

[dexinwong]

上次BM不是有在讨论说要给多一些手续费给代表吗？大家都反对这个。。。。。

[Musewhale]

不懂技术的路过
但是看起来很有道理，转BM批阅

[PTS中国]

可以同时让几个代表一起生产块。最先生成的有效。
类似比特币的挖矿。矿工同时挖矿，最先计算出hash值的有效。

嗯，引入竞争可能更好点，否则受托端的硬件水准很难主动去提高

[gyhy]

可以同时让几个代表一起生产块。最先生成的有效。
类似比特币的挖矿。矿工同时挖矿，最先计算出hash值的有效。

[PTS中国]

网络硬件种类繁多，透传的、不透传的各种网桥、网关是互联网绕不过去的设施。DAC所需要的非中心化的网络最大特征是需要一个扁平的，短时延的，透传的互联网络（广域网）；中心化的网站平台，其实服务的核心组件都位于一个局域网内，服务质量是有保证，保障也极为给力（统一维护，冗余出口）；这些网络基础硬件及组网模式上的异同，导致当前的互联网络环境是较难满足DAC的确认速度需求，那么为了可靠性，稳定性，适当牺牲效率成了不得已的“确认”方案措施。

BM提出的给受托人们建立虚拟的专用网络链接（软件实现）是有积极意义；但奈何网络硬伤单纯依靠软件弥补依然是力有不逮。那么为了降低1个“确认”时间，诸君可以集思广益，头脑风暴一番，何如？

我个人想法，硬件方面：
1、受托人应尽量专线直接链入运营商的骨干互联网，减少中间各种网络设备的延迟；
2、受托人终端设施应该较为快速、稳定；双机热备份为标配，带宽至少100M；建议将服务器直接置入运营商的数据机房；
3、受托人的终端所处地理位置尽量靠近或者直接就是各个运营商下的骨干网络汇接点，例如北上广；
4、就全世界范围而言，互联网网速慢的国家暂时不设置受托人，就网络货币而言，是极度依赖互联网生存的，而确认速度跟网速息息相关，基础设置不牢靠，建筑于其上的互联网金融也是镜花水月

软件方面：
1、建议将30S的确认时间，延长至60S，后期网络稳定提速后，择机升级钱包改进；
2、网络接口方面，赞成BM的受托人虚网络组团，1个确认后，受托权限优先传给下一个受托人，再全网广播；这里提个建议，能否代码实现受托人与继位受托人同步确认？这样设计的好处是很明显的，继位受托人与当前受托人是无缝处理出块请求的，大家探讨。
3、DPOS肯定导致确认验证的复杂化，如果这种复杂的程度所带来的坏处能低于效率的提升所带来的好处，那么就是好的设计，并非需要推倒重来。
4、软件代码的测试，失败越多，经验越丰富，想想那些19、20世纪的化学家搞发现，真的没什么大不了。