What are the main design trade-offs that had to be made with an omnichain design?
There are multiple design options available to realize the omnichain restaking infrastructure, which mostly concerns where the main logic of Exocore (main accounting, reward, slashing etc.) exists. Specifically:
Implement on the smart contract level in a secure blockchain such as Ethereum
Pros:
No need for network bootstrap, Exocore starts working after contracts are deployed.
Security supported by Ethereum consensus.
Cons:
Cost-prohibitive especially when it needs to handle verification of valid work (for rewards) and malicious behavior (for slashing).
Reliance on multi-sig for governance.
All complex business-logic must be implemented at the smart contract level, which can increase the attack surface.
Not flexible in feature implementation on smart contract level of third-party chains.
Implement as a layer 2 solution on Ethereum
Pros:
No need for network bootstrap, Exocore starts working after the L2 is deployed.
Security supported by Ethereum L2.
Transaction cost is lower than main chain Ethereum.
Cons:
Slow finality (days) if we use optimistic rollup.
ZK rollup is not mature enough for complex feature implementation
Need to rely on third-party bridge (additional trust assumption) for messaging between chains.
Implement as a separate chain
Pros:
Transaction fees can be very low.
Full autonomy and flexibility in feature implementation and upgrade.
Complex business logic can be implemented at the protocol level and secured by consensus.
No third-party bridge is necessary (no additional trust assumption)
Cons:
Network bootstrap is needed.
If Exocore chain halts, the restaking operations (withdraw, slashing etc.) will stop until the chain resumes. But no assets can be stolen since Exocore doesn’t have permission to transfer user assets on client chain.
The high transaction cost and reliance on multi-sig for governance is a deal breaker for choosing to implement Exocore as a smart contract in Ethereum. The slow finality of optimistic rollups is also not acceptable since fast synchronization is needed in Exocore.
Overall, choosing to build Exocore as a separate chain hit the sweet spot in the tradeoffs as it’s most cost-efficient for operations, provides full flexibility and autonomy in feature implementation, and does not require to introduce third-party bridges in the trust assumption.
Last updated