From 77647e908969ff09c83f413595d58e658279ed43 Mon Sep 17 00:00:00 2001 From: Paul Wackerow <54227730+wackerow@users.noreply.github.com> Date: Wed, 23 Jul 2025 14:09:53 -0700 Subject: [PATCH] chore: deprecate miner terminology [Closes #12030] --- public/content/developers/docs/apis/json-rpc/index.md | 4 ++-- .../docs/nodes-and-clients/client-diversity/index.md | 2 +- public/content/developers/docs/nodes-and-clients/index.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/public/content/developers/docs/apis/json-rpc/index.md b/public/content/developers/docs/apis/json-rpc/index.md index e831cffe7b2..6b85f335185 100755 --- a/public/content/developers/docs/apis/json-rpc/index.md +++ b/public/content/developers/docs/apis/json-rpc/index.md @@ -1148,13 +1148,13 @@ params: [ - `number`: `QUANTITY` - the block number. `null` when its pending block. - `hash`: `DATA`, 32 Bytes - hash of the block. `null` when its pending block. - `parentHash`: `DATA`, 32 Bytes - hash of the parent block. -- `nonce`: `DATA`, 8 Bytes - hash of the generated proof-of-work. `null` when its pending block. +- `nonce`: `DATA`, 8 Bytes - hash of the generated proof-of-work. `null` when its pending block, `0x0` for proof-of-stake blocks (since The Merge) - `sha3Uncles`: `DATA`, 32 Bytes - SHA3 of the uncles data in the block. - `logsBloom`: `DATA`, 256 Bytes - the bloom filter for the logs of the block. `null` when its pending block. - `transactionsRoot`: `DATA`, 32 Bytes - the root of the transaction trie of the block. - `stateRoot`: `DATA`, 32 Bytes - the root of the final state trie of the block. - `receiptsRoot`: `DATA`, 32 Bytes - the root of the receipts trie of the block. -- `miner`: `DATA`, 20 Bytes - the address of the beneficiary to whom the mining rewards were given. +- `miner`: `DATA`, 20 Bytes - the address of the beneficiary to whom the block rewards were given. - `difficulty`: `QUANTITY` - integer of the difficulty for this block. - `totalDifficulty`: `QUANTITY` - integer of the total difficulty of the chain until this block. - `extraData`: `DATA` - the "extra data" field of this block. diff --git a/public/content/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/developers/docs/nodes-and-clients/client-diversity/index.md index 0e0f28439ad..789f2193d40 100644 --- a/public/content/developers/docs/nodes-and-clients/client-diversity/index.md +++ b/public/content/developers/docs/nodes-and-clients/client-diversity/index.md @@ -56,7 +56,7 @@ Until now, the conversation around client diversity has focused mainly on the co ## Use a minority client {#use-minority-client} -Addressing client diversity requires more than individual users to choose minority clients - it requires mining/validator pools and institutions like the major dapps and exchanges to switch clients too. However, all users can do their part in redressing the current imbalance and normalizing the use of all the available Ethereum software. After The Merge, all node operators will be required to run an execution client and a consensus client. Choosing combinations of the clients suggested below will help increase client diversity. +Addressing client diversity requires more than individual users to choose minority clients - it requires validator pools and institutions like the major dapps and exchanges to switch clients too. However, all users can do their part in redressing the current imbalance and normalizing the use of all the available Ethereum software. After The Merge, all node operators will be required to run an execution client and a consensus client. Choosing combinations of the clients suggested below will help increase client diversity. ### Execution clients {#execution-clients} diff --git a/public/content/developers/docs/nodes-and-clients/index.md b/public/content/developers/docs/nodes-and-clients/index.md index e5a2abd532b..fe95fc21430 100644 --- a/public/content/developers/docs/nodes-and-clients/index.md +++ b/public/content/developers/docs/nodes-and-clients/index.md @@ -68,7 +68,7 @@ Full nodes do a block-by-block validation of the blockchain, including downloadi Archive nodes are full nodes that verify every block from genesis and never delete any of the downloaded data. -- Stores everything kept in the full node and builds an archive of historical states. It is needed if you want to query something like an account balance at block #4,000,000, or simply and reliably test your own transactions set without mining them using tracing. +- Stores everything kept in the full node and builds an archive of historical states. It is needed if you want to query something like an account balance at block #4,000,000, or simply and reliably test your own transactions set without validating them using tracing. - This data represents units of terabytes, which makes archive nodes less attractive for average users but can be handy for services like block explorers, wallet vendors, and chain analytics. Syncing clients in any mode other than archive will result in pruned blockchain data. This means, there is no archive of all historical states but the full node is able to build them on demand. @@ -77,7 +77,7 @@ Learn more about [Archive nodes](/developers/docs/nodes-and-clients/archive-node ### Light node {#light-node} -Instead of downloading every block, light nodes only download block headers. These headers contain summary information about the contents of the blocks. Any other information the light node requires gets requested from a full node. The light node can then independently verify the data they receive against the state roots in the block headers. Light nodes enable users to participate in the Ethereum network without the powerful hardware or high bandwidth required to run full nodes. Eventually, light nodes might run on mobile phones or embedded devices. The light nodes do not participate in consensus (i.e. they cannot be miners/validators), but they can access the Ethereum blockchain with the same functionality and security guarantees as a full node. +Instead of downloading every block, light nodes only download block headers. These headers contain summary information about the contents of the blocks. Any other information the light node requires gets requested from a full node. The light node can then independently verify the data they receive against the state roots in the block headers. Light nodes enable users to participate in the Ethereum network without the powerful hardware or high bandwidth required to run full nodes. Eventually, light nodes might run on mobile phones or embedded devices. The light nodes do not participate in consensus (i.e. they cannot be validators), but they can access the Ethereum blockchain with the same functionality and security guarantees as a full node. Light clients are an area of active development for Ethereum and we expect to see new light clients for the consensus layer and execution layer soon. There are also potential routes to providing light client data over the [gossip network](https://www.ethportal.net/). This is advantageous because the gossip network could support a network of light nodes without requiring full nodes to serve requests.