infusion logo

Introduction

Built on top of the Injective blockchain, Infusion is a Layer 2 Independent Rollup with integrated EVM. It inherits all of Injective's security and decentralization while offering blazingly faster and more scalable performance without any security trade-offs.

Infusion is proof-less, eliminates the need for zk proofs or optimistic fraud proofs, but is even more secure and efficient. It also offers user-driven upgradability and sovereignty, empowering the community."

Problems with other rollups

Optimistic Rollup

Security: Optimistic rollups are heavily dependent on validators to function. If there is no validator online 24/7, there will be no one to submit challenges if there is fraudulent data, and the network might be at risk. Furthermore, it is systematically complex with a lot of components, which introduces potential vulnerabilities to attackers.
Upgradability: The problem above leads to the need of upgradability, which is only possible through token governance (which gives sharks almost full power) or security councils - centralizing everything to the developers and companies behind the project because it does not have its own sovereignty.
Efficiency: When fraud proof challenges happen, sequencers need to be compensated for submitting full on-chain proof, which is very costly.
Decentralization: Decentralized sequencer is hard to implement, depending on how it is built, there will be problems for each implementation. If sequencers can freely upload blocks, they might extract MEV unfairly to win first place, if sequencers are rotated, there might be DDoS/censorship/latency issues that can lead to false penalties. Furthermore, validators and sequencers also have to stake to have something to be penalized for, which creates a small barrier.

Zk Rollup

Security: ZK rollups rely on zk proofs, which present potential risks. A ZK scheme like SNARK depends on immature cryptography primitives (pairings, trusted setup), a scheme like STARK is safe but is too expensive to be practical. Furthermore, the zkp implementation in rollups are too complex and immature which might lead to possible attacking vectors.
Efficiency: Despite being designed for affordability, zk proofs can be costly, with a fixed gas cost of around 500k per rollup block in EVM-based networks. This means when networks have few transactions, users may experience exceptionally high fees.
Upgradability and decentralization: ZK rollups face similar challenges as Optimistic rollups. However, they don't require staking; rather, they need sequencers to have specialized hardware for efficiently generating zk proofs. Acquiring such hardware can be difficult, which creates a barrier to participation.

Our solution

Infusion, as a Layer 2 rollup scaling solution, enhances Injective blockchain network by increasing transaction throughput and lowering fees, all without compromising security.
As an Independent Rollup, Infusion eliminates the need for zk proofs or optimistic fraud proofs, providing a more secure and efficient solution.
Infusion has the Ethereum Virtual Machine (EVM). It introduces EVM compatibility to Injective, allowing developers with experience in EVM-based chains to effortlessly build on Injective using their existing skills and tools, enriching the dApp ecosystem of Injective.
Infusion has a decentralized sequencer system that promotes trustlessness and decentralization, in contrast to other rollups that use centralized sequencer systems, which potentially become a single point of failure.
Infusion naturally inherits interoperability of Injective and Cosmos, allowing it to seamlessly access sovereign Layer 1 chains. This enhances Injective's interoperability, taking it to new heights and expanding its potential.
Upgradability in Infusion is determined by users rather than token holders, companies, or developers. All new upgraded clients from developers are transparently presented to users, who can choose which client to run or change the consensus rule of Infusion. This approach fosters true decentralization and earns community trust.

Comparison to other rollup

Deep dive into Infusion's technology

There are primary technologies in Infusion:

The rollup
The EVM
Proofless model
Decentralized sequencers
Community-Driven Upgradability

The rollup

As a Layer 2 network, specifically a "rollup", Infusion moves state data and computation outside of Injective, while keeping some data on the chain for security.

To be more specific, transactions sent in a rollup are collected by nodes called "sequencers". Sequencers will then pack some of the transactions into a "batch" (or a "rollup block") and upload the batch onto the Injective blockchain via a transaction to Injective with an amount of INJ for gas fees. The special part is that these transactions are not executed or verified on layer 1 like Optimistic and Zk rollup. All Infusion nodes will read and verify the transactions from Injective Blockchain based on Infusion consensus rules, then execute them with their own independent state.

From that, we have sharded the transaction execution process and state storage from Layer 1 to a different environment of Layer 2. The aggregation cost is also reduced, where normally people would have to pay for individual transactions on Layer 1, but here, the sequencer packs transactions into a batch and single-handedly submits the batch on-chain.

In addition, there are heavy compression tricks of rollups to make transactions even lighter, further increasing Infusion’s transaction throughput because we can fit in more compressed transactions in one batch. Batches are also only stored as a note of a transaction in Injective (or "calldata", depending on how each chain calls it), which does not interfere with Layer 1's state storage, making it gas-efficient!

Unlike some existing Layer 2 scaling solutions like plasma chains or state channels such as the Lightning Network, which are limited to small parties making constrained transactions, a rollup like Infusion has full capabilities of a normal Layer 1 blockchain network. You can create transactions however you like to whoever you like without complicated setups and quirky steps.

