Kinetex Light Clients (MMR)

[ Overview ] The Kinetex team firmly believes that Ethereum remains the flagship and leading network in the crypto space. However, due to the rapid growth of activities and the influx of new projects, the network's load is increasing significantly. Scalability is becoming a major concern, and Layer 2 (L2) networks have emerged as one of the solutions, although they create fragmented liquidity. As most protocols become multi-chain, the need for quick, cost-effective, and secure liquidity movement becomes paramount.

To address these challenges, bridges offer a solution for transferring liquidity between Ethereum's L1 and L2 networks. The Kinetex team has been aggregating bridges and decentralized exchanges (dexes) to support the community in moving liquidity. However, the recent collapse of large bridges like MultiChain prompted the team to reevaluate the security and effectiveness of existing bridge solutions.

[ Main Problems ] The team has identified several key problems:

1. Each transaction takes time to validate, ranging from 2 to 5 minutes on average.
2. The cost of gas and slippage can change during the validation period.
3. Bridges lack a batch system to optimize gas costs.

[ Idea ] Kinetex plans to launch a decentralized cross-chain public resolving solution soon. In today's presentation, the team introduces Light Clients that aim to optimize gas cost for transactions and enhance security. We at Kinetex do not claim to be superior to other bridges or message protocols but instead, we are commited to the idea of composability and unification of DeFi sector solutions.

The proposed approach by Kinetex team involves reimagining liquidity movement. Rather than relying on a controlled liquidity pool that is vulnerable to attacks, we suggests transferring control to a decentralized market. In this market, users create swap orders, and professional resolvers take on the risks of managing the swaps while charging a commission. This approach fosters an honest and truly decentralized market where resolvers compete to serve users.

[ Batch Optimization ] Kinetex Light Clients tackle one of the crucial challenges by enabling batch processing of transactions. This approach allows users and resolvers to conduct peer-to-peer transactions directly without waiting for or depending on validators. By doing so, it significantly optimizes gas costs. Additionally, the use of Zk (zero-knowledge) technology in the batches further enhances gas optimization.

[ Light Clients ] To facilitate the transfer of blockchain state to another network, Kinetex team employs several protocols for messaging between chains. Utilizing multiple protocols simultaneously ensures maximum security. It is worth to note that the blockhash function that is used to transfer hash of block header, enables access to 256 blocks, necessitating regular updates.

The team drew inspiration from Hashi's ideas, which facilitate connections with various protocols and oracle sources through adapters, including Zk light clients. Hashi acts as a common interface for providing data of light clients.

In terms of optimizing data storage, Kinetex utilizes the Merkle Mountain Range structure, which enables efficient handling of large datasets, making it particularly suitable for working with blockchain historical data. This approach was inspired by Axiom.

Kinetex on-chain light clients are designed to be deployed on any EVM network and to be capable of storing the state of supported networks. In its fundamental form, the applied approach utilizes the blockhash function to obtain one of the last 256 blocks. Subsequently, the cross-chain messaging protocols are used to transfer this block hash to networks where instances of light clients are deployed.

Our solution is built upon Hashi adapters, which we have specifically developed for various cross-chain messaging protocols such as Chainlink CCIP, Axelar, Hyperlane, and Zetachain. This allows us to support light clients for numerous networks, including Ethereum, Gnosis, Polygon, Linea, Celo, and others.

Notably, every block hash is not transmitted individually. Instead, the BlockReporter contract is executed every 1024 blocks, creating checkpoints. Based on these checkpoints, Merkle-trees of block hash batches are constructed and stored in the appendable Merkle Mountain Range for enhanced efficiency. This approach draws inspiration from the Axiom project's idea.

The project includes several components, including an MMR LightClient implementation, Hashi adapter contracts for cross-chain messaging protocols, a BlockReporter managing contract, and an Event Logs proofer implementation that can be utilized in the Kinetex Protocol or other projects.

Moreover, the project includes functionalities for generating proofs and raw data of block headers. Additionally, we have developed sketches for the zk-circuits related to block batching.

It is also worth noting that we have integrated 1inch Fusion in order to create an auction for the execution of tasks to update light clients.

To ease the deployment and management of contract calls, we have included helper scripts.