Recently, Igra/Kasplex/Sparkle Teams are working on L2s to enable smart contract features on Kaspa. While everyone seems to be jumping from one question to another and lose focus and priority of issues, i.e. fees/nodes requirement/economic model.
This post is to show that this will not be just “another EVM chain replicate”. I am writing to organize all my questions and the difficulties I see in a structured way. Definitely welcome others to add more. Some were already mentioned by @FreshAir08: On the inherent tension between multileader consensus and inclusion-time proving - #3 by FreshAir08.
1. ETH Mempool/Txpool & Node Rules
When a TX nonce value is too large, or the gas fee is too low (e.g., during network congestion), ETH nodes cache the TX in the queue until conditions are met. Then the TX is executed.
Since L2 lacks P2P consensus and relies solely on L1 sequencing, TX execution may differ across nodes. For instance, some nodes may cache transactions that others do not have and executed these TXs later again in future blocks.
Specifically, nodes that has cache TXs with invalid nonce values will re-execute them once the conditions are met. Newly joined nodes cannot re-cache these TXs. It will then look like that “older nodes have more TXs,” when in fact those should have been discarded.
ETH tried to solve this issue by switching this feature off.
2. L2 Node Reconstruction and Consistency
Based rollups means that all TXs are sequenced and ordered by L1. L2 functions solely as a layer for state storage and computation. In theory, L1 L2 logic and consensus should be aligned. In that case, ideally, as long as the data sources are identical, all L2 data, statefulness, and TXs can be simply rebuilt with any L1 archive.
By the way, this is also an overlooked feature of KRC20 protocol. KRC20 needs no compatibility; KRC20 doesn’t generate any block. A TX is an execution. Every TX generates a checkpoint. KRC20 blocks = L1 block. It is the most “based”.
For EVM chain, in contrast, things are way more complicated. EVM L2s produce blocks by themselves, obviously. The biggest issue of typical EVM L2 designs is TXs are NOT executed from L1 directly. It needs a LOT of compatibility stuff, including block binding, TX execution rules, mempool rules etc. As a result, any two of the L2 nodes may diverge in transaction ordering due to caching (as mentioned above) or deep reorgs. Despite the op codes themselves, EVM chains need to incorporate EIP-xxxx, various gas fee mechanisms, and other protocols. All these are included in the ETH client ends. Very difficult to make changes. I don’t know how Igra/Kasplex team will manage this problem.
One solution (maybe) is to supporting multiple supernodes mode: this assures at least syper nodes has same results when executed against the same L1 data.
3. Additional Thoughts
- ReOrg Handling: When an L1 reorg occurs (this is a very unique Kaspa issue), usually, the resolution is to determine the affected VSPC blocks, and then the L2 must roll back these affected TXs/statefulness and re-execute them based on the new L1 data. This would require significant modification of EVM’s core components if the EVM L2 is on Kaspa.
- To be attractive to existing EVM devs and dapps, L2 must achieve close-to-complete compatibility. Just allowing for progammaticability with Solidity is not good enough. It needs to get across infrastructure and protocol layers.
- Wallet compatibility: Imo the EVM ecosystem is too heavy, but for reasons above, if Kaspa makes an EVM L2, it must try its best to be as compatible as possible. Seamless wallet integration is required
- RPC Compatibility: Since TXs are submitted to L1 (if the L2 is based), read-only RPCs (on-chain data queries) can use existing EVM components directly. However, writing (transaction broadcasting) must be submitted to L1. There are maybe two possible solutions:
(a) Wallets directly construct and submit L1 transactions. The bad news is EVM wallets cannot be used then.
(b) Modify RPC to intercept broadcast calls and relay them to L1 (“relayer” compatible with EVM wallets). This is against decentralization.
- L2 Explorer: L2 explorers must display the mapping between L2 blocks/transactions and L1 data, which is still not given by neither Kasplex nor Igra.
------------ NON EVM PARTS ------------
I have a sense that Kaspa people don’t really know much about ETH clients. Imo, Kasplex’s design is more trusless and is more challenging by its design. It seems to be based and it is consistent with their design of KRC20. Igra’s plan is not as based, although their transparent communication and update is highly appreciable.
The actual challenge is not with tge question “can they build a L2 that can run”. The question relies upon frontier conditions, such as DA cost. A good question can be: Under 10 BPS, if L2 uses a lot of calldata (not memory or blob), does the L2 have a strategy to manage potential congestion and bloat on L1 (the fee will then rise)? That’s kinda similar to what happened during the KRC20 launch. Unfortunately, these questions are so rare. Only see buzz words of “decentralized nodes”“trust model”“pre-zk” blah blah.