search

caivega / ipfslib

Other
2 stars 1 forks source link

[enhancement] - 默认区块参数应该有哪些？ #130

Open foreso-GitHub opened 3 years ago

foreso-GitHub commented 3 years ago

目前默认区块参数定义如下： https://github.com/caivega/ipfslib/wiki/chain%E7%9A%84JSON_RPC%E6%89%8B%E5%86%8C#the-default-block-parameter

以下可能是默认区块参数:

以太坊是3个：

ripple是3个：

foreso-GitHub commented 3 years ago

ripple有closed，但我不是很确定我们的链目前是否有”has been closed for modifications and proposed for validation“这样的状态。

另外意义相同的区块参数比如latest和validated，建议确定一个名称，不需要2个。

此外这个问题建议当面讨论。

caivega commented 3 years ago

有的，而且我们的共识算法在提交建议区块的时候，类似BOS（EOS一个变种）会同时有多个节点，每个节点都会生成并提交一个区块（大部分时间这些区块都是一样的，但是极端情况下会有多个closed区块)，所以，同时会多个closed的区块，等待共识，这就是为啥我们的closed会比ripple复杂的原因，会有多个, 另外之前好多当前讨论的及群里边讨论的，好多最后都没有结果，也没有成文档，所以好多事情没有最后敲定下来，也没有进展。。。

foreso-GitHub commented 3 years ago

维佳，这个问题最好你给我和东东当面说一下我们的链在各个状态的区别和细节。比如validated和closed的区别在哪里我就不知道。

caivega commented 3 years ago

维佳，这个问题最好你给我和东东当面说一下我们的链在各个状态的区别和细节。比如validated和closed的区别在哪里我就不知道。

上边解释了，实际上ripple的文档里边也解释了，"closed” for the most recent ledger that has been closed for modifications and proposed for validation，后续我们也得有定义，当然定义最好是按现在已经有的定义

foreso-GitHub commented 3 years ago

就是我们的链其实还是更接近ripple的共识方式？那这个closed参数对我们有没有意义？ 我的理解其实closed和validated在时间上的区别非常小，不到5秒，最多一个区块的差异，是不是？

caivega commented 3 years ago

非POW的共识的，或者说节点没有那么多的共识算法，都存在这个问题，因为共识时间快嘛，所以就没那么多个阶段，或者说好多阶段就直接合并了

caivega commented 3 years ago

closed，我的理解，结合上边ripple文档的理解，就是区块已经打包好交易，而且不准备接受更多的交易，所以就把区块close了，然后区块就有了最终的hash, 然后就可以作为一个候选的区块，提交到各个节点，进行共识

foreso-GitHub commented 3 years ago

那closed的区块一定存在吗？会不会有一个时刻不存在closed区块？比如上一个区块已经生成，但新的区块还没有进入closed状态？ 如果closed一定存在，它和current有啥区别吗？

caivega commented 3 years ago

一个新的区块大致这几个阶段：

  1. 节点验证并收集交易阶段
  2. 节点打包交易生成候选区块阶段
  3. 节点提交候选区块阶段
  4. 所有节点收集候选区块，并进入共识阶段
  5. 共识出最终区块，节点写入最终区块

上边五个阶段是每一个区块共识的时候都会做的，大约closed对应是阶段[2，4]， 感觉基本上closed区块与current差不多。。。有一种情况，估计因为ripple的网络比较大（但是ripple的网络扩展方式有些问题，所以，之前down网过。。。），有的closed的区块，估计会在下一轮或者下下一轮进行共识，如果这样的话，就可以区分closed与current了

foreso-GitHub commented 3 years ago

无论是哪种tag，都是某个具体的区块的快捷键（shortcut）。我的理解current一定包含了closed。如果是这样，不管是current还是closed，对应的区块应该是同一个吧。这样的话就不需要区分这两个tag了。感觉硬区分出来也没有意义。

foreso-GitHub commented 3 years ago

我目前的理解： earliest=genesis validated=latest current=pending=closed

caivega commented 3 years ago

我目前的理解： earliest=genesis validated=latest current=pending=closed

比如当前区块是n

earliest = genesis = block 0 lastest = block n validated = block [0,n] 会在这些区块里边查 current=pending=closed = block n + 1(当前节点正准备共识的这个区块)

这里边区别就是lastest与validated

foreso-GitHub commented 3 years ago

次序上是不是这样的？ earliest <= validated <= latest < current

caivega commented 3 years ago

次序上是不是这样的？ earliest <= validated <= latest < current

lastest与validated， 我现在也纠结这两个，因为ripple里边，每个区块都会包含之前区块所有的状态的快照（在ripple里边，lastest == validated, 以太也是这样的。。。)，但存储量很大，我们现在还没有这么干，不过，如果为了实现历史查询功能（本来计划所以与历史查询相关的功能都放到非共识节点，所以这个功能要不要放到共识结果也是这个问题），但是只要加了这个功能在底层，底层就会随着时间的积累（随着区块高度变大），帐本会非线性增长，系统也会越来越慢，最后难以为继。。。所以，这个地方要再讨论下

foreso-GitHub commented 3 years ago

每个区块都会包含之前区块所有的状态的快照

这个确实太大了，撑爆只是时间问题，会成为一个明显的坑。我觉得这样的数据不要放区块里面，实现历史查询功能肯定还有其他方式。

caivega commented 3 years ago

之前的做法，是通过空间（也就是存储）来换取时间（查询时间），可以很方便的可追溯，显然我们需要找到一种即省空间，又得少时间的方法（不然查询时间太长，也会拖死共识节点，影响共识的稳定性）