启动阶段（0）
在启动时，IBC Eureka 将部署在两条区块链上：Ethereum 和 Cosmos Hub 主网。在 Cosmos Hub 一侧，安全属性与 IBC Classic 保持一致，即治理对链、轻客户端和通道拥有最终控制权。 而在 Ethereum 主网一侧，情况则不同：安全委员会将控制合约升级能力、暂停功能以及轻客户端升级。安全委员会
Eureka 安全委员会被设定为一个 7 人中 5 人签署通过的委员会，可以执行如下操作：- 升级
ICS20Transfer、ICS26Router、IBCERC20和Escrow合约 - 在因作恶行为、过期或安全漏洞/事件导致冻结时迁移轻客户端
- 为 Ethereum 主网上的 IBC 应用和轻客户端指定特定的规范名称
TimelockController 合约进行时间锁控制，最短延迟为三天。该延迟为 Cosmos Hub 提供了一个机会窗口，以便在安全委员会采取恶意操作时暂停入站/出站转账。
安全委员会由来自以太坊和 Cosmos 社区中备受尊重且值得信赖的实体相关人员组成：
- Wildcat Finance
- Informal
- Hypha
- ZK Validator
- Chorus One
- Keplr
- Interchain Labs
暂停委员会
暂停委员会用于对安全事件进行快速响应。暂停委员会唯一可以执行的操作，是暂停和恢复从 Ethereum 侧合约发出的转账。 该委员会由安全委员会中的一部分成员组成，他们将快速响应与规范 IBC Eureka 部署相关的安全事件。为了实现快速响应，暂停委员会的操作不受时间锁限制。治理阶段（1）
在协议成功启动后，IBC Eureka 路线图的下一步是允许链与链之间进行通用合约消息传递。 这将使规范 EVM Eureka 部署能够由 Cosmos Hub 治理进行控制。因此，安全委员会将把TimelockController 的最短延迟提高到超过 Cosmos Hub 通过一项治理提案所需的时间。
这意味着安全委员会将更接近于被淘汰，同时允许 Cosmos Hub 覆盖安全委员会所采取的操作。
暂停阶段（2）
在允许 Cosmos Hub 治理规范 Eureka 部署经过一段试运行期后，安全委员会将撤销其对规范部署的权限和控制，完全由 Cosmos Hub 接管其职责。Depending on where it is deployed, IBC Eureka might have different security properties compared to the ones in IBC Classic. This is mainly because EVM chains do not have any form of governance, whereas Cosmos chains do. To improve protocol and fund safety at launch, IBC Eureka is going to launch in stages, delineated by improved security properties at each stage.
Launch stage (0)
At launch, IBC Eureka is going to be deployed on two blockchains: Ethereum and Cosmos Hub mainnet. On the Cosmos Hub side, the security properties remain the same as in IBC Classic - governance has ultimate control over the chain, light client and channels. On the Ethereum mainnet side, it is different - a security council will have control over contract upgradeability, pausing and light client upgrades.Security council
The Eureka Security Council is designated as a 5-of-7 council that can take actions such as:- upgrading the
ICS20Transfer,ICS26Router,IBCERC20andEscrowcontracts - migrating light clients in case of freezing due to misbehaviour, expiration or security vulnerabilities/incidents
- designating specific canonical names for IBC applications and light clients on Ethereum mainnet
TimelockController contract with a minimum
delay of three days. The delay gives an opportunity for the Cosmos Hub to halt inbound / outbound transfers in case of a malicious action taken by the Security Council.
The security council is composed of individuals associated with well-respected and trusted entities in the Ethereum and Cosmos communities:
- Wildcat Finance
- Informal
- Hypha
- ZK Validator
- Chorus One
- Keplr
- Interchain Labs
Pausing council
The pausing council is designated for rapid-response to a security incident. The only actions that the pausing council can take are pausing and unpausing transfers out of the Ethereum-side contracts. The council is composed of a subset of people in the Security Council who are going to be rapidly responding to security incidents related to canonical IBC Eureka deployments. The actions of the pausing council are not time-locked to allow for a quick response time.Governance stage (1)
After the protocol has successfully launched, the next step in the IBC Eureka roadmap is to allow general contract message passing between chains. This will enable canonical EVM Eureka deployments to be controlled by Cosmos Hub governance. As such, the security council will increase the minimum delay of theTimelockController
to be longer than the time it takes to pass a governance proposal on the Cosmos Hub.
This means that the security council will be much closer to becoming obsolete, while allowing the Cosmos Hub to override actions taken by the security council.