feat(sequencer): cross chain sequencer communication

[Trantorian1]

Is there an existing issue?

• I have searched the existing issues

Motivation

There currently is a drive by several players in the ecosystem for the integration of appchains into Starknet. These would essentially act as coprocessors similar to Polkadot parachains: rollups which provide app-specific functionality with settlement onto Starknet itself. This has the added advantage of isolating an app from spikes in network traffic, making its operational costs more predictable for end users.

While this is very interesting in that it would allow for highly efficient applications which still benefit from the crypto-economic security of Starknet, it also poses several issues related to the fragmentation of the ecosystem (liquidity or otherwise). This is very similar to the issues faced by the Ethereum L1 with the fragmented L2 landscape.

While it seems evident that appchains are a very powerful tool towards designing the next generation of highly efficient dapps and blockchain services, the question remains: how do we maintain high cohesion alongside high scalability and avoid a liquidity and ecosystem fragmentation similar to what Ethereum is facing right now.

Request

Explore the implementation, practicality and risks of cross-chain sequencer to sequencer messaging.

Solution

Note

This is an area of the blockchain, not only Starknet, which is very much under active development.

First, let us consider the problem: we want separate, likely heterogeneous networks based on Starknet to be able to communicate seamlessly with no trust assumptions. The solution we will be focusing on in this issue is making the state of a chain A available to a chain B at sub-consensus intervals, and analyzing the risks and challenges incurred by this approach.

Direct Sequencer to Sequencer cross-chain communication (S2S)

(Based on the Scaling App Chains Solutions Overview by Herodotus)

Many different solutions are arising on the matter of cross-chain communication, with chains such as Espresso Systems focusing on providing an intermediate communication layer with fast settlement times. This has the disadvantage of lowering the crypto-economic security of the systems interacting with it and putting them at risk of a single, external point of failure.

S2S in comparison is much simpler to implement and does not require an additional communication layer. The protocol is as follows:

• Sequencers A and B on different chains begin by staking some funds as collateral for misbehavior. This is done onto a common settlement layer.

• A and B then perform a handshake via the settlement layer to establish a common key. This will last for the duration of the exchange or can have an expiration date.

• When A wants to initiate a cross-chain operation with B, it makes an RPC request to which B responds to with the requested data and a signed copy of the on-chain state used to produce it.

• A will optimistically apply this result, keeping a copy of the on-chain data it was provided.

• Once both chains have settled, a verification process ensues, where a trustless third party (a smart contract) verifies that the state which each sequencer received was indeed published. This is possible since each sequencer will have signed the data it has sent.

Limitations and vulnerabilities

Up to this point, we have made several assumptions which limit the scope of this protocol:

1. So far, we have assumed that A is able to make sense of the data which is being sent to it. This is not necessarily the case, unless chain B shares the same block structure as A. So already, this is a far more manual approach than might first seems, as A must have at least basic knowledge of the block structure of the chain it is querying to be able to extract any meaningful information from it.

2. While it is trivial to query sequencer B to retrieve raw data from the chain, for more complex operations which do not directly represent the on-chain state (for example, a smart-contract execution) B can always send A an invalid answer but valid data to back it. Since we are using data settlement as an arbiter for misbehavior, this means that the verifying contract cannot check anything more than the basic existence of on-chain data, or else it has to implement unique verification logic, potentially for every appchain which it verifies. Therefore, we must assume that this protocol only allows for the transfer of basic on-chain state, the authenticity of which is verifiable by settlement alone.

3. It must also be noted that we have so far assumed a centralized sequencer architecture. It is not clear how this method of communication could be adapted to a fully decentralized network.

4. Finally, the use of sub-consensus exchange of information greatly increases the risk of byzantine behavior. If for some reason -exploit or other- a bad actor is able to convince chain A of an invalid state on chain B, such as in the hypothetical scenario of cross-appchain bridging, then they could effectively mint token on A for free and this would only be detected after settlement. This can be used to duplicate funds, devalue a token or event profit from a short order on that token at the cost of little initial liquidity. This poses a significant issue as it is not clear that this kind of exploit would have a maximal return on investment, meaning it could well outweigh the penalty for misbehavior associated with staking.

Conclusion

S2S is an interesting yet limited tool towards achieving further scalability in Starknet while maintaining high cohesion. It only works in cases where both appchains share the same block structure, or implement logic to decode each other's block structure, and can only be used to query the direct state of each chain as this could otherwise lead to claims which cannot be verified on the settlement layer without re-execution. It also introduces higher risks of byzantine behavior.

Despite these limitation, this might still be an interesting tool to explore in the context of private appchains, where communication occurs between centralized, trusted sources and where interactions are restricted by on-chain logic (such as in the case of a contract-specific appchain). This could strongly limit the risk of byzantine behavior by letting the developers implement safeguards against such risks, especially when it comes to the bridging of valuable assets.

Are you willing to help with this request?

Yes!