Kernel
The kernel is essential as it contains all of Pandora's pure execution logic.
At each layer 1 level, it reads from what is called the inbox (the inbox is stored in Tezos' context; users add messages to the rollup inbox via a dedicated manager operation on layer 1). For each read, it sorts the messages intended for it. To do this, the message must have a predefined format known to the kernel, which it can parse. It first tries to detect if the message is external or internal. An external message comes from a real user, while an internal message comes from a smart contract (this is in our case, note that there are other internal messages to the protocol). Internal messages are recognized by the protocol, ensuring an additional layer of security.
The next step is to verify if the destination address of the message matches that of the Pandora rollup. If it does, the kernel processes the message; otherwise, it ignores it. At this stage, there are several possibilities, the message is:
- a notarization request.
- a deposit of funds.
- a withdrawal of funds.
- an upgrade message.
For a notarization request, since it is an external message, a cryptographic layer is required, and the message must be signed. If the message's signature is valid, the message is kept; otherwise, it is ignored. The kernel will check if the account requesting notarization has enough funds on Pandora. If not, the message is ignored. If sufficient funds are available, the chosen amount is deducted for notarization, and the data is anchored on L2 with a timestamp.
In case it is a deposit of funds, it comes from an internal message (from the bridge contract, which will be detailed in the following sections). The message is trusted, and the account is credited with the amount specified in the message.
If it is a withdrawal of funds, it also comes from an internal message, hence trusted. The kernel checks if the L2 account's balance permits that withdrawal. If not, the message is ignored. If everything goes well, a message is posted in the rollup's outbox. The user must wait for the dispute period (see this article for a quick overview on refutation games) defined by the Tezos protocol to elapse. Once the message is cemented, it can be triggered to retrieve the funds on the bridge contract (more details provided in subsequent sections).
Finally, an admin message can request an upgrade that will allow the rollup to update its logic, add features, or fix bugs. This is one of the biggest strengths of smart optimistic rollups on Tezos, enabling continuous updates to execution logic, unlike immutable smart contracts that cannot update their code in case of issues.