Skip to main content

3.13 时间领主算法

Timelord Algorithm


有关更多信息,请参阅第 3.4 节

鉴于可用处理器数量有限,时间领主如何决定创建时间证明的挑战?虽然未来可能会开发 ASIC,但目前最快的类组 VDF 实现是在通用硬件上。此外,即使在 ASIC 开发之后,重要的是要强调任何拥有 CPU 的用户都可以成为时间领主,在 ASIC 时间领主出现故障或变得恶意等情况下提供回退。


时间领主并行运行三个 VDF 链。因此,至少需要三个快速 CPU 内核才能以有效的速度推进区块链。创建证明需要额外的 CPU 内核,但它们不必那么快。


如果时间领主收到一个迟到的融合块(我们已经到达应该融入块的挑战点),时间领主会忽略该块,因为注入它会允许攻击者在尝试重新组织或 DoS 链。




A timelord keeps track of the current peak, which includes an infused block at a certain height, and signage points from the peak onward. A timelord might receive new blocks to infuse, new peaks (blocks which are already infused), or new signage points.

For more info, see Section 3.4.

How does a timelord decide which challenges to create proofs of time on, given a limited number of available processors? While ASICs are likely to develop in the future, at the moment the fastest classgroup VDF implementations are on general purpose hardware. Furthermore, even after the development of ASICs, it’s important to emphasize that any user with a CPU can be a timelord, to provide fallbacks in the case that the ASIC timelords go down, or becomes malicious, etc.

In general, timelords work on the heaviest chain. They create proofs of time at the signage points, and broadcast these to the network as they are reached. Timelords also infuse blocks as often as they can. When the timelord receives an infused block which has a greater weight than the current peak, they switch to it immediately.

Timelords also run the three VDF chains in parallel. Therefore, at least three fast CPU cores are necessary to advance the blockchain at an efficient rate. Extra CPU cores will be necessary to create proofs, but they do not have to be as fast.

If the timelord receives a challenge with less weight than their current peak, they ignore it. If the timelord receives a challenge point later in the current chain, they do the safe thing: ignore it. The reason is that by switching to a point further in the future, the timelord might be skipping the infusion of blocks, and thus orphaning valid blocks.

If the timelord receives a block for infusion which is late (we have already reached the challenge point at which the block should have been infused), the timelord ignores the block, since infusing to it would allow attackers to instigate a withholding attack, in an attempt to re-org or DoS the chain.

Therefore, the main operation of the timelord involves keeping a cache of future blocks to infuse, broadcasting challenge points when they are reached, and infusing blocks when they reach their challenge points.

If the timelord receives a challenge with the same weight as the current peak, they choose the unfinished block which they saw first (that is, the block that has not been infused yet), as opposed to choosing the infused block (peak) which they saw first. This also disincentivizes the withholding of blocks.