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 can be executed by the KIRA, its code along with a bond in the form of KEX tokens and metadata describing necessary resources and infrastructure configuration must be published on-chain. This allows Consensus nodes interested in running the app to evaluate if they have sufficient hardware resources and prevent spam. The RollApp submission process is activated by Controllers similar to the Ethereum smart contract deployer, where a transaction with all necessary data is sent on-chain. In KIRA we call the RollApp deployer a ‘Controller’. There can be one or many Controllers, such as individual KIRA accounts including users designated by governance curated ‘roles’ such as ‘validators’ (Consensus nodes) or any other network-related sub-groups. Since KIRA utilizes a concept known from Ethereum as account abstractions, RollApps can own themselves or each other, allowing the ‘control’ to be delegated into the programmatic constraints of the RollApp’s code itself.
When instantiating a new RollApp, a minimum bond in KEX tokens is required, ensuring developers' commitment. A minimum bond must also be reached before the deployment request expires for the RollApp to be launched. The minimum bond can be crowdsourced across collaborators. If it is not reached before the end of the proposal period, the RollApp is rejected and funds are returned. There is also a maximum bond that caps total deposits. Once approved through governance, RollApp tokens representing ownership are minted and paired with the bonded KEX in an AMM pool.
This permissionless, crowdsourced process is similar to Polkadot parachain auctions. However, the bonded KEX crowdsourced through the proposal remains liquid: Upon approval, RollApp tokens representing ownership are minted and paired with the bonded KEX in a Uniswap v2-like pool, and the LP tokens are distributed to all investors who contributed to crowdsource. For the RollApp to remain active perpetually, the LP providers must persist a minimum required amount of KEX bonded to the AMM dedicated to the specific RollApp.
More information about the crowdsourcing mechanism is described in Initial Liquidity Offering 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.
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.