Author Topic: 透明锻造&DPOS随机选择下一个delegate对比参考  (Read 8044 times)

0 Members and 1 Guest are viewing this topic.

Offline KyLin

  • Sr. Member
  • ****
  • Posts: 232
    • View Profile
什么时候BTS能出来啊,半成品啊!


Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
review了代码,有个问题不太明白,如何保证产生块的delegate是随机的?现在似乎是从list里随机拿出一个跟自己的id对比,如果match则产生块,不是则跳过,假如我的客户端是custermized的,而我又是delegate,我是否就可以跳过这个 checking直接产生块,如何防止这种情况?

就是 https://bitsharestalk.org/index.php?topic=4164.0 里面提到的算法,每个delegate先publish secret_hash,下一轮reveal secret,由这些secrets哈希值来更新随机数。

之前的实现有一个漏洞,最新的实现每一轮delegate的顺序仍然是随机的,但是只在这一轮开始的时候刷新一下随机顺序,不是随机确定下一个delegate,而是随机确定下一轮delegate顺序。

谢谢解答,但是在块产生代码里我还是没看到你说的实现算法(https://github.com/BitShares/bitshares_toolkit/blob/ab177ba65f4355af9805b4e7451ed9f7dba8a0b7/libraries/client/client.cpp#L70#L104)能否指出具体实现在哪里?

https://github.com/BitShares/bitshares_toolkit/blob/master/libraries/blockchain/chain_database.cpp#L509
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline crazybit

review了代码,有个问题不太明白,如何保证产生块的delegate是随机的?现在似乎是从list里随机拿出一个跟自己的id对比,如果match则产生块,不是则跳过,假如我的客户端是custermized的,而我又是delegate,我是否就可以跳过这个 checking直接产生块,如何防止这种情况?

就是 https://bitsharestalk.org/index.php?topic=4164.0 里面提到的算法,每个delegate先publish secret_hash,下一轮reveal secret,由这些secrets哈希值来更新随机数。

之前的实现有一个漏洞,最新的实现每一轮delegate的顺序仍然是随机的,但是只在这一轮开始的时候刷新一下随机顺序,不是随机确定下一个delegate,而是随机确定下一轮delegate顺序。

谢谢解答,但是在块产生代码里我还是没看到你说的实现算法(https://github.com/BitShares/bitshares_toolkit/blob/ab177ba65f4355af9805b4e7451ed9f7dba8a0b7/libraries/client/client.cpp#L70#L104)能否指出具体实现在哪里?
« Last Edit: May 24, 2014, 04:04:01 pm by CrazyBit »

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
review了代码,有个问题不太明白,如何保证产生块的delegate是随机的?现在似乎是从list里随机拿出一个跟自己的id对比,如果match则产生块,不是则跳过,假如我的客户端是custermized的,而我又是delegate,我是否就可以跳过这个 checking直接产生块,如何防止这种情况?

就是 https://bitsharestalk.org/index.php?topic=4164.0 里面提到的算法,每个delegate先publish secret_hash,下一轮reveal secret,由这些secrets哈希值来更新随机数。

之前的实现有一个漏洞,最新的实现每一轮delegate的顺序仍然是随机的,但是只在这一轮开始的时候刷新一下随机顺序,不是随机确定下一个delegate,而是随机确定下一轮delegate顺序。
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Musewhale

  • Hero Member
  • *****
  • Posts: 2881
  • 丑,实在是太丑了 !
    • View Profile
MUSE witness:mygoodfriend     vote for me

Offline crazybit

review了代码,有个问题不太明白,如何保证产生块的delegate是随机的?现在似乎是从list里随机拿出一个跟自己的id对比,如果match则产生块,不是则跳过,假如我的客户端是custermized的,而我又是delegate,我是否就可以跳过这个 checking直接产生块,如何防止这种情况?
« Last Edit: May 23, 2014, 06:04:50 pm by CrazyBit »

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
只有100个代表,按30秒一块,一个特定代表1个小时内都没轮上的概率为0.299。
所以盯住一个代表ddos攻击的话,命中率也不算低。

其实对100个节点同时发起攻击,成本也不少太高

这个也有应对办法,每个delegate因为只需要可以签名然后将块广播出去OK,所以可以选择一个pubkey 运行一些匿名节点,实际上100个delegate可能不止100个节点。
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Top的代表仍然是投票选择的,只是现在是随机判断下一个delegate,而不是按照顺序执行。
哦 现在执行的顺序是随机 那也不错,我还有几个问题 一直不明白:
一共可能是100个代表,每笔交易可能都会去这100个代表的账簿里面核对,现在核对的顺序变成随机了。
那是否要完全执行完这100个代表呢,还是 只要随机执行其中50%就行
还有 如果某些代表的电脑 down机 又是如何处理的。我估计如果发现down那可能会自动跳过。
那么是否有一种机制 每个几分钟去寻找下 有多少个代表在线,因为如果代表只有10个,那就太少了,是否有后补代表什么的。自动切换后补代表。

Top 100目前的实现貌似是每个一轮(100个快)会刷新一下vote,每笔交易不需要去代表的账簿里面核对,这个没有太明白你的问题。
有候补代表
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline sfinder

  • Hero Member
  • *****
  • Posts: 1205
  • 4 Cores CPU+100GB SSD+anti-DDoS Pro
    • View Profile
只有100个代表,按30秒一块,一个特定代表1个小时内都没轮上的概率为0.299。
所以盯住一个代表ddos攻击的话,命中率也不算低。

其实对100个节点同时发起攻击,成本也不少太高
微博:星在飘我在找|BTS X 受托人delegate ID:baidu
中国教育书店合作将20%收入捐献给贫困山区学生。
Cooperating with China Education Bookstore and will donate 20% of delegate income to the poor students

Offline logxing

一个代表可以担任多个dac的代表,硬件成本类似,可以摊低。

来自我的 HUAWEI P6-C00 上的 Tapatalk

BTS Account:logxing

Offline muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
不知道100这个数是否可变的,一些规模小或者没盈利空间的DAC,有可能找不出100个代表。

Offline logxing

当然这样只是骚扰一下,没办法让整个网络停摆。
BTS Account:logxing

Offline logxing

只有100个代表,按30秒一块,一个特定代表1个小时内都没轮上的概率为0.299。
所以盯住一个代表ddos攻击的话,命中率也不算低。
BTS Account:logxing

Offline zhao150

  • Hero Member
  • *****
  • Posts: 606
  • 老子早就不想当代表了
    • View Profile
Top的代表仍然是投票选择的,只是现在是随机判断下一个delegate,而不是按照顺序执行。
哦 现在执行的顺序是随机 那也不错,我还有几个问题 一直不明白:
一共可能是100个代表,每笔交易可能都会去这100个代表的账簿里面核对,现在核对的顺序变成随机了。
那是否要完全执行完这100个代表呢,还是 只要随机执行其中50%就行
还有 如果某些代表的电脑 down机 又是如何处理的。我估计如果发现down那可能会自动跳过。
那么是否有一种机制 每个几分钟去寻找下 有多少个代表在线,因为如果代表只有10个,那就太少了,是否有后补代表什么的。自动切换后补代表。
« Last Edit: May 23, 2014, 10:47:55 am by zhao150 »
老子早就不想当代表了