Inco-Eigen Dual Staking

This page serves as a living document to explore how a Cosmos chain (here Inco Network) can be dual-secured by using EigenLayer restaked ETH.

Context

TODO: what is Inco, what is Eigen, why dual stake. This blog post is a good intro.

Goals

1. Use both INCO and ETH to secure the Inco appchain.
2. As far as possible, use the same infrastructure for Inco's bridging.

A third consideration is that the Inco validators will additionally run a MPC network for the FHE decryption key. However, due to the current difficulties with slashing in a MPC network, we can omit this consideration in this document.

In other terms, the goal is to decide which design to use:

• for dual staking
• for listening to voting power

Table of Contents

1. Dual Staking Solutions
   • Design #1: Self-Sovereign Dual Staking
   • Design #2: Modular Dual Staking (abandoned)
   • Design #3: Finality Dual Staking (abandoned)
   • Design #4: Ethos RS
   • Design #5: Ethos Mesh
   • Summary
2. Listening to Voting Power
   • Design #1: VoteExtensions
   • Design #2: On-Chain Voting
   • Design #3: Ethos (via Mesh)
   • Summary
3. Slashing

Dual Staking Solutions

Design #1: Self-Sovereign Dual Staking

The validators run a CometBFT chain whose voting power is a function of both INCO and ETH. They use a side-car to natively listen to events on Ethereum, and inject it into the Inco chain.

(Excalidraw Link.)

1a. With Price Oracle

We use the USD market cap of staked token as a common denominator for dual staking both tokens. We inject into CometBFT's voting power the sum of $(INCO) + $(ETH).

The price oracle is fetched by the active validator set, using for example VoteExtensions, or via on-chain voting. See section "Listening to Voting Power" for a comparison.

Pros:

• Use existing technologies (vanilla CometBFT, ABCI++), low implementation cost

Cons:

• Price oracle risks (TODO be more precise)

Notes: Inco has started working on a PoC based on this design. See diagram.

1b. Without Price Oracle

Without price oracle, we propose to do a weighted sum of the absolute values of both voting powers: x * INCO + y * ETH with x + y = 1. The two parameters can be updated via governance.

An sub-case is to set x := 0, i.e. use ETH for securing the network and INCO solely as a governance token.

Pros:

• Low implementation cost

Cons:

• x and y are only gov-updatable, which is slow compared to ETH/INCO price volatility.

Design #2: Modular Dual Staking (Abandoned)

Design #3: Finality Dual Staking (Abandoned)

Design #4 & #5: Ethos (RS or Mesh)

