Overview

KIRA’s base layer, SEKAI, handles governance, token transfers, multi-staking, and all other system security-related on-chain logic. At the same time, SEKAI assists in the execution of decentralized applications taking place on their dedicated off-chain ‘subnets’ by enabling their orchestration, communication, and settlement. This separation enables parallel scaling of execution, storage, and networking capabilities of each application. KIRA applications, also referred to as ‘RollApps’, consist of an execution container defining application logic, and a verification container defining how changes in the application state can be verified.

KIRA by default pessimistically assumes incorrectness of all RollApps computations. For a RollApp's state to be finalized, its execution must be verified as correct through a consensus of Verifier nodes, each following its own programmable verification rules. This is in contrast to optimistic rollup systems which by default assume the correctness of all computations unless fraud proofs are presented which unnecessarily prolong the settlement process even if all network participants agree that the RollApp state transitions are correct.

Application Submission

Before a RollApp execution can begin, its code must be published on-chain along with two key components:

1. metadata describing necessary resources and infrastructure configuration, and
2. a bond in KEX tokens.

The metadata allows interested Consensus nodes to assess whether they have adequate hardware resources to serve as Executors for the RollApp's execution. It also includes essential execution requirements for the RollApp's operation that will be enforced by SEKAI, such as the minimum number of Executors and Verifiers required. Meanwhile, the bond, crowdsourced through an Initial Liquidity Offering (ILO), ensures developers' commitment and provides initial liquidity. This submission process helps prevent spam by pruning out less viable projects, and ensures that only well-prepared RollApps proceed to execution.

The submission process is initiated by the application's deployers—called "Controllers" in KIRA—through a governance proposal. Controllers can be individual KIRA accounts or group of users designated by governance-curated "roles". Importantly, KIRA's use of account abstractions allows RollApps to be treated similarly to user accounts. As a result, RollApps can act as Controllers for themselves or each other, enabling governance to be defined by the programmatic constraints of the RollApp’s code.

note

More information about the crowdsourcing mechanism is described in Initial Liquidity Offering for RollApps page.

Permissioned Execution, Permissionless Verification

There are two primary roles for participation in a RollApp execution process - Executors and Verifiers, also referred to as Fishermen.

KIRA’s Consensus nodes have the option to take on either or both of these roles, they are not compelled and do not need to post a bond to take these roles. This is to ensure they can adapt their hardware to suit the RollApp’s needs and avoid interacting with code logic or content that may pose legal issues in their operating region. In addition, this strategy encourages a diverse Consensus node set that can accommodate a wide range of hardware capabilities among its members. This means even those with the most basic hardware have the ability to contribute to network security by simply validating SEKAI. This strategy enhances KIRA's accessibility for operators of home nodes and encourages network decentralization by establishing the minimum participation requirement in SEKAI as the validation of a fundamental, minimalist blockchain application. However the participation of these nodes is contingent on the approval of Controllers, and they can be evicted from SEKAI’s Consensus node set if acting maliciously. If a Consensus node becomes an Executor, they will run the execution container and periodically serve as Leader for Sessions, proposing state changes while also automatically taking on the role of Verifier when not actively leading a Session.

On the other hand, any users can permissionlessly become Fishermen, i.e. if they have a vested interest in this RollApp. They are not subject to approval by controllers but must submit a bond in the RollApp's liquidity pool tokens. The bond amount is set via governance, defaulting to 0.1% of the pool’s total LP tokens circulating supply. In summary, Consensus nodes can opt-in to run as Executors or Verifiers, pending approval. Other users can freely become Fishermen verifiers by providing a bond.

The key difference between the Executors and Verifiers lies in their responsibilities and how each role is held accountable. Only Executors can become Leaders and propose state changes for a RollApp, while Fishermen solely verify its integrity. Executors are held accountable by risking their ‘validator’ role and income if removed for misconduct. Fishermen are held accountable through the verifier bonds they stake as collateral, which are slashable if they incorrectly judge a valid RollApp execution as invalid, causing an unjustified stoppage.

Sessions

In KIRA's Layer 2, computation occurs in timed periods called Sessions, similar to the "challenge periods" in Ethereum optimistic rollups. However, unlike Ethereum rollups which optimistically assume correct execution, KIRA pessimistically assumes incorrect results and only settles the state if a sufficient number of verification votes is submitted to vouch for the correctness of each session. The duration of each session is decided by each RollApp individually and can be as fast as a single SEKAI block.

A session proceeds as follows:

• A single Executor acts as the Session leader and performs computation, proposing a new RollApp state root (the hash of the new app database state) and changes to account balances on the base layer. The Leader can only be an active Consensus node and is chosen in a round-robin fashion among existing RollApp’s Executors.
• Immediately after the current Executor finishes and submits his computation results on-chain, the next leader can optimistically start executing the next session. This mechanism allows for continuous execution without waiting for the prior session's full verification to complete effectively eliminating the halting problem faced by classical smart contracts. In rare scenarios where the previous session was invalid and the following one could not be correctly executed, both sessions can be discarded, although this is unlikely to occur. For this reason, while composing multiple RollApps the KIRA base layer (SEKAI) should be used as a trusted source of account balance data and RollApps state.
• Other Executors acting as Verifiers collect the input data stream sequenced by INTERX and verify Leader results by casting their approval on proposed state changes or submitting a challenge. The end of the session and settlement requires over 2/3 of the Executor's participation and unanimous agreement. In cases where the RollApp has only one Executor, the end of the session relies on the approval of no less than 2/3 of all active Verifiers as well as a minimum vote count threshold in both cases as a simple censorship attack prevention mechanism.
• Meanwhile, multiple verifier nodes (Fishermen) verify the integrity of the leader's execution. They can halt settlement if they find incorrect state transitions, but cannot finalize the settlement, only Executors can.

note

The number of Verifiers (Fishermen) is uncapped and can be much greater than the number of Executors. However, there is only one Leader at any point in time to guarantee consistent RollApp input sequencing.