RFC-0325/DanEpochManagement

Epochs and time management

status: draft

Licence

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistributions of this document must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS DOCUMENT IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS", AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Language

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (covering RFC2119 and RFC8174) when, and only when, they appear in all capitals, as shown here.

Disclaimer

This document and its content are intended for information purposes only and may be subject to change or update without notice.

This document may include preliminary concepts that may or may not be in the process of being developed by the Tari community. The release of this document is intended solely for review and discussion by the community of the technological merits of the potential system outlined herein.

Goals

The aim of this Request for Comment (RFC) is to describe the role of Epochs and time management on the DAN.

RFC-0303: The Digital Assets Network Overview

Motivation

For stability and security in the VNCs we have the following requirements:

We need to know who the valid and active VNs are.
VNCs need to be periodically shuffled to prevent shard targeting attacks.
VNC members cannot be swapped on a whim and need to be stable to allow members to vote on and process instructions.
Chain re-organisations on the Minotari chain should not have an effect on the VNC distribution.
When swapping VNs from one [shard] to another, the VN has enough time to sync the required state before the swapping takes effect.
When swapping VNs from one [shard] to another, the VNC must retain enough members so as to keep functioning.

DAN Lag

Because the Minotari chain influences the DAN layer and is used as a timing mechanism for the DAN, we need to ensure that the DAN has a stable view of the Minotari.

The Minotari is built on Proof-of-Work and this means that chain might undergo re-organisation. We need to ensure that re-orgs do cause a VNC reshuffle. We introduce a concept called DAN Lag which is an offset between when a VNC change is recorded on the Minotari chain and when it takes effect.

For example, if we define DAN Lag as 720 blocks, or a day. Then when a VN registers and that transaction is mined in the Minotari at height 1000 then only at height 1720 will the DAN Layer recognise the VN as being registered.

This DAN Lag allows the Minotari chain to have small re-orgs of less than the DAN Lag without it having any effect on the DAN Layer. An added benefit of this is that the DAN Layer knows all changes in advance of when it will happen, so when a VN is swapped to a new shard space it will give it the DAN Lag period to sync the required state.

DAN Grace Time

Minotari nodes are decentralized. Thus, we don't have a single point of view of the state of the chain.

The DAN operates in ms timeframes, while the Minotari chain runs at the minute timeframe, averaging 2 minutes per block. These blocks also take a few seconds to process and propagate through the network.

This means that for some VNs the Minotari block height might be 999, while for others it might be 1000. The practical problem for this is that we cannot base consensus decisions on the block height if the VNs cannot come to some consensus as to what the Minotari height is.

We define DAN Grace Time or DGT as the number of blocks in the past or future of the VN's own current block height, that it will accept. This is very similar to the FTL concept concerning the timestamp in the block header.

In example of this would be, that we have VN_1 whose base node is on height 999 and VN_2 whose base node is on height 1000. We have set the DGT as 1. An instruction has specified that from height 1000 the VNC that must process it contain both VN_1 and VN_2, but before that it is only VN_1. From this it can be seen that VN_1 thinks only it must be in the VNC but VN_2 thinks they both need to be. But using the DGT of 1 block, VN_1 will accept VN_2 as part of the VNC because it is withing the DGT period and it assumes that its own base node is simply lagging 1 block.

The DGT has the additional benefit of allowing a VN to finish processing an instruction after a block height has been reached.

With the example mentioned above if VN_1 has to stop processing an instruction at height 1000, but it started the instruction at height 999. When height 1000 comes along it can still continue to process the instruction till height 1001.

VN Epoch

We define VN Epoch as the time period a VN must serve in a single [shard] before being moved to a different [shard]. The purpose of this shuffling is to prevent having a single VNC cover the same shard for an extended period of time and thus reduce the risk of VN collusion.

The shuffling algorithm can be linked to the VN registration hash. This provides a random and uniformly distributed seed that allows us to shuffle the VNs around the shard space in a deterministic way. The algorithm can also be constructed such that a minority of nodes are shuffled at every epoch, while still maintaining equal-sized VNCs.

Summary

VNs must re-register periodically. This is to ensure that the VNs are still active and to prevent a VN from registering once and then never being removed from the VN registry. A new shard key is generated each time that a VN re-registers.

(Open question: Is the re-registration fee cheaper than the initial registration fee? Is it zero?)

VNs that miss their re-registration deadline will automatically be de-registered. (Open question: Is the registration deposit lost in this case?) Therefore it is always possible to maintain a list of recently active VNs.

The DAN Lag gives VNs enough time to sync their new shard's state.

VN are shuffled periodically, but a minority of nodes are shuffled every epoch.

The epoch must also be short enough that we can effectively remove inactive VNs from the VN registry.

Change Log

Date	Change	Author
19 Oct 2022	First outline	SWvHeerden