Rely on Ethos for ETH backing. In a way, this is very similar to Self-Sovereign Dual Staking (design #1), but using Ethos for injecting voting power instead of doing it directly with EigenLayer. Inco can integrate with Ethos:

• either via Mesh Security
• or via Replicated Security

Pros:

• Easy implementation

Cons:

• Price oracle risks (TODO be more precise)

Open Questions:

• [To Ethos] When are ETH-backed eigen operators slashed?

Summary

	Mesh (Ethos)	RS (Ethos)	Self-Sovereign Dual Staking
Dual tokens	yes	no	yes
Slashing	IBC	IBC	directly to Eigen
Death by Contagion	Medium+	Highest	Medium-
Implentation cost	Low	Low	Medium (but ongoing)
Difficulty of recruiting ETH security	Easy (ask Ethos operators to delegate to Inco vals)	Medium (ask Ethos operators to also run an Inco val)	Hard
Overhead on Eigen operator	None	Run Inco validator	Run Inco validator
Ease of scaling Inco validators	Easy	Hard	Hardest
Inco token utility	High (security, gov, fees)	Low (gov, fees)	High (security, gov, fees)

Evaluation Framework

1. Security
   self-sovereign> mesh> rs
2. Bridging
   we don't know
3. How easy to recruit ETH security TVL?
   rs>mesh>self-sovereign
4. How easy to recruit inco validators?
   rs>self-sovereign
5. How easy to build?
   rs>mesh>self-sovereign

Listening to Voting Power

If using Ethos, then this section can be ignored, as voting power will be natively injected by Ethos. If using self-sovereign dual staking, please unscroll.

This section describes how the Inco chain updates its on-chain stake table by listening to the Ethereum chain. The current plan is to first define an epoch (e.g. 1h), and update the stake table at the beginning of each epoch.

Note: We might also want to use the same mechanism for price oracle, if we need one.

Design #1: VoteExtensions

We use a solution based on ABCI++'s VoteExtensions, for example using Skip's Slinky. This means that voting on Ethereum events is delegated to CometBFT: votes are not casted on chain, but done during CometBFT's voting rounds, only the result is stored on chain (via PreBlocker).

See Slinky's documentation.

If we don't use Slinky, we can still design our own implementation using VoteExtensions.

Pros:

• Low implementation cost
• Speed (not relevant for voting power, updated every epoch, but it might be relevant for bridge events)

Cons:

• Risk of overloading consensus, especially if we want to listen to multiple chains in the future (bridging)
• Risk of chain halt (e.g. bugs)

Design #2: On-Chain Voting

Each validator will have its own observer side-car, which monitors events on Ethereum. Once the side-car receives an event, it will broadcast a Msg on the Inco chain using the associated validator's private key.

This design takes inspiration from prior art:

• Axelar
• Zetachain (docs)
• Gravity Bridge (e.g. Sommelier, code)

Pros:

• Battle-tested
• All votes are on chain
• Possibility to decouple the observer nodes from the validator set (e.g. observers are Eth-backed, validators are Inco-backed)

Cons:

• Slightly lower speed compared to VoteExtensions, though only relevant for real-time use cases (e.g. bridging)

Open Questions:

• [To Inco] Are there any pros of having the observer set different from the validator set (e.g. whitelisted by gov)?

Design #3: Using Ethos (Mesh/RS, IBC)

With this design, the voting power is injected from Ethos to Inco's state machine using IBC.

Slashing

We propose to categorize slashing into two categories: consensus misbehaviors and bridging misbehaviors.

Consensus misbehaviors

CometBFT and Cosmos SDK currently handle 3 types of misbehaviors:

1. Non-Liveness.
2. Double-Signing.
3. Light Client Attack (docs, already natively handled by CometBFT and slashed on the Cosmos SDK).

The evidences of such misbehaviors are easily verifiable on the Cosmos side, but verifying them on the Ethereum/EigenLayer side requires periodically passing Cosmos stake tables to Ethereum.

Bridging Misbehaviors

4. Incorrect Observed Event: for Inco's FHE bridge events

Additional misbehaviors if we use Self-Sovereign dual staking

5. Incorrect Voting Power: validator proposes or votes on an ETH stake table that's not the final accepted one.
6. Skipped Voting Power: validator did not vote during an epoch.

	Inco Slash %	ETH Slash %
Non-Liveness	1%	?
Double-Signing	5%	yes, if possible
LC Attack	5%	yes, if possible
Incorrect bridged event	?%	yes

Bridging

This table summarizes how other Ethereum-Cosmos bridges are designed. It is not meant as a bencharmark of which bridge Inco should connect to, but as inspiration for Inco's own native bridge.

Some other references:

• https://www.maven11.com/publication/horatius-at-the-bridge

	Blobstream	Zetachain	Axelar	Gravity	Slinky	Namada
Technical docs	spec	docs, whitepaper	cgp-spec	design	notion	blog
Validator runs observer?	n/a	Yes, validators run light-client (passive) or full-node (active) [11]	Yes, validators run full-nodes[1]	Yes, validators run full-nodes[2]	Yes, agnostic over RPC vs full-node	Yes, validators run full nodes [8]
Consensus on observed events	n/a	on-chain[2]	on-chain	on-chain	VoteExtensions	VoteExtensions
Slash malicious observers	n/a			No (intentional) [6]	possible
What is stored on the ETH contract?	Latest valset + height=>dataRoot [5]	Latest TSS address [10]	Latest valset[7]	Latest valset[4]	n/a	Latest valset [9]
What does ETH key sign?	1 sig per attestation (valset or data commitment) per validator[13]	1 TSS sig per outbound tx[12] (TODO can batch?)		1 sig per validator per BatchRequest or ValsetRequest	n/a
How are ETH signatures aggregated?	EDCSA multi-sigs. Custom P2P network, relayers bundle N sigs	TSS (edcsa & eddsa)	On-chain EDCSA multi-sigs	On-chain EDCSA multi-sigs	n/a
Example TX		link		link (decode input data)
Who relays the tx? (pays for ETH gas fee)					n/a
Relayer incentive			Fees		n/a
Additional backstop mechanism
Fraud Proof					n/a

References:

1. "This requires validators to run nodes for Axelar-supported chains, and observe those external chains for activity." from docs.
2. "The sequencer discovers relevant external trans-actions/events/states and reports to verifiers; the verifiers verify and vote on ZetaChain to reach consensus," from docs.
3. "Full Node - This is an Ethereum Full Node run by an Operator", spec.
4. See Gravity.sol.
5. See Blobstream.sol. They are also called Valset and Data commitment attestations in the spec.
6. GRAVSLASH-04 and GRAVSLASH-05, spec.
7. "AxelarAuthWeighted: The authentication contract . It allows the sender to specify a list of validators and the corresponding weights," blog post.
8. "Namada validators will run Ethereum full nodes", source.
9. See Bridge.sol.
10. See ZetaConnector.base.sol.
11. See "Observers Active and Passive mode" in whitepaper.
12. See tx lifecycle p17 in whitepaper.
13. "The role of the orchestrator is to sign attestations using its corresponding validator EVM private key", spec.

Miscelleanous Notes

Below are some notes that haven't been integrated in to a section above

Failure Modes

There are three main failure modes to consider:

• Validators with >2/3 INCO voting power go Byzantine.
  • Assuming these validators don't have >2/3 ETH voting power, can we block attack propogation before it reaches
• Validators with >2/3 ETH voting power go Byzantine.
• (Huge price swing, if using price oracle)

References

• https://www.blog.eigenlayer.xyz/dual-staking/

✅⚠️❌