# 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](https://www.blog.eigenlayer.xyz/dual-staking/) 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
4. 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](https://excalidraw.com/#room=4dbff06b26c55b104180,oSfIg2v4tLtaKk2xDjm-qA)._)

#### 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](https://drive.google.com/file/d/1nKt72DfKQv8RzoBzJHuhWHNojlt66aIx/view).

#### 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.
</details>

### Design #2: Modular Dual Staking (Abandoned)
### Design #3: Finality Dual Staking (Abandoned)

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

Rely on [Ethos](https://ethosstake.com/introduction-to-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
3. Bridging
we don't know
5. How easy to recruit ETH security TVL?
rs>mesh>self-sovereign
7. How easy to recruit inco validators?
rs>self-sovereign
9. How easy to build?
rs>mesh>self-sovereign

## Listening to Voting Power

<details>
<summary>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.</summary>
<br/>
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](https://github.com/skip-mev/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`](https://github.com/skip-mev/slinky/blob/main/abci/preblock/oracle/README.md)).

See [Slinky's documentation](https://skip-protocol.notion.site/Slinky-f803571ffa354549b07d684401be04be).

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](https://www.zetachain.com/docs/architecture/modules/crosschain/overview/#voting))
- Gravity Bridge (e.g. Sommelier, [code](https://github.com/PeggyJV/gravity-bridge/blob/8a21caf22eabccf0383e594783ee23c58eeb6e3c/module/x/gravity/keeper/msg_server.go#L173))

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]((https://github.com/osmosis-labs/mesh-security/tree/main/docs))/RS, IBC)

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

## 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](https://docs.cometbft.com/v0.38/spec/light-client/#attack-detection), 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
<details>
<summary>Additional misbehaviors if we use Self-Sovereign dual staking</summary>

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.
</details>

<br />

||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](https://github.com/celestiaorg/celestia-app/tree/main/x/blobstream)|[docs](https://www.zetachain.com/docs/architecture/overview/), [whitepaper](https://www.zetachain.com/whitepaper.pdf)|[cgp-spec](https://github.com/axelarnetwork/cgp-spec)|[design](https://github.com/Gravity-Bridge/Gravity-Bridge/blob/main/docs/design/overview.md)|[notion](https://skip-protocol.notion.site/Slinky-f803571ffa354549b07d684401be04be?pvs=74)|[blog](https://namada.net/blog/the-namada-ethereum-bridge)|
|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](https://etherscan.io/tx/0xc81fe8f48b02ac1c65895512a1aee72c1d61d83396883d0e92c992799ecad1b1)||[link](https://etherscan.io/tx/0x30edcf523efec2bbcbd7bad40090b5857440956f3851dbc32d821f79a95edfa6) (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](https://docs.axelar.dev/learn#validators).
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](https://www.zetachain.com/docs/architecture/overview/#observers).
3. "Full Node - This is an Ethereum Full Node run by an Operator", [spec](https://github.com/Gravity-Bridge/Gravity-Bridge/blob/main/docs/design/overview.md#definitions).
4. See [`Gravity.sol`](https://github.com/Gravity-Bridge/Gravity-Bridge/blob/main/solidity/contracts/Gravity.sol#L69-L83).
5. See [`Blobstream.sol`](https://github.com/celestiaorg/blobstream-contracts/blob/048a12d35408834c332c406eb64e8a7a0d277344/src/Blobstream.sol#L49-L56). They are also called `Valset` and `Data commitment` attestations [in the spec](https://github.com/celestiaorg/celestia-app/tree/main/x/blobstream).
6. GRAVSLASH-04 and GRAVSLASH-05, [spec](https://github.com/Gravity-Bridge/Gravity-Bridge/blob/main/spec/slashing-spec.md#gravslash-04-submitting-incorrect-eth-oracle-claim---intentionally-not-implemented).
7. "AxelarAuthWeighted: The authentication contract . It allows the sender to specify a list of validators and the corresponding weights," [blog post](https://github.com/axelarnetwork/cgp-spec/tree/main/solidity).
8. "Namada validators will run Ethereum full nodes", [source](https://namada.net/blog/the-namada-ethereum-bridge#direct-integration-into-namada).
9. See [`Bridge.sol`](https://github.com/anoma/ethereum-bridge/blob/main/src/Bridge.sol#L21C49-L22).
10. See [`ZetaConnector.base.sol`](https://github.com/zeta-chain/protocol-contracts/blob/main/contracts/evm/ZetaConnector.base.sol#L27).
11. See "Observers Active and Passive mode" in [whitepaper](https://www.zetachain.com/whitepaper.pdf).
12. See tx lifecycle p17 in [whitepaper](https://www.zetachain.com/whitepaper.pdf).
13. "The role of the orchestrator is to sign attestations using its corresponding validator EVM private key", [spec](https://github.com/celestiaorg/orchestrator-relayer/blob/main/docs/orchestrator.md).

## 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/

✅⚠️❌