Compression tricks

Infusion has implemented advanced transaction compression techniques to further enhance speed and reduce gas fees.

Our MVP employs two effective compression tricks:

The fist trick is "address indexing." Instead of storing the complete address in each transaction, nodes maintain an array that contains existing addresses within the network; thus, we only need to store the position or index of the address in that array. This approach allows us to transform a 20-byte address into a 4-byte number within the EVM environment, resulting in a reduction of 16 bytes per transaction.
The second trick is "gas compression." Typically, EVM transactions require a 3-byte gas limit (representing the maximum amount of gas the transaction can consume) and a 7/8-byte gas price (denoting the price per gas unit). However, we have devised a more efficient method that only necessitates the storage of 1 byte - 0.5 bytes for the gas limit and 0.5 bytes for the gas price. This idea is inspired by “An Incomplete Guide to Rollups” article written by Vitalik. The technique is based on using consecutive powers of two for gas and gas limit values. Specifically, gas is represented by 2^n (where n ranges from 9 to 24, with 2^9 being the minimum gas limit and 2^24 being the maximum gas limit), while gas price is represented by 2^m (where m ranges from 25 to 40). Although this approach does not explicitly state the exact gas limit and gas fee, it works effectively due to the wide range of options available for users. Since gas estimation is often not 100% accurate, consecutive powers of two provide approximate values that align closely with the desired outcomes. Overall, this compression technique allows us to achieve a significant reduction of 10 bytes per transaction. As we move forward, we plan to implement more compression tricks to enhance the efficiency of Infusion!

The EVM

Infusion has the EVM as the core contract execution environment. It is fully compatible with Ethereum's original EVM and is actually built upon an existing Ethereum client's EVM implementation (Ethereum js), which integrates seamlessly with our rollup model. The transaction format, the address format, signatures, etc. are also the same as the original Ethereum.

Using the EVM, Infusion can:

Enrich Injective's application ecosystem with more dApp potentials as well as ports of existing EVM-based dApps.
Onboard developers with existing skills and toolings related to EVM-based dApp development.
Provide an alternative for dApp development to existing languages/tools like CosmWasm

Proof-less model

"Prooflessness" is by far the most unique design of Infusion compared to other rollups.

Why does Infusion eliminate the need for sending proof to Layer 1?

As explained in "The Rollup" section, user nodes execute transactions after reading and verifying them from batches. If transactions are faulty, the user nodes simply ignore them and only execute valid transactions according to the predefined consensus rules, which eliminates the need for sending proof to Layer 1 for verification, as is required in other rollup models.

A common misconception is that rollups need to verify the batch (rollup blocks) on-chain, but in reality, user nodes can fully verify them off-chain according to the consensus rules of Infusion nodes before submitting proofs. Take Optimistic rollups for example, nodes must be able to verify the transactions in batches first to know if they are faulty or not to send a fraud proof to the layer one, and the way they verify these transactions is the same as Infusion: checking transactions in batches by using consensus rules.

The only reason rollups need optimistic fraud proof or zk proof is that most rollups currently don't have their own independent assets, they need to bridge existing assets from the layer one to the rollup. For example, Arbitrum, Optimism, zkSync, etc has users bridging their existing assets on Ethereum to their rollup. These assets are controlled by a bridge smart contract, so only verifying by consensus rules would not work, because even though rollup nodes know what transactions are correct, the bridge - an entity that exists in the layer one, can not verify it without some form of proof. Infusion is sovereign and has the same power as a layer one in spite of being a layer two, additionally, it has its own native token to pay gas fees, so it doesn't need a bridge to transfer the layer one's token onto the rollup for gas fees at the beginning. The bridge is not built-in to the protocol, but as mentioned in our submissions' roadmap, bridges can be built on top of Infusion in the future, but as dapps with a layer-one-to-layer-one model with a variety of approaches.

Advantages of the Proofless Model:

It is efficient: Infusion requires no potential optimistic disputes and no computationally extensive cryptographic proofs.
It solves the upgradability problem: Infusion does not need to be upgraded through a centralized multisig or token governance. The community can change their consensus rules to create a hard fork for an upgrade, something that cannot be done with traditional rollups.
It makes decentralized sequencers easy: Since sequencers can submit batches freely and nodes will discard any transaction that is faulty, sequencers don't need to worry about the duplication of some transactions that they might falsely submit from losing a slot to another sequencer. This means that decentralized sequencers with Infusion can be done much easier, without clunky stakes or bonds like Optimistic rollups.
The simplicity reduces risk from manipulation, while Optimistic and ZK rollups face challenges due to complexity. Meanwhile, Optimistic rollups are systemically complex through their fraud proof scheme, and ZK rollups have encapsulated complexity where cryptography can be easily broken if not done right/tested properly.

