Skip to content

update internal links #216

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
evanorti wants to merge 1 commit into
base: main
Choose a base branch
from
Open

update internal links #216

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions cometbft/v0.38/spec/abci/Outline.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ The first time a new blockchain is started, CometBFT calls `InitChain`. From the
state. During the execution of an instance of consensus, which decides the block for a given
height, and before method `FinalizeBlock` is called, methods `PrepareProposal`, `ProcessProposal`,
`ExtendVote`, and `VerifyVoteExtension` may be called several times. See
[CometBFT's expected behavior](./CometBFTs-expected-behavior.mdx) for details on the possible
[CometBFT's expected behavior](./CometBFTs-expected-behavior) for details on the possible
call sequences of these methods.

- [**InitChain:**](./Methods.mdx#initchain) This method initializes the blockchain.
Expand Down Expand Up @@ -156,7 +156,7 @@ call sequences of these methods.

State sync allows new nodes to rapidly bootstrap by discovering, fetching, and applying
state machine (application) snapshots instead of replaying historical blocks. For more details, see the
[state sync documentation](../p2p/legacy-docs/messages/state-sync.mdx).
[state sync documentation](../p2p/legacy-docs/messages/state-sync).

New nodes discover and request snapshots from other nodes in the P2P network.
A CometBFT node that receives a request for snapshots from a peer will call
Expand All @@ -180,7 +180,7 @@ application with `ApplySnapshotChunk`. When all chunks have been applied, the
Application's `AppHash` is retrieved via an `Info` query.
To ensure that the sync proceeded correctly, CometBFT compares the local Application's `AppHash`
to the `AppHash` stored on the blockchain (verified via
[light client verification](../light-client/verification.mdx)).
[light client verification](../light-client/verification)).

In summary:

Expand Down Expand Up @@ -377,8 +377,8 @@ passed on to the Application through ABCI++. It is the responsibility of the
Application to handle evidence of misbehavior and exercise punishment.

There are two forms of evidence: Duplicate Vote and Light Client Attack. More
information can be found in either [data structures](../core/Data_structures.mdx)
or [accountability](../light-client/Accountability.mdx).
information can be found in either [data structures](../core/Data_structures)
or [accountability](../light-client/Accountability).

EvidenceType has the following protobuf format:

Expand Down
8 changes: 4 additions & 4 deletions cometbft/v0.38/spec/core/Data_structures.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -123,7 +123,7 @@ the data in the current block, the previous block, and the results returned by t
| Version | [Version](#version) | Version defines the application and block versions being used. | Must adhere to the validation rules of [Version](#version) |
| ChainID | String | ChainID is the ID of the chain. This must be unique to your chain. | ChainID must be less than 50 bytes. |
| Height | uint64 | Height is the height for this header. | Must be > 0, >= initialHeight, and == previous Height+1 |
| Time | [Time](#time) | The timestamp is equal to the weighted median of validators present in the last commit. Read more on time in the [BFT-time section](../consensus/BFT-Time.mdx). Note: the timestamp of a vote must be greater by at least one millisecond than that of the block being voted on. | Time must be >= previous header timestamp + consensus parameters TimeIotaMs. The timestamp of the first block must be equal to the genesis time (since there's no votes to compute the median). |
| Time | [Time](#time) | The timestamp is equal to the weighted median of validators present in the last commit. Read more on time in the [BFT-time section](../consensus/BFT-Time). Note: the timestamp of a vote must be greater by at least one millisecond than that of the block being voted on. | Time must be >= previous header timestamp + consensus parameters TimeIotaMs. The timestamp of the first block must be equal to the genesis time (since there's no votes to compute the median). |
| LastBlockID | [BlockID](#blockid) | BlockID of the previous block. | Must adhere to the validation rules of [blockID](#blockid). The first block has `block.Header.LastBlockID == BlockID{}`. |
| LastCommitHash | slice of bytes (`[]byte`) | MerkleRoot of the lastCommit's signatures. The signatures represent the validators that committed to the last block. The first block has an empty slices of bytes for the hash. | Must be of length 32 |
| DataHash | slice of bytes (`[]byte`) | MerkleRoot of the hash of transactions. **Note**: The transactions are hashed before being included in the merkle tree, the leaves of the Merkle tree are the hashes, not the transactions themselves. | Must be of length 32 |
Expand Down Expand Up @@ -373,7 +373,7 @@ EvidenceList is a simple wrapper for a list of evidence:

Evidence in CometBFT is used to indicate breaches in the consensus by a validator.

More information on how evidence works in CometBFT can be found [here](../consensus/Evidence.mdx)
More information on how evidence works in CometBFT can be found [here](../consensus/Evidence)

### DuplicateVoteEvidence

Expand Down Expand Up @@ -405,11 +405,11 @@ and Amnesia. These attacks are exhaustive. You can find a more detailed overview

## LightBlock

LightBlock is the core data structure of the [light client](../light-client/Light-Client-Specification.mdx). It combines two data structures needed for verification ([signedHeader](#signedheader) & [validatorSet](#validatorset)).
LightBlock is the core data structure of the [light client](../light-client/Light-Client-Specification). It combines two data structures needed for verification ([signedHeader](#signedheader) & [validatorSet](#validatorset)).

| Name | Type | Description | Validation |
|--------------|-------------------------------|----------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------|
| SignedHeader | [SignedHeader](#signedheader) | The header and commit, these are used for verification purposes. To find out more visit [light client docs](../light-client/Light-Client-Specification.mdx) | Must not be nil and adhere to the validation rules of [signedHeader](#signedheader) |
| SignedHeader | [SignedHeader](#signedheader) | The header and commit, these are used for verification purposes. To find out more visit [light client docs](../light-client/Light-Client-Specification) | Must not be nil and adhere to the validation rules of [signedHeader](#signedheader) |
| ValidatorSet | [ValidatorSet](#validatorset) | The validatorSet is used to help with verify that the validators in that committed the infraction were truly in the validator set. | Must not be nil and adhere to the validation rules of [validatorSet](#validatorset) |

The `SignedHeader` and `ValidatorSet` are linked by the hash of the validator set(`SignedHeader.ValidatorsHash == ValidatorSet.Hash()`.
Expand Down
4 changes: 2 additions & 2 deletions cometbft/v0.38/spec/light-client/verification.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ Given a known bound `TRUSTED_PERIOD`, and a block `b` with header `h` generated
in `validators(b.Header.NextValidatorsHash)` is correct until time `b.Header.Time + TRUSTED_PERIOD`.

*Assumption*: "correct" is defined w.r.t. realtime (some Newtonian global notion of time, i.e., wall time),
while `Header.Time` corresponds to the [BFT time](../consensus/BFT-Time.mdx). In this note, we assume that clocks of correct processes
while `Header.Time` corresponds to the [BFT time](../consensus/BFT-Time). In this note, we assume that clocks of correct processes
are synchronized (for example using NTP), and therefore there is bounded clock drift (`CLOCK_DRIFT`) between local clocks and
BFT time. More precisely, for every correct light client process and every `header.Time` (i.e. BFT Time, for a header correctly
generated by the Tendermint consensus), the following inequality holds: `Header.Time < now + CLOCK_DRIFT`,
Expand All @@ -47,7 +47,7 @@ Mechanisms like `fork accountability` and `evidence submission` are defined in t
they incentivize validators to follow the protocol specification defined in this document. If they don't,
and we have 1/3 (or more) faulty validators, safety may be violated. Our approach then is
to *detect* these cases (after the fact), and take suitable repair actions (automatic and social).
This is discussed in document on [Fork accountability](./Accountability.mdx).
This is discussed in document on [Fork accountability](./Accountability).

The term "trusted" above indicates that the correctness of the protocol depends on
this assumption. It is in the responsibility of the user that runs the light client to make sure that the risk
Expand Down
32 changes: 16 additions & 16 deletions evm/next/api-reference/ethereum-json-rpc/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ More on Ethereum JSON-RPC:
* All `trace_*` methods - Parity/OpenEthereum trace namespace
* All `engine_*` methods - Post-merge Engine API

See the [methods page](./methods) for complete details.
See the [methods page](/evm/next/api-reference/ethereum-json-rpc/methods) for complete details.
</Warning>

## Enabling the JSON-RPC Server
Expand Down Expand Up @@ -119,19 +119,19 @@ Response:
### Namespaces supported on Cosmos EVM

<Info>
See the [methods](./methods) page for an exhaustive list and working examples.
See the [methods](/evm/next/api-reference/ethereum-json-rpc/methods) page for an exhaustive list and working examples.
</Info>

| Namespace | Description | Supported | Enabled by Default |
|-----------|-------------|-----------|-------------------|
| [`eth`](./methods#eth-methods) | Core Ethereum JSON-RPC methods for interacting with the EVM | Y | Y |
| [`web3`](./methods#web3-methods) | Utility functions for the web3 client | Y | Y |
| [`net`](./methods#net-methods) | Network information about the node | Y | Y |
| [`txpool`](./methods#txpool-methods) | Transaction pool inspection | Y | N |
| [`debug`](./methods#debug-methods) | Debugging and tracing functionality | Y | N |
| [`personal`](./methods#personal-methods) | Private key management | Y | N |
| [`admin`](./methods#admin-methods) | Node administration | Y | N |
| [`miner`](./methods#miner-methods) | Mining operations (stub for PoS) | Y | N |
| [`eth`](/evm/next/api-reference/ethereum-json-rpc/methods#eth-methods) | Core Ethereum JSON-RPC methods for interacting with the EVM | Y | Y |
| [`web3`](/evm/next/api-reference/ethereum-json-rpc/methods#web3-methods) | Utility functions for the web3 client | Y | Y |
| [`net`](/evm/next/api-reference/ethereum-json-rpc/methods#net-methods) | Network information about the node | Y | Y |
| [`txpool`](/evm/next/api-reference/ethereum-json-rpc/methods#txpool-methods) | Transaction pool inspection | Y | N |
| [`debug`](/evm/next/api-reference/ethereum-json-rpc/methods#debug-methods) | Debugging and tracing functionality | Y | N |
| [`personal`](/evm/next/api-reference/ethereum-json-rpc/methods#personal-methods) | Private key management | Y | N |
| [`admin`](/evm/next/api-reference/ethereum-json-rpc/methods#admin-methods) | Node administration | Y | N |
| [`miner`](/evm/next/api-reference/ethereum-json-rpc/methods#miner-methods) | Mining operations (stub for PoS) | Y | N |
| `clique` | Proof-of-Authority consensus | N | N |
| `les` | Light Ethereum Subprotocol | N | N |

Expand All @@ -143,7 +143,7 @@ See the [methods](./methods) page for an exhaustive list and working examples.

### Filters[​](#filters "Direct link to Filters")

Cosmos EVM also supports the Ethereum [JSON-RPC](./methods) filters calls to subscribe to [state logs](https://eth.wiki/json-rpc/API#eth_newfilter), [blocks](https://eth.wiki/json-rpc/API#eth_newblockfilter) or [pending transactions](https://eth.wiki/json-rpc/API#eth_newpendingtransactionfilter) changes.
Cosmos EVM also supports the Ethereum [JSON-RPC](/evm/next/api-reference/ethereum-json-rpc/methods) filters calls to subscribe to [state logs](https://eth.wiki/json-rpc/API#eth_newfilter), [blocks](https://eth.wiki/json-rpc/API#eth_newblockfilter) or [pending transactions](https://eth.wiki/json-rpc/API#eth_newpendingtransactionfilter) changes.

Under the hood, it uses the CometBFT RPC client's event system to process subscriptions that are then formatted to Ethereum-compatible events.

Expand Down Expand Up @@ -258,11 +258,11 @@ Examples:
Several methods that query the state of the EVM accept a default block parameter. This allows you to specify the block height at which to perform the query.

Methods supporting block parameter:
* [`eth_getBalance`](./methods#eth_getbalance)
* [`eth_getCode`](./methods#eth_getcode)
* [`eth_getTransactionCount`](./methods#eth_gettransactioncount)
* [`eth_getStorageAt`](./methods#eth_getstorageat)
* [`eth_call`](./methods#eth_call)
* [`eth_getBalance`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_getbalance)
* [`eth_getCode`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_getcode)
* [`eth_getTransactionCount`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_gettransactioncount)
* [`eth_getStorageAt`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_getstorageat)
* [`eth_call`](/evm/next/api-reference/ethereum-json-rpc/methods#eth_call)

The possible values for the `defaultBlock` parameter:
* **Hex String** - A specific block number (e.g., `0xC9B3C0`)
Expand Down
2 changes: 1 addition & 1 deletion evm/next/documentation/concepts/pending-state.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -148,4 +148,4 @@ const fasterTx = await wallet.sendTransaction({
For a detailed understanding of how the pending state is managed:
- See [Mempool Architecture](/evm/next/documentation/concepts/mempool#architecture) for the two-tier system design
- Review [Transaction Flow](/evm/next/documentation/concepts/mempool#transaction-flow) for state transitions
- Check [Integration Guide](/evm/next/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration.mdx) for implementation details
- Check [Integration Guide](/evm/next/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration) for implementation details
2 changes: 1 addition & 1 deletion evm/next/documentation/concepts/predeployed-contracts.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,7 +106,7 @@ For comprehensive information on each contract including usage examples and inte
## Related Concepts

- [Precompiles](/evm/next/documentation/smart-contracts/precompiles/overview) - Native chain implementations exposed as smart contracts
- [VM Module](evm/next/documentation/cosmos-sdk/modules/vm) - Core EVM module configuration including preinstalls
- [VM Module](/evm/next/documentation/cosmos-sdk/modules/vm) - Core EVM module configuration including preinstalls
- [Building Your Chain](/evm/next/documentation/getting-started/build-a-chain/overview) - Complete guide to chain setup

## Implementation Guides
Expand Down
2 changes: 1 addition & 1 deletion evm/next/documentation/concepts/replay-protection.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -162,4 +162,4 @@ grep allow-unprotected-txs $HOME/.evmd/config/config.toml
- [EIP-155 Specification](https://eips.ethereum.org/EIPS/eip-155)
- [Chain ID Configuration](/evm/next/documentation/concepts/chain-id)
- [Transaction Types](/evm/next/documentation/concepts/transactions#ethereum-tx-type)
- [EVM Module Parameters](evm/next/documentation/cosmos-sdk/modules/vm#parameters)
- [EVM Module Parameters](/evm/next/documentation/cosmos-sdk/modules/vm#parameters)
2 changes: 1 addition & 1 deletion evm/next/documentation/cosmos-sdk/modules/erc20.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -523,7 +523,7 @@ evmd tx erc20 register-coin <denom> --from mykey
## Related Documentation

- [Building Your Chain Guide](/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough
- [VM Module](evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration
- [VM Module](/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration
- [IBC Module](/evm/next/documentation/cosmos-sdk/modules/ibc) - IBC token handling

---
Expand Down
2 changes: 1 addition & 1 deletion evm/next/documentation/cosmos-sdk/modules/feemarket.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -848,7 +848,7 @@ evmd tx gov submit-proposal param-change proposal.json --from validator --chain-
## Related Documentation

- [Building Your Chain Guide](/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough
- [VM Module](evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration
- [VM Module](/evm/next/documentation/cosmos-sdk/modules/vm) - EVM configuration
- [EIP-1559 Specification](https://eips.ethereum.org/EIPS/eip-1559) - Original Ethereum proposal

---
Expand Down
2 changes: 1 addition & 1 deletion evm/next/documentation/cosmos-sdk/modules/precisebank.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -641,7 +641,7 @@ REMAINDER=$(evmd query precisebank remainder -o json | jq -r '.remainder')
## Related Documentation

- [Building Your Chain Guide](/evm/next/documentation/getting-started/build-a-chain/overview) - Main configuration walkthrough
- [VM Module](evm/next/documentation/cosmos-sdk/modules/vm) - extended_denom_options setup
- [VM Module](/evm/next/documentation/cosmos-sdk/modules/vm) - extended_denom_options setup
- [ERC20 Module](/evm/next/documentation/cosmos-sdk/modules/erc20) - Token pair configuration

---
Expand Down
2 changes: 1 addition & 1 deletion evm/next/documentation/cosmos-sdk/protocol.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ Cosmos EVM enables EVM compatibility by implementing various components that tog
* `StateDB` interface for state updates and queries
* [JSON-RPC](/evm/next/api-reference/ethereum-json-rpc) client for interacting with the EVM

Most components are implemented in the [VM module](evm/next/documentation/cosmos-sdk/modules/vm). However, to achieve a seamless developer experience, some components are implemented outside of the module.
Most components are implemented in the [VM module](/evm/next/documentation/cosmos-sdk/modules/vm). However, to achieve a seamless developer experience, some components are implemented outside of the module.

To learn more about how Cosmos EVM achieves EVM compatibility as a Cosmos chain, explore the following concepts:

Expand Down
Loading