SEKAI: SEKAI is KIRA Network's base layer (L1) blockchain application sometimes referred to as “backend”. The role of SEKAI is to be a source of shared security as well as a governance and settlement layer for all KIRA RollApps (L2). KIRA Blockchain preserves information such as user account balances, governance permissions, and RollApp state roots as well as other essential data for coordinating both L1 and L2 operations.
MBPoS (Multi-Bonded Proof of Stake): MBPoS is a staking mechanism in SEKAI aimed at enforcing the network's Sybil resistance. It differentiates from typical Proof-of-Stake models by permitting the use of a diverse range of digital assets as staking collateral. This includes but is not limited to, native assets of the KIRA network, non-native assets originating from other blockchain networks such as BTC and ETH, NFTs, RWAs, LP tokens, and stablecoins, all subject to approval via governance proposals. The reason behind multi-staking implementation in KIRA is to increase the security of the network in the scenario where tokens originating from foreign networks add incentives for consensus participants to misbehave. Additionally, MBPoS natively issues liquid staking derivatives (LSD) for all staked assets boosting economic activity and access to assets for all KIRA RollApps.
INTERX: INTERX, which stands for Interchain NginX, is a decentralized middleware making it simple and intuitive to interact with KIRA network. INTERX has a supporting role for both frontends as dAPI gateway as well as for RollApps abstracting the complexity of blockchains and serving as a Content Availability Layer and P2P node discovery tool. In the context of RollApps INTERX is used as both DA and Sequencer so that developers can focus fully on business logic and not infrastructure. One of the important features of INTERX is acting as a light client replacement and removes the dependency on centralized SSL certificate authorities through a combination of digital signatures and fraud proofs.
RYOKAI: The next generation of the KIRA Manager (KM 2.0) supporting the orchestration of KIRA’s RollApps.
VFG (Virtual Finality Gadget): The Virtual Finality Gadget (VFG) is a programmable finality enabling RollApps to share the security of the base layer and define their own consensus rules. The VFG is a protocol that enables KIRA to support any type of RollApp (Pessimistic, Optimistic, General Purpose, Recursive Blockchain). At the core of VFG lies the idea of splitting the application into dedicated execution and verification parts. Depending on which network participants run which part (execution or verification logic) any modern consensus type can be virtualized.
Monolithic Blockchain: In a monolithic blockchain, consensus nodes handle all network functions. These include processing transactions for all RollApps, verifying transaction correctness, managing data storage, and achieving consensus among nodes. This model integrates all core tasks into a single blockchain system.
Modular Blockchain: A modular blockchain is a system where various functions of the blockchain stack are separated into independent networks and then interconnected. This approach is similar to the concept of microservices in traditional web architectures, where different components like notifications, storage, monitoring, and payment are split into distinct services and integrated via APIs. In a modular blockchain, components such as the execution layer (i.e. sequencers), data availability layer, and settlement layer are distinct yet linked through specific protocols.
Hypermodularity: Hypermodularity refers to a system where all essential modular components are readily accessible to the nodes that require them, without the need to retrieve them from complex, dependent networks. This architecture aims to reduce unnecessary bandwidth overhead, system complexity, and dependency risk. An example here might be network layer awareness of the node location allowing DA microservice to be positioned right next to the Sequencer on the physical layer or other location relevant to a particular RollApp and user-boosting efficiency.
Rollup/Rolldown: These terms describe different methods of finalizing the state transitions of Layer 2, particularly user balances or overall database state. In the case of "Rollups," state transitions that are attempted to be settled on the base layer are assumed to be by default correct unless evidence in the form of fraud proof is provided. In the case of "Rolldowns," state transitions that are attempted to be settled require a threshold of verifiers to accept them - for that reason, Rolldowns are sometimes referred to as "Pessimistic Rollups." In general, Rollup might be also referred to as an L2 or an independent network that uses a "pessimistic" or "optimistic" settlement with a larger base layer network (e.g., Ethereum) that it actively observes to gain access to tokens or otherwise communicate with other networks or applications. We might refer to such networks as sidechains, zones, and/or parachains. If such a network serves a very specific purpose, it might be also referred to as an "AppChain," or in other words, an Application Specific Blockchain. As of 2024, AppChains are an extinct concept, but you might come across them in various crypto-related literature and topics. In the case of KIRA, thanks to VFG, we can classify all types of blockchain or blockchain-less applications requiring trustless compute verification as "General Purpose Rollups" and do not have to reason about their inner-workings.
Optimistic Layer 2: In the optimistic approach, the computation of the new state of L2 is assumed to be correct by the Executor, until proven incorrect. The finality or computational verification of the rollup's new state is rerun only by one or more nodes that choose to do so. If no node disputes the state within a certain time frame (typically 7 days), it is then considered finalized.
Pessimistic Layer 2: In this approach, the computation of the new state of L2 is assumed to be incorrect by the Executor, until proven correct. The finality or computational verification of the rollup's new state is deterministically re-executed by one or more other nodes. An example of a pessimistic rollup is the use of Zero-Knowledge proofs, where the Executor generates a proof, and then another node verifies this proof. The proof verification logic is deterministic and uniform across all verifiers.
General Layer 2: In the general approach, the computation of the new state of L2 is assumed to be incorrect by the Executor, until proven correct. Finality is still contingent upon at least one node's re-execution of the state transition, but the verification can employ non-deterministic methods. This approach accommodates a broader spectrum of application frameworks, e.g., applications that operate at CPU clock speeds, also known as Blockchain-less applications.
Blockchain-less Application: A blockchain-less application is a type of RollApp that processes user transactions in real-time, without the traditional blockchain mempool. This absence of a visible mempool eliminates the possibility of malicious participants manipulating transaction order, thereby reducing common issues such as front-running and Maximum Extractable Value exploitation. The responsibility for maintaining the integrity of transaction processing and execution order lies with the RollApp Leader, who, in the event of any provable misconduct, can be subject to eviction.
Consensus node (validator): A Consensus node is an active network participant responsible for processing transactions, adding new blocks to SEKAI, and storing SEKAI state by running a ‘validator’ node. Each node is responsible for creating and managing its unique staking pool where delegators can lock their funds to provide security to the network. Additionally, Consensus nodes may opt in to act as Executors for RollApps.
Delegator: A Delegator is any network participant who engages in consensus by locking assets as collateral to one or multiple staking pools without necessarily running a Consensus node. Note that KIRA doesn’t require block proposers to have a minimum self-bonded stake to pledge their honesty. It is the responsibility of delegators to exercise due diligence and diversification when choosing a block proposer staking pool, as the risk of staked assets is directly exposed to the block proposer’s actions. However, contrary to other PoS blockchains, double-signing is the only behavior that results in slashing (downtime is not penalized).
Session: A RollApp session refers to a designated period during which a RollApp is executed by a single Executor, known as the RollApp Leader. This session encompasses the operational phase of the RollApp: the execution of its code and the subsequent processing of any changes to SEKAI state and/or the RollApp's internal database. The session concludes with the submission of these changes for verification by Fishermen, and consensus by other Executors, in cases where more than one Executor is involved. For changes to be accepted, they must be approved by a supermajority of Executors and receive no rejections from Fishermen.
Verifier: A Verifier is a participant responsible for verifying the correctness of submissions made by the RollApp Leader following the execution phase of a RollApp session. Verifiers are either Fishermen or Executors who are not currently serving as the RollApp Leader.
Executor: An Executor is a consensus node responsible for the validation and approval of the outcomes of a RollApp session. They are responsible for storing the RollApp's internal state and reviewing and voting on the results submitted by the RollApp Leader, including changes to SEKAI state and updates to the RollApp's internal state. Executors who are not serving as the RollApp Leader automatically assume the role of a Verifier. Executors have the freedom to select which RollApp(s) they wish to run, based on system requirements, and/or they can be appointed by the RollApp's controllers.
RollApp Leader: A RollApp Leader, also referred to as a Sequencer, is a single Executor responsible for executing a RollApp session. They are tasked with computing the outcomes of the RollApp, such as changes in SEKAI state and/or RollApp internal database updates. The RollApp Leader submits these results for verification by Fishermen, and consensus by other Executors in cases where more than one Executor is involved.
Controller(s): This term refer to the person or team responsible for developing and maintaining a RollApp. They are represented by a set of KIRA addresses and have the ability to update the controller set and the RollApp's binaries through new releases. Note that KIRA implements account abstraction, so a RollApp can serve as its own Controller. As the managers of a RollApp, Controllers have the authority to approve or deny Consensus nodes participation as Executors or Verifiers. This gives them control over who can validate and execute transactions for their particular RollApp. However, they do not have the ability to approve or deny Fishermen, as this verification role is permissionless.
Fishermen: As a subset of RollApp Verifiers, their sole task is to oversee and validate state transitions of a RollApp. Like the Executors, they are responsible for storing the RollApp's internal state. However, they are distinct from Executors in that they are not part of SEKAI Consensus node set and therefore cannot become RollApp leaders. Their primary function is to ensure the correctness of state transitions using any chosen proprietary logic, with the authority to halt a RollApp if they detect incorrect transitions.