Author Topic: 关于担忧出块过快而块链肿胀的问题  (Read 2754 times)

0 Members and 1 Guest are viewing this topic.

Offline dcchong

  • Sr. Member
  • ****
  • Posts: 203
    • View Profile
你这个问题应该是之前的白皮书里就有提过
当初的那版白皮书是说会控制在每年100G之内
然后可以在代码中实现自动丢弃一年前的,只保留一年的,印象中是这样 :P

哦哦,这个不错。不过对于只是使用钱包的人来说同步100G还是挺不便的,轻钱包功能的需求还是很大的。
像bytecoin那样,同步块链的功能和钱包的功能分开来;同步块链的原因其实只有两点:

1,供其他节点同步下载块链,这个其实完全可以由受托人网络去执行,同步块链的工作全放在受托人那里。

2,供钱包查询余额;关于这点,钱包端可以指定某个或某些受托人来查询块链从而返回余额。


当然,钱包端也可以由用户选择是否自己同步块链或者不同步块链而指定受托人来查询块链。

当然这样会增加受托人端的负担,不过我们完全可以给受托人多付交易费从而让受托人增强硬件资源。另外,不知道同步块链的工作只放在受托人端是否会降低安全?


上面是我个人的理解,可能理解有误,还望各位大大海涵。 :P
wallet_approve_delegate dc-delegate true
wallet_approve_delegate bitsharesx-delegate true

Offline Musewhale

  • Hero Member
  • *****
  • Posts: 2881
  • 丑,实在是太丑了 !
    • View Profile
你这个问题应该是之前的白皮书里就有提过
当初的那版白皮书是说会控制在每年100G之内
然后可以在代码中实现自动丢弃一年前的,只保留一年的,印象中是这样 :P

MUSE witness:mygoodfriend     vote for me

Offline PTS中国

  • Sr. Member
  • ****
  • Posts: 416
    • View Profile
  • BitShares: ptschina
这个问题的确现在就要考虑解决,海量的交易诞生的BLOCK是急速膨胀的,“到时候”来解决是巨大的风险。
--------

PTS中国

Offline thistome

  • Sr. Member
  • ****
  • Posts: 250
    • View Profile
听起来 真有戏的样子,目前这个还不是最重要的,到后期了 这个问题会比较突出,这个能搞成 更能凸显bts的竞争力

Offline dcchong

  • Sr. Member
  • ****
  • Posts: 203
    • View Profile
你的英文很好理解,感谢分享。 ;D

一本很长的总账簿,应该定时整理,然后对外的接口应该是最近的整理好的账簿。 根据这样的思想,个人觉得,包含所有交易的最长总账簿应该保存在代表端,所有代表需要同步最长的总账簿,而我们非代表应该只需同步最新的小账簿。

bm说的基于代表的系统有别于其他系统,我想bm可能会利用代表来做一些额外工作 ;D
wallet_approve_delegate dc-delegate true
wallet_approve_delegate bitsharesx-delegate true

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1

这只是我个人的建议,BM估计有自己的点子

I am a little investor of AGS and PTS, I have an idea about how to reduce volume of block chain using snapshot,  English is not my native language , I hope I can been understood.
1.   The purpose of snapshot in my express is different from normal , this snapshot is to replace blocks before them to reduce this size of block chain.
2.   Perform a snapshot per N block; and the next block is a special block , its header include the hash both previous block and this snapshot.  We also can set the confirm time of this block is longer than others, maybe need  all delegates honored.
3.   Each block after this snapshot include the status if honor this snapshot.
4.   Each translation include the status if honor this snapshot
5.   if the snapshot was honored by N block, and was honored by translation witch hold 90% stockholder , this snapshot is a formal snapshot.  The blocks before this snapshot can been ignore . ignore the blocks before this snapshot have risk ,so there have N block time to check if there is no attack/ scam in the snapshot ,  if  select N equal 100,000, it mean , every delegate check this snapshot 1000 times if there are 100 delegates, and every client also check this snapshot when a translation is done, and the meantime ,any node can select to keep all block for checking.
6.    If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant,   if N equal  100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume  +  volume of 34 days translation. It doesn’t increase as time passing  .

Solid idea.  The challenge is in defining what to include in the state and how to download it.   With DPOS we have some options not available to other systems, but it is still challenging.
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline dcchong

  • Sr. Member
  • ****
  • Posts: 203
    • View Profile
有没有人担忧出块过快而块链肿胀的问题,有没有哪位大大知道bm是怎么考虑的或怎么处理的?

像alt提出的出块时间动态调整的方法,是否可行?  或者对于没打包交易的空块不时的清理掉,是否可行?

望各位知道的还请不吝赐教,或由此展开讨论。。。 :D
wallet_approve_delegate dc-delegate true
wallet_approve_delegate bitsharesx-delegate true