I'm reading the "parachain implementers guide" here and I understood that the parachain block journey ends when it is finally "approved" and included in the relay chain.
My questions are:
The parachain block candidate first gets included into the relay-chain during the processes known as "backing". At that point, the candidate is just saved in the relay-chain, but is not treated as "executed". Only when the backed candidate gets available the candidate is taken into account by the relay-chain and its effects are applied. That includes updating the head data and sending out messages. But at that point, the chain at which such candidate is included is not finalized and cannot be, until all the candidates are gone through the approval process.
The candidate data gets into the relay-chain via the so-called parasinherent. Inherent is a special type of an extrinsic which is submitted by the block producer. During the on-chain handling, they will get into the process_candidates of the inclusion module. Then the candidate receipts will get saved into the storage while waiting for the availability.
Similarly, process_ bitfields handles the candidates that passed the availability stage which, as I mentioned earlier, leads to the enactment of the candidate.
enact_candidate performs several state transitions, as you can see. The most important one is noting new head.
As comes from its name, it updates the head data of the corresponding parachain.
The head data is a small piece of data. In Cumulus it is used to save the header of the last parablock which contains the state hash.
