Skip to main content

Middleware - INTERX

Overview​

INTERX (インターエックス) is KIRA's decentralized middleware service and is often referred to as KIRA’s Content Availability Layer. It is responsible for node monitoring, peer discovery, response caching, proxy, load balancing, storage, sequencing, and propagation (targeted gossiping) of data and transactions between client-facing applications and KIRA’s back-end services such as L2 apps or SEKAI. It optimizes communication across users, nodes, and Rollapps by enabling the formation of well-connected network subnets dedicated to each application.

INTERX simplifies the transition from Web2 to Web3 for developers by removing the complexity of blockchain interactions. Web3 interactions often involve dealing with smart contracts and complex interfaces that must be queried and interpreted like Ethereum's ABI or decoded like SCALE encoded metadata for Substrate RPC, an overwhelming and cumbersome change from the straightforward API calls typical for Web2 environments. By offering a familiar Web2-like API interface and acting as the default 'Sequencer' for applications, INTERX reduces the learning curve of Web3, empowering developers to focus more on their business logic.

One of INTERX's most important features is its combination of digital signatures and fraud proofs to effectively function as a decentralized API. This feature eliminates the need for light client implementations and maintenance, as well as dependence on centralized SSL certificate authorities.

Kira’s Approach to Data Availability​

Traditional systems often treat all application data uniformly—both user balances and arbitrary data— a method that compromises UX and practicality. This is particularly true when quick access to essential and trusted information, like user balances, is required during unexpected interruptions in the application’s sequencing process (e.g. requests rate limiting). KIRA addresses this by clearly distinguishing these types of data. Specifically, user balances can be directly settled on SEKAI, KIRA’s base layer, leveraging account abstraction. This arrangement allows Layer 2 applications to be treated similarly to user accounts, enabling them to perform on-chain actions such as issuing tokens, participating in governance, staking, and even communicating with other applications as if they were autonomous humans.

In managing and ensuring the availability of arbitrary application data, INTERX adopts a specialized implementation designed to enhance the data replication versus network overhead ratio. This implementation is underpinned by four foundational concepts:

  • Integrated Data Management: Consensus nodes operate and autoscale INTERX containers alongside their RollApp execution containers, akin to how edge nodes function within traditional Web2 networks. An edge node serves as a conduit between local environments (SEKAI and RollApp containers in KIRA’s case) and the external world. In this setup, essential data is directly accessible on the same devices that execute the application, thus reducing latency and the dependency issues seen when DA is handled by an external network.
  • Dedicated DA Sub-networks: Leveraging its node discovery capabilities, INTERX assigns each RollApp its own firewalled and rate-limited DA 'subnet'. This architecture optimizes bandwidth utilization and resource allocation by reducing the exchange and management of the application’s data only to the nodes directly relevant to the application—namely, its executors and verifiers.
  • Adaptive Data Replication: Traditional DA systems often employ a one-size-fits-all replication factor. Essentially, they define the level of redundancy through a fixed number of copies distributed within the network to ensure data availability. In practice, however, individual applications have distinct requirements for data access speed and replication based on the data type. With INTERX, RollApp data is replicated based on the individual needs of executors and verifiers. Developers can scale this replication level to align precisely with their application's needs, such as minimum bandwidth utilization for noncritical data and/or maximum possible security for application-critical data.
  • Caching: INTERX implements a caching mechanism to efficiently manage high-demand scenarios and prevent system overload. This feature is especially important in KIRA, where SEKAI’s block time can be extended based on the number of consensus nodes involved, influencing the likelihood of data being queried multiple times before any updates occur. By storing data after its initial retrieval, INTERX can swiftly respond to duplicate requests, conserving resources required to perform complex queries and thus maintaining network responsiveness.

Decentralized Api Gateway Through Swarm Request​

A distinctive feature of INTERX is its functionality as a decentralized RPC gateway. This capability stems from its unique setup where each INTERX node, regardless of its associated subnet, is linked to a KIRA account address, with all responses being digitally signed. This architecture allows users to query multiple nodes simultaneously and evaluate the responses against each other. Such a mechanism enables users to identify nodes that consistently deliver precise responses and craft off-chain fraud proofs against nodes disseminating fraudulent or inconsistent data.

While light clients theoretically offer higher security through block-by-block consensus verification (without storing data), they fall short due to the maintenance they require. This maintenance challenge becomes particularly pronounced across hundreds or thousands of applications in a growing multi-chain world. By enabling the creation of fraud proofs, INTERX introduces a practical alternative for decentralization. It establishes a balance between the security offered by light clients and the convenience of Infura-style RPC providers. Through repeated queries to a broad spectrum of INTERX nodes, users can achieve a level of security comparable to that of light clients, assuming these nodes are either verified through the Identity Registrar or have stakes involved. This system underscores that even a single honest INTERX node in the query batch can trigger the eviction or slashing of dishonest ones. However, for maximum safety, users are recommended to operate their own INTERX node as well as a SEKAI instance, essentially running a full node.