The block time of the parentchain is currently set to 12s. The validateers themselves produce sidechain blocks in intervals of 300ms. The block production and consensus algorithm used to produce sidechain blocks, is AURA. This means we have a defined set of authorities (i.e. validateers) that take turns in producing blocks. Each validateer (or more general, Integritee worker) is registered to the parentchain, thus defining the set of authorities. Time is then partitioned into slots of 300ms and each slot is assigned to a validateer in a round-robin fashion. As an example, with 3 validateers, each validateer will produce a sidechain block every third slot.
When a validateer produces a sidechain block, it broadcasts this new block to all of its peer validateers. How does it know its peers? As mentioned above, all validateers are registered on the parent chain. A validateer queries the parent chain to get the identities and URIs to communicate with all its peers.\
Depiction of the cycle each validateer runs for a slot. This is done in the slot worker component of a validateer. A cycle is triggered every 300ms.
First, the validateer processes the sidechain import queue. Sidechain blocks from the queue are imported until the queue is empty. Importing a sidechain block results in applying the state diff and removing executed operations from the trusted operation pool. It also includes potential fetching of sidechain blocks from a peer in case missing blocks were detected.
The next step is determining if the current slot should be claimed, meaning determining if it is this validateers turn to produce a block. If not, the slot cycle ends here.
In case the slot is claimed, a validateer starts executing trusted operations from the trusted operation pool until the allocated time limit is reached. The time limit is a configurable fraction of the slot time, currently set to 80%. The result of the trusted operations is a state diff which will be included in the sidechain block. With this information, the sidechain block will be composed. Once a sidechain block is composed, the validateer checks the slot time to ensure it's still within its claimed slot. If not, the block is discarded and the cycle ends. Otherwise, this new sidechain block is broadcasted to all peers, a parent chain extrinsic with confirmation of all executed operations composed and sent.
Note on the slot time: At various points during the cycle the slot time is checked, to ensure the slot time of 300ms is not exceeded. There are several cases where it still can happen. In order to prevent forks in the sidechain from happening, a sidechain block is only produced and broadcast when all the steps can be executed within the 300ms time window. Otherwise, it is discarded or not produced in the first place.
\
The block import stage will import all the sidechain blocks it finds in the queue. This might also trigger a fetching of sidechain blocks from a peer when missing blocks are detected (further described in the on-boarding process). This whole process might take considerably longer than the slot time, but is necessary for further execution. If the time is exceeded here, the slot cycle will end after the import and be triggered again at the next point in time when a slot starts. This can potentially skip multiple slots including ones where this validateer should have produced a block. This is however not a problem, not producing a block during a slot does not endanger the integrity of the sidechain. And furthermore, the exceeding of the slot time because of block import should only happen in rare cases, e.g. during on-boarding or after being offline for period of time.
Slot time is checked after each trusted operation execution. Only a defined fraction (80% by default) of the slot time is allocated for trusted operation execution. Despite this precaution however, it is possible that the last executed operation takes too long and exceeds the allocated slot time fraction. In that case no block will be produced.