Decentralized sequencer system

Infusion's proofless model enables a decentralized sequencer system, allowing anyone to run a sequencing node, listen to transactions, and bundle and upload rollup batches using our client on their computer.

No requirements, staking barriers, governance tokens, or specialized hardware are needed – just ensure you have some INJs to cover gas fees when submitting rollup batches.

Community-Driven Upgradability

Infusion is upgradable in the same way layer 1s do hard forks and soft forks, users have all the rights to choose which client, which Infusion fork they think is best. This approach is superior to token governance which gives too much power to token holders and sharks, or security committees/councils which are all centralized.

FAQ

Question 1: What if a party spawns thousands of nodes all changing their client's code/consensus rules?

This does not affect Infusion at all because what they have done is just create their own different chain. This is the same in Bitcoin nodes, Ethereum nodes, and other blockchains nodes as it is in Infusion, and it's not considered an attack.

Take Bitcoin for example, if a large number of nodes suddenly rewrite their balances into millions (which is against the consensus rules), they are just creating their own chain that says they have millions of Bitcoins while the others say otherwise. To be more precise, if they send a transaction to buy some goods using those millions they have just created, other nodes, which have the attacker's true balance stored on their node, even when the network has a lower amount of healthy nodes than the number of malicious nodes that the attackers have just spawned, will deem this as a faulty transaction independently on their own node through the correct consensus rules and everything will work normally.

Question 2: How does Infusion reach consensus and why can't Infusion sequencers do a 51% attack

Infusion does not possess its own consensus mechanism, meaning no single sequencer, or a group thereof, holds more power than another; instead, it reaches consensus by inheriting the consensus mechanism of Injective (with Injective's consensus mechanism being Tendermint PoS). The rollup batches are uploaded to layer one as Injective transactions with the batches' data embedded in them, so the Injective chain records the whole Infusion chain because Infusion batches are just Injective transactions. Injective nodes have a consensus on the Injective chain, so they have a consensus on transactions in Injective, which includes transactions that hold Infusion's blocks. Therefore, Infusion can come to a consensus through Injective's consensus mechanism. Additionally, a 51% attack can only happen in layer 1, not Infusion, because Infusion does not have a consensus mechanism.

Infusion reaches consensus based on this structure by inheriting the consensus mechanism from Layer 1 but with its own set of consensus rules that operate within the client. The consensus rules ensure that non-malicious Infusion nodes will get the same result (same balances, storage, data, etc), and only non-malicious transactions are executed even if only a single sequencer is running a normal client among others running malicious.

The term “consensus rules” - which are conditions used to verify transactions, are different from "consensus mechanisms" (PoS and PoW) - protocols that produce blocks in the layer one. All other rollups like Arbitrum, Optimism, zkSync, Starknet, Fuel, etc inherit consensus mechanisms from Layer 1, and have their own consensus rules. This approach ensures robust security against malicious activities like the 51% attack.

Use cases

There are endless possibilities with Infusion. But here are some of the promising use cases:

Blazing faster transactions and lower gas fees, scaling Injective and Cosmos even further.
Through EVM integration, existing protocols can easily be ported over to Injective without sacrificing efficiency, security or decentralization.
Attract existing Solidity, Vyper and Yul developers to build protocols on top of Infusion and Injective.
Leveraging the decentralization of Injective and Cosmos with the decentralized sequencers system.
Further push INJ token’s price linearly with Infusion’s growth through batches submitted by Infusion sequencers to Injective.

Roadmap

In a two-week phase, we have done:

✅Finish the core Infusion network, make sure nodes can sync rollup blocks perfectly; transactions, EVM contracts and state data storage are executed correctly.
✅ Finish adding transaction compression to make transactions cheap and light.
✅ Finish the JSON-RPC server so that wallets and dapps can easily interact with the network, read state data, send transactions, etc.
✅Test the rollup, try deploying and using existing EVM contracts on Infusion.
✅ Release proper documentation and specifications of Infusion’s architecture and APIs.

With your recognition and support, we can accelerate the development of Infusion, and the estimated development lifecycle looks like this:

In the next 2 months, we plan to:

Add in Ethereum compatibility specifications so that existing wallets like Metamask or Frame, devtools like Hardhat, Brownie, Foundry, etc can work with Infusion.
Embed the Infusion client into the Injective client, making block syncs much faster and more efficient. It would also make it possible to do special adjustments to optimize and prune unnecessary layer 1 data to get the best performance for the rollup.
Optimize the Infusion client for lower hardware requirements and better performance.
Build an Infusion light client so that low-end computers, mobile phones, and embedded devices can have access to the blockchain network in a totally decentralized way, independently verify data without any reliance on centralized node-providing services.
Build a cross-chain protocol or a bridge to make it easier for asset migration to Infusion.