diff --git a/docs/getting-started/system-requirements.md b/docs/getting-started/system-requirements.md index 542cfe76679..fbb13d0dbeb 100644 --- a/docs/getting-started/system-requirements.md +++ b/docs/getting-started/system-requirements.md @@ -1,7 +1,15 @@ # System requirements -The Gaia application typically needs at least 32GB RAM for smooth operation. + + +## Gaia Upgrades + +The Gaia application typically needs at least 32GB RAM, for smooth operation for upgrade, as there may be lenghty migrations to perform. If you have less than 32GB RAM, you might try creating a swapfile to swap an idle program onto the hard disk to free up memory. This can allow your machine to run the binary than it could run in RAM alone. diff --git a/docs/gtm-interchain.md b/docs/gtm-interchain.md deleted file mode 100644 index 2c52ecfc44b..00000000000 --- a/docs/gtm-interchain.md +++ /dev/null @@ -1,75 +0,0 @@ -**Introduction** - -IBC and Hub go-to-market is a complex organizational, developmental, and marketing undertaking that involves many entities, software projects, and services. IBC is also intimately bound up to the roadmap, development, and go-to-market of Gaia. Though it is possible to bring IBC to market without Gaia, Gaia should be the primary vehicle and product we are concerned with, since the value of Gaia stems from the utility it brings to the ecosystem of chains connected to and benefiting from its position as a Hub. Thus, this plan will consider go-to-market needs for IBC and Gaia simultaneously. The roadmap will be designed to ensure that IBC is valuable to the Hub and its users, including the many interconnected sovereign blockchains that derive utility from the Hub. - -The IBC and Gaia go-to-market initiatives will be about direct engagement with the products that directly validate the utility of the Hub and IBC. This initiative encompasses the utility of various interoperable and cross-chain Cosmos entities such as application-specific blockchains, Bridges, Relayers, Validators, etc. More importantly, we envision that the market will quickly grasp the meaning and relevance of cross-chain interoperability of which Cosmos is a leading contender. -This is an evolving document and process. Please feel free to contribute where you think something is missing or could be improved! -**How we work** - -These discussions will take place during weekly Gaia team calls. The Hub will determine the value proposition of IBC and how it is integrated into Gaia and how it will serve the larger ecosystem of interconnected blockchains. These discussions will continue to take place with key stakeholders during the bi-weekly Cosmos multi entity call. Importantly, the purpose of the bi-weekly multi entity call will be to consider all technical aspects of IBC launch from a strategic perspective (outlined in 'What's Needed to Successfully Go to Market?'). This will inform the agenda. - -Leading up to Stargate, IBC Development was led by Chris Goes (Interchain Berlin), while Gaia did not have a maintainer. Go-to-market for Stargate was led by Zaki (Iqlusion). Moving forward, we are aiming to organize Cosmos Hub leadership under Shahan Khatchadourian (Interchain Berlin) and go-to-market led by Jelena Djuric (Informal Systems). Both Shahan and Jelena are being onboarded into these roles with the support of previous leads. - -Execution and completion will be tracked via a meta-project dashboard ([Gaia Roadmap](https://github.com/cosmos/gaia/projects/6)) that incorporates the high level objectives for each phase roll out. Each phase (i.e. Phase 1 - Accounts UX, Phase 2 - Interchain Interchange, etc) will have their own project dashboard that will link to the repos, issues, PRs, etc, where development is taking place. - -"_Never doubt that a small group of thoughtful, committed, citizens can change the world. Indeed, it is the only thing that ever has." - Margaret Mead_ - -**What's Needed to Successfully Go to Market?** - -1. **Project management** - -In sum, project management will focus on surfacing issues, dependencies, relative roadmaps, and coordinating across all stakeholders. Questions that will be considered throughout each phase of the Gaia roadmap: - -- What is missing from an integration points perspective with end users? - -- Which relationships are missing? -- What's the highest priority? Least priority? - -2. **Market validation** - -The user is paramount. For Gaia and IBC, we see the users being: - -- ATOM holders -- Existing zones -- New zones -- Validators on hub and zones -- Nodes on hub and zones -- Other service providers on hubs and zones (wallets, explorers, exchanges, etc.) - -We will also want to be tracking outreach to the relevant users per phase to ensure that Hub utility (and IBC where appropriate) are being validated. Spotlights on experiments will continue to validate the utility of the Hub and IBC (i.e. bridge to Ethereum, AMM, etc). We will also be conducting continuous outbound outreach to look for partners that are aligned with the interchain mission. - -3. **Communications** - -Communications should focus on the features of IBC and the Hub that demonstrate the most utility for users. Stories should answer questions such as: - -- How does IBC relate to ATOM and the Hub? -- How does IBC derive its value from the Hub, and vice versa? -- Why should you build your blockchain with IBC? -- How does a blockchain benefit from connecting to the Hub? - -4. **Technical Support** - -We will need technical support for users depending on the phase that is being rolled out. A phase rollout is not complete without proper technical support. - -Further, we will need technical support that goes beyond the different phase rollouts. Importantly, to create an IBC connected blockchain developers will need the following things: - -- A value proposition - - - A State Machine: - - Built on Cosmos SDK - - ABCI - - Cosmos-rs.. etc - - Security: - - Cross chain Validation - - Validator set formation - - Community - - Discoverability Opportunities - - Connectivity - - Visibility - - Wallet, Block Explorer, etc - -5. **METRICS: How do we know when IBC is succeeding? How do we know when Hub is providing value to an interconnected ecosystem of sovereign blockchains?** - -The go-to-market team should be tracking the extent to which IBC is succeeding or failing in terms of key metrics. This will require continuous experimentation and coordination between entities. An example of a metric that best represents IBC go to market would be # of distinct IBC connections that transport x amount of value. To get to these metrics we need the developer resources and proven business models that encourage developers to use this technology. - -The Cosmos-SDK exposes some [existing metrics for IBC](https://docs.cosmos.network/v0.45/core/telemetry.html#supported-metrics). diff --git a/docs/interchain-security/README.md b/docs/interchain-security/README.md new file mode 100644 index 00000000000..b0964862426 --- /dev/null +++ b/docs/interchain-security/README.md @@ -0,0 +1,11 @@ +--- +order: false +parent: + order: 2 +--- + +# Interchain Security + +This folder contains an overview of Interchain Security, one of the core features of the Cosmos Hub. + +- [Interchain Security](./interchain-security.md) diff --git a/docs/interchain-security/interchain-security.md b/docs/interchain-security/interchain-security.md new file mode 100644 index 00000000000..ed40831a31b --- /dev/null +++ b/docs/interchain-security/interchain-security.md @@ -0,0 +1,22 @@ +--- +order: 5 +title: Introduction to Interchain Security +--- + +# Interchain Security + +The Interchain Security feature, brings to the Cosmos Hub a shared security model, where the Cosmos Hub validators, also validate on consumer chains. This is valuable for consumer chains, as consumer chains can focus on product-market fit, rather than business and operational agreements in bringing together a validator set. As part of this agreement, consumer chains pay for the security by distributing a portion of the consumer chain revenue to Hub token holders. + +All potential chains are onboarded as consumer chains, via Hub Governance, with the feedback from the Hub community. + +Currently the Cosmos Hub has the following two Consumer Chains. + +## Neutron + +[Neutron](https://neutron.org/), is a smart contracting platform, that was the first consumer chain onboarded. +Neutron was onboarded as a consumer chain in May 2023, see Hub [proposal 792](https://www.mintscan.io/cosmos/proposals/792) for more details. + +## Stride + +[Stride](https://www.stride.zone/), is a liquid staking provider, which aims to unlock liquidity for Cosmos Hub token holders. +Stride was onboarded as a consumer chain in July 2023, see Hub [proposal 799](https://www.mintscan.io/cosmos/proposals/799) for more details. diff --git a/docs/migration/cosmoshub-4-v14-upgrade.md b/docs/migration/cosmoshub-4-v14-upgrade.md index f0e898cdf79..0af35468ac3 100644 --- a/docs/migration/cosmoshub-4-v14-upgrade.md +++ b/docs/migration/cosmoshub-4-v14-upgrade.md @@ -5,10 +5,12 @@ order: 8 # Cosmos Hub 4, Gaia v14 Upgrade, Instructions -This document describes the steps for validators and full node operators, to upgrade successfully to the Gaia v14 release. +This document describes the steps for validators, full node operators and relayer operators, to upgrade successfully for the Gaia v14 release. For more details on the release, please see the [release notes](https://github.com/cosmos/gaia/releases/tag/v14.1.0) +**Relayer Operators** for the Cosmos Hub and consumer chains, will also need to update to use [Hermes 1.7.3](https://github.com/informalsystems/hermes/releases/tag/v1.7.3) or higher, see [Relayer Operations](#relayer-operations) or more details. + ## Release Binary > Please note that the **v14.0.0** binary is depreceated and **ALL** validators **MUST** use the **v14.1.0** binary instead. @@ -38,6 +40,7 @@ For more details on the release, please see the [release notes](https://github.c - [Rollback plan](#rollback-plan) - [Communications](#communications) - [Risks](#risks) + - [Relayer Operations](#relayer-operations) - [Reference](#reference) ## On-chain governance proposal attains consensus @@ -203,6 +206,38 @@ As a validator performing the upgrade procedure on your consensus nodes carries The riskiest thing a validator can do is discover that they made a mistake and repeat the upgrade procedure again during the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start before correcting it. +## Relayer Operations + +The Gaia `v14.1.0` upgrade brings forth the cryptographic verification of equivocation feature from ICS `v2.4.0-lsm`. This important security enhancement empowers external agents to promptly submit evidence evidence of light client and double signing attacks observed on a consumer chain. Operators can seize the control of this feature using either the dedicated ICS CLI commands or unleash the power of the Hermes IBC relayer in “evidence” mode. + +This feature is supported by an updated [Hermes v1.7.3](https://github.com/informalsystems/hermes/releases/tag/v1.7.3). + +### **1. Hermes “evidence” mode** + +Ensure you have a well-configured Hermes `v1.7.3+` relayer effectively relaying packets between a consumer and a provider chain. The following command demonstrates how to run a Hermes instance in “evidence” mode to detect misbehaviors on a consumer chain. + +```sh +hermes evidence --chain +``` + +**Tip**: this command takes a `--check-past-blocks` option giving the possibility to look for older evidences (default is `100`). + +### **2. ICS CLI** + +The ICS provider module offers two commands for submitting evidence of misbehavior originating from a consumer chain. Here are two examples illustrating the process: + +To submit evidence of a double-vote: + +```sh +gaiad tx provider submit-consumer-double-voting [path/to/evidence.json] [path/to/infraction_header.json] --from node0 --home ../node0 --chain-id $CID +``` + +And for a light client attack: + +```sh +gaiad tx provider submit-consumer-misbehaviour [path/to/misbehaviour.json] --from node0 --home ../node0 --chain-id $CID +``` + ## Reference [Join Cosmos Hub Mainnet](https://github.com/cosmos/mainnet)