sync: coreth PR #1392: chore: Add lint link check job (#1870)

Signed-off-by: Jonathan Oppenheimer <147infiniti@gmail.com>
Co-authored-by: Austin Larson <78000745+alarso16@users.noreply.github.com>
Co-authored-by: Michael Kaplan <55204436+michaelkaplan13@users.noreply.github.com>

Author: 3 people

.github/CONTRIBUTING.md

@@ -1,47 +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 subnet-evm, 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 subnet-evm, 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 and documentation
-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)
+- 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"
 
-### Mocks
+## 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.
+
+## 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) 2019-2025, Ava Labs, Inc. All rights reserved.
@@ -58,26 +55,29 @@ Mocks are auto-generated using [mockgen](https://pkg.go.dev/go.uber.org/mock/moc
 - 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://immunefi.com/bug-bounty/avalanche/information/).
+You can submit a bug on the [Avalanche Bug Bounty program page](https://immunefi.com/bug-bounty/avalanche/information/).

.github/ISSUE_TEMPLATE/feature_spec.md

@@ -16,4 +16,4 @@ Include a description of the changes to be made to the code along with alternati
 that were considered, including pro/con analysis where relevant.
 
 **Open questions**
-Questions that are still being discussed.
+Questions that are still being discussed

.github/pull_request_template.md

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

.github/workflows/ci.yml

@@ -35,6 +35,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

@@ -5,11 +5,11 @@
 [![CodeQL](https://github.com/ava-labs/subnet-evm/actions/workflows/codeql-analysis.yml/badge.svg)](https://github.com/ava-labs/subnet-evm/actions/workflows/codeql-analysis.yml)
 [![License](https://img.shields.io/github/license/ava-labs/subnet-evm)](https://github.com/ava-labs/subnet-evm/blob/master/LICENSE)
 
-[Avalanche](https://docs.avax.network/avalanche-l1s) is a network composed of multiple blockchains.
+[Avalanche](https://build.avax.network/docs/avalanche-l1s) is a network composed of multiple blockchains.
 Each blockchain is an instance of a Virtual Machine (VM), much like an object in an object-oriented language is an instance of a class.
 That is, the VM defines the behavior of the blockchain.
 
-Subnet EVM is the [Virtual Machine (VM)](https://docs.avax.network/learn/virtual-machines) that defines the Subnet Contract Chains. Subnet EVM is a simplified version of [Coreth VM (C-Chain)](https://github.com/ava-labs/coreth).
+Subnet EVM is the [Virtual Machine (VM)](https://build.avax.network/docs/quick-start/virtual-machines) that defines the Subnet Contract Chains. Subnet EVM is a simplified version of [Coreth VM (C-Chain)](https://github.com/ava-labs/coreth).
 
 This chain implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client functionality.
 
@@ -44,11 +44,11 @@ The Subnet EVM supports the following API namespaces:
 
 Only the `eth` namespace is enabled by default.
 Subnet EVM is a simplified version of [Coreth VM (C-Chain)](https://github.com/ava-labs/coreth).
-Full documentation for the C-Chain's API can be found [here](https://build.avax.network/docs/api-reference/c-chain/api).
+Full documentation for the C-Chain's API can be found in the [builder docs](https://build.avax.network/docs/rpcs/c-chain).
 
 ## Compatibility
 
-The Subnet EVM is compatible with almost all Ethereum tooling, including [Remix](https://docs.avax.network/build/dapp/smart-contracts/remix-deploy), [Metamask](https://docs.avax.network/build/dapp/chain-settings), and [Foundry](https://docs.avax.network/build/dapp/smart-contracts/toolchains/foundry).
+Subnet-EVM is compatible with almost all Ethereum tooling, including [Foundry](https://build.avax.network/academy/blockchain/solidity-foundry/03-smart-contracts/03-foundry-quickstart) and [Remix](https://build.avax.network/docs/avalanche-l1s/add-utility/deploy-smart-contract#using-remix).
 
 **Note:** Subnet-EVM and Avalanche C-Chain currently implement the Ethereum Cancun fork and do not yet support newer hardforks (such as Pectra). Since Solidity v0.8.30 switched its default target EVM version to Pectra, contracts compiled with default settings may emit bytecode using instructions/features that Avalanche does not support.
 To avoid this mismatch, explicitly set the Solidity compiler’s `evmVersion` to `cancun` when deploying to Subnet-EVM or the C-Chain.
@@ -73,7 +73,7 @@ To support these changes, there have been a number of changes to the SubnetEVM b
 
 ### Clone Subnet-evm
 
-First install Go 1.24.9 or later. Follow the instructions [here](https://go.dev/doc/install). You can verify by running `go version`.
+First install Go 1.24.9 or later. Follow the instructions on the [go docs](https://go.dev/doc/install). You can verify by running `go version`.
 
 Set `$GOPATH` environment variable properly for Go to look for Go Workspaces. Please read [this](https://go.dev/doc/code) for details. You can verify by running `echo $GOPATH`.
 
@@ -97,8 +97,8 @@ To run a local network, it is recommended to use the [avalanche-cli](https://git
 
 There are two options when using the Avalanche-CLI:
 
-1. Use an official Subnet-EVM release: <https://docs.avax.network/subnets/build-first-subnet>
-2. Build and deploy a locally built (and optionally modified) version of Subnet-EVM: <https://docs.avax.network/subnets/create-custom-subnet>
+1. Use an official Subnet-EVM release: <https://build.avax.network/docs/tooling/avalanche-cli/create-avalanche-l1>
+1. Build and deploy a locally built (and optionally modified) version of Subnet-EVM: <https://build.avax.network/docs/tooling/avalanche-cli/create-deploy-avalanche-l1s/deploy-with-custom-vm>
 
 ## Releasing
 

RELEASES.md

@@ -1,3 +1,5 @@
+<!-- markdownlint-disable MD024 -->
+
 # Release Notes
 
 ## [v0.8.1](https://github.com/ava-labs/subnet-evm/releases/tag/v0.8.1)
@@ -201,7 +203,7 @@ The plugin version is unchanged at 37 and is compatible with AvalancheGo version
 - Added following new database options:
   - `"use-standalone-database"` (`bool`): If true it enables creation of standalone database. If false it uses the GRPC Database provided by AvalancheGo. Default is nil and creates the standalone database only if there is no accepted block in the AvalancheGo database (node has not accepted any blocks for this chain)
   - `"database-type"` (`string`): Specifies the type of database to use. Must be one of `pebbledb`, `leveldb` or `memdb`. memdb is an in-memory, non-persisted database. Default is `pebbledb`
-  - `"database-config-file"` (`string`): Path to the database config file. Config file is changed for every database type. See [docs](https://docs.avax.network/api-reference/avalanche-go-configs-flags#database-config) for available configs per database type. Ignored if --config-file-content is specified
+  - `"database-config-file"` (`string`): Path to the database config file. Config file is changed for every database type. See [docs](https://build.avax.network/docs/nodes/configure/configs-flags#database-config) for available configs per database type. Ignored if --config-file-content is specified
   - `"database-config-file-content"` (`string`): As an alternative to `database-config-file`, it allows specifying base64 encoded database config content
   - `"database-path"` (`string`): Specifies the directory to which the standalone database is persisted. Defaults to "`$HOME/.avalanchego/chainData/{chainID}`"
   - `"database-read-only"` (`bool`) : Specifies if the standalone database should be a read-only type. Defaults to false

cmd/precompilegen/template-readme.md

@@ -2,7 +2,7 @@ There are some must-be-done changes waiting in the generated file. Each area req
 Additionally there are other files you need to edit to activate your precompile.
 These areas are highlighted with comments "ADD YOUR PRECOMPILE HERE".
 For testing take a look at other precompile tests in contract_test.go and config_test.go in other precompile folders.
-See the tutorial in <https://docs.avax.network/subnets/hello-world-precompile-tutorial> for more information about precompile development.
+See the tutorial in <https://build.avax.network/academy/blockchain/solidity-foundry/04-hello-world-part-1/01-intro> for more information about precompile development.
 
 General guidelines for precompile development:
 

cmd/simulator/README.md

@@ -24,11 +24,11 @@ To confirm that you built successfully, run the simulator and print the version:
 
 This should give the following output:
 
-```
+```bash
 v0.1.0
 ```
 
-To run the load simulator, you must first start an EVM based network. The load simulator works on both the C-Chain and Subnet-EVM, so we will start a single node network and run the load simulator on the C-Chain.
+To run the load simulator, you must first start an EVM based network. The load simulator works on both the C-Chain and Subnet-EVM, so we will start a single node network and run the load simulator on a Subnet-EVM blockchain.
 
 To start a single node network, follow the instructions from the AvalancheGo [README](https://github.com/ava-labs/avalanchego#building-avalanchego) to build from source.
 
@@ -45,9 +45,9 @@ 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 your Subnet-EVM blockchain will be `http://127.0.0.1:9650/ext/bc/BLOCKCHAIN_ID/rpc` and `ws://127.0.0.1:9650/ext/bc/BLOCKCHAIN_ID/ws` for WebSocket connections, where `BLOCKCHAIN_ID` is the blockchain ID of your deployed Subnet-EVM instance.
 
-Now, we can run the simulator command to simulate some load on the local C-Chain for 30s:
+Now, we can run the simulator command to simulate some load on the local Subnet-EVM blockchain:
 
 ```bash
 ./simulator --timeout=1m --workers=1 --max-fee-cap=300 --max-tip-cap=10 --txs-per-worker=50

consensus/dummy/README.md

@@ -1,6 +1,6 @@
 # Consensus
 
-Disclaimer: the consensus package in subnet-evm is a complete misnomer.
+Disclaimer: the consensus package in Subnet-EVM is a complete misnomer.
 
 The consensus package in go-ethereum handles block validation and specifically handles validating the PoW portion of consensus - thus the name.
 
@@ -12,7 +12,7 @@ The dummy consensus engine is responsible for performing verification on the hea
 
 ## Dynamic Fees
 
-Subnet-EVM 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.
+Subnet-EVM 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. Subnet-EVM 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). 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). 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.