chore: Add lint link check job (#1392)

Signed-off-by: Jonathan Oppenheimer <[email protected]>
Co-authored-by: Austin Larson <[email protected]>

Author: JonathanOppenheimer

.github/CONTRIBUTING.md

@@ -1,53 +1,44 @@
 # Contributing
 
-Thank you for considering to help out with the source code! We welcome 
-contributions from anyone on the internet, and are grateful for even the 
-smallest of fixes!
-
-If you'd like to contribute to coreth, please fork, fix, commit and send a 
-pull request for the maintainers to review and merge into the main code base. If
-you wish to submit more complex changes though, please check up with the core 
-devs first on [Discord](https://chat.avalabs.org) to 
-ensure those changes are in line with the general philosophy of the project 
-and/or get some early feedback which can make both your efforts much lighter as
-well as our review and merge procedures quick and simple.
+Thank you for considering to help out with the source code! We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes!
+
+If you'd like to contribute to coreth, please fork, fix, commit and send a pull request for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check up with the core devs first on [Discord](https://chat.avalabs.org) to ensure those changes are in line with the general philosophy of the project and/or get some early feedback which can make both your efforts much lighter as well as our review and merge procedures quick and simple.
 
 ## Coding guidelines
 
 Please make sure your contributions adhere to our coding guidelines:
 
- * Code must adhere to the official Go 
-[formatting](https://go.dev/doc/effective_go#formatting) guidelines 
-(i.e. uses [gofmt](https://pkg.go.dev/cmd/gofmt)).
- * Code must be documented adhering to the official Go 
-[commentary](https://go.dev/doc/effective_go#commentary) guidelines.
- * Pull requests need to be based on and opened against the `master` branch.
- * Pull reuqests should include a detailed description
- * Commits are required to be signed. See [here](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
- for information on signing commits.
- * Commit messages should be prefixed with the package(s) they modify.
-   * E.g. "eth, rpc: make trace configs optional"
+- Code must adhere to the official Go
+  [formatting](https://go.dev/doc/effective_go#formatting) guidelines
+  (i.e. uses [gofmt](https://pkg.go.dev/cmd/gofmt)).
+- Code must be documented adhering to the official Go
+  [commentary](https://go.dev/doc/effective_go#commentary) guidelines.
+- Pull requests need to be based on and opened against the `master` branch.
+- Pull reuqests should include a detailed description
+- Commits are required to be signed. See the [commit signature verification documentation](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
+  for information on signing commits.
+- Commit messages should be prefixed with the package(s) they modify.
+  - E.g. "eth, rpc: make trace configs optional"
 
 ## Can I have feature X
 
-Before you submit a feature request, please check and make sure that it isn't 
-possible through some other means.
+Before you submit a feature request, please check and make sure that it isn't possible through some other means.
 
 ## Mocks
 
 Mocks are auto-generated using [mockgen](https://pkg.go.dev/go.uber.org/mock/mockgen) and `//go:generate` commands in the code.
 
-* To **re-generate all mocks**, use the command below from the root of the project:
+- To **re-generate all mocks**, use the task below from the root of the project:
 
-    ```sh
-    go generate -run mockgen ./...
-    ```
+  ```sh
+  task generate-mocks
+  ```
 
-* To **add** an interface that needs a corresponding mock generated:
-  * if the file `mocks_generate_test.go` exists in the package where the interface is located, either:
-    * modify its `//go:generate go tool -modfile=tools/go.mod mockgen` to generate a mock for your interface (preferred); or
-    * add another `//go:generate go tool -modfile=tools/go.mod mockgen` to generate a mock for your interface according to specific mock generation settings
-  * if the file `mocks_generate_test.go` does not exist in the package where the interface is located, create it with content (adapt as needed):
+- To **add** an interface that needs a corresponding mock generated:
+  - if the file `mocks_generate_test.go` exists in the package where the interface is located, either:
+    - modify its `//go:generate go tool -modfile=tools/go.mod mockgen` to generate a mock for your interface (preferred); or
+    - add another `//go:generate go tool -modfile=tools/go.mod mockgen` to generate a mock for your interface according to specific mock generation settings
+  - if the file `mocks_generate_test.go` does not exist in the package where the interface is located, create it with content (adapt as needed):
 
     ```go
     // Copyright (C) 2025-2025, Ava Labs, Inc. All rights reserved.
@@ -61,29 +52,32 @@ Mocks are auto-generated using [mockgen](https://pkg.go.dev/go.uber.org/mock/moc
     Notes:
     1. Ideally generate all mocks to `mocks_test.go` for the package you need to use the mocks for and do not export mocks to other packages. This reduces package dependencies, reduces production code pollution and forces to have locally defined narrow interfaces.
     1. Prefer using reflect mode to generate mocks than source mode, unless you need a mock for an unexported interface, which should be rare.
-* To **remove** an interface from having a corresponding mock generated:
+- To **remove** an interface from having a corresponding mock generated:
   1. Edit the `mocks_generate_test.go` file in the directory where the interface is defined
   1. If the `//go:generate` mockgen command line:
-      * generates a mock file for multiple interfaces, remove your interface from the line
-      * generates a mock file only for the interface, remove the entire line. If the file is empty, remove `mocks_generate_test.go` as well.
+      - generates a mock file for multiple interfaces, remove your interface from the line
+      - generates a mock file only for the interface, remove the entire line. If the file is empty, remove `mocks_generate_test.go` as well.
 
 ## Tool Dependencies
 
 This project uses `go tool` to manage development tool dependencies in `tools/go.mod`. This isolates tool dependencies from the main application dependencies and provides consistent, version-locked tools across the team.
 
 ### Managing Tools
 
-* To **add a new tool**:
+- To **add a new tool**:
+
   ```sh
   go get -tool -modfile=tools/go.mod example.com/tool/cmd/toolname@version
   ```
 
-* To **upgrade a tool**:
+- To **upgrade a tool**:
+
   ```sh
   go get -tool -modfile=tools/go.mod example.com/tool/cmd/toolname@newversion
   ```
 
-* To **run a tool manually**:
+- To **run a tool manually**:
+
   ```sh
   go tool -modfile=tools/go.mod toolname [args...]
   ```

.github/ISSUE_TEMPLATE/bug_report.md

@@ -31,4 +31,4 @@ Which OS you used to reveal the bug.
 **Additional context**
 Add any other context about the problem here.
 
-Avalanche Bug Bounty program can be found [here](https://hackenproof.com/avalanche/avalanche-protocol).
+You can submit a bug on the [Avalanche Bug Bounty program page](https://hackenproof.com/avalanche/avalanche-protocol).

.github/pull_request_template.md

@@ -1,3 +1,4 @@
+<!-- markdownlint-disable MD041 -->
 ## Why this should be merged
 
 ## How this works

.github/workflows/ci.yml

@@ -50,6 +50,14 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: ./scripts/run_task.sh check-avalanchego-version
+  links-lint:
+    name: Markdown Links Lint
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: umbrelladocs/action-linkspector@de84085e0f51452a470558693d7d308fbb2fa261 #v1.2.5
+        with:
+          fail_level: any
 
   unit_test:
     name: Golang Unit Tests (${{ matrix.os }})

README.md

@@ -31,11 +31,11 @@ test run, require binary dependencies. One way of making these dependencies avai
 to use a nix shell which will give access to the dependencies expected by the test
 tooling:
 
- - Install [nix](https://nixos.org/). The [determinate systems
-   installer](https://github.com/DeterminateSystems/nix-installer?tab=readme-ov-file#install-nix)
-   is recommended.
- - Use `./scripts/dev_shell.sh` to start a nix shell
- - Execute the dependency-requiring command (e.g. `./scripts/tests.e2e.sh --start-collectors`)
+- Install [nix](https://nixos.org/). The [determinate systems
+  installer](https://github.com/DeterminateSystems/nix-installer?tab=readme-ov-file#install-nix)
+  is recommended.
+- Use `./scripts/dev_shell.sh` to start a nix shell
+- Execute the dependency-requiring command (e.g. `./scripts/tests.e2e.sh --start-collectors`)
 
 This repo also defines a `.envrc` file to configure [devenv](https://direnv.net/). With
 `devenv` and `nix` installed, a shell at the root of the repo will automatically start a nix
@@ -50,13 +50,13 @@ The C-Chain supports the following API namespaces:
 - `txpool`
 - `debug`
 
-Only the `eth` namespace is enabled by default. 
-To enable the other namespaces see the instructions for passing the C-Chain config to AvalancheGo [here.](https://docs.avax.network/nodes/configure/chain-config-flags#enabling-evm-apis)
-Full documentation for the C-Chain's API can be found [here.](https://docs.avax.network/reference/avalanchego/c-chain/api)
+Only the `eth` namespace is enabled by default.
+To enable the other namespaces see the instructions for passing the C-Chain config to AvalancheGo in the [chain-config-flags documentation](https://build.avax.network/docs/nodes/chain-configs/c-chain#api-configuration).
+Full documentation for the C-Chain's API can be found in the [C-Chain API documentation](https://build.avax.network/docs/nodes/chain-configs/c-chain).
 
 ## Compatibility
 
-The C-Chain is compatible with almost all Ethereum tooling, including [Core,](https://docs.avax.network/build/dapp/launch-dapp#through-core) [Metamask,](https://docs.avax.network/build/dapp/launch-dapp#through-metamask) [Remix](https://docs.avax.network/dapps/smart-contract-dev/deploy-with-remix-ide) and [Truffle.](https://docs.avax.network/build/tutorials/smart-contracts/using-truffle-with-the-avalanche-c-chain)
+The C-Chain is compatible with almost all Ethereum tooling, including [Core,](https://docs.avax.network/build/dapp/launch-dapp#through-core) [Metamask,](https://docs.avax.network/build/dapp/launch-dapp#through-metamask) and [Remix](https://docs.avax.network/dapps/smart-contract-dev/deploy-with-remix-ide).
 
 ## Differences Between Avalanche C-Chain and Ethereum
 
@@ -82,15 +82,15 @@ To support these changes, there have been a number of changes to the C-Chain blo
 
 ### Block Body
 
-* `Version`: provides version of the `ExtData` in the block. Currently, this field is always 0.
-* `ExtData`: extra data field within the block body to store atomic transaction bytes.
+- `Version`: provides version of the `ExtData` in the block. Currently, this field is always 0.
+- `ExtData`: extra data field within the block body to store atomic transaction bytes.
 
 ### Block Header
 
-* `ExtDataHash`: the hash of the bytes in the `ExtDataHash` field
-* `BaseFee`: Added by EIP-1559 to represent the base fee of the block (present in Ethereum as of EIP-1559)
-* `ExtDataGasUsed`: amount of gas consumed by the atomic transactions in the block
-* `BlockGasCost`: surcharge for producing a block faster than the target rate
+- `ExtDataHash`: the hash of the bytes in the `ExtDataHash` field
+- `BaseFee`: Added by EIP-1559 to represent the base fee of the block (present in Ethereum as of EIP-1559)
+- `ExtDataGasUsed`: amount of gas consumed by the atomic transactions in the block
+- `BlockGasCost`: surcharge for producing a block faster than the target rate
 
 ## Releasing
 

RELEASES.md

@@ -16,7 +16,6 @@
   - Changed default percentile from 60 to 40
   - This impacts `eth_suggestGasPrice` and `eth_suggestGasTipCap` , `eth_suggestPriceOptions`, `eth_maxPriorityFeePerGas`, `eth_gasPrice` APIs
 
-
 ## [v0.15.3](https://github.com/ava-labs/coreth/releases/tag/v0.15.3)
 
 - Removed legacy warp message handlers in favor of ACP-118 SDK handlers.

SECURITY.md

@@ -5,16 +5,15 @@ responsible disclosures. Valid reports will be eligible for a reward (terms and
 
 ## Reporting a Vulnerability
 
-**Please do not file a public ticket** mentioning the vulnerability. To disclose a vulnerability submit it through our [Bug Bounty Program](https://hackenproof.com/avalanche).
+**Please do not file a public ticket** mentioning the vulnerability. To disclose a vulnerability submit it through our [Bug Bounty Program](https://immunefi.com/bug-bounty/avalabs/information/).
 
 Vulnerabilities must be disclosed to us privately with reasonable time to respond, and avoid compromise of other users and accounts, or loss of funds that are not your own. We do not reward spam or
 social engineering vulnerabilities.
 
 Do not test for or validate any security issues in the live Avalanche networks (Mainnet and Fuji testnet), confirm all exploits in a local private testnet.
 
-Please refer to the [Bug Bounty Page](https://hackenproof.com/avalanche) for the most up-to-date program rules and scope.
+Please refer to the [Bug Bounty Page](https://immunefi.com/bug-bounty/avalabs/information/) for the most up-to-date program rules and scope.
 
 ## Supported Versions
 
 Please use the [most recently released version](https://github.com/ava-labs/coreth/releases/latest) to perform testing and to validate security issues.
-

cmd/simulator/README.md

@@ -24,7 +24,7 @@ To confirm that you built successfully, run the simulator and print the version:
 
 This should give the following output:
 
-```
+```bash
 v0.1.0
 ```
 
@@ -45,7 +45,7 @@ The `--sybil-protection-enabled=false` flag is only suitable for local testing.
 1. Ignore stake weight on the P-Chain and count each connected peer as having a stake weight of 1
 2. Automatically opts in to validate every Subnet
 
-Once you have AvalancheGo running locally, it will be running an HTTP Server on the default port `9650`. This means that the RPC Endpoint for the C-Chain will be http://127.0.0.1:9650/ext/bc/C/rpc and ws://127.0.0.1:9650/ext/bc/C/ws for WebSocket connections.
+Once you have AvalancheGo running locally, it will be running an HTTP Server on the default port `9650`. This means that the RPC Endpoint for the C-Chain will be `http://127.0.0.1:9650/ext/bc/C/rpc` and `ws://127.0.0.1:9650/ext/bc/C/ws` for WebSocket connections.
 
 Now, we can run the simulator command to simulate some load on the local C-Chain for 30s:
 

consensus/dummy/README.md

@@ -12,7 +12,7 @@ The dummy consensus engine is responsible for performing verification on the hea
 
 ## Dynamic Fees
 
-As of Apricot Phase 3, the C-Chain includes a dynamic fee algorithm based off of (EIP-1559)[https://eips.ethereum.org/EIPS/eip-1559]. This introduces a field to the block type called `BaseFee`. The Base Fee sets a minimum gas price for any transaction to be included in the block. For example, a transaction with a gas price of 49 gwei, will be invalid to include in a block with a base fee of 50 gwei.
+As of Apricot Phase 3, the C-Chain includes a dynamic fee algorithm based off of [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). This introduces a field to the block type called `BaseFee`. The Base Fee sets a minimum gas price for any transaction to be included in the block. For example, a transaction with a gas price of 49 gwei, will be invalid to include in a block with a base fee of 50 gwei.
 
 The dynamic fee algorithm aims to adjust the base fee to handle network congestion. Coreth sets a target utilization on the network, and the dynamic fee algorithm adjusts the base fee accordingly. If the network operates above the target utilization, the dynamic fee algorithm will increase the base fee to make utilizing the network more expensive and bring overall utilization down. If the network operates below the target utilization, the dynamic fee algorithm will decrease the base fee to make it cheaper to use the network.
 
@@ -30,4 +30,4 @@ The FinalizeAndAssemble callback is used as the final step in building a block w
 
 ### Finalize
 
-Finalize is called as the final step in processing a block [here](../../core/state_processor.go). Finalize adds a callback function in order to process atomic transactions as well. Since either Finalize or FinalizeAndAssemble are called, but not both, when building or verifying/processing a block they need to perform the exact same processing/verification step to ensure that a block produced by the miner where FinalizeAndAssemble is called will be processed and verified in the same way when Finalize gets called.
+Finalize is called as the final step in processing a block in [state_processor.go](../../core/state_processor.go). Finalize adds a callback function in order to process atomic transactions as well. Since either Finalize or FinalizeAndAssemble are called, but not both, when building or verifying/processing a block they need to perform the exact same processing/verification step to ensure that a block produced by the miner where FinalizeAndAssemble is called will be processed and verified in the same way when Finalize gets called.

core/README.md

@@ -6,7 +6,7 @@ The core package maintains the backend for the blockchain, transaction pool, and
 
 The [BlockChain](./blockchain.go) struct handles the insertion of blocks into the maintained chain. It maintains a "canonical chain", which is essentially the preferred chain (the chain that ends with the block preferred by the AvalancheGo consensus engine).
 
-When the consensus engine verifies blocks as they are ready to be issued into consensus, it calls `Verify()` on the ChainVM Block interface implemented [here](../plugin/evm/block.go). This calls `InsertBlockManual` on the BlockChain struct implemented in this package, which is the first entrypoint of a block into the blockchain.
+When the consensus engine verifies blocks as they are ready to be issued into consensus, it calls `Verify()` on the ChainVM Block interface implemented in [wrapped_block.go](../plugin/evm/wrapped_block.go). This calls `InsertBlockManual` on the BlockChain struct implemented in this package, which is the first entrypoint of a block into the blockchain.
 
 InsertBlockManual verifies the block, inserts it into the state manager to track the merkle trie for the block, and adds it to the canonical chain if it extends the currently preferred chain.
 
@@ -20,7 +20,7 @@ The transaction pool maintains the set of transactions that need to be issued in
 
 ## State Manager
 
-The State Manager manages the [TrieDB](../trie/database.go). The TrieDB tracks a merkle forest of all of the merkle tries for the last accepted block and processing blocks. When a block is processed, the state transition results in a new merkle trie added to the merkle forest. The State Manager can operate in either archival or pruning mode.
+The State Manager manages references to state roots in the TrieDB implementations (see [`triedb`](../triedb/) for hashdb, pathdb, and firewood implementations). The TrieDB stores trie nodes (the individual components of state tries) in memory and on disk. When a block is processed, the state transition results in a new state root, and the TrieDB updates or inserts the trie nodes that compose this state. The State Manager tracks which state roots are referenced by processing blocks and manages when to commit trie nodes to disk or dereference them. The State Manager can operate in either archival or pruning mode.
 
 ### Archival Mode