Merge branch 'geth-next'

.eslintignore

@@ -0,0 +1,3 @@
+.next
+dist
+node_modules/

.eslintrc.json

@@ -0,0 +1,3 @@
+{
+  "extends": ["next/core-web-vitals", "prettier"]
+}

.gitignore

@@ -0,0 +1,36 @@
+# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
+
+# dependencies
+/node_modules
+/.pnp
+.pnp.js
+
+# testing
+/coverage
+
+# next.js
+/.next/
+/out/
+
+# production
+/build
+
+# misc
+.DS_Store
+*.pem
+
+# debug
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+.pnpm-debug.log*
+
+# local env files
+.env*.local
+
+# vercel
+.vercel
+
+# typescript
+*.tsbuildinfo
+next-env.d.ts

.prettierignore

@@ -0,0 +1,6 @@
+.next
+node_modules
+yarn.lock
+package-lock.json
+public
+build

.prettierrc

@@ -0,0 +1,10 @@
+{
+  "printWidth": 100,
+  "trailingComma": "none",
+  "semi": true,
+  "arrowParens": "avoid",
+  "singleQuote": true,
+  "jsxSingleQuote": true,
+  "tabWidth": 2,
+  "useTabs": false
+}

README.md

@@ -5,11 +5,47 @@ This repo will act as a shared workspace for the geth website team in developing
 Resources:
 
 - the project management notes: https://www.notion.so/efdn/Build-new-Geth-website-bf35a46cfe5848db83ac3acb5191eb1c
-- some draft figma files for design sketching:  https://www.figma.com/file/ekzIgwyeVKLtFSAcnA0Q0D/geth-website?node-id=6%3A31
+- some draft figma files for design sketching: https://www.figma.com/file/ekzIgwyeVKLtFSAcnA0Q0D/geth-website?node-id=6%3A31
 - content planning notes: https://www.notion.so/efdn/Content-Strategy-3252234338814a749374fa7f11049083
 - meeting notes: https://www.notion.so/efdn/Call-notes-46aa0202810a402ebfda07b046761cbd
 
-
 Notes:
 
-**Dev note**: Remember that the fiules in `vulnerabilities` must be served at the same URLs as they are currently to avoid breaking some Geth functions related to security auditing. 
+**Dev note**: Remember that the fiules in `vulnerabilities` must be served at the same URLs as they are currently to avoid breaking some Geth functions related to security auditing.
+
+---
+
+This is a [Next.js](https://nextjs.org/) project bootstrapped with [`create-next-app`](https://github.com/vercel/next.js/tree/canary/packages/create-next-app).
+
+## Getting Started
+
+First, run the development server:
+
+```bash
+npm run dev
+# or
+yarn dev
+```
+
+Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.
+
+You can start editing the page by modifying `pages/index.tsx`. The page auto-updates as you edit the file.
+
+[API routes](https://nextjs.org/docs/api-routes/introduction) can be accessed on [http://localhost:3000/api/hello](http://localhost:3000/api/hello). This endpoint can be edited in `pages/api/hello.ts`.
+
+The `pages/api` directory is mapped to `/api/*`. Files in this directory are treated as [API routes](https://nextjs.org/docs/api-routes/introduction) instead of React pages.
+
+## Learn More
+
+To learn more about Next.js, take a look at the following resources:
+
+- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js features and API.
+- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
+
+You can check out [the Next.js GitHub repository](https://github.com/vercel/next.js/) - your feedback and contributions are welcome!
+
+## Deploy on Vercel
+
+The easiest way to deploy your Next.js app is to use the [Vercel Platform](https://vercel.com/new?utm_medium=default-template&filter=next.js&utm_source=create-next-app&utm_campaign=create-next-app-readme) from the creators of Next.js.
+
+Check out our [Next.js deployment documentation](https://nextjs.org/docs/deployment) for more details.

content/docs/getting_started/Backup--restore.md

@@ -1,65 +0,0 @@
----
-title: Backup & Restore
-sort_key: C
----
-
-Most important info first: **REMEMBER YOUR PASSWORD** and **BACKUP YOUR KEYSTORE**.
-
-## Data Directory
-
-Everything `geth` persists gets written inside its data directory. The default data
-directory locations are platform specific:
-
-* Mac: `~/Library/Ethereum`
-* Linux: `~/.ethereum`
-* Windows: `%LOCALAPPDATA%\Ethereum`
-
-Accounts are stored in the `keystore` subdirectory. The contents of this directories
-should be transportable between nodes, platforms, implementations (C++, Go, Python).
-
-To configure the location of the data directory, the `--datadir` parameter can be
-specified. See [CLI Options](../interface/command-line-options) for more details.
-
-Note the [ethash dag](../interface/mining) is stored at `~/.ethash` (Mac/Linux) or
-`%APPDATA%\Ethash` (Windows) so that it can be reused by all clients. You can store this
-in a different location by using a symbolic link.
-
-## Cleanup
-
-Geth's blockchain and state databases can be removed with:
-
-```
-geth removedb
-```
-
-This is useful for deleting an old chain and sync'ing to a new one. It only affects data
-directories that can be re-created on synchronisation and does not touch the keystore.
-
-## Blockchain Import/Export
-
-Export the blockchain in binary format with:
-
-```
-geth export <filename>
-```
-
-Or if you want to back up portions of the chain over time, a first and last block can be
-specified. For example, to back up the first epoch:
-
-```
-geth export <filename> 0 29999
-```
-
-Note that when backing up a partial chain, the file will be appended rather than
-truncated.
-
-Import binary-format blockchain exports with:
-
-```
-geth import <filename>
-```
-
-_See https://eth.wiki/en/howto/blockchain-import-and-export-instructions for more info_
-
-
-And finally: **REMEMBER YOUR PASSWORD** and **BACKUP YOUR KEYSTORE**

content/docs/interacting_with_geth/RPC/objects.md

@@ -1,72 +0,0 @@
----
-title: Objects
-description: Data structures used for RPC methods
----
-
-The following are data structures which are used for various RPC methods.
-
-### Transaction call object
-
-The *transaction call object* contains all the necessary parameters for executing an EVM contract method.
-
-| Field      | Type       | Bytes | Optional | Description |
-|:-----------|:-----------|:------|:---------|:------------|
-| `from`     | `Address`  | 20    | Yes      | Address the transaction is simulated to have been sent from. Defaults to first account in the local keystore or the `0x00..0` address if no local accounts are available. |
-| `to`       | `Address`  | 20    | No       | Address the transaction is sent to. |
-| `gas`      | `Quantity` | <8    | Yes      | Maximum gas allowance for the code execution to avoid infinite loops. Defaults to `2^63` or whatever value the node operator specified via `--rpc.gascap`. |
-| `gasPrice` | `Quantity` | <32   | Yes      | Number of `wei` to simulate paying for each unit of gas during execution. Defaults to `1 gwei`. |
-| `maxFeePerGas` | `Quantity` | <32   | Yes      | Maximum fee per gas the transaction should pay in total. Relevant for type-2 transactions. |
-| `maxPriorityFeePerGas` | `Quantity` | <32   | Yes      | Maximum tip per gas that's given directly to the miner. Relevant for type-2 transactions. |
-| `value`    | `Quantity` | <32   | Yes      | Amount of `wei` to simulate sending along with the transaction. Defaults to `0`. |
-| `nonce`     | `Quantity`   | <8   | Yes      | Nonce of sender account. |
-| `input`     | `Binary`   | any   | Yes      | Binary data to send to the target contract. Generally the 4 byte hash of the method signature followed by the ABI encoded parameters. For details please see the [Ethereum Contract ABI](https://docs.soliditylang.org/en/v0.7.0/abi-spec.html). This field was previously called `data`. |
-| `accessList`     | `AccessList`   | any   | Yes      | A list of addresses and storage keys that the transaction plans to access. Used in non-legacy, i.e. type 1 and 2 transactions. |
-| `chainId`     | `Quantity`   | <32   | Yes      | Transaction only valid on networks with this chain ID. Used in non-legacy, i.e. type 1 and 2 transactions. |
-
-Example for a legacy transaction:
-
-```json
-{
-  "from": "0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3",
-  "to":   "0xebe8efa441b9302a0d7eaecc277c09d20d684540",
-  "gas":  "0x1bd7c",
-  "data": "0xd459fc46000000000000000000000000000000000000000000000000000000000046c650dbb5e8cb2bac4d2ed0b1e6475d37361157738801c494ca482f96527eb48f9eec488c2eba92d31baeccfb6968fad5c21a3df93181b43b4cf253b4d572b64172ef000000000000000000000000000000000000000000000000000000000000008c00000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000001c000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000002b85c0c828d7a98633b4e1b65eac0c017502da909420aeade9a280675013df36bdc71cffdf420cef3d24ba4b3f9b980bfbb26bd5e2dcf7795b3519a3fd22ffbb2000000000000000000000000000000000000000000000000000000000000000238fb6606dc2b5e42d00c653372c153da8560de77bd9afaba94b4ab6e4aa11d565d858c761320dbf23a94018d843772349bd9d92301b0ca9ca983a22d86a70628",
-}
-```
-
-Example for a type-1 transaction:
-
-```json
-{
-  "from": "0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3",
-  "to":   "0xebe8efa441b9302a0d7eaecc277c09d20d684540",
-  "gas":  "0x1bd7c",
-  "data": "0xd459fc46000000000000000000000000000000000000000000000000000000000046c650dbb5e8cb2bac4d2ed0b1e6475d37361157738801c494ca482f96527eb48f9eec488c2eba92d31baeccfb6968fad5c21a3df93181b43b4cf253b4d572b64172ef000000000000000000000000000000000000000000000000000000000000008c00000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000001c000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000002b85c0c828d7a98633b4e1b65eac0c017502da909420aeade9a280675013df36bdc71cffdf420cef3d24ba4b3f9b980bfbb26bd5e2dcf7795b3519a3fd22ffbb2000000000000000000000000000000000000000000000000000000000000000238fb6606dc2b5e42d00c653372c153da8560de77bd9afaba94b4ab6e4aa11d565d858c761320dbf23a94018d843772349bd9d92301b0ca9ca983a22d86a70628",
-  "chainId": "0x1",
-  "accessList":  [
-    {
-      "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
-      "storageKeys": ["0xda650992a54ccb05f924b3a73ba785211ba39a8912b6d270312f8e2c223fb9b1", "0x10d6a54a4754c8869d6886b5f5d7fbfa5b4
-                  522237ea5c60d11bc4e7a1ff9390b"]
-    }, {
-      "address": "0xa2327a938febf5fec13bacfb16ae10ecbc4cbdcf",
-      "storageKeys": []
-    },
-  ]
-}
-```
-
-Example for a type-2 transaction:
-
-```json
-{
-  "from": "0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3",
-  "to":   "0xebe8efa441b9302a0d7eaecc277c09d20d684540",
-  "gas":  "0x1bd7c",
-  "maxFeePerGas": "0x6b44b0285",
-  "maxPriorityFeePerGas": "0x6b44b0285",
-  "data": "0xd459fc46000000000000000000000000000000000000000000000000000000000046c650dbb5e8cb2bac4d2ed0b1e6475d37361157738801c494ca482f96527eb48f9eec488c2eba92d31baeccfb6968fad5c21a3df93181b43b4cf253b4d572b64172ef000000000000000000000000000000000000000000000000000000000000008c00000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000001c000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000002b85c0c828d7a98633b4e1b65eac0c017502da909420aeade9a280675013df36bdc71cffdf420cef3d24ba4b3f9b980bfbb26bd5e2dcf7795b3519a3fd22ffbb2000000000000000000000000000000000000000000000000000000000000000238fb6606dc2b5e42d00c653372c153da8560de77bd9afaba94b4ab6e4aa11d565d858c761320dbf23a94018d843772349bd9d92301b0ca9ca983a22d86a70628",
-  "chainId": "0x1",
-  "accessList":  []
-}
-```

next.config.js

@@ -0,0 +1,18 @@
+/** @type {import('next').NextConfig} */
+
+const withMDX = require('@next/mdx')({
+  extension: /\.mdx?$/,
+  options: {
+    remarkPlugins: [],
+    rehypePlugins: []
+    // If you use `MDXProvider`, uncomment the following line.
+    // providerImportSource: "@mdx-js/react",
+  }
+});
+
+module.exports = withMDX({
+  reactStrictMode: true,
+  swcMinify: true,
+  // Append the default value with md extensions
+  pageExtensions: ['ts', 'tsx', 'md', 'mdx']
+});

package.json

@@ -0,0 +1,39 @@
+{
+  "name": "geth-site",
+  "private": false,
+  "description": "The website for geth.ethereum.org",
+  "version": "2.0.0",
+  "author": "Nicolás Quiroz <nicolas.quiroz@ethereum.org>",
+  "scripts": {
+    "dev": "next dev",
+    "build": "npm run lint && next build && npm run format:fix",
+    "start": "next start",
+    "lint": "next lint",
+    "format:fix": "prettier . --write --config .prettierrc --ignore-path .prettierignore --loglevel warn"
+  },
+  "dependencies": {
+    "@chakra-ui/react": "^2.3.2",
+    "@emotion/react": "^11.10.4",
+    "@emotion/styled": "^11.10.4",
+    "@mdx-js/loader": "^2.1.3",
+    "@mdx-js/react": "^2.1.3",
+    "@next/mdx": "^12.3.0",
+    "focus-visible": "^5.2.0",
+    "framer-motion": "^7.3.2",
+    "next": "^12.3.0",
+    "react": "18.2.0",
+    "react-dom": "18.2.0",
+    "react-syntax-highlighter": "^15.5.0"
+  },
+  "devDependencies": {
+    "@types/node": "18.7.16",
+    "@types/react": "18.0.18",
+    "@types/react-dom": "18.0.6",
+    "@types/react-syntax-highlighter": "^15.5.5",
+    "eslint": "8.23.0",
+    "eslint-config-next": "12.2.5",
+    "eslint-config-prettier": "^8.5.0",
+    "prettier": "^2.7.1",
+    "typescript": "4.8.2"
+  }
+}

public/docs/vulnerabilities/vulnerabilities.json

@@ -93,9 +93,7 @@
     "fixed": "v1.9.20",
     "summary": "A consensus-vulnerability in Geth could cause a chain split, where vulnerable versions refuse to accept the canonical chain.",
     "description": "A flaw was repoted at 2020-08-11 by John Youngseok Yang (Software Platform Lab), where a particular sequence of transactions could cause a consensus failure.\n\n- Tx 1:\n - `sender` invokes `caller`.\n - `caller` invokes `0xaa`. `0xaa` has 3 wei, does a self-destruct-to-self\n - `caller` does a  `1 wei` -call to `0xaa`, who thereby has 1 wei (the code in `0xaa` still executed, since the tx is still ongoing, but doesn't redo the selfdestruct, it takes a different path if callvalue is non-zero)\n\n-Tx 2:\n - `sender` does a 5-wei call to 0xaa. No exec (since no code). \n\nIn geth, the result would be that `0xaa` had `6 wei`, whereas OE reported (correctly) `5` wei. Furthermore, in geth, if the second tx was not executed, the `0xaa` would be destructed, resulting in `0 wei`. Thus obviously wrong. \n\nIt was determined that the root cause was this [commit](https://github.com/ethereum/go-ethereum/commit/223b950944f494a5b4e0957fd9f92c48b09037ad) from [this PR](https://github.com/ethereum/go-ethereum/pull/19953). The semantics of `createObject` was subtly changd, into returning a non-nil object (with `deleted=true`) where it previously did not if the account had been destructed. This return value caused the new object to inherit the old `balance`.\n",
-    "links": [
-      "https://github.com/ethereum/go-ethereum/security/advisories/GHSA-xw37-57qp-9mm4"
-    ],
+    "links": ["https://github.com/ethereum/go-ethereum/security/advisories/GHSA-xw37-57qp-9mm4"],
     "published": "2020-12-10",
     "severity": "High",
     "CVE": "CVE-2020-26265",

public/vercel.svg

@@ -0,0 +1,4 @@
+<svg width="283" height="64" viewBox="0 0 283 64" fill="none" 
+    xmlns="http://www.w3.org/2000/svg">
+    <path d="M141.04 16c-11.04 0-19 7.2-19 18s8.96 18 20 18c6.67 0 12.55-2.64 16.19-7.09l-7.65-4.42c-2.02 2.21-5.09 3.5-8.54 3.5-4.79 0-8.86-2.5-10.37-6.5h28.02c.22-1.12.35-2.28.35-3.5 0-10.79-7.96-17.99-19-17.99zm-9.46 14.5c1.25-3.99 4.67-6.5 9.45-6.5 4.79 0 8.21 2.51 9.45 6.5h-18.9zM248.72 16c-11.04 0-19 7.2-19 18s8.96 18 20 18c6.67 0 12.55-2.64 16.19-7.09l-7.65-4.42c-2.02 2.21-5.09 3.5-8.54 3.5-4.79 0-8.86-2.5-10.37-6.5h28.02c.22-1.12.35-2.28.35-3.5 0-10.79-7.96-17.99-19-17.99zm-9.45 14.5c1.25-3.99 4.67-6.5 9.45-6.5 4.79 0 8.21 2.51 9.45 6.5h-18.9zM200.24 34c0 6 3.92 10 10 10 4.12 0 7.21-1.87 8.8-4.92l7.68 4.43c-3.18 5.3-9.14 8.49-16.48 8.49-11.05 0-19-7.2-19-18s7.96-18 19-18c7.34 0 13.29 3.19 16.48 8.49l-7.68 4.43c-1.59-3.05-4.68-4.92-8.8-4.92-6.07 0-10 4-10 10zm82.48-29v46h-9V5h9zM36.95 0L73.9 64H0L36.95 0zm92.38 5l-27.71 48L73.91 5H84.3l17.32 30 17.32-30h10.39zm58.91 12v9.69c-1-.29-2.06-.49-3.2-.49-5.81 0-10 4-10 10V51h-9V17h9v9.2c0-5.08 5.91-9.2 13.2-9.2z" fill="#000"/>
+</svg>

src/components/MDXComponents.tsx

@@ -0,0 +1,115 @@
+import { Heading, Link, Stack, Text } from '@chakra-ui/react';
+import NextLink from 'next/link';
+import { PrismLight as SyntaxHighlighter } from 'react-syntax-highlighter';
+import { nightOwl } from 'react-syntax-highlighter/dist/cjs/styles/prism';
+
+import bash from 'react-syntax-highlighter/dist/cjs/languages/prism/bash';
+import go from 'react-syntax-highlighter/dist/cjs/languages/prism/go';
+import graphql from 'react-syntax-highlighter/dist/cjs/languages/prism/graphql';
+import java from 'react-syntax-highlighter/dist/cjs/languages/prism/java';
+import javascript from 'react-syntax-highlighter/dist/cjs/languages/prism/javascript';
+import json from 'react-syntax-highlighter/dist/cjs/languages/prism/json';
+import python from 'react-syntax-highlighter/dist/cjs/languages/prism/python';
+import sh from 'react-syntax-highlighter/dist/cjs/languages/prism/shell-session';
+import solidity from 'react-syntax-highlighter/dist/cjs/languages/prism/solidity';
+import swift from 'react-syntax-highlighter/dist/cjs/languages/prism/swift';
+
+// syntax highlighting languages supported
+SyntaxHighlighter.registerLanguage('bash', bash);
+SyntaxHighlighter.registerLanguage('go', go);
+SyntaxHighlighter.registerLanguage('graphql', graphql);
+SyntaxHighlighter.registerLanguage('java', java);
+SyntaxHighlighter.registerLanguage('javascript', javascript);
+SyntaxHighlighter.registerLanguage('json', json);
+SyntaxHighlighter.registerLanguage('python', python);
+SyntaxHighlighter.registerLanguage('sh', sh);
+SyntaxHighlighter.registerLanguage('solidity', solidity);
+SyntaxHighlighter.registerLanguage('swift', swift);
+
+import { getProgrammingLanguageName } from '../utils';
+
+const MDXComponents = {
+  // paragraphs
+  p: ({ children }: any) => {
+    return (
+      <Text mb={7} _last={{ mb: 0 }} size='sm' lineHeight={1.5}>
+        {children}
+      </Text>
+    );
+  },
+  // links
+  a: ({ children, href }: any) => {
+    return (
+      <NextLink href={href} passHref>
+        <Link
+          isExternal={href.startsWith('http') && !href.includes('geth.ethereum.org')}
+          color='#18bc9c'
+        >
+          {children}
+        </Link>
+      </NextLink>
+    );
+  },
+  // headings
+  h1: ({ children }: any) => {
+    return (
+      <Heading as='h1' textAlign='start' fontSize='4xl' mb={5}>
+        {children}
+      </Heading>
+    );
+  },
+  h2: ({ children }: any) => {
+    return (
+      <Heading as='h2' textAlign='start' fontSize='3xl' mb={4}>
+        {children}
+      </Heading>
+    );
+  },
+  h3: ({ children }: any) => {
+    return (
+      <Heading as='h3' fontSize='2xl' mt={5} mb={2.5}>
+        {children}
+      </Heading>
+    );
+  },
+  h4: ({ children }: any) => {
+    return (
+      <Heading as='h4' fontSize='lg' mb={2.5}>
+        {children}
+      </Heading>
+    );
+  },
+  // pre
+  pre: ({ children }: any) => {
+    return (
+      <Stack mb={5}>
+        <pre>{children}</pre>
+      </Stack>
+    );
+  }
+  // code
+  // code: (code: any) => {
+  //   const language = getProgrammingLanguageName(code);
+
+  //   return !!code.inline ? (
+  //     <Text
+  //       as={'span'}
+  //       padding='0.125em 0.25em'
+  //       color='red.300'
+  //       background='#1c1e2d'
+  //       borderRadius='0.25em'
+  //       fontFamily='code'
+  //       fontSize='sm'
+  //       overflowY='scroll'
+  //     >
+  //       {code.children[0]}
+  //     </Text>
+  //   ) : (
+  //     <Stack style={nightOwl}>
+  //       {code.children[0]}
+  //     </Stack>
+  //   );
+  // }
+};
+
+export default MDXComponents;

src/components/index.ts

@@ -0,0 +1 @@
+export { default } from './MDXComponents';

src/components/layouts/Layout.tsx

@@ -0,0 +1,14 @@
+import { Container } from '@chakra-ui/react';
+import { FC } from 'react';
+
+interface Props {
+  children?: React.ReactNode;
+}
+
+export const Layout: FC<Props> = ({ children }) => {
+  return (
+    <Container maxW='container.lg' my={7}>
+      {children}
+    </Container>
+  );
+};

src/components/layouts/index.ts

@@ -0,0 +1 @@
+export { Layout } from './Layout';

src/pages/_app.tsx

@@ -0,0 +1,23 @@
+import { ChakraProvider } from '@chakra-ui/react';
+import { AppProps } from 'next/app';
+
+import { Layout } from '../components/layouts';
+
+import 'focus-visible/dist/focus-visible';
+
+import theme from '../theme';
+
+import { MDXProvider } from '@mdx-js/react';
+import MDXComponents from '../components/';
+
+export default function App({ Component, pageProps }: AppProps) {
+  return (
+    <ChakraProvider theme={theme}>
+      <MDXProvider components={MDXComponents}>
+        <Layout>
+          <Component {...pageProps} />
+        </Layout>
+      </MDXProvider>
+    </ChakraProvider>
+  );
+}

src/pages/about.mdx

@@ -0,0 +1,5 @@
+# About
+
+## Subtitle
+
+Text sample for testing only

src/pages/api/hello.ts

@@ -0,0 +1,10 @@
+// Next.js API route support: https://nextjs.org/docs/api-routes/introduction
+import type { NextApiRequest, NextApiResponse } from 'next';
+
+type Data = {
+  name: string;
+};
+
+export default function handler(req: NextApiRequest, res: NextApiResponse<Data>) {
+  res.status(200).json({ name: 'John Doe' });
+}

src/pages/docs/developers/contributing.md

@@ -11,11 +11,11 @@ If you'd like to contribute to the Geth source code, please fork the [Github rep
 
 Please make sure your contributions adhere to our coding guidelines:
 
-* Code must adhere to the official Go formatting guidelines (i.e. uses gofmt).
-* Code must be documented adhering to the official Go commentary guidelines.
-* Pull requests need to be based on and opened against the master branch.
-* 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 guidelines (i.e. uses gofmt).
+- Code must be documented adhering to the official Go commentary guidelines.
+- Pull requests need to be based on and opened against the master branch.
+- Commit messages should be prefixed with the package(s) they modify.
+  E.g. "eth, rpc: make trace configs optional"
 
 Pull requests generally need to be based on and opened against the `master` branch, unless by explicit agreement because the work is contributing to some more complex feature branch.
 

src/pages/docs/developers/dapp-developer/built-in-tracers.md

@@ -5,25 +5,24 @@ description: Explanation of the tracers that come bundled in Geth as part of the
 
 Geth comes bundled with a choice of tracers ready for usage through the [tracing API](/docs/rpc/ns-debug). Some of them are implemented natively in Go, and others in JS. In this page a summary of each of these will be outlined. They have to be specified by name when sending a request. The only exception is the opcode logger (otherwise known as struct logger) which is the default tracer for all the methods and cannot be specified by name.
 
-
 ## Struct logger
 
 Struct logger or opcode logger is a native Go tracer which executes a transaction and emits the opcode and execution context at every step. This is the tracer that will be used when no name is passed to the API, e.g. `debug.traceTransaction(<txhash>)`. The following information is emitted at each step:
 
-| field      | type          | description                                                                                                                       |
-|------------|---------------|-----------------------------------------------------------------------------------------------------------------------------------|
-| pc         | uint64        | program counter                                                                                                                   |
-| op         | byte          | opcode to be executed                                                                                                             |
-| gas        | uint64        | remaining gas                                                                                                                     |
-| gasCost    | uint64        | cost for executing op                                                                                                             |
-| memory     | []byte        | EVM memory. Enabled via `enableMemory`                                                                                            |
-| memSize    | int           | Size of memory                                                                                                                    |
-| stack      | []uint256     | EVM stack. Disabled via `disableStack`                                                                                            |
-| returnData | []byte        | Last call's return data. Enabled via `enableReturnData`                                                                           |
-| storage    | map[hash]hash | Storage slots of current contract read from and written to. Only emitted for `SLOAD` and `SSTORE`. Disabled via `disableStorage`  |
-| depth      | int           | Current call depth                                                                                                                |
-| refund     | uint64        | Refund counter                                                                                                                    |
-| error      | string        | Error message if any                                                                                                              |
+| field      | type          | description                                                                                                                      |
+| ---------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| pc         | uint64        | program counter                                                                                                                  |
+| op         | byte          | opcode to be executed                                                                                                            |
+| gas        | uint64        | remaining gas                                                                                                                    |
+| gasCost    | uint64        | cost for executing op                                                                                                            |
+| memory     | []byte        | EVM memory. Enabled via `enableMemory`                                                                                           |
+| memSize    | int           | Size of memory                                                                                                                   |
+| stack      | []uint256     | EVM stack. Disabled via `disableStack`                                                                                           |
+| returnData | []byte        | Last call's return data. Enabled via `enableReturnData`                                                                          |
+| storage    | map[hash]hash | Storage slots of current contract read from and written to. Only emitted for `SLOAD` and `SSTORE`. Disabled via `disableStorage` |
+| depth      | int           | Current call depth                                                                                                               |
+| refund     | uint64        | Refund counter                                                                                                                   |
+| error      | string        | Error message if any                                                                                                             |
 
 Note that the fields `memory`, `stack`, `returnData`, and `storage` have dynamic size and depending on the exact transaction they could grow large in size. This is specially true for `memory` which could blow up the trace size. It is recommended to keep them disabled unless they are explicitly required for a given use-case.
 
@@ -52,18 +51,18 @@ The `4byteTracer` collects the function selectors of every function executed in
 
 The `callTracer` tracks all the call frames executed during a transaction, including depth 0. The result will be a nested list of call frames, resembling how EVM works. They form a tree with the top-level call at root and sub-calls as children of the higher levels. Each call frame has the following fields:
 
-| field   | type        | description                               |
-|---------|-------------|-------------------------------------------|
-| type    | string      | CALL or CREATE                            |
-| from    | string      | address                                   |
-| to      | string      | address                                   |
-| value   | string      | hex-encoded amount of value transfer      |
-| gas     | string      | hex-encoded gas provided for call         |
-| gasUsed | string      | hex-encoded gas used during call          |
-| input   | string      | call data                                 |
-| output  | string      | return data                               |
-| error   | string      | error, if any                             |
-| calls   | []callframe | list of sub-calls                         |
+| field   | type        | description                          |
+| ------- | ----------- | ------------------------------------ |
+| type    | string      | CALL or CREATE                       |
+| from    | string      | address                              |
+| to      | string      | address                              |
+| value   | string      | hex-encoded amount of value transfer |
+| gas     | string      | hex-encoded gas provided for call    |
+| gasUsed | string      | hex-encoded gas used during call     |
+| input   | string      | call data                            |
+| output  | string      | return data                          |
+| error   | string      | error, if any                        |
+| calls   | []callframe | list of sub-calls                    |
 
 Things to note about the call tracer:
 
@@ -79,7 +78,7 @@ This tracer is noop. It returns an empty object and is only meant for testing th
 Executing a transaction requires the prior state, including account of sender and recipient, contracts that are called during execution, etc. The `prestateTracer` replays the tx and tracks every part of state that is touched. This is similar to the concept of a [stateless witness](https://ethresear.ch/t/the-stateless-client-concept/172), the difference being this tracer doesn't return any cryptographic proof, rather only the trie leaves. The result is an object. The keys are addresses of accounts. The value is an object with the following fields:
 
 | field   | type              | description                   |
-|---------|-------------------|-------------------------------|
+| ------- | ----------------- | ----------------------------- |
 | balance | string            | balance in Wei                |
 | nonce   | uint64            | nonce                         |
 | code    | string            | hex-encoded bytecode          |

src/pages/docs/developers/dapp-developer/custom-tracer.md

@@ -11,42 +11,41 @@ Transaction traces include the complete status of the EVM at every point during
 
 ### A simple filter
 
-Filters are Javascript functions that select information from the trace to persist and discard based on some conditions. The following Javascript function returns only the sequence of opcodes executed by the transaction as a comma-separated list. The function could be written directly in the Javascript console, but it is cleaner to write it in a separate re-usable file and load it into the console. 
+Filters are Javascript functions that select information from the trace to persist and discard based on some conditions. The following Javascript function returns only the sequence of opcodes executed by the transaction as a comma-separated list. The function could be written directly in the Javascript console, but it is cleaner to write it in a separate re-usable file and load it into the console.
 
 1. Create a file, `filterTrace_1.js`, with this content:
 
    ```javascript
-
-   tracer = function(tx) {
-      return debug.traceTransaction(tx, {tracer:
+   tracer = function (tx) {
+     return debug.traceTransaction(tx, {
+       tracer:
          '{' +
-            'retVal: [],' +
-            'step: function(log,db) {this.retVal.push(log.getPC() + ":" + log.op.toString())},' +
-            'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
-            'result: function(ctx,db) {return this.retVal}' +
+         'retVal: [],' +
+         'step: function(log,db) {this.retVal.push(log.getPC() + ":" + log.op.toString())},' +
+         'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
+         'result: function(ctx,db) {return this.retVal}' +
          '}'
-      }) // return debug.traceTransaction ...
-   }   // tracer = function ...
-
+     }); // return debug.traceTransaction ...
+   }; // tracer = function ...
    ```
 
 2. Run the [JavaScript console](https://geth.ethereum.org/docs/interface/javascript-console).
-   
 3. Get the hash of a recent transaction from a node or block explorer.
 
 4. Run this command to run the script:
 
    ```javascript
-   loadScript("filterTrace_1.js")
+   loadScript('filterTrace_1.js');
    ```
 
 5. Run the tracer from the script. Be patient, it could take a long time.
 
    ```javascript
-   tracer("<hash of transaction>")
+   tracer('<hash of transaction>');
    ```
 
    The bottom of the output looks similar to:
+
    ```sh
    "3366:POP", "3367:JUMP", "1355:JUMPDEST", "1356:PUSH1", "1358:MLOAD", "1359:DUP1", "1360:DUP3", "1361:ISZERO", "1362:ISZERO",
    "1363:ISZERO", "1364:ISZERO", "1365:DUP2", "1366:MSTORE", "1367:PUSH1", "1369:ADD", "1370:SWAP2", "1371:POP", "1372:POP", "1373:PUSH1",
@@ -56,10 +55,10 @@ Filters are Javascript functions that select information from the trace to persi
 6. Run this line to get a more readable output with each string in its own line.
 
    ```javascript
-   console.log(JSON.stringify(tracer("<hash of transaction>"), null, 2))
+   console.log(JSON.stringify(tracer('<hash of transaction>'), null, 2));
    ```
 
-More information about the `JSON.stringify` function is available [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify). 
+More information about the `JSON.stringify` function is available [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify).
 
 The commands above worked by calling the same `debug.traceTransaction` function that was previously explained in [basic traces](https://geth.ethereum.org/docs/dapp/tracing), but with a new parameter, `tracer`. This parameter takes the JavaScript object formated as a string. In the case of the trace above, it is:
 
@@ -71,6 +70,7 @@ The commands above worked by calling the same `debug.traceTransaction` function
    result: function(ctx,db) {return this.retVal}
 }
 ```
+
 This object has three member functions:
 
 - `step`, called for each opcode.
@@ -86,21 +86,22 @@ The `step` function adds to `retVal` the program counter and the name of the opc
 For actual filtered tracing we need an `if` statement to only log relevant information. For example, to isolate the transaction's interaction with storage, the following tracer could be used:
 
 ```javascript
-tracer = function(tx) {
-      return debug.traceTransaction(tx, {tracer:
+tracer = function (tx) {
+  return debug.traceTransaction(tx, {
+    tracer:
       '{' +
-         'retVal: [],' +
-         'step: function(log,db) {' +
-         '   if(log.op.toNumber() == 0x54) ' +
-         '     this.retVal.push(log.getPC() + ": SLOAD");' +
-         '   if(log.op.toNumber() == 0x55) ' +
-         '     this.retVal.push(log.getPC() + ": SSTORE");' +
-         '},' +
-         'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
-         'result: function(ctx,db) {return this.retVal}' +
+      'retVal: [],' +
+      'step: function(log,db) {' +
+      '   if(log.op.toNumber() == 0x54) ' +
+      '     this.retVal.push(log.getPC() + ": SLOAD");' +
+      '   if(log.op.toNumber() == 0x55) ' +
+      '     this.retVal.push(log.getPC() + ": SSTORE");' +
+      '},' +
+      'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
+      'result: function(ctx,db) {return this.retVal}' +
       '}'
-      }) // return debug.traceTransaction ...
-}   // tracer = function ...
+  }); // return debug.traceTransaction ...
+}; // tracer = function ...
 ```
 
 The `step` function here looks at the opcode number of the op, and only pushes an entry if the opcode is `SLOAD` or `SSTORE` ([here is a list of EVM opcodes and their numbers](https://github.com/wolflo/evm-opcodes)). We could have used `log.op.toString()` instead, but it is faster to compare numbers rather than strings.
@@ -120,7 +121,6 @@ The output looks similar to this:
 ]
 ```
 
-
 ### Stack Information
 
 The trace above reports the program counter (PC) and whether the program read from storage or wrote to it. That alone isn't particularly useful. To know more, the `log.stack.peek` function can be used to peek into the stack. `log.stack.peek(0)` is the stack top, `log.stack.peek(1)` the entry below it, etc.
@@ -129,28 +129,28 @@ The values returned by `log.stack.peek` are Go `big.Int` objects. By default the
 
 #### Storage Information
 
-The function below provides a trace of all the storage operations and their parameters. This gives a more complete picture of the program's interaction with storage. 
+The function below provides a trace of all the storage operations and their parameters. This gives a more complete picture of the program's interaction with storage.
 
 ```javascript
-tracer = function(tx) {
-      return debug.traceTransaction(tx, {tracer:
+tracer = function (tx) {
+  return debug.traceTransaction(tx, {
+    tracer:
       '{' +
-         'retVal: [],' +
-         'step: function(log,db) {' +
-         '   if(log.op.toNumber() == 0x54) ' +
-         '     this.retVal.push(log.getPC() + ": SLOAD " + ' +
-         '        log.stack.peek(0).toString(16));' +
-         '   if(log.op.toNumber() == 0x55) ' +
-         '     this.retVal.push(log.getPC() + ": SSTORE " +' +
-         '        log.stack.peek(0).toString(16) + " <- " +' +
-         '        log.stack.peek(1).toString(16));' +
-         '},' +
-         'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
-         'result: function(ctx,db) {return this.retVal}' +
+      'retVal: [],' +
+      'step: function(log,db) {' +
+      '   if(log.op.toNumber() == 0x54) ' +
+      '     this.retVal.push(log.getPC() + ": SLOAD " + ' +
+      '        log.stack.peek(0).toString(16));' +
+      '   if(log.op.toNumber() == 0x55) ' +
+      '     this.retVal.push(log.getPC() + ": SSTORE " +' +
+      '        log.stack.peek(0).toString(16) + " <- " +' +
+      '        log.stack.peek(1).toString(16));' +
+      '},' +
+      'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
+      'result: function(ctx,db) {return this.retVal}' +
       '}'
-      }) // return debug.traceTransaction ...
-}   // tracer = function ...
-
+  }); // return debug.traceTransaction ...
+}; // tracer = function ...
 ```
 
 The output is similar to:
@@ -176,35 +176,36 @@ storage, so here we can't.
 The solution is to have a flag, `afterSload`, which is only true in the opcode right after an `SLOAD`, when we can see the result at the top of the stack.
 
 ```javascript
-tracer = function(tx) {
-      return debug.traceTransaction(tx, {tracer:
+tracer = function (tx) {
+  return debug.traceTransaction(tx, {
+    tracer:
       '{' +
-         'retVal: [],' +
-         'afterSload: false,' +
-         'step: function(log,db) {' +
-         '   if(this.afterSload) {' +
-         '     this.retVal.push("    Result: " + ' +
-         '          log.stack.peek(0).toString(16)); ' +
-         '     this.afterSload = false; ' +
-         '   } ' +
-         '   if(log.op.toNumber() == 0x54) {' +
-         '     this.retVal.push(log.getPC() + ": SLOAD " + ' +
-         '        log.stack.peek(0).toString(16));' +
-         '        this.afterSload = true; ' +
-         '   } ' +
-         '   if(log.op.toNumber() == 0x55) ' +
-         '     this.retVal.push(log.getPC() + ": SSTORE " +' +
-         '        log.stack.peek(0).toString(16) + " <- " +' +
-         '        log.stack.peek(1).toString(16));' +
-         '},' +
-         'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
-         'result: function(ctx,db) {return this.retVal}' +
+      'retVal: [],' +
+      'afterSload: false,' +
+      'step: function(log,db) {' +
+      '   if(this.afterSload) {' +
+      '     this.retVal.push("    Result: " + ' +
+      '          log.stack.peek(0).toString(16)); ' +
+      '     this.afterSload = false; ' +
+      '   } ' +
+      '   if(log.op.toNumber() == 0x54) {' +
+      '     this.retVal.push(log.getPC() + ": SLOAD " + ' +
+      '        log.stack.peek(0).toString(16));' +
+      '        this.afterSload = true; ' +
+      '   } ' +
+      '   if(log.op.toNumber() == 0x55) ' +
+      '     this.retVal.push(log.getPC() + ": SSTORE " +' +
+      '        log.stack.peek(0).toString(16) + " <- " +' +
+      '        log.stack.peek(1).toString(16));' +
+      '},' +
+      'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
+      'result: function(ctx,db) {return this.retVal}' +
       '}'
-      }) // return debug.traceTransaction ...
-}   // tracer = function ...
+  }); // return debug.traceTransaction ...
+}; // tracer = function ...
 ```
 
-The output now contains the result in the line that follows the `SLOAD`. 
+The output now contains the result in the line that follows the `SLOAD`.
 
 ```javascript
 [
@@ -229,64 +230,55 @@ So the storage has been treated as if there are only 2<sup>256</sup> cells. Howe
 However, `log.contract.getAddress()` returns an array of bytes. To convert this to the familiar hexadecimal representation of Ethereum addresses, `this.byteHex()` and `array2Hex()` can be used.
 
 ```javascript
-tracer = function(tx) {
-      return debug.traceTransaction(tx, {tracer:
+tracer = function (tx) {
+  return debug.traceTransaction(tx, {
+    tracer:
       '{' +
-         'retVal: [],' +
-         'afterSload: false,' +
-         'callStack: [],' +
-
-         'byte2Hex: function(byte) {' +
-         '  if (byte < 0x10) ' +
-         '      return "0" + byte.toString(16); ' +
-         '  return byte.toString(16); ' +
-         '},' +
-
-         'array2Hex: function(arr) {' +
-         '  var retVal = ""; ' +
-         '  for (var i=0; i<arr.length; i++) ' +
-         '    retVal += this.byte2Hex(arr[i]); ' +
-         '  return retVal; ' +
-         '}, ' +
-
-         'getAddr: function(log) {' +
-         '  return this.array2Hex(log.contract.getAddress());' +
-         '}, ' +
-
-         'step: function(log,db) {' +
-         '   var opcode = log.op.toNumber();' +
-
-         // SLOAD
-         '   if (opcode == 0x54) {' +
-         '     this.retVal.push(log.getPC() + ": SLOAD " + ' +
-         '        this.getAddr(log) + ":" + ' +
-         '        log.stack.peek(0).toString(16));' +
-         '        this.afterSload = true; ' +
-         '   } ' +
-
-         // SLOAD Result
-         '   if (this.afterSload) {' +
-         '     this.retVal.push("    Result: " + ' +
-         '          log.stack.peek(0).toString(16)); ' +
-         '     this.afterSload = false; ' +
-         '   } ' +
-
-         // SSTORE
-         '   if (opcode == 0x55) ' +
-         '     this.retVal.push(log.getPC() + ": SSTORE " +' +
-         '        this.getAddr(log) + ":" + ' +
-         '        log.stack.peek(0).toString(16) + " <- " +' +
-         '        log.stack.peek(1).toString(16));' +
-
-         // End of step
-         '},' +
-
-         'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
-
-         'result: function(ctx,db) {return this.retVal}' +
+      'retVal: [],' +
+      'afterSload: false,' +
+      'callStack: [],' +
+      'byte2Hex: function(byte) {' +
+      '  if (byte < 0x10) ' +
+      '      return "0" + byte.toString(16); ' +
+      '  return byte.toString(16); ' +
+      '},' +
+      'array2Hex: function(arr) {' +
+      '  var retVal = ""; ' +
+      '  for (var i=0; i<arr.length; i++) ' +
+      '    retVal += this.byte2Hex(arr[i]); ' +
+      '  return retVal; ' +
+      '}, ' +
+      'getAddr: function(log) {' +
+      '  return this.array2Hex(log.contract.getAddress());' +
+      '}, ' +
+      'step: function(log,db) {' +
+      '   var opcode = log.op.toNumber();' +
+      // SLOAD
+      '   if (opcode == 0x54) {' +
+      '     this.retVal.push(log.getPC() + ": SLOAD " + ' +
+      '        this.getAddr(log) + ":" + ' +
+      '        log.stack.peek(0).toString(16));' +
+      '        this.afterSload = true; ' +
+      '   } ' +
+      // SLOAD Result
+      '   if (this.afterSload) {' +
+      '     this.retVal.push("    Result: " + ' +
+      '          log.stack.peek(0).toString(16)); ' +
+      '     this.afterSload = false; ' +
+      '   } ' +
+      // SSTORE
+      '   if (opcode == 0x55) ' +
+      '     this.retVal.push(log.getPC() + ": SSTORE " +' +
+      '        this.getAddr(log) + ":" + ' +
+      '        log.stack.peek(0).toString(16) + " <- " +' +
+      '        log.stack.peek(1).toString(16));' +
+      // End of step
+      '},' +
+      'fault: function(log,db) {this.retVal.push("FAULT: " + JSON.stringify(log))},' +
+      'result: function(ctx,db) {return this.retVal}' +
       '}'
-      }) // return debug.traceTransaction ...
-}   // tracer = function ...
+  }); // return debug.traceTransaction ...
+}; // tracer = function ...
 ```
 
 The output is similar to:
@@ -310,12 +302,10 @@ The output is similar to:
 ]
 ```
 
-
 ## Other traces
 
 This tutorial has focused on `debug_traceTransaction()` which reports information about individual transactions. There are also RPC endpoints that provide different information, including tracing the EVM execution within a block, between two blocks, for specific `eth_call`s or rejected blocks. The full list of trace functions can be explored in the [reference documentation](/content/docs/interacting_with_geth/RPC/ns-debug.md).
 
-
 ## Custom Go tracing
 
 Custom tracers can also be made more performant by writing them in Go. The gain in performance mostly comes from the fact that Geth doesn't need
@@ -418,5 +408,3 @@ As can be seen every method of the [EVMLogger interface](https://pkg.go.dev/gith
     ...
 }
 ```
-
-

src/pages/docs/developers/dapp-developer/mobile.md

@@ -3,7 +3,7 @@ title: Geth for Mobile
 description: Introduction to mobile development with Geth
 ---
 
-Embedding clients into mobile devices is an important part of Ethereum's decentralization vision. This is because being able to verify data, follow the chain and submit transactions without relying on centralized intermediaries is critical for censorship resistant access to the network. Doing so on a mobile device is the most convenient route for many users. This relies on Geth running a [light client](/docs/interface/les) on the mobile 
+Embedding clients into mobile devices is an important part of Ethereum's decentralization vision. This is because being able to verify data, follow the chain and submit transactions without relying on centralized intermediaries is critical for censorship resistant access to the network. Doing so on a mobile device is the most convenient route for many users. This relies on Geth running a [light client](/docs/interface/les) on the mobile
 device and exposing an API that developers can use to build mobile apps on top of Geth. This page outlines how to download Geth for mobile and how to get started with managing Ethereum accounts in mobile applications. Ethereum mobile development is relatively nascent, but there is an active developer community. For further information on Geth mobile development visit the #mobile channel in the [Geth discord](https://discord.gg/wQdpS5aA).
 
 ## Download and install
@@ -53,7 +53,7 @@ Similarly to the reusable [Go libraries](content/docs/developers/dapp-developer/
 - Remote node interfacing via different transports
 - Contract interactions through auto-generated bindings
 
-The Geth mobile API is broadly equivalent to the [Go API](/content/docs/developers/dapp-developer/native-accounts.md). The source code can be found in the `mobile` section of Geth's 
+The Geth mobile API is broadly equivalent to the [Go API](/content/docs/developers/dapp-developer/native-accounts.md). The source code can be found in the `mobile` section of Geth's
 [Github](https://github.com/ethereum/go-ethereum/tree/master/mobile).
 
 ## Mobile Account Management
@@ -65,15 +65,15 @@ To support this, Geth provides an accounts library that includes the tools requi
 
 ### Encrypted keystores
 
-Access keys to Ethereum accounts should never be stored in plain-text. Instead, they should be stored encrypted so that even if the mobile device is accessed by a malicious third party the keys are still hidden under an additional layer of security. Geth provides a keystore that enables developers to store keys securely using the [`secp256k1` elliptic curve](https://www.secg.org/sec2-v2.pdf), implemented using [`libsecp256k`](https://github.com/bitcoin-core/secp256k1) and wrapped by [Geth accounts](https://godoc.org/github.com/ethereum/go-ethereum/accounts). 
+Access keys to Ethereum accounts should never be stored in plain-text. Instead, they should be stored encrypted so that even if the mobile device is accessed by a malicious third party the keys are still hidden under an additional layer of security. Geth provides a keystore that enables developers to store keys securely using the [`secp256k1` elliptic curve](https://www.secg.org/sec2-v2.pdf), implemented using [`libsecp256k`](https://github.com/bitcoin-core/secp256k1) and wrapped by [Geth accounts](https://godoc.org/github.com/ethereum/go-ethereum/accounts).
 
 Accounts are stored on disk in the [Web3 Secret Storage](https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition) format. Developers should be aware of these implementation details but are not required to deeply understand the cryptographic primitives in order to use the keystore.
 
-One thing that should be understood, though, is that the cryptographic primitives underpinning the keystore can operate in *light* or *standard* mode. Light mode is computationally cheaper, while standard mode has extra security. Light mode is appropriate for mobile devices, but developers
+One thing that should be understood, though, is that the cryptographic primitives underpinning the keystore can operate in _light_ or _standard_ mode. Light mode is computationally cheaper, while standard mode has extra security. Light mode is appropriate for mobile devices, but developers
 should be aware that there is a security trade-off.
 
-* *standard* needs 256MB memory and 1 second processing on a modern CPU to access a key 
-* *light* needs 4MB memory and 100 millisecond processing on a modern CPU to access a key
+- _standard_ needs 256MB memory and 1 second processing on a modern CPU to access a key
+- _light_ needs 4MB memory and 100 millisecond processing on a modern CPU to access a key
 
 ### Keystores on Android (Java)
 
@@ -92,11 +92,11 @@ KeyStore ks = new KeyStore("/path/to/keystore", Geth.LightScryptN, Geth.LightScr
 
 The keystore should be in a location writable by the local mobile application but on-readable for other installed applications such as inside the app's data directory. If the `KeyStore` is created from within a class extending an Android object, access to the `Context.getFilesDir()` method is probably provided via `this.getFilesDir()`, so the keystore path could be set to `this.getFilesDir() + "/keystore"`.
 
-The last two arguments of the `KeyStore` constructor are the crypto parameters defining how resource-intensive the keystore encryption should be. The choices are `Geth.StandardScryptN, Geth.StandardScryptP`, `Geth.LightScryptN, Geth.LightScryptP` or custom numbers. The *light* version is recommended.
+The last two arguments of the `KeyStore` constructor are the crypto parameters defining how resource-intensive the keystore encryption should be. The choices are `Geth.StandardScryptN, Geth.StandardScryptP`, `Geth.LightScryptN, Geth.LightScryptP` or custom numbers. The _light_ version is recommended.
 
 ### Keystores on iOS (Swift 3)
 
-The encrypted keystore on iOS is implemented by the `GethKeyStore` class from the `Geth` framework. The configuration constants are located in the same namespace as global variables. Hence to do client side account management on iOS, `Geth` framework should be 
+The encrypted keystore on iOS is implemented by the `GethKeyStore` class from the `Geth` framework. The configuration constants are located in the same namespace as global variables. Hence to do client side account management on iOS, `Geth` framework should be
 imported into the Swift code:
 
 ```swift
@@ -112,7 +112,7 @@ let ks = GethNewKeyStore("/path/to/keystore", GethLightScryptN, GethLightScryptP
 The keystore folder needs to be in a location writable by the local mobile application but non-readable for other installed applications such as inside the app's document directory. The document directory shopuld be retrievable using
 `let datadir = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true)[0]`, so the keystore path could be `datadir + "/keystore"`.
 
-The last two arguments of the `GethNewKeyStore` factory method are the crypto parameters defining how resource-intensive the keystore encryption should be. The choices are `GethStandardScryptN, GethStandardScryptP`, `GethLightScryptN, GethLightScryptP` or custom numbers. The *light* version is recommended.
+The last two arguments of the `GethNewKeyStore` factory method are the crypto parameters defining how resource-intensive the keystore encryption should be. The choices are `GethStandardScryptN, GethStandardScryptP`, `GethLightScryptN, GethLightScryptP` or custom numbers. The _light_ version is recommended.
 
 ### Account lifecycle
 
@@ -123,13 +123,13 @@ Although the keystore defines the encryption strength it uses to store accounts,
 
 This individuality means that any operation requiring access to an account will need to provide the necessary authentication credentials for that particular account in the form of a passphrase:
 
- * When creating a new account, the caller must supply a passphrase to encrypt the account with. This passphrase will be required for any subsequent access.
- * When deleting an existing account, the caller must supply a passphrase to verify ownership of the account. This isn't cryptographically necessary, rather a protective measure against accidental loss of accounts.
- * When updating an existing account, the caller must supply both current and new passphrases. After completing the operation, the account will not be accessible via the old passphrase.
- * When exporting an existing account, the caller must supply both the current passphrase to decrypt the account, as well as an export passphrase to re-encrypt it with before returning the key-file to the user. This is required to allow moving accounts between devices without sharing original credentials.
- * When importing a new account, the caller must supply both the encryption passphrase of the key-file being imported, as well as a new passphrase with which to store the account. This is required to allow storing account with different credentials than used for moving them around.
+- When creating a new account, the caller must supply a passphrase to encrypt the account with. This passphrase will be required for any subsequent access.
+- When deleting an existing account, the caller must supply a passphrase to verify ownership of the account. This isn't cryptographically necessary, rather a protective measure against accidental loss of accounts.
+- When updating an existing account, the caller must supply both current and new passphrases. After completing the operation, the account will not be accessible via the old passphrase.
+- When exporting an existing account, the caller must supply both the current passphrase to decrypt the account, as well as an export passphrase to re-encrypt it with before returning the key-file to the user. This is required to allow moving accounts between devices without sharing original credentials.
+- When importing a new account, the caller must supply both the encryption passphrase of the key-file being imported, as well as a new passphrase with which to store the account. This is required to allow storing account with different credentials than used for moving them around.
 
-*Please note, there is no recovery mechanisms for losing the passphrases. The cryptographic properties of the encrypted keystore (if using the provided parameters) guarantee that account credentials cannot be brute forced in any meaningful time.*
+_Please note, there is no recovery mechanisms for losing the passphrases. The cryptographic properties of the encrypted keystore (if using the provided parameters) guarantee that account credentials cannot be brute forced in any meaningful time._
 
 ### Accounts on Android (Java)
 
@@ -187,10 +187,9 @@ As mentioned above, account objects do not hold the sensitive private keys of th
 
 There are a few different ways one can authorize the account manager to execute signing operations. Since the different methods have very different security guarantees, it is essential to be clear on how each works:
 
- * **Single authorization**: The simplest way to sign a transaction via the keystore is to provide the passphrase of the account every time something needs to be signed, which will ephemerally decrypt the private key, execute the signing operation and immediately throw away the decrypted key. The drawbacks are that the passphrase needs to be queried from the user every time, which can become annoying if done frequently; or the application needs to keep the passphrase in memory, which can have security consequences if not done properly; and depending on the keystore's configured strength, constantly decrypting keys can result in non-negligible resource requirements.
-  
- * **Multiple authorizations**: A more complex way of signing transactions via the keystore is to unlock the account via its passphrase once, and allow the account manager to cache the decrypted private key, enabling all subsequent signing requests tocomplete without the passphrase. The lifetime of the cached private key may be managed manually (by explicitly locking the account back up) or automatically (by providing a timeout during unlock). This mechanism is useful for scenarios where the user may need to sign many transactions or the application would need to do so without requiring user input. The crucial aspect to remember is that **anyone with access to the account manager can sign transactions while a particular account is unlocked** (e.g. device left unattended; application running untrusted code).
+- **Single authorization**: The simplest way to sign a transaction via the keystore is to provide the passphrase of the account every time something needs to be signed, which will ephemerally decrypt the private key, execute the signing operation and immediately throw away the decrypted key. The drawbacks are that the passphrase needs to be queried from the user every time, which can become annoying if done frequently; or the application needs to keep the passphrase in memory, which can have security consequences if not done properly; and depending on the keystore's configured strength, constantly decrypting keys can result in non-negligible resource requirements.
 
+- **Multiple authorizations**: A more complex way of signing transactions via the keystore is to unlock the account via its passphrase once, and allow the account manager to cache the decrypted private key, enabling all subsequent signing requests tocomplete without the passphrase. The lifetime of the cached private key may be managed manually (by explicitly locking the account back up) or automatically (by providing a timeout during unlock). This mechanism is useful for scenarios where the user may need to sign many transactions or the application would need to do so without requiring user input. The crucial aspect to remember is that **anyone with access to the account manager can sign transactions while a particular account is unlocked** (e.g. device left unattended; application running untrusted code).
 
 ### Signing on Android (Java)
 
@@ -223,7 +222,7 @@ signed = ks.signTx(signer, tx, chain);
 
 ### Signing on iOS (Swift 3)
 
-Assuming an instance of a `GethKeyStore` called `ks` exists, a new account can be created to sign transactions with its `newAccount` method. For 
+Assuming an instance of a `GethKeyStore` called `ks` exists, a new account can be created to sign transactions with its `newAccount` method. For
 this demonstation a hard-coded example transaction is created to sign:
 
 ```swift
@@ -255,5 +254,3 @@ signed = try! ks?.signTx(signer, tx: tx, chainID: chain)
 ## Summary
 
 This page introduced Geth for mobile. In addition to download and installation instructions, basic account management was demonstrated for mobile applications on iOS and Android.
-
-

src/pages/docs/developers/dapp-developer/native-accounts.md

@@ -3,28 +3,29 @@ title: Go Account Management
 description: Introduction to account management in Go native applications.
 ---
 
-Geth provides a simple, yet thorough accounts package that includes all the tools developers need to leverage all the security of Geth's crypto implementation in a Go native application. The account management is done client side with all sensitive data held inside the application. This gives the user control over access permissions without relying on any third party. 
+Geth provides a simple, yet thorough accounts package that includes all the tools developers need to leverage all the security of Geth's crypto implementation in a Go native application. The account management is done client side with all sensitive data held inside the application. This gives the user control over access permissions without relying on any third party.
 
-**Note Geth's built-in account management is convenient and straightforward to use, but best practise is to use the external tool *Clef* for key management.**
+**Note Geth's built-in account management is convenient and straightforward to use, but best practise is to use the external tool _Clef_ for key management.**
 
 ## Encrypted keystores
 
-Access keys to Ethereum accounts should never be stored in plain-text. Instead, they should be stored encrypted so that even if the mobile device is accessed by a malicious third party the keys are still hidden under an additional layer of security. Geth provides a keystore that enables developers to store keys securely. The Geth keystore uses [Scrypt](https://pkg.go.dev/golang.org/x/crypto/scrypt) to store keys that are encoded using the [`secp256k1`](https://www.secg.org/sec2-v2.pdf) elliptic curve. Accounts are stored on disk in the [Web3 Secret Storage](https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition) format. Developers should be aware of these implementation details 
+Access keys to Ethereum accounts should never be stored in plain-text. Instead, they should be stored encrypted so that even if the mobile device is accessed by a malicious third party the keys are still hidden under an additional layer of security. Geth provides a keystore that enables developers to store keys securely. The Geth keystore uses [Scrypt](https://pkg.go.dev/golang.org/x/crypto/scrypt) to store keys that are encoded using the [`secp256k1`](https://www.secg.org/sec2-v2.pdf) elliptic curve. Accounts are stored on disk in the [Web3 Secret Storage](https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition) format. Developers should be aware of these implementation details
 but are not required to deeply understand the cryptographic primitives in order to use the keystore.
 
 One thing that should be understood, though, is that the cryptographic primitives underpinning the keystore can operate in light or standard mode.Light mode is computationally cheaper, while standard mode has extra security. Light mode is appropriate for mobile devices, but developers should be aware that there is a security trade-off.
 
-* standard needs 256MB memory and 1 second processing on a modern CPU to access a key
-* light needs 4MB memory and 100 millisecond processing on a modern CPU to access a key
+- standard needs 256MB memory and 1 second processing on a modern CPU to access a key
+- light needs 4MB memory and 100 millisecond processing on a modern CPU to access a key
 
-The encrypted keystore is implemented by the [`accounts.Manager`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Manager) struct from the [`accounts`](https://godoc.org/github.com/ethereum/go-ethereum/accounts) package, which also contains the configuration constants for the *standard* or *light* security modes described above. Hence client side account management 
-simply requires importing the `accounts` package into the application code. 
+The encrypted keystore is implemented by the [`accounts.Manager`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Manager) struct from the [`accounts`](https://godoc.org/github.com/ethereum/go-ethereum/accounts) package, which also contains the configuration constants for the _standard_ or _light_ security modes described above. Hence client side account management
+simply requires importing the `accounts` package into the application code.
 
 ```go
 import "github.com/ethereum/go-ethereum/accounts"
 import "github.com/ethereum/go-ethereum/accounts/keystore"
 import "github.com/ethereum/go-ethereum/common"
 ```
+
 Afterwards a new encrypted account manager can be created via:
 
 ```go
@@ -34,7 +35,7 @@ am := accounts.NewManager(&accounts.Config{InsecureUnlockAllowed: false}, ks)
 
 The path to the keystore folder needs to be a location that is writable by the local user but non-readable for other system users, such as inside the user's home directory.
 
-The last two arguments of [`keystore.NewKeyStore`](https://godoc.org/github.com/ethereum/go-ethereum/accounts/keystore#NewKeyStore) are the crypto parameters defining how resource-intensive the keystore encryption should be. The options are [`accounts.StandardScryptN, accounts.StandardScryptP`, `accounts.LightScryptN, accounts.LightScryptP`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#pkg-constants) or custom values (requiring understanding of the underlying cryptography). The *standard* version is recommended.
+The last two arguments of [`keystore.NewKeyStore`](https://godoc.org/github.com/ethereum/go-ethereum/accounts/keystore#NewKeyStore) are the crypto parameters defining how resource-intensive the keystore encryption should be. The options are [`accounts.StandardScryptN, accounts.StandardScryptP`, `accounts.LightScryptN, accounts.LightScryptP`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#pkg-constants) or custom values (requiring understanding of the underlying cryptography). The _standard_ version is recommended.
 
 ## Account lifecycle
 
@@ -44,17 +45,17 @@ Although the keystore defines the encryption strength it uses to store accounts,
 
 This individuality means that any operation requiring access to an account will need to provide the necessary authentication credentials for that particular account in the form of a passphrase:
 
-* When creating a new account, the caller must supply a passphrase to encrypt the account with. This passphrase will be required for any subsequent access, the lack of which will forever forfeit using the newly created account.
+- When creating a new account, the caller must supply a passphrase to encrypt the account with. This passphrase will be required for any subsequent access, the lack of which will forever forfeit using the newly created account.
 
-* When deleting an existing account, the caller must supply a passphrase to verify  ownership of the account. This isn't cryptographically necessary, rather a protective measure against accidental loss of accounts.
+- When deleting an existing account, the caller must supply a passphrase to verify ownership of the account. This isn't cryptographically necessary, rather a protective measure against accidental loss of accounts.
 
-* When updating an existing account, the caller must supply both current and new passphrases. After completing the operation, the account will not be accessible via the old passphrase any more.
+- When updating an existing account, the caller must supply both current and new passphrases. After completing the operation, the account will not be accessible via the old passphrase any more.
 
-* When exporting an existing account, the caller must supply both the current passphrase to decrypt the account, as well as an export passphrase to re-encrypt it with before returning the key-file to the user. This is required to allow moving accounts between machines and applications without sharing original credentials.
+- When exporting an existing account, the caller must supply both the current passphrase to decrypt the account, as well as an export passphrase to re-encrypt it with before returning the key-file to the user. This is required to allow moving accounts between machines and applications without sharing original credentials.
 
-* When importing a new account, the caller must supply both the encryption passphrase of the key-file being imported, as well as a new passhprase with which to store the account. This is required to allow storing account with different credentials than used for moving them around.
+- When importing a new account, the caller must supply both the encryption passphrase of the key-file being imported, as well as a new passhprase with which to store the account. This is required to allow storing account with different credentials than used for moving them around.
 
-***Please note, there are no recovery mechanisms for lost passphrases. The cryptographic properties of the encrypted keystore (using the provided parameters) guarantee that account credentials cannot be brute forced in any meaningful time.***
+**_Please note, there are no recovery mechanisms for lost passphrases. The cryptographic properties of the encrypted keystore (using the provided parameters) guarantee that account credentials cannot be brute forced in any meaningful time._**
 
 An Ethereum account is implemented by the [`accounts.Account`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Account) struct from the Geth [accounts](https://godoc.org/github.com/ethereum/go-ethereum/accounts) package. Assuming an instance of an [`accounts.Manager`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Manager) called `am` exists, all of the described lifecycle operations can be executed with a handful of function calls (error handling omitted).
 
@@ -78,7 +79,7 @@ _ = ks.Delete(newAcc, "Update password")
 impAcc, _ := ks.Import(jsonAcc, "Export password", "Import password")
 ```
 
-*Although instances of [`accounts.Account`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Account) can be used to access various information about specific Ethereum accounts, they do not contain any sensitive data (such as passphrases or private keys), rather they act solely as identifiers for client code and the keystore.*
+_Although instances of [`accounts.Account`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Account) can be used to access various information about specific Ethereum accounts, they do not contain any sensitive data (such as passphrases or private keys), rather they act solely as identifiers for client code and the keystore._
 
 ## Signing authorization
 
@@ -86,9 +87,9 @@ Account objects do not hold the sensitive private keys of the associated Ethereu
 
 There are a few different ways to authorize the account manager to execute signing operations, each having its advantages and drawbacks. Since the different methods have wildly different security guarantees, it is essential to be clear on how each works:
 
-* **Single authorization**: The simplest way to sign a transaction via the account manager is to provide the passphrase of the account every time something needs to be signed, which will ephemerally decrypt the private key, execute the signing operation and immediately throw away the decrypted key. The drawbacks are that the passphrase needs to be queried from the user every time, which can become annoying if done frequently or the application needs to keep the passphrase in memory, which can have security consequences if not done properly. Depending on the keystore's configured strength, constantly decrypting keys can result in non-negligible resource requirements.
+- **Single authorization**: The simplest way to sign a transaction via the account manager is to provide the passphrase of the account every time something needs to be signed, which will ephemerally decrypt the private key, execute the signing operation and immediately throw away the decrypted key. The drawbacks are that the passphrase needs to be queried from the user every time, which can become annoying if done frequently or the application needs to keep the passphrase in memory, which can have security consequences if not done properly. Depending on the keystore's configured strength, constantly decrypting keys can result in non-negligible resource requirements.
 
-* **Multiple authorizations**: A more complex way of signing transactions via the account manager is to unlock the account via its passphrase once, and allow the account manager to cache the decrypted private key, enabling all subsequent signing requests to complete without the passphrase. The lifetime of the cached private key may be managed manually (by explicitly locking the account back up) or automatically (by providing a timeout during unlock). This mechanism is useful for scenarios where the user may need to sign many transactions or the application would need to do so without requiring user input. The crucial aspect to remember is that **anyone with access to the account manager can sign transactions while a particular account is unlocked** (e.g. application running untrusted code).
+- **Multiple authorizations**: A more complex way of signing transactions via the account manager is to unlock the account via its passphrase once, and allow the account manager to cache the decrypted private key, enabling all subsequent signing requests to complete without the passphrase. The lifetime of the cached private key may be managed manually (by explicitly locking the account back up) or automatically (by providing a timeout during unlock). This mechanism is useful for scenarios where the user may need to sign many transactions or the application would need to do so without requiring user input. The crucial aspect to remember is that **anyone with access to the account manager can sign transactions while a particular account is unlocked** (e.g. application running untrusted code).
 
 Assuming an instance of an [`accounts.Manager`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Manager) called `am` exists, a new account can be created to sign transactions using [`NewAccount`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Manager.NewAccount). Creating transactions is out of scope for this page so instead a random [`common.Hash`](https://godoc.org/github.com/ethereum/go-ethereum/common#Hash) will be signed instead.
 
@@ -121,4 +122,3 @@ Note that [`SignWithPassphrase`](https://godoc.org/github.com/ethereum/go-ethere
 ## Summary
 
 Account management is a fundamental pillar of Ethereum development. Geth's Go API provides the tools required to integrate best-practise account security into Go native applications using a simple set of Go functions.
-

src/pages/docs/developers/dapp-developer/native-bindings.md

@@ -13,10 +13,9 @@ This page provides an introduction to generating Go contract bindings and using
 
 This page is fairly beginner-friendly and designed for people starting out with writing Go native dapps. The core concepts will be introduced gradually as a developer would encounter them. However, some basic familiarity with [Ethereum](https://ethereum.org), [Solidity](https://docs.soliditylang.org/en/v0.8.15/) and [Go](https://go.dev/) is assumed.
 
-
 ## What is an ABI?
 
-Ethereum smart contracts have a schema that defines its functions and return types in the form of a JSON file. This JSON file is known as an *Application Binary Interface*, or ABI. The ABI acts as a specification for precisely how to encode data sent to a contract and how to decode the data the contract sends back. The ABI is the only essential piece of information required to generate Go bindings. Go developers can then use the bindings to interact with the contract from their Go application without having to deal directly with data encoding and decoding. An ABI is generated when a contract is compiled.
+Ethereum smart contracts have a schema that defines its functions and return types in the form of a JSON file. This JSON file is known as an _Application Binary Interface_, or ABI. The ABI acts as a specification for precisely how to encode data sent to a contract and how to decode the data the contract sends back. The ABI is the only essential piece of information required to generate Go bindings. Go developers can then use the bindings to interact with the contract from their Go application without having to deal directly with data encoding and decoding. An ABI is generated when a contract is compiled.
 
 ## Abigen: Go binding generator
 
@@ -67,7 +66,22 @@ The ABI can also be generated in other ways such as using the `compile` commands
 The ABI for `Storage.sol` (`Storage.abi`) looks as follows:
 
 ```json
-[{"inputs":[],"name":"retrieve","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"stateMutability":"view","type":"function"},{"inputs":[{"internalType":"uint256","name":"number","type":"uint256"}],"name":"store","outputs":[],"stateMutability":"nonpayable","type":"function"}]
+[
+  {
+    "inputs": [],
+    "name": "retrieve",
+    "outputs": [{ "internalType": "uint256", "name": "", "type": "uint256" }],
+    "stateMutability": "view",
+    "type": "function"
+  },
+  {
+    "inputs": [{ "internalType": "uint256", "name": "number", "type": "uint256" }],
+    "name": "store",
+    "outputs": [],
+    "stateMutability": "nonpayable",
+    "type": "function"
+  }
+]
 ```
 
 The contract binding can then be generated by passing the ABI to `abigen` as follows:
@@ -78,10 +92,10 @@ $ abigen --abi Storage.abi --pkg main --type Storage --out Storage.go
 
 Where the flags are:
 
- * `--abi`: Mandatory path to the contract ABI to bind to
- * `--pkg`: Mandatory Go package name to place the Go code into
- * `--type`: Optional Go type name to assign to the binding struct
- * `--out`: Optional output path for the generated Go source file (not set = stdout)
+- `--abi`: Mandatory path to the contract ABI to bind to
+- `--pkg`: Mandatory Go package name to place the Go code into
+- `--type`: Optional Go type name to assign to the binding struct
+- `--out`: Optional output path for the generated Go source file (not set = stdout)
 
 This will generate a type-safe Go binding for the Storage contract. The generated code will look something like the snippet below, the full version of which can be viewed [here](https://gist.github.com/jmcook1186/a78e59d203bb54b06e1b81f2cda79d93).
 
@@ -150,7 +164,6 @@ solc --bin Storage.sol -o Storage.bin
 
 Then `abigen` can be run again, this time passing `Storage.bin`:
 
-
 ```
 $ abigen --abi Storage.abi --pkg main --type Storage --out Storage.go --bin Storage.bin
 ```
@@ -175,6 +188,7 @@ func DeployStorage(auth *bind.TransactOpts, backend bind.ContractBackend) (commo
 	return address, tx, &Storage{StorageCaller: StorageCaller{contract: contract}, StorageTransactor: StorageTransactor{contract: contract}, StorageFilterer: StorageFilterer{contract: contract}}, nil
 }
 ```
+
 View the full file [here](https://gist.github.com/jmcook1186/91124cfcbc7f22dcd3bb4f148d2868a8).
 
 The new `DeployStorage()` function can be used to deploy the contract to an Ethereum testnet from a Go application. To do this requires incorporating the bindings into a Go application that also handles account management, authorization and Ethereum backend to deploy the contract through. Specifically, this requires:
@@ -241,30 +255,29 @@ Transaction waiting to be mined: 0x6a81231874edd2461879b7280ddde1a857162a744e365
 Pending name: Storage contract in Go!
 ```
 
-Once the contract deployment has been included in a validated block, the contract exists permanently at its deployment address and can now be interacted with from other applications without ever needing to be redeployed. 
+Once the contract deployment has been included in a validated block, the contract exists permanently at its deployment address and can now be interacted with from other applications without ever needing to be redeployed.
 
 Note that `DeployStorage` returns four variables:
 
 - `address`: the deployment address of the contract
- 
+
 - `tx`: the transaction hash that can be queried using Geth or a service like [Etherscan](etherscan.io)
- 
-- `instance`: an instance of the deployed contract whose functions can be called in the Go application 
- 
+
+- `instance`: an instance of the deployed contract whose functions can be called in the Go application
+
 - `err`: a variable that handles errors in case of a deployment failure
- 
 
 ### Accessing an Ethereum contract
 
 To interact with a contract already deployed on the blockchain, the deployment `address` is required and a `backend` through which to access Ethereum must be defined. The binding generator provides an RPC backend out-of-the-box that can be used to attach to an existing Ethereum node via IPC, HTTP or WebSockets.
 
-As in the previous section, a  Geth node running on an Ethereum testnet (recommend Goerli) and an account with some test ETH to cover gas is required. The `Storage.sol` deployment address is also needed.
+As in the previous section, a Geth node running on an Ethereum testnet (recommend Goerli) and an account with some test ETH to cover gas is required. The `Storage.sol` deployment address is also needed.
 
-Again, an instance of `ethclient` can be created, passing the path to Geth's ipc file. In the example below this backend is assigned to the variable `conn`. 
+Again, an instance of `ethclient` can be created, passing the path to Geth's ipc file. In the example below this backend is assigned to the variable `conn`.
 
 ```go
 // Create an IPC based RPC connection to a remote node
-// NOTE update the path to the ipc file! 
+// NOTE update the path to the ipc file!
 conn, err := ethclient.Dial("/home/go-ethereum/goerli/geth.ipc")
 if err != nil {
 	log.Fatalf("Failed to connect to the Ethereum client: %v", err)
@@ -286,7 +299,6 @@ func NewStorage(address common.Address, backend bind.ContractBackend) (*Storage,
 
 `NewStorage()` takes two arguments: the deployment address and a backend (`conn`) and returns an instance of the deployed contract. In the example below, the instance is assigned to `store`.
 
-
 ```go
 package main
 
@@ -300,7 +312,7 @@ import (
 
 func main() {
 	// Create an IPC based RPC connection to a remote node
-	// NOTE update the path to the ipc file! 
+	// NOTE update the path to the ipc file!
 	conn, err := ethclient.Dial("/home/go-ethereum/goerli/geth.ipc")
 	if err != nil {
 		log.Fatalf("Failed to connect to the Ethereum client: %v", err)
@@ -337,8 +349,8 @@ func (_Storage *StorageCaller) Retrieve(opts *bind.CallOpts) (*big.Int, error) {
 
 Note that the `Retrieve()` function requires a parameter to be passed, even though the original Solidity contract didn't require any at all none. The parameter required is a `*bind.CallOpts` type, which can be used to fine tune the call. If no adjustments to the call are required, pass `nil`. Adjustments to the call include:
 
-* `Pending`: Whether to access pending contract state or the current stable one
-* `GasLimit`: Place a limit on the computing resources the call might consume
+- `Pending`: Whether to access pending contract state or the current stable one
+- `GasLimit`: Place a limit on the computing resources the call might consume
 
 So to call the `Retrieve()` function in the Go application:
 
@@ -413,16 +425,15 @@ Update pending: 0x4f4aaeb29ed48e88dd653a81f0b05d4df64a86c99d4e83b5bfeb0f0006b0e5
 
 Similar to the method invocations in the previous section which only read contract state, transacting methods also require a mandatory first parameter, a `*bind.TransactOpts` type, which authorizes the transaction and potentially fine tunes it:
 
-* `From`: Address of the account to invoke the method with (mandatory)
-* `Signer`: Method to sign a transaction locally before broadcasting it (mandatory)
-* `Nonce`: Account nonce to use for the transaction ordering (optional)
-* `GasLimit`: Place a limit on the computing resources the call might consume (optional)
-* `GasPrice`: Explicitly set the gas price to run the transaction with (optional)
-* `Value`: Any funds to transfer along with the method call (optional)
+- `From`: Address of the account to invoke the method with (mandatory)
+- `Signer`: Method to sign a transaction locally before broadcasting it (mandatory)
+- `Nonce`: Account nonce to use for the transaction ordering (optional)
+- `GasLimit`: Place a limit on the computing resources the call might consume (optional)
+- `GasPrice`: Explicitly set the gas price to run the transaction with (optional)
+- `Value`: Any funds to transfer along with the method call (optional)
 
 The two mandatory fields are automatically set by the `bind` package if the auth options are constructed using `bind.NewTransactor`. The nonce and gas related fields are automatically derived by the binding if they are not set. Unset values are assumed to be zero.
 
-
 ### Pre-configured contract sessions
 
 Reading and state modifying contract-calls require a mandatory first parameter which can authorize and fine tune some of the internal parameters. However, most of the time the same accounts and parameters will be used to issue many transactions, so constructing the call/transact options individually quickly becomes unwieldy.
@@ -470,10 +481,9 @@ Place the binding generation command into a Go source file before the package de
 
 After which whenever the Solidity contract is modified, instead of needing to remember and run the above command, we can simply call `go generate` on the package (or even the entire source tree via `go generate ./...`), and it will correctly generate the new bindings for us.
 
-
 ## Blockchain simulator
 
-Being able to deploy and access deployed Ethereum contracts from native Go code is a powerful feature. However, using public testnets as a backend does not lend itself well to *automated unit testing*. Therefore, Geth also implements a *simulated blockchain* that can be set as a backend to native contracts the same way as a live RPC backend, using the command `backends.NewSimulatedBackend(genesisAccounts)`. The code snippet below shows how this can be used as a backend in a Go application.
+Being able to deploy and access deployed Ethereum contracts from native Go code is a powerful feature. However, using public testnets as a backend does not lend itself well to _automated unit testing_. Therefore, Geth also implements a _simulated blockchain_ that can be set as a backend to native contracts the same way as a live RPC backend, using the command `backends.NewSimulatedBackend(genesisAccounts)`. The code snippet below shows how this can be used as a backend in a Go application.
 
 ```go
 package main
@@ -515,7 +525,6 @@ func main() {
 }
 ```
 
-
 ## Summary
 
 To make interacting with Ethereum contracts easier for Go developers, Geth provides tools that generate contract bindings automatically. This makes contract functions available in Go native applications.

src/pages/docs/developers/dapp-developer/native.md

@@ -11,7 +11,7 @@ To support this, Geth ships official Go packages that can be embedded into third
 
 This page provides a high-level overview of the Go API.
 
-*Note, this guide will assume some familiarity with Go development. It does not cover general topics about Go project layouts, import paths or any other standard methodologies. If you are new to Go, consider reading [Getting Started with Go](https://github.com/golang/go/wiki#getting-started-with-go) first.*
+_Note, this guide will assume some familiarity with Go development. It does not cover general topics about Go project layouts, import paths or any other standard methodologies. If you are new to Go, consider reading [Getting Started with Go](https://github.com/golang/go/wiki#getting-started-with-go) first._
 
 ## Overview
 
@@ -41,10 +41,9 @@ $ go get -d github.com/ethereum/go-ethereum/...
 
 More Go API support for dapp developers can be found on the [Go Contract Bindings](/content/docs/developers/dapp-developer/native-bindings.md) and [Go Account Management](/docs/dapp/native-accounts) pages.
 
-
 ## Tutorial
 
-This section includes some basic usage examples for the `ethclient` and `gethclient` packages available as part of the Go API. The `ethclient` package provides a client that implements the full Ethereum JSON-RPC API, whereas `gethclient` offers the Geth-specific API. 
+This section includes some basic usage examples for the `ethclient` and `gethclient` packages available as part of the Go API. The `ethclient` package provides a client that implements the full Ethereum JSON-RPC API, whereas `gethclient` offers the Geth-specific API.
 
 ### Instantiating a client
 
@@ -65,7 +64,7 @@ _ = cl
 
 The client can now be used to handle requests to the Geth node using the full JSON-RPC API. For example, the function `BlockNumer()` wraps a call to the `eth_blockNumber` endpoint. The function `SendTransaction` wraps a call to `eth_sendTransaction`. The full list of client methods can be found [here](https://pkg.go.dev/github.com/ethereum/go-ethereum/ethclient#Client).
 
-Frequently, the functions take an instance of the `Context` type as their leading argument. This defines context about requests sent from the application such as deadlines, cancellation signals etc. More information on this can be found in the [Go documentation](https://pkg.go.dev/golang.org/x/net/context). An empty context instance can be created using `Context.Background()`. 
+Frequently, the functions take an instance of the `Context` type as their leading argument. This defines context about requests sent from the application such as deadlines, cancellation signals etc. More information on this can be found in the [Go documentation](https://pkg.go.dev/golang.org/x/net/context). An empty context instance can be created using `Context.Background()`.
 
 ### Querying client for data
 
@@ -108,7 +107,7 @@ if err != nil {
 ### Sending a transaction
 
 Sending a transaction is achieved using the `SendTransaction()` function. `SendTransaction` takes an instance of `context.Context` as its leading argument and a signed transaction as its second argument. The signed transaction must be generated in advance. Building the signed transaction is a multi-stage process that requires first generating a key pair if none exists already, retrieving some chain data and defining sender and recipient
-addresses. Then these data can be collected into a transaction object and signed. The resulting signed transaction can then be passed to `SendTransaction`. 
+addresses. Then these data can be collected into a transaction object and signed. The resulting signed transaction can then be passed to `SendTransaction`.
 
 The example below assumes the following key pair has already been generated:
 
@@ -187,13 +186,11 @@ MemStats()
 SetHead()
 SubscribePendingTransactions()
 ```
-*Note that both `ethclient` and `gethclient` have a `CallContract()` function - the difference is that the `gethclient` version includes an `overrides` argument.*
 
-Details relating to these endpoints can be found at [pkg.go.dev](https://pkg.go.dev/github.com/ethereum/go-ethereum@v1.10.19/ethclient/gethclient) or the Geth [Github](https://github.com/ethereum/go-ethereum/tree/master/ethclient). The code snippets in this tutorial were adapted from a more more in-depth set of examples available on [Github](https://github.com/MariusVanDerWijden/web3go). 
+_Note that both `ethclient` and `gethclient` have a `CallContract()` function - the difference is that the `gethclient` version includes an `overrides` argument._
 
+Details relating to these endpoints can be found at [pkg.go.dev](https://pkg.go.dev/github.com/ethereum/go-ethereum@v1.10.19/ethclient/gethclient) or the Geth [Github](https://github.com/ethereum/go-ethereum/tree/master/ethclient). The code snippets in this tutorial were adapted from a more more in-depth set of examples available on [Github](https://github.com/MariusVanDerWijden/web3go).
 
 ## Summary
 
 There are a wide variety of Go APIs available for dapp developers that abstract away the complexity of interacting with Ethereum using a set of composable, reusable functions provided by Geth.
-
-

src/pages/docs/developers/dapp-developer/tracing.md

@@ -9,43 +9,42 @@ Having code associated with Ethereum accounts permits transactions to do arbitra
 
 The downside of contract execution is that it is very hard to say what a transaction actually did. A transaction receipt does contain a status code to check whether execution succeeded or not, but there is no way to see what data was modified, nor what external contracts where invoked. Geth resolves this by re-running transactions locally and collecting data about precisely what was executed by the EVM. This is known as "tracing" the transaction.
 
-
 ## Tracing prerequisites
 
 In its simplest form, tracing a transaction entails requesting the Ethereum node to reexecute the desired transaction with varying degrees of data collection and have it return the aggregated summary for post processing. Reexecuting a transaction however has a few prerequisites to be met.
 
 In order for an Ethereum node to reexecute a transaction, all historical state accessed by the transaction must be available. This includes:
 
-* Balance, nonce, bytecode and storage of both the recipient as well as all internally invoked contracts.
-* Block metadata referenced during execution of both the outer as well as all internally created transactions.
-* Intermediate state generated by all preceding transactions contained in the same block as the one being traced.
+- Balance, nonce, bytecode and storage of both the recipient as well as all internally invoked contracts.
+- Block metadata referenced during execution of both the outer as well as all internally created transactions.
+- Intermediate state generated by all preceding transactions contained in the same block as the one being traced.
 
 This means there are limits on the transactions that can be traced imposed by the synchronization and pruning configuration of a node.
 
-* An **archive** node retains **all historical data** back to genesis. It can therefore trace arbitrary transactions at any point in the history of the chain. Tracing a single transaction requires reexecuting all preceding transactions in the same block.
+- An **archive** node retains **all historical data** back to genesis. It can therefore trace arbitrary transactions at any point in the history of the chain. Tracing a single transaction requires reexecuting all preceding transactions in the same block.
 
-* A **full synced** node retains the most recent 128 blocks in memory, so transactions in that range are always accessible. Full nodes also store occasional checkpoints back to genesis that can be used to rebuild the state at any point on-the-fly. This means older transactions can be traced but if there is a large distance between the requested transaction and the most recent checkpoint rebuilding the state can take a long time. Tracing a single transaction requires reexecuting all preceding transactions in the same block **and** all preceding blocks until the previous stored snapshot.
+- A **full synced** node retains the most recent 128 blocks in memory, so transactions in that range are always accessible. Full nodes also store occasional checkpoints back to genesis that can be used to rebuild the state at any point on-the-fly. This means older transactions can be traced but if there is a large distance between the requested transaction and the most recent checkpoint rebuilding the state can take a long time. Tracing a single transaction requires reexecuting all preceding transactions in the same block **and** all preceding blocks until the previous stored snapshot.
 
-* A **snap synced** node holds the most recent 128 blocks in memory, so transactions in that range are always accessible. However, snap-sync only starts processing from a relatively recent block (as opposed to genesis for a full node). Between the initial sync block and the 128 most recent blocks, the node stores occasional checkpoints that can be used to rebuild the state on-the-fly. This means transactions can be traced back as far as the block that was used for the initial sync. Tracing a single transaction requires reexecuting all preceding transactions in the same block,
-**and** all preceding blocks until the previous stored snapshot.
+- A **snap synced** node holds the most recent 128 blocks in memory, so transactions in that range are always accessible. However, snap-sync only starts processing from a relatively recent block (as opposed to genesis for a full node). Between the initial sync block and the 128 most recent blocks, the node stores occasional checkpoints that can be used to rebuild the state on-the-fly. This means transactions can be traced back as far as the block that was used for the initial sync. Tracing a single transaction requires reexecuting all preceding transactions in the same block,
+  **and** all preceding blocks until the previous stored snapshot.
 
-* A **light synced** node retrieving data **on demand** can in theory trace transactions for which all required historical state is readily available in the network. This is because the data required to generate the trace is requested from an les-serving full node. In practice, data 
-availability **cannot** be reasonably assumed.
+- A **light synced** node retrieving data **on demand** can in theory trace transactions for which all required historical state is readily available in the network. This is because the data required to generate the trace is requested from an les-serving full node. In practice, data
+  availability **cannot** be reasonably assumed.
 
-*There are exceptions to the above rules when running batch traces of entire blocks or chain segments. Those will be detailed later.*
+_There are exceptions to the above rules when running batch traces of entire blocks or chain segments. Those will be detailed later._
 
 ## Basic traces
 
-The simplest type of transaction trace that Geth can generate are raw EVM opcode traces. For every VM instruction the transaction executes, a structured log entry is emitted, containing all contextual metadata deemed useful. This includes the *program counter*, *opcode name*, *opcode cost*, *remaining gas*, *execution depth* and any *occurred error*. The structured logs can optionally also contain the content of the *execution stack*, *execution memory* and *contract storage*.
+The simplest type of transaction trace that Geth can generate are raw EVM opcode traces. For every VM instruction the transaction executes, a structured log entry is emitted, containing all contextual metadata deemed useful. This includes the _program counter_, _opcode name_, _opcode cost_, _remaining gas_, _execution depth_ and any _occurred error_. The structured logs can optionally also contain the content of the _execution stack_, _execution memory_ and _contract storage_.
 
-The entire output of a raw EVM opcode trace is a JSON object having a few metadata fields: *consumed gas*, *failure status*, *return value*; and a list of *opcode entries*:
+The entire output of a raw EVM opcode trace is a JSON object having a few metadata fields: _consumed gas_, _failure status_, _return value_; and a list of _opcode entries_:
 
 ```json
 {
-  "gas":         25523,
-  "failed":      false,
+  "gas": 25523,
+  "failed": false,
   "returnValue": "",
-  "structLogs":  []
+  "structLogs": []
 }
 ```
 
@@ -53,12 +52,12 @@ An example log for a single opcode entry has the following format:
 
 ```json
 {
-  "pc":      48,
-  "op":      "DIV",
+  "pc": 48,
+  "op": "DIV",
   "gasCost": 5,
-  "gas":     64532,
-  "depth":   1,
-  "error":   null,
+  "gas": 64532,
+  "depth": 1,
+  "error": null,
   "stack": [
     "00000000000000000000000000000000000000000000000000000000ffffffff",
     "0000000100000000000000000000000000000000000000000000000000000000",
@@ -69,8 +68,7 @@ An example log for a single opcode entry has the following format:
     "0000000000000000000000000000000000000000000000000000000000000000",
     "0000000000000000000000000000000000000000000000000000000000000060"
   ],
-  "storage": {
-  }
+  "storage": {}
 }
 ```
 
@@ -81,7 +79,7 @@ To generate a raw EVM opcode trace, Geth provides a few [RPC API endpoints](/doc
 In its simplest form, `traceTransaction` accepts a transaction hash as its only argument. It then traces the transaction, aggregates all the generated data and returns it as a **large** JSON object. A sample invocation from the Geth console would be:
 
 ```js
-debug.traceTransaction("0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa71226b7aa92c6f")
+debug.traceTransaction('0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa71226b7aa92c6f');
 ```
 
 The same call can also be invoked from outside the node too via HTTP RPC (e.g. using Curl). In this case, the HTTP endpoint must be enabled in Geth using the `--http` command and the `debug` API namespace must be exposed using `--http.api=debug`.
@@ -92,7 +90,7 @@ $ curl -H "Content-Type: application/json" -d '{"id": 1, "method": "debug_traceT
 
 To follow along with this tutorial, transaction hashes can be found from a local Geth node (e.g. by attaching a [Javascript console](/docs/interface/javascript-console) and running `eth.getBlock('latest')` then passing a transaction hash from the returned block to `debug.traceTransaction()`) or from a block explorer (for [Mainnet](https://etherscan.io/) or a [testnet](https://goerli.etherscan.io/)).
 
-It is also possible to configure the trace by passing Boolean (true/false) values for four parameters that tweak the verbosity of the trace. By default, the *EVM memory* and *Return data* are not reported but the *EVM stack* and *EVM storage* are. To report the maximum amount of data:
+It is also possible to configure the trace by passing Boolean (true/false) values for four parameters that tweak the verbosity of the trace. By default, the _EVM memory_ and _Return data_ are not reported but the _EVM stack_ and _EVM storage_ are. To report the maximum amount of data:
 
 ```shell
 enableMemory: true
@@ -104,12 +102,17 @@ enableReturnData: true
 An example call, made in the Geth Javascript console, configured to report the maximum amount of data looks as follows:
 
 ```js
-debug.traceTransaction("0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa71226b7aa92c6f",{enableMemory: true, disableStack: false, disableStorage: false, enableReturnData: true})
+debug.traceTransaction('0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa71226b7aa92c6f', {
+  enableMemory: true,
+  disableStack: false,
+  disableStorage: false,
+  enableReturnData: true
+});
 ```
 
 Running the above operation on the Rinkeby network (with a node retaining enough history) will result in this [trace dump](https://gist.github.com/karalabe/c91f95ac57f5e57f8b950ec65ecc697f).
 
-Alternatively, disabling *EVM Stack*, *EVM Memory*, *Storage* and *Return data* (as demonstrated in the Curl request below) results in the following, much shorter, [trace dump](https://gist.github.com/karalabe/d74a7cb33a70f2af75e7824fc772c5b4).
+Alternatively, disabling _EVM Stack_, _EVM Memory_, _Storage_ and _Return data_ (as demonstrated in the Curl request below) results in the following, much shorter, [trace dump](https://gist.github.com/karalabe/d74a7cb33a70f2af75e7824fc772c5b4).
 
 ```
 $ curl -H "Content-Type: application/json" -d '{"id": 1, "method": "debug_traceTransaction", "params": ["0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa71226b7aa92c6f", {"disableStack": true, "disableStorage": true}]}' localhost:8545
@@ -119,11 +122,11 @@ $ curl -H "Content-Type: application/json" -d '{"id": 1, "method": "debug_traceT
 
 Although the raw opcode traces generated above are useful, having an individual log entry for every single opcode is too low level for most use cases, and will require developers to create additional tools to post-process the traces. Additionally, a full opcode trace can easily go into the hundreds of megabytes, making them very resource intensive to get out of the node and process externally.
 
-To avoid those issues, Geth supports running custom JavaScript tracers *within* the Ethereum node, which have full access to the EVM stack, memory and contract storage. This means developers only have to gather the data they actually need, and do any processing at the source.
+To avoid those issues, Geth supports running custom JavaScript tracers _within_ the Ethereum node, which have full access to the EVM stack, memory and contract storage. This means developers only have to gather the data they actually need, and do any processing at the source.
 
 ## Pruning
 
-Geth does in-memory state-pruning by default, discarding state entries that it deems no longer necessary to maintain. This is configured via the `--gcmode` command. An error message alerting the user that the necessary state is not available is common in EVM tracing on 
+Geth does in-memory state-pruning by default, discarding state entries that it deems no longer necessary to maintain. This is configured via the `--gcmode` command. An error message alerting the user that the necessary state is not available is common in EVM tracing on
 anything other than an archive node.
 
 ```sh
@@ -149,6 +152,4 @@ The time taken to regenerate a specific state increases with the distance betwee
 
 This page covered the concept of EVM tracing and how to generate traces with the default opcode-based tracers using RPC. More advanced usage is possible, including using other built-in tracers as well as writing [custom tracing](/docs/dapp/custom-tracer) code in Javascript and Go. The API as well as the JS tracing hooks are defined in [the reference](/docs/rpc/ns-debug#debug_traceTransaction).
 
-
-
-[evm]: 
+[evm]:

src/pages/docs/developers/geth-developer/code-review-guidelines.md

@@ -7,13 +7,11 @@ The only way to get code into Geth is to submit a pull request (PR). Those pull
 
 ## Terminology
 
-* The **author** of a pull request is the entity who wrote the diff and submitted it to GitHub.
+- The **author** of a pull request is the entity who wrote the diff and submitted it to GitHub.
 
-* The **team** consists of people with commit rights on the go-ethereum repository.
-  
-* The **reviewer** is the person assigned to review the diff. The reviewer must be a team member.
-  
-* The **code owner** is the person responsible for the subsystem being modified by the PR.
+- The **team** consists of people with commit rights on the go-ethereum repository.
+- The **reviewer** is the person assigned to review the diff. The reviewer must be a team member.
+- The **code owner** is the person responsible for the subsystem being modified by the PR.
 
 ## The Process
 
@@ -49,13 +47,13 @@ Commit messages on the master branch should follow the rule below. PR authors ar
 
 The commit message style we use is similar to the style used by the Go project:
 
-The first line of the change description is conventionally a one-line summary of the change, prefixed by the primary affected Go package. It should complete the sentence "This change modifies go-ethereum to _____." The rest of the description elaborates and should provide context for the change and explain what it does.
+The first line of the change description is conventionally a one-line summary of the change, prefixed by the primary affected Go package. It should complete the sentence "This change modifies go-ethereum to **\_**." The rest of the description elaborates and should provide context for the change and explain what it does.
 
 Template:
 
 ```text
 package/path: change XYZ
- 
+
 Longer explanation of the change in the commit. You can use multiple sentences here. It's usually best to include content from the PR description in the final commit message.
 
 issue notices, e.g. "Fixes #42353".
@@ -65,8 +63,8 @@ issue notices, e.g. "Fixes #42353".
 
 Reviewers may find themselves in one of the sitations below. Here's how to deal with them:
 
-* The author doesn't follow up: ping them after a while (i.e. after a few days). If there is no further response, close the PR or complete the work yourself.
+- The author doesn't follow up: ping them after a while (i.e. after a few days). If there is no further response, close the PR or complete the work yourself.
 
-* Author insists on including refactoring changes alongside bug fix: We can tolerate small refactorings alongside any change. If you feel lost in the diff, ask the author to submit the refactoring as an independent PR, or at least as an independent commit in the same PR.
+- Author insists on including refactoring changes alongside bug fix: We can tolerate small refactorings alongside any change. If you feel lost in the diff, ask the author to submit the refactoring as an independent PR, or at least as an independent commit in the same PR.
 
-* Author keeps rejecting feedback: reviewers have authority to reject any change for technical reasons. If you're unsure, ask the team for a second opinion. The PR can be closed if no consensus can be reached. 
+- Author keeps rejecting feedback: reviewers have authority to reject any change for technical reasons. If you're unsure, ask the team for a second opinion. The PR can be closed if no consensus can be reached.

src/pages/docs/developers/geth-developer/dev-guide.md

@@ -72,8 +72,6 @@ killall -QUIT geth
 
 This will dump stack traces for each instance to their respective log file.
 
-
 ## Where to go next
 
 Read the remaning pages in the Geth developer section, and get building!
-

src/pages/docs/developers/geth-developer/dev-mode.md

@@ -5,12 +5,12 @@ description: Instructions for setting up Geth in developer mode
 
 It is often convenient for developers to work in an environment where changes to client or application software can be deployed and tested rapidly and without putting real-world users or assets at risk. For this purpose, Geth has a `--dev` flag that spins up Geth in "developer mode". This creates a single-node Ethereum test network with no connections to any external peers. It exists solely on the local machine. Starting Geth in developer mode does the following:
 
--   Initializes the data directory with a testing genesis block
--   Sets max peers to 0 (meaning Geth does not search for peers)
--   Turns off discovery by other nodes (meaning the node is invisible to other nodes)
--   Sets the gas price to 0 (no cost to send transactions)
--   Uses the Clique proof-of-authority consensus engine which allows blocks to be mined as-needed without excessive CPU and memory consumption
--   Uses on-demand block generation, producing blocks when transactions are waiting to be mined
+- Initializes the data directory with a testing genesis block
+- Sets max peers to 0 (meaning Geth does not search for peers)
+- Turns off discovery by other nodes (meaning the node is invisible to other nodes)
+- Sets the gas price to 0 (no cost to send transactions)
+- Uses the Clique proof-of-authority consensus engine which allows blocks to be mined as-needed without excessive CPU and memory consumption
+- Uses on-demand block generation, producing blocks when transactions are waiting to be mined
 
 This configuration enables developers to experiment with Geth's source code or develop new applications without having to sync to a pre-existing public network. Blocks are only mined when there are pending transactions. Developers can break things on this network without affecting other users. This page will demonstrate how to spin up a local Geth testnet and a simple smart contract will be deployed to it using the Remix online integrated development environment (IDE).
 
@@ -22,7 +22,7 @@ Some basic knowledge of [Solidity](https://docs.soliditylang.org/) and [smart co
 
 ## Start Geth in Dev Mode
 
-Starting Geth in developer mode is as simple as providing the `--dev` flag. It is also possible to create a realistic block creation frequency by setting `--dev.period 13` instead of creating blocks only when transactions are pending. There are also additional configuration options required to follow this tutorial. 
+Starting Geth in developer mode is as simple as providing the `--dev` flag. It is also possible to create a realistic block creation frequency by setting `--dev.period 13` instead of creating blocks only when transactions are pending. There are also additional configuration options required to follow this tutorial.
 
 Remix will be used to deploy a smart contract to the node which requires information to be exchanged externally to Geth's own domain. To permit this, enable `http` and the `net` namespace must be enabled and the Remix URL must be provided to `--http.corsdomain`. For this tutorial some other namespaces will also be enabled. The full command is as follows:
 
@@ -33,13 +33,13 @@ geth --dev --http --http.api eth,web3,personal,net --http.corsdomain "http://rem
 The terminal will display the following logs, confirming Geth has started successfully in developer mode:
 
 ```terminal
-INFO [05-09|10:49:02.951] Starting Geth in ephemeral dev mode... 
+INFO [05-09|10:49:02.951] Starting Geth in ephemeral dev mode...
 INFO [05-09|10:49:02.952] Maximum peer count                       ETH=50 LES=0 total=50
 INFO [05-09|10:49:02.952] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
 INFO [05-09|10:49:02.953] Set global gas cap                       cap=50,000,000
 INFO [05-09|10:49:03.133] Using developer account                  address=0x7Aa16266Ba3d309e3cb278B452b1A6307E52Fb62
 INFO [05-09|10:49:03.196] Allocated trie memory caches             clean=154.00MiB dirty=256.00MiB
-INFO [05-09|10:49:03.285] Writing custom genesis block 
+INFO [05-09|10:49:03.285] Writing custom genesis block
 INFO [05-09|10:49:03.286] Persisted trie from memory database      nodes=13 size=1.90KiB time="180.524µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
 INFO [05-09|10:49:03.287] Initialised chain configuration          config="{ ChainID: 1337 Homestead: 0 DAO: nil DAOSupport: false EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 Constantinople: 0 Petersburg: 0 Istanbul: 0, Muir Glacier: 0, Berlin: 0, London: 0, Arrow Glacier: nil, MergeFork: nil, Terminal TD: nil, Engine: clique}"
 INFO [05-09|10:49:03.288] Initialising Ethereum protocol           network=1337 dbversion= nil
@@ -47,14 +47,14 @@ INFO [05-09|10:49:03.289] Loaded most recent local header          number=0 hash
 INFO [05-09|10:49:03.289] Loaded most recent local full block      number=0 hash=c9c3de..579bb8 td=1 age=53y1mo1w
 INFO [05-09|10:49:03.289] Loaded most recent local fast block      number=0 hash=c9c3de..579bb8 td=1 age=53y1mo1w
 WARN [05-09|10:49:03.289] Failed to load snapshot, regenerating    err="missing or corrupted snapshot"
-INFO [05-09|10:49:03.289] Rebuilding state snapshot 
+INFO [05-09|10:49:03.289] Rebuilding state snapshot
 INFO [05-09|10:49:03.290] Resuming state snapshot generation       root=ceb850..0662cb accounts=0 slots=0 storage=0.00B elapsed="778.089µs"
 INFO [05-09|10:49:03.290] Regenerated local transaction journal    transactions=0 accounts=0
 INFO [05-09|10:49:03.292] Gasprice oracle is ignoring threshold set threshold=2
 INFO [05-09|10:49:03.292] Generated state snapshot                 accounts=10 slots=0 storage=412.00B elapsed=2.418ms
 WARN [05-09|10:49:03.292] Error reading unclean shutdown markers   error="leveldb: not found"
 INFO [05-09|10:49:03.292] Starting peer-to-peer node               instance=Geth/v1.10.18-unstable-8d84a701-20220503/linux-amd64/go1.18.1
-WARN [05-09|10:49:03.292] P2P server will be useless, neither dialing nor listening 
+WARN [05-09|10:49:03.292] P2P server will be useless, neither dialing nor listening
 INFO [05-09|10:49:03.292] Stored checkpoint snapshot to disk       number=0 hash=c9c3de..579bb8
 INFO [05-09|10:49:03.312] New local node record                    seq=1,652,089,743,311 id=bfedca74bea20733 ip=127.0.0.1 udp=0 tcp=0
 INFO [05-09|10:49:03.313] Started P2P networking                   self=enode://0544de6446dd5831daa5a391de8d0375d93ac602a95d6a182d499de31f22f75b6645c3f562932cac8328d51321b676c683471e2cf7b3c338bb6930faf6ead389@127.0.0.1:0
@@ -166,12 +166,11 @@ The transaction details are displayed as follows:
 
 Now that the user account is funded with ether, a contract can be created ready to deploy to the Geth node.
 
-
 ## A simple smart contract
 
 This tutorial will make use of a classic example smart contract, `Storage.sol`. This contract exposes two public functions, one to add a value to the contract storage and one to view the stored value. The contract, written in Solidity, is provided below:
 
-```Solidity
+```solidity
 pragma solidity >=0.7.0;
 
 contract Storage{
@@ -186,14 +185,13 @@ contract Storage{
 
     function retrieve() public view returns (uint256){
         return number;
-    
+
     }
 }
 ```
 
 Solidity is a high-level language that makes code executable by the Ethereum virtual machine (EVM) readable to humans. This means that there is an intermediate step between writing code in Solidity and deploying it to Ethereum. This step is called "compilation" and it converts human-readable code into EVM-executable byte-code. This byte-code is then included in a transaction sent from the Geth node during contract deployment. This can all be done directly from the Geth Javascript console; however this tutorial uses an online IDE called Remix to handle the compilation and deployment of the contract to the local Geth node.
 
-
 ## Compile and deploy using Remix
 
 In a web browser, open <https://remix.ethereum.org>. This opens an online smart contract development environment. On the left-hand side of the screen there is a side-bar menu that toggles between several toolboxes that are displayed in a vertical panel. On the right hand side of the screen there is an editor and a terminal. This layout is similar to the default layout of many other IDEs such as [VSCode](https://code.visualstudio.com/). The contract defined in the previous section, `Storage.sol` is already available in the `Contracts` directory in Remix. It can be opened and reviewed in the editor.
@@ -206,15 +204,12 @@ The Solidity logo is present as an icon in the Remix side-bar. Clicking this ico
 
 Below the Solidity icon is a fourth icon that includes the Ethereum logo. Clicking this opens the Deploy menu. In this menu, Remix can be configured to connect to the local Geth node. In the drop-down menu labelled `ENVIRONMENT`, select `Injected Web3`. This will open an information pop-up with instructions for configuring Geth - these can be ignored as they were completed earlier in this tutorial. However, at the bottom of this pop-up is a box labelled `Web3 Provider Endpoint`. This should be set to Geth's 8545 port on `localhost` (`127.0.0.1:8545`). Click OK. The `ACCOUNT` field should automatically populate with the address of the account created earlier using the Geth Javascript console.
 
-
 ![Remix-deploy](assets/remix-deploy.png)
 
-
 To deploy `Storage.sol`, click `DEPLOY`.
 
 The following logs in the Geth terminal confirm that the contract was successfully deployed.
 
-
 ```terminal
 INFO [05-09|12:27:09.680] Setting new local account                address=0x7Aa16266Ba3d309e3cb278B452b1A6307E52Fb62
 INFO [05-09|12:27:09.680] Submitted contract creation              hash=0xbf2d2d1c393a882ffb6c90e6d1713906fd799651ae683237223b897d4781c4f2 from=0x7Aa16266Ba3d309e3cb278B452b1A6307E52Fb62 nonce=1 contract=0x4aA11DdfD817dD70e9FF2A2bf9c0306e8EC450d3 value=0
@@ -225,7 +220,7 @@ INFO [05-09|12:27:09.681] 🔨 mined potential block                  number=2 h
 
 ## Interact with contract using Remix
 
-The contract is now deployed on a local testnet version of the Etheruem blockchain. This means there is a contract address that contains executable bytecode that can be invoked by sending transactions with instructions, also in bytecode, to that address. Again, this can all be achieved by constructing transactions directly in the Geth console or even by making external http requests using tools such as Curl. Here, Remix is used to retrieve the value, then the same action is taken using the Javascript console. 
+The contract is now deployed on a local testnet version of the Etheruem blockchain. This means there is a contract address that contains executable bytecode that can be invoked by sending transactions with instructions, also in bytecode, to that address. Again, this can all be achieved by constructing transactions directly in the Geth console or even by making external http requests using tools such as Curl. Here, Remix is used to retrieve the value, then the same action is taken using the Javascript console.
 
 After deploying the contract in Remix, the `Deployed Contracts` tab in the sidebar automatically populates with the public functions exposed by `Storage.sol`. To send a value to the contract storage, type a number in the field adjacent to the `store` button, then click the button.
 
@@ -282,7 +277,7 @@ The returned value is a left-padded hexadecimal value. For example, the return v
 
 ## Reusing --datadir
 
-This tutorial used an ephemeral blockchain that is completely destroyed and started afresh during each dev-mode session. However, it is also possible to create persistent blockchain and account data that can be reused across multiple sessions. This is done by providing the `--datadir` flag and a directory name when starting Geth in dev-mode. 
+This tutorial used an ephemeral blockchain that is completely destroyed and started afresh during each dev-mode session. However, it is also possible to create persistent blockchain and account data that can be reused across multiple sessions. This is done by providing the `--datadir` flag and a directory name when starting Geth in dev-mode.
 
 ```shell
 geth --datadir dev-chain --dev --http --http.api personal,web3,eth,net --http.corsdomain "remix.ethereum.org"
@@ -297,9 +292,8 @@ Geth will fail to start in dev-mode if keys have been manually created or import
 geth --datadir dev-chain --dev --http --http.api personal,web3,eth,net --http.corsdomain "remix.ethereum.org" --password password.txt
 
 ```
-**Note** that this is an edge-case that applies when both the `--datadir` and `--dev` flags are used and a key has been manually created or imported into the keystore.
-
 
+**Note** that this is an edge-case that applies when both the `--datadir` and `--dev` flags are used and a key has been manually created or imported into the keystore.
 
 ## Summary
 

src/pages/docs/developers/geth-developer/disclosures.md

@@ -8,14 +8,14 @@ In the software world, it is expected for security vulnerabilities to be immedia
 Vulnerabilies typically take two forms:
 
 1. Vulnerabilies that, if exploited, would harm the software operator. In the case of Geth, examples would be:
-    - A bug that would allow remote reading or writing of OS files, or
-    - Remote command execution, or
-    - Bugs that would leak cryptographic keys
+   - A bug that would allow remote reading or writing of OS files, or
+   - Remote command execution, or
+   - Bugs that would leak cryptographic keys
 2. Vulnerabilies that, if exploited, would harm the Ethereum mainnet. In the case of Geth, examples would be:
-    - Consensus vulnerabilities, which would cause a chain split,
-    - Denial-of-service during block processing, whereby a malicious transaction could cause the geth-portion of the network to crash.
-    - Denial-of-service via p2p networking, whereby portions of the network could be made
-      inaccessible due to crashes or resource consumption.
+   - Consensus vulnerabilities, which would cause a chain split,
+   - Denial-of-service during block processing, whereby a malicious transaction could cause the geth-portion of the network to crash.
+   - Denial-of-service via p2p networking, whereby portions of the network could be made
+     inaccessible due to crashes or resource consumption.
 
 In most cases so far, vulnerabilities in Geth have been of the second type, where the health of the network is a concern, rather than individual node operators. For such issues, Geth reserves the right to silently patch and ship fixes in new releases.
 
@@ -41,9 +41,9 @@ In keeping with this policy, we have taken inspiration from [Solidity bug disclo
 
 ## Disclosed vulnerabilities
 
-On the Geth Github  can find a JSON-formatted list ([`vulnerabilities.json`](vulnerabilities.json)) of some of the known security-relevant vulnerabilities concerning Geth.
+There is a JSON-formatted list ([`vulnerabilities.json`](/docs/vulnerabilities/vulnerabilities.json)) of some of the known security-relevant vulnerabilities concerning Geth.
 
-As of version `1.9.25`, Geth has a built-in command to check whether it is affected by any publically disclosed vulnerability, using the command `geth version-check`. This command will fetch the latest json file (and the accompanying [signature-file](vulnerabilities.json.minisig), and cross-check the data against it's own version number.
+As of version `1.9.25`, Geth has a built-in command to check whether it is affected by any publically disclosed vulnerability, using the command `geth version-check`. This command will fetch the latest json file (and the accompanying [signature-file](/docs/vulnerabilities/vulnerabilities.json.minisig), and cross-check the data against it's own version number.
 
 The list of vulnerabilities was started in November 2020, and covers mainly `v1.9.7` and forward.
 
@@ -79,3 +79,7 @@ The JSON file of known vulnerabilities below is a list of objects, one for each
 We prefer to not rely on Github as the only/primary publishing protocol for security advisories, but we plan to use the Github-advisory process as a second channel for disseminating vulnerability-information.
 
 Advisories published via Github can be accessed [here](https://github.com/ethereum/go-ethereum/security/advisories?state=published).
+
+## Bug Bounties
+
+The Ethereum Foundation run a bug bounty program to reward responsible disclosures of bugs in client software and specs. The details are provided on [ethereum.org](https://ethereum.org/en/bug-bounty/).

src/pages/docs/developers/geth-developer/dns-discovery-setup.md

@@ -7,7 +7,7 @@ This document explains how to set up an [EIP 1459](https://eips.ethereum.org/EIP
 
 DNS-based node lists can serve as a fallback option when connectivity to the discovery DHT is unavailable. In this guide, node lists will be reated by crawling the discovery DHT, then publishing the resulting node sets under chosen DNS names.
 
-### Installing the devp2p command
+## Installing the devp2p command
 
 `cmd/devp2p` is a developer utility and is not included in the Geth distribution. You can install this command using `go get`:
 
@@ -21,7 +21,7 @@ To create a signing key, the `ethkey` utility is needed.
 go get github.com/ethereum/go-ethereum/cmd/ethkey
 ```
 
-### Crawling the v4 DHT
+## Crawling the v4 DHT
 
 Our first step is to compile a list of all reachable nodes. The DHT crawler in cmd/devp2p is a batch process which runs for a set amount of time. You should should schedule this command to run at a regular interval. To create a node list, run
 
@@ -35,7 +35,7 @@ add newly-found nodes to the set, and remove nodes which are no longer alive. Th
 of the node set improves with each run because the number of revalidations is tracked
 alongside each node in the set.
 
-### Creating sub-lists through filtering
+## Creating sub-lists through filtering
 
 Once `all-nodes.json` has been created and the set contains a sizeable number of nodes,
 useful sub-sets of nodes can be extracted using the `devp2p nodeset filter` command. This
@@ -57,13 +57,13 @@ devp2p nodeset filter all-nodes.json -eth-network mainnet > mainnet.nodes.exampl
 
 The following filter flags are available:
 
-* `-eth-network ( mainnet | ropsten | rinkeby | goerli )` selects an Ethereum network.
-* `-les-server` selects LES server nodes.
-* `-ip <mask>` restricts nodes to the given IP range.
-* `-min-age <duration>` restricts the result to nodes which have been live for the
+- `-eth-network ( mainnet | ropsten | rinkeby | goerli )` selects an Ethereum network.
+- `-les-server` selects LES server nodes.
+- `-ip <mask>` restricts nodes to the given IP range.
+- `-min-age <duration>` restricts the result to nodes which have been live for the
   given duration.
 
-### Creating DNS trees
+## Creating DNS trees
 
 To turn a node list into a DNS node tree, the list needs to be signed. To do this, a key pair is required. To create the key file in the correct format, the cmd/ethkey utility should be used. Choose a strong password to encrypt the key on disk!
 
@@ -79,7 +79,7 @@ devp2p dns sign mainnet.nodes.example.org dnskey.json
 
 The resulting DNS tree metadata is stored in the `mainnet.nodes.example.org/enrtree-info.json` file.
 
-### Publishing DNS trees
+## Publishing DNS trees
 
 Now that the tree is signed, it can be published to a DNS provider. cmd/devp2p currently supports publishing to CloudFlare DNS and Amazon Route53.TXT records can also be exported as a JSON file and published independently.
 
@@ -91,7 +91,7 @@ devp2p dns to-cloudflare mainnet.nodes.example.org
 
 Note that this command uses the domain name specified during signing. Any existing records below this name will be erased by cmd/devp2p.
 
-### Using DNS trees with Geth
+## Using DNS trees with Geth
 
 Once a tree is available through a DNS name, Geth can use it with the `--discovery.dns` command line flag. Node trees are referenced using the `enrtree://` URL scheme. The URL of the tree can be found in the `enrtree-info.json` file created by `devp2p dns sign`. Pass the URL as an argument to the flag in order to make use of the published tree.
 

src/pages/docs/developers/geth-developer/issue-handling-workflow.md

@@ -3,38 +3,40 @@ title: Issue Handling Workflow
 description: Instructions for managing Github issues
 ---
 
-### Draft proposal
-
-* Keep the number of open issues under 820
-
-* Keep the ratio of open issues per all issues under 13%
-
-* Have 50 issues labelled [help wanted](https://github.com/ethereum/go-ethereum/labels/help%20wanted) and 50 [good first issue](https://github.com/ethereum/go-ethereum/labels/good%20first%20issue).
-
-* Use structured labels of the form `<category>:<label>` or if need be `<category>:<main>/<sub>`, for example `area: plugins/foobuzzer`.
-
-* Use the following labels. Areas and statuses depend on the application and workflow.
-- area
-    - `area: android`
-    - `area: clef`
-    - `area: network`
-    - `area: swarm`
-    - `area: whisper`
-- type
-    - `type: bug`
-    - `type: feature`
-    - `type: documentation`
-    - `type: discussion`
-- status
-    - `status: PR review`
-    - `status: community working on it`
-- need
-    - `need: more info`
-    - `need: steps to reproduce`
-    - `need: investigation`
-    - `need: decision`
+## Draft proposal
+
+- Keep the number of open issues under 820
+
+- Keep the ratio of open issues per all issues under 13%
+
+- Have 50 issues labelled [help wanted](https://github.com/ethereum/go-ethereum/labels/help%20wanted) and 50 [good first issue](https://github.com/ethereum/go-ethereum/labels/good%20first%20issue).
+
+- Use structured labels of the form `<category>:<label>` or if need be `<category>:<main>/<sub>`, for example `area: plugins/foobuzzer`.
+
+- Use the following labels. Areas and statuses depend on the application and workflow.
+
+* area
+  - `area: android`
+  - `area: clef`
+  - `area: network`
+  - `area: swarm`
+  - `area: whisper`
+* type
+  - `type: bug`
+  - `type: feature`
+  - `type: documentation`
+  - `type: discussion`
+* status
+  - `status: PR review`
+  - `status: community working on it`
+* need
+  - `need: more info`
+  - `need: steps to reproduce`
+  - `need: investigation`
+  - `need: decision`
 
 Use these milestones
+
 - [Future](https://github.com/ethereum/go-ethereum/milestone/80) - Maybe implement one day
 - [Coming soon](https://github.com/ethereum/go-ethereum/milestone/81) - Not assigned to a specific release, but to be delivered in one of the upcoming releases
 - \<next version\> - Next release with a version number
@@ -56,5 +58,5 @@ The Geth core team hold a weekly or bi-weekly triage meeting. Issues are presele
 
 Optional further activities:
 
-* Label the issue with the appropriate area/component.
-* Add a section to the FAQ or add a wiki page. Link to it from the issue.
+- Label the issue with the appropriate area/component.
+- Add a section to the FAQ or add a wiki page. Link to it from the issue.

src/pages/docs/developers/geth-developer/private-network.md

@@ -3,18 +3,16 @@ title: Private Networks
 description: Tutorial on setting up private Ethereum networks
 ---
 
-This guide explains how to set up a private network of multiple Geth nodes. An Ethereum network is private if the nodes are not connected to the main network. In this context private only means reserved or isolated, rather than protected or secure. A fully controlled, private Ethereum network is useful as a backend for core developers working on issues relating to networking/blockchain syncing etc. Private networks are also useful for Dapp developers testing multi-block and multi-user scenarios. 
+This guide explains how to set up a private network of multiple Geth nodes. An Ethereum network is private if the nodes are not connected to the main network. In this context private only means reserved or isolated, rather than protected or secure. A fully controlled, private Ethereum network is useful as a backend for core developers working on issues relating to networking/blockchain syncing etc. Private networks are also useful for Dapp developers testing multi-block and multi-user scenarios.
 
 ## Prerequisites
 
 To follow the tutorial on this page it is necessary to have a working Geth installation (instructions [here](content/docs/getting_started/Installing-Geth.md)). It is also helpful to understand Geth fundamentals (see [Getting Started](/content/docs/getting_started/getting_started.md)).
 
-
 ## Private Networks
 
 A private network is composed of multiple Ethereum nodes that can only connect to each other. In order to run multiple nodes locally, each one requires a separate data directory (`--datadir`). The nodes must also know about each other and be able to exchange information, share an initial state and a common consensus algorithm. The remainder of this page will explain how to configure Geth so that these basic requirements are met, enabling a private network to be started.
 
-
 ### Choosing A Network ID
 
 Ethereum Mainnet has Network ID = 1. There are also many other networks that Geth can connect to by providing alternative Chain IDs, some are testnets and others are alternative networks built from forks of the Geth source code. Providing a network ID that is not already being used by an existing network or testnet means the nodes using that network ID can only connect to each other, creating a private network. A list of current network IDs is available at [Chainlist.org](https://chainlist.org/). The network ID is controlled using the `networkid` flag, e.g.
@@ -23,7 +21,6 @@ Ethereum Mainnet has Network ID = 1. There are also many other networks that Get
 geth --networkid 12345
 ```
 
-
 ### Choosing A Consensus Algorithm
 
 While the main network uses proof-of-work (PoW) to secure the blockchain, Geth also supports the the 'Clique' proof-of-authority (PoA) consensus algorithm as an alternative for private networks. Clique is strongly recommended for private testnets because PoA is far less resource-intensive than PoW. Clique is currently used as the consensus algorithm in public testnets such as [Rinkeby](https://www.rinkeby.io) and [Görli](https://goerli.net). The key differences between the consensus algorithms available in Geth are:
@@ -36,18 +33,15 @@ Geth's PoW algorithm, [Ethhash](https://ethereum.org/en/developers/docs/consensu
 
 Clique consensus is a PoA system where new blocks can be created by authorized 'signers' only. The clique consenus protocol is specified in [EIP-225](https://eips.ethereum.org/EIPS/eip-225). The initial set of authorized signers is configured in the genesis block. Signers can be authorized and de-authorized using a voting mechanism, thus allowing the set of signers to change while the blockchain operates. Clique can be configured to target any block time (within reasonable limits) since it isn't tied to the difficulty adjustment.
 
-
 ### Creating The Genesis Block
 
 Every blockchain starts with a genesis block. When Geth is run with default settings for the first time, it commits the Mainnet genesis to the database. For a private network, it is generally preferable to use a different genesis block. The genesis block is configured using a _genesis.json_ file whose path must be provided to Geth on start-up. When creating a genesis block, a few initial parameters for the private blockchain must be defined:
 
 - Ethereum platform features enabled at launch (`config`). Enabling and disabling features once the blockchain is running requires scheduling a [hard fork](https://ethereum.org/en/glossary/#hard-fork).
-  
 - Initial block gas limit (`gasLimit`). This impacts how much EVM computation can happen within a single block. Mirroring the main Ethereum network is generally a [good choice](https://etherscan.io/chart/gaslimit). The block gas limit can be adjusted after launch using the `--miner.gastarget` command-line flag.
 
 - Initial allocation of ether (`alloc`). This determines how much ether is available to the addresses listed in the genesis block. Additional ether can be created through mining as the chain progresses.
 
-
 #### Clique Example
 
 Below is an example of a `genesis.json` file for a PoA network. The `config` section ensures that all known protocol changes are available and configures the 'clique' engine to be used for consensus. Note that the initial signer set must be configured through the `extradata` field. This field is required for Clique to work.
@@ -128,7 +122,6 @@ geth init --datadir data genesis.json
 
 When Geth is started using `--datadir data` the genesis block defined in `genesis.json` will be used. For example:
 
-
 ```shell
 geth --datadir data --networkid 12345
 ```
@@ -142,11 +135,8 @@ The modification to `genesis.json` is as follows:
 ```json
 {
   "config": {
-  
-    "londonBlock": 40000,
-    
-  },
-  
+    "londonBlock": 40000
+  }
 }
 ```
 
@@ -156,7 +146,6 @@ The upgrade command is:
 geth init --datadir data genesis.json
 ```
 
-
 ### Setting Up Networking
 
 With the node configured and initialized, the next step is to set up a peer-to-peer network. This requires a bootstrap node. The bootstrap node is a normal node that is designated to be the entry point that other nodes use to join the network. Any node can be chosen to be the bootstrap node.
@@ -226,7 +215,6 @@ geth <other-flags> --mine --miner.threads=1 --miner.etherbase=0xf41c74c9ae680c1a
 
 This will start mining bocks and transactions on a single CPU thread, crediting all block rewards to the account specified by `--miner.etherbase`.
 
-
 ## End-to-end example {#end-to-end-example}
 
 This section will run through the commands for setting up a simple private network of two nodes. Both nodes will run on the local machine using the same genesis block and network ID. The data directories for each node will be named `node1` and `node2`.
@@ -263,7 +251,6 @@ The keyfile and account password should be backed up securely. These steps can t
 
 In each data directory save a copy of the following `genesis.json` to the top level project directory. The account addresses in the `alloc` field should be replaced with those created for each node in the previous step (without the leading `0x`).
 
-
 ```json
 {
   "config": {
@@ -294,7 +281,6 @@ In each data directory save a copy of the following `genesis.json` to the top le
     "c94d95a5106270775351eecfe43f97e8e75e59e8": { "balance": "500000" }
   }
 }
-
 ```
 
 The nodes can now be set up using `geth init` as follows:
@@ -310,11 +296,11 @@ INFO [05-13|15:41:47.520] Maximum peer count                       ETH=50 LES=0
 INFO [05-13|15:41:47.520] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
 INFO [05-13|15:41:47.520] Set global gas cap                       cap=50,000,000
 INFO [05-13|15:41:47.520] Allocated cache and file handles         database=/home/go-ethereum/node2/geth/chaindata cache=16.00MiB handles=16
-INFO [05-13|15:41:47.542] Writing custom genesis block 
+INFO [05-13|15:41:47.542] Writing custom genesis block
 INFO [05-13|15:41:47.542] Persisted trie from memory database      nodes=3 size=397.00B time="41.246µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
 INFO [05-13|15:41:47.543] Successfully wrote genesis state         database=chaindata hash=c9a158..d415a0
 INFO [05-13|15:41:47.543] Allocated cache and file handles         database=/home/go-ethereum/node2/geth/chaindata cache=16.00MiB handles=16
-INFO [05-13|15:41:47.556] Writing custom genesis block 
+INFO [05-13|15:41:47.556] Writing custom genesis block
 INFO [05-13|15:41:47.557] Persisted trie from memory database      nodes=3 size=397.00B time="81.801µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
 INFO [05-13|15:41:47.558] Successfully wrote genesis state         database=chaindata hash=c9a158..d415a0
 ```
@@ -322,7 +308,7 @@ INFO [05-13|15:41:47.558] Successfully wrote genesis state         database=chai
 The next step is to configure a bootnode. This can be any node, but for this tutorial the developer tool `bootnode` will be used to quickly and easily configure a dedicated bootnode. First the bootnode requires a key, which can be created with the following command, which will save a key to `boot.key`:
 
 ```shell
-bootnode -genkey boot.key 
+bootnode -genkey boot.key
 ```
 
 This key can then be used to generate a bootnode as follows:
@@ -401,7 +387,6 @@ TRACE[05-13|16:15:57.767]  PING/v4                               id=f1364e6d060c
 
 It is now possible to attach a Javascript console to either node to query the network properties:
 
-
 ```shell
 geth attach node1/geth.ipc
 ```
@@ -454,21 +439,23 @@ eth.getBalance(eth.accounts[0])
 
 This account can then be unlocked and some ether sent to Node 2, using the following commands:
 
-
 ```javascript
 // unlock account
-personal.unlock(eth.accounts[0])
+personal.unlockAccount(eth.accounts[0]);
 
 // send some Wei
-eth.sendTransaction({to: "0xc94d95a5106270775351eecfe43f97e8e75e59e8", from: eth.accounts[0], value: 25000})
+eth.sendTransaction({
+  to: '0xc94d95a5106270775351eecfe43f97e8e75e59e8',
+  from: eth.accounts[0],
+  value: 25000
+});
 
 //check the transaction was successful by querying Node 2's account balance
-eth.getBalance("0xc94d95a5106270775351eecfe43f97e8e75e59e8")
+eth.getBalance('0xc94d95a5106270775351eecfe43f97e8e75e59e8');
 ```
 
 The same steps can then be repeated to attach a console to Node 2.
 
-
 ## Summary
 
-This page explored the various options for configuring a local private network. A step by step guide showed how to set up and launch a private network, unlock the associated accounts, attach a console to check the network status and make some basic interactions.
+This page explored the various options for configuring a local private network. A step by step guide showed how to set up and launch a private network, unlock the associated accounts, attach a console to check the network status and make some basic interactions.

src/pages/docs/faq.md

@@ -9,18 +9,21 @@ This page contains answers to common questions about Geth. The Geth team have al
 
 It is also recommended to search for 'Geth' and 'go-ethereum' on [ethereum.stackexchange](ethereum.stackexchange.com).
 
+## What are RPC and IPC?
 
-#### What are RPC and IPC?
-
-IPC stands for Inter-Process Communications. Geth creates a `geth.ipc` file on startup that other processes on the same computer can use to communicate with Geth. 
+IPC stands for Inter-Process Communications. Geth creates a `geth.ipc` file on startup that other processes on the same computer can use to communicate with Geth.
 RPC stands for Remote Procedure Call. RPC is a mode of communication between processes that may be running on different machines. Geth accepts RPC traffic over HTTP or Websockets. Geth functions are invoked by sending requests that are formatted according to the RPC-API to the node via either IPC or RPC.
 
-#### What is `jwtsecret`?
+## What is `jwtsecret`?
 
 The `jwtsecret` file is required to create an authenticated connection between Geth and a consensus client. JWT stands for JSON Web Token - it is signed using a secret key, proving each party's identity. Read about how to create `jwt-secret` in Geth on our [Connecting to consensus clients](/content/docs/getting_started/consensus-clients.md) page.
 
+<<<<<<< HEAD:content/docs/faq.md
 
 #### I noticed my peercount slowly decreasing, and now it is at 0.  Restarting doesn't get any peers.
+=======
+## I noticed my peercount slowly decreasing, and now it is at 0. Restarting doesn't get any peers.
+>>>>>>> geth-next:src/pages/docs/faq.md
 
 This may be because your clock has fallen out of sync with other nodes. You can [force a clock update using ntp](https://askubuntu.com/questions/254826/how-to-force-a-clock-update-using-ntp) like so:
 
@@ -28,11 +31,11 @@ This may be because your clock has fallen out of sync with other nodes. You can
 sudo ntpdate -s time.nist.gov
 ```
 
-#### I would like to run multiple Geth instances but got the error "Fatal: blockchain db err: resource temporarily unavailable".
+## I would like to run multiple Geth instances but got the error "Fatal: blockchain db err: resource temporarily unavailable".
 
 Geth uses a datadir to store the blockchain, accounts and some additional information. This directory cannot be shared between running instances. If you would like to run multiple instances follow [these](/content/docs/developers/geth-developer/Private-Network.md) instructions.
 
-#### When I try to use the --password command line flag, I get the error "Could not decrypt key with given passphrase" but the password is correct. Why does this error appear?
+## When I try to use the --password command line flag, I get the error "Could not decrypt key with given passphrase" but the password is correct. Why does this error appear?
 
 Especially if the password file was created on Windows, it may have a Byte Order Mark or other special encoding that the go-ethereum client doesn't currently recognize. You can change this behavior with a PowerShell command like:
 
@@ -42,15 +45,20 @@ echo "mypasswordhere" | out-file test.txt -encoding ASCII
 
 Additional details and/or any updates on more robust handling are at <https://github.com/ethereum/go-ethereum/issues/19905>.
 
-#### How does Ethereum syncing work?
+## How does Ethereum syncing work?
 
 The current default syncing mode used by Geth is called [snap sync](https://github.com/ethereum/devp2p/blob/master/caps/snap.md). Instead of starting from the genesis block and processing all the transactions that ever occurred (which could take weeks), snap sync downloads the blocks, and only verifies the associated proof-of-works, assuming state transitions to be correct. Downloading all the blocks is a straightforward and fast procedure and will relatively quickly reassemble the entire chain.
 
 Many people assume that because they have the blocks, they are in sync. Unfortunately this is not the case. Since no transaction was executed, so we do not have any account state available (ie. balances, nonces, smart contract code and data). These need to be downloaded separately and cross-checked with the latest blocks. This phase is called the state trie download phase. Snap sync tries to hasten this process by downloading contiguous chunks of useful state data, instead of doing so one-by-one, as in previous synchronization methods. Geth downloads the leaves of the trie without the intermediate nodes that connect the leaves to the root. The full trie is regenerated locally. However, while this is happening, the blockchain is progressing, meaning some of the regenerated state trie becomes invalid. Therefor, there is also a healing phase that corrects any errors in the state trie. The state sync has to progress faster than the chain growth otherwise it will never finish.
+<<<<<<< HEAD:content/docs/faq.md
+
+Geth can also be sync'd with `--syncmode full`. In this case, Geth downloads and independently verifies every block since genesis in sequence, including re-executing transactions to verify state transitions. Although Geth verifies every block since genesis, only 128 blocks are stored in memory.
+=======
+>>>>>>> geth-next:src/pages/docs/faq.md
 
 Geth can also be sync'd with `--syncmode full`. In this case, Geth downloads and independently verifies every block since genesis in sequence, including re-executing transactions to verify state transitions. Although Geth verifies every block since genesis, only 128 blocks are stored in memory.
 
-#### What's the state trie?
+## What's the state trie?
 
 In the Ethereum mainnet, there are a ton of accounts already, which track the balance, nonce, etc of each user/contract. The accounts themselves are however insufficient to run a node, they need to be cryptographically linked to each block so that nodes can actually verify that the accounts are not tampered with.
 
@@ -58,22 +66,36 @@ This cryptographic linking is done by creating a tree-like data structure, where
 
 Read more about Merkle Tries in general and the Ethereum state trie specifically on [ethereum.org](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie)
 
+<<<<<<< HEAD:content/docs/faq.md
 #### Why does the state trie download phase require a special syncing mode?
+=======
+## Why does the state trie download phase require a special syncing mode?
+>>>>>>> geth-next:src/pages/docs/faq.md
 
 The trie data structure is an intricate interlink of hundreds of millions of tiny cryptographic proofs (trie nodes). To truly have a synchronized node, you need to download all the account data, as well as all the tiny cryptographic proofs to verify that no one in the network is trying to cheat you. This itself is already a crazy number of data items.
 
 The part where it gets even messier is that this data is constantly morphing: at every block (roughly 13s), about 1000 nodes are deleted from this trie and about 2000 new ones are added. This means your node needs to synchronize a dataset that is changing more than 200 times per second. Until you actually do gather all the data, your local node is not usable since it cannot cryptographically prove anything about any accounts. But while you're syncing the network is moving forward and most nodes on the network keep the state for only a limited number of recent blocks. Any sync algorithm needs to consider this fact.
 
-#### What happened to fast sync?
+## What happened to fast sync?
 
 Snap syncing was introduced by version [1.10.0](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) and was adopted as the default mode in version [1.10.4](https://github.com/ethereum/go-ethereum/releases/tag/v1.10.4). Before that, the default was the "fast" syncing mode, which was dropped in version [1.10.14](https://github.com/ethereum/go-ethereum/releases/tag/v1.10.14). Even though support for fast sync was dropped, Geth still serves the relevant `eth` requests to other client implementations still relying on it. The reason being that snap sync relies on an alternative data structure called the [snapshot](https://blog.ethereum.org/2020/07/17/ask-about-geth-snapshot-acceleration/) which not all clients implement.
 
 You can read more in the article posted above why snap sync replaced fast sync in Geth.
 
+<<<<<<< HEAD:content/docs/faq.md
 #### What is wrong with my light client?
 
 Light sync relies on full nodes that serve data to light clients. Historically, this has been hampered by the fact that serving light clients was turned off by default in geth full nodes and few nodes chose to turn it on. Therefore, light nodes often struggled to find peers. Since Ethereum switched to proof-of-stake, Geth light clients have stopped working altogether. Light clients for proof-of-stake Ethereum are expected to be implemented soon!
 
 #### Why do I need another client in addition to Geth?
 
-Historically, running Geth was enough to turn a computer into an Ethereum node. However, when Ethereum transitioned to proof-of-stake, responsibility for consensus logic and block gossip was handed over to a separate consensus layer client. However, Geth still handles transactions and state management. When the consensus client is required to create a new block, it requests Geth to gather transactions from the transaction pool, execute them to compute a state transition and pass this information back to the consensus client. When the consensus client receives a new block from a peer, it passes the transactions to Geth to re-execute to verify the proposed state-transition. There is a clear separationm of concerns between the two clients, meaning that both are required for a computer function as an Ethereum node.
+Historically, running Geth was enough to turn a computer into an Ethereum node. However, when Ethereum transitioned to proof-of-stake, responsibility for consensus logic and block gossip was handed over to a separate consensus layer client. However, Geth still handles transactions and state management. When the consensus client is required to create a new block, it requests Geth to gather transactions from the transaction pool, execute them to compute a state transition and pass this information back to the consensus client. When the consensus client receives a new block from a peer, it passes the transactions to Geth to re-execute to verify the proposed state-transition. There is a clear separationm of concerns between the two clients, meaning that both are required for a computer function as an Ethereum node.
+=======
+## What is wrong with my light client?
+
+Light sync relies on full nodes that serve data to light clients. Historically, this has been hampered by the fact that serving light clients was turned off by default in geth full nodes and few nodes chose to turn it on. Therefore, light nodes often struggled to find peers. Since Ethereum switched to proof-of-stake, Geth light clients have stopped working altogether. Light clients for proof-of-stake Ethereum are expected to be implemented soon!
+
+## Why do I need another client in addition to Geth?
+
+Historically, running Geth was enough to turn a computer into an Ethereum node. However, when Ethereum transitioned to proof-of-stake, responsibility for consensus logic and block gossip was handed over to a separate consensus layer client. However, Geth still handles transactions and state management. When the consensus client is required to create a new block, it requests Geth to gather transactions from the transaction pool, execute them to compute a state transition and pass this information back to the consensus client. When the consensus client receives a new block from a peer, it passes the transactions to Geth to re-execute to verify the proposed state-transition. There is a clear separationm of concerns between the two clients, meaning that both are required for a computer function as an Ethereum node.
+>>>>>>> geth-next:src/pages/docs/faq.md

src/pages/docs/fundamentals/account-management.md

@@ -19,7 +19,7 @@ geth account <command> [options...] [arguments...]
 
 The account command enables the user to create new accounts, list existing accounts, import private keys into a new account, update key formats and update the passwords that lock each account. In interactive mode, the user is prompted for passwords in the console when the `account` functions are invoked, whereas in non-interactive mode passwords to unlock accounts are saved to text files whose path is passed to Geth at startup. Non-interactive mode is only intended for use on private networks or known safe environments.
 
-The `account` subcommands are: 
+The `account` subcommands are:
 
 ```
 COMMANDS:
@@ -44,7 +44,7 @@ OPTIONS:
 
 ## Creating new accounts
 
-New accounts can be created using `account new`. This generates a new key pair and adds them to the `keystore` directory in the `datadir`.  To 
+New accounts can be created using `account new`. This generates a new key pair and adds them to the `keystore` directory in the `datadir`. To
 create a new account in the default data directory:
 
 ```shell
@@ -62,14 +62,13 @@ Address: {168bc315a2ee09042d83d7c5811b533620531f67}
 
 It is critical to backup the account password safely and securely as it cannot be retrieved or reset.
 
-{% include note.html content=" If the password provided on account creation is lost or forgotten, there is no way to retrive it and the account will simply stay locked forever. The password MUST be backed up safely and securely! 
+{% include note.html content=" If the password provided on account creation is lost or forgotten, there is no way to retrive it and the account will simply stay locked forever. The password MUST be backed up safely and securely!
 **IT IS CRITICAL TO BACKUP THE KEYSTORE AND REMEMBER PASSWORDS**" %}
 
 The newly generated key files can be viewed in `<datadir>/keystore/`. The file naming format is `UTC--<date>--<address>` where `date` is the date and time of key creation formatted according to [UTC 8601](https://www.iso.org/iso-8601-date-and-time-format.html) with zero time offset and seconds precise to eight decimal places. `address` is the 40 hexadecimal characters that make up the account address without a leading `0x`, for example:
 
 `UTC--2022-05-19T12-34-36.47413510Z--0b85e5a13e118466159b1e1b6a4234e5f9f784bb`
 
-
 ## Listing Accounts
 
 Listing all existing accounts is achieved using the `account list` command. If the keystore is located anywhere other than the default location its path should be included with the `keystore` flag. For example, if the datadir is `some-dir`:
@@ -87,12 +86,11 @@ Account 1: {9acb9ff906641a434803efb474c96a837756287f} keystore:///tmp/mykeystore
 
 The ordering of accounts when they are listed is lexicographic, but is effectively chronological based on time of creation due to the timestamp in the file name. It is safe to transfer the entire `keystore` directory or individual key files between Ethereum nodes. This is important because when accounts are added from other nodes the order of accounts in the keystore may change. It is therefore important not to rely on account indexes in scripts or code snippets.
 
-
 ## Importing accounts
 
 ### Import a keyfile
 
-It is also possible to create a new account by importing a private key. For example, a user might already have some ether at an address they created using a browser wallet and now wish to use a new Geth node to interact with their funds. In this case, the private key can be exported from the browser wallet and imported into Geth. Geth requires the private key to be stored as a file which contains the private key as unencrypted 
+It is also possible to create a new account by importing a private key. For example, a user might already have some ether at an address they created using a browser wallet and now wish to use a new Geth node to interact with their funds. In this case, the private key can be exported from the browser wallet and imported into Geth. Geth requires the private key to be stored as a file which contains the private key as unencrypted
 canonical elliptic curve bytes encoded into hex (i.e. plain text key without leading 0x). The new account is then saved in encrypted format, protected by a passphrase the user provides on request. As always, this passphrase must be securely and safely backed up - there is no way to retrieve or reset it if it is forgotten!
 
 ```shell
@@ -110,11 +108,12 @@ Address: {7f444580bfef4b9bc7e14eb7fb2a029336b07c9d}
 
 This import/export process is not necessary for transferring accounts between Geth instances because the key files can simply be copied directly from one keystore to another.
 
-It is also possible to import an account in non-interactive mode by saving the account password as plaintext in a `.txt` file and passing its path with the `--password` flag on startup. 
+It is also possible to import an account in non-interactive mode by saving the account password as plaintext in a `.txt` file and passing its path with the `--password` flag on startup.
 
 ```shell
 geth account import --password path/password.txt path/keyfile
 ```
+
 In this case, it is important to ensure the password file is not readable by anyone but the intended user. This can be achieved by changing the file permissions. On Linux, the following commands update the file permissions so only the current user has access:
 
 ```shell
@@ -160,11 +159,10 @@ geth account update a94f5374fce5edbc8e2a8697c15331677e6ebf0b --password path/pas
 
 Updating the account replaces the original file with a new one - this means the original file is no longer available after it has been updated.
 
-
 ## Unlocking accounts
 
-In Geth, accounts are locked unless they are explicitly unlocked. If an account is intended to be used by apps connecting to Geth via RPC then it can be unlocked in non-interactive mode by passing the `--unlock` flag with a comma-separated list of account addresses (or keystore indexes) to unlock. This unlocks the accounts for one session only. Including the `--unlock` flag without any account addresses defaults to unlocking the first account 
-in the keystore. 
+In Geth, accounts are locked unless they are explicitly unlocked. If an account is intended to be used by apps connecting to Geth via RPC then it can be unlocked in non-interactive mode by passing the `--unlock` flag with a comma-separated list of account addresses (or keystore indexes) to unlock. This unlocks the accounts for one session only. Including the `--unlock` flag without any account addresses defaults to unlocking the first account
+in the keystore.
 
 ```shell
 geth <other commands> --unlock 0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b
@@ -176,10 +174,9 @@ Geth will start and prompt the user to input the account password in the termina
 geth <other commands> --unlock 0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b --password path/password.txt
 ```
 
-{% include note.html content=" By default, account **unlocking is forbidden when HTTP or Websocket access is enabled** (i.e. by passing `--http` or `ws` flag). This is because an attacker that manages to access the node via the externally-exposed HTTP/WS port can then control the unlocked account. 
+{% include note.html content=" By default, account **unlocking is forbidden when HTTP or Websocket access is enabled** (i.e. by passing `--http` or `ws` flag). This is because an attacker that manages to access the node via the externally-exposed HTTP/WS port can then control the unlocked account.
 It is possible to force account unlock by including the `--allow-insecure-unlock` flag but this is unsafe and **not recommended** except for expert users that completely understand how it can be used safely. This is not a hypothetical risk: **there are bots that continually scan for http-enabled Ethereum nodes to attack**" %}
 
-
 ## Accounts in the Javascript console
 
 Account management can also be achieved in the Javascript console attached to a running Geth instance. Assuming Geth is already running, in a new terminal attach a Javascript console using the `geth.ipc` file. This file can be found in the data directory. Assuming the data directory is named `data` the console can be started using:
@@ -209,11 +206,13 @@ The `accounts` function in the `eth` namespace can be used to list the accounts
 ```
 eth.accounts
 ```
+
 or alternatively the same is achieved using:
 
 ```
 personal.listAccounts
 ```
+
 This returns an array of account addresses to the terminal.
 
 ### Unlocking accounts
@@ -240,11 +239,10 @@ personal.unlockAccount(eth.accounts[1], "passphrase", 60)
 
 This unlocks the account for 60 seconds. However, this is not recommended because the command history is logged by the Javascript console which could compromise the security of the account. An unlocked account can be manually re-locked using `personal.lockAccount()`, passing the address as the sole argument.
 
-
 ### Unlocking for transactions
 
-Sending transactions from the Javascript console also requires the sender account to be unlocked. There are two ways to send transactions: `eth.sendTransaction` and `personal.sendTransaction`. The difference between these two functions is that `eth.sendTransaction` requires the account to be 
-unlocked globally, at the node level (i.e., by unlocking it on the command line at the start of the Geth session). On the other hand, `personal.sendTransaction` takes a passphrase argument that unlocks the account temporarily in order to sign the transaction, then locks it again 
+Sending transactions from the Javascript console also requires the sender account to be unlocked. There are two ways to send transactions: `eth.sendTransaction` and `personal.sendTransaction`. The difference between these two functions is that `eth.sendTransaction` requires the account to be
+unlocked globally, at the node level (i.e., by unlocking it on the command line at the start of the Geth session). On the other hand, `personal.sendTransaction` takes a passphrase argument that unlocks the account temporarily in order to sign the transaction, then locks it again
 immediately afterwards. For example, to send 5 ether between two accounts in the keystore:
 
 ```shell
@@ -259,4 +257,4 @@ personal.sendTransaction(tx, "password")
 
 ## Summary
 
-This page has demonstrated how to use Geth's built-in account management tools, both on the command line and in the Javascript console. Accounts are stored encrypted by a password. It is critical that the account passwords and the keystore directory are safely and securely backed up.
+This page has demonstrated how to use Geth's built-in account management tools, both on the command line and in the Javascript console. Accounts are stored encrypted by a password. It is critical that the account passwords and the keystore directory are safely and securely backed up.

src/pages/docs/fundamentals/backup-restore.md

@@ -9,9 +9,9 @@ description: How to backup and restore keyfiles and blockchain data
 
 All data relating to a specific Geth instance gets written inside a data directory. The default data directory locations are platform specific:
 
-* Mac: `~/Library/Ethereum`
-* Linux: `~/.ethereum`
-* Windows: `%LOCALAPPDATA%\Ethereum`
+- Mac: `~/Library/Ethereum`
+- Linux: `~/.ethereum`
+- Windows: `%LOCALAPPDATA%\Ethereum`
 
 Accounts are stored in the `keystore` subdirectory. The contents of this directories should be transportable between nodes, platforms, and client implementations.
 

src/pages/docs/fundamentals/command-line-options.md

@@ -3,7 +3,7 @@ title: Command-line Options
 description: A list of commands for Geth
 ---
 
-Geth is primarily controlled using the command line. Geth is started using the `geth` command. Geth is stopped by pressing `ctrl-c`. There are then many combinations of commands that configure precisely how geth will run. These commands are displayed below. The same information can be 
+Geth is primarily controlled using the command line. Geth is started using the `geth` command. Geth is stopped by pressing `ctrl-c`. There are then many combinations of commands that configure precisely how geth will run. These commands are displayed below. The same information can be
 obtained at any time from your Geth instance by running:
 
 ```sh
@@ -84,7 +84,7 @@ LIGHT CLIENT OPTIONS:
   --ulc.onlyannounce                  Ultra light server sends announcements only
   --light.nopruning                   Disable ancient light chain data pruning
   --light.nosyncserve                 Enables serving light clients before syncing
-  
+
 DEVELOPER CHAIN OPTIONS:
   --dev                               Ephemeral proof-of-authority network with a pre-funded developer account, mining enabled
   --dev.period value                  Block period to use in developer mode (0 = mine only if transaction pending) (default: 0)
@@ -174,7 +174,7 @@ NETWORKING OPTIONS:
   --netrestrict value                 Restricts network communication to the given IP networks (CIDR masks)
   --nodekey value                     P2P node key file
   --nodekeyhex value                  P2P node key as hex (for testing)
-  
+
 MINER OPTIONS:
   --mine                              Enable mining
   --miner.threads value               Number of CPU threads to use for mining (default: 0)

src/pages/docs/fundamentals/les.md

@@ -5,13 +5,12 @@ description: Introduction to Geth's light sync mode
 
 {% include note.html content="Light nodes do not currently work on proof-of-stake Ethereum, but new proof-of-stake light clients are expected to ship soon!" %}
 
-Running a full node is the most trustless, private, decentralized and censorship resistant way to interact with Ethereum. It is also the best choice for the health of the network, because a decentralized network relies on having many individual nodes that independently verify the head of the chain. In a full node a copy of the blockchain is stored locally enabling users to verify incoming data against a local source of truth. However, running a full node requires a lot of disk space and non-negligible CPU allocation and takes hours (for snap sync) or days (for full sync) to sync the blockchain from genesis. Geth also offers a light mode that overcomes these issues and provides some of the benefits of running a node but requires only a fraction of the resources. 
+Running a full node is the most trustless, private, decentralized and censorship resistant way to interact with Ethereum. It is also the best choice for the health of the network, because a decentralized network relies on having many individual nodes that independently verify the head of the chain. In a full node a copy of the blockchain is stored locally enabling users to verify incoming data against a local source of truth. However, running a full node requires a lot of disk space and non-negligible CPU allocation and takes hours (for snap sync) or days (for full sync) to sync the blockchain from genesis. Geth also offers a light mode that overcomes these issues and provides some of the benefits of running a node but requires only a fraction of the resources.
 
 Read more about the reasons to run nodes on [ethereum.org](https://ethereum.org/en/run-a-node/).
 
 {% include note.html content=" Geth light clients **do not currently work** on proof-of-stake Ethereum. New light clients that work with the proof-of-stake consensus engine are expected to ship soon!" %}
 
-
 ## Light node vs full node
 
 Running Geth in light mode has the following advantages for users:
@@ -50,7 +49,6 @@ Data can be requested from this light Geth instance in the same way as for a ful
 
 It's also possible to send transactions. However, light clients are not connected directly to Ethereum Mainnet but to a network of light servers that connect to Ethereum Mainnet. This means a transaction submitted by a light client is received first by a light server that then propagates it to full-node peers on the light-client's behalf. This reliance on honest light-servers is one of the trust compromises that comes along with running a light node instead of a full node.
 
-
 ### Ultra light clients
 
 Geth has an even lighter sync mode called ultra light client (ULC). The difference between light mode and ultra-light mode is that a ULC doesn't check the PoW in block headers. There is an assumption that the ULC has access to one or more trusted light servers. This option has the greatest trust assumptions but the smallest resource requirement.

src/pages/docs/fundamentals/mining.md

@@ -7,15 +7,13 @@ description: Introduction to proof-of-work mining with Geth
 
 Blockchains grow when nodes add blocks and distribute them to their peers. Nodes that add blocks are rewarded with ether payouts. On Ethereum Mainnet, the proof-of-stake consensus engine randomyl selects a node to produce each block. Under proof-of-work, however, block producers are selected by competition. The node that computes a certain value that can only be found using repeated random guesses wins the right to propose the next block. Only if a node can demonstrate that they have calculated this value, and therefore expended energy, will their block be accepted by other nodes. This secures the network. This process of creating blocks and securing them using proof-of-work is known as "mining".
 
-Much more information about mining, including details about the specific algorithm ("Ethash") used by Ethereum nodes is available on [ethereum.org](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining). 
-
+Much more information about mining, including details about the specific algorithm ("Ethash") used by Ethereum nodes is available on [ethereum.org](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining).
 
 ## CPU vs GPU
 
 Participating in Ethereum's PoW mining requires running an algorithm called ["Ethash"](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining-algorithms/ethash). Geth includes a CPU miner which runs Ethash within the Geth process. This might be useful for mining on testnets or private networks where competition for producing new blocks is small. When minign was used to secure Ethereum Mainnet, CPU mining was not viable because CPU miners were easily outcompeted by more efficient GPU miners. To mine using GPUs an additional piece of third-party software is required. The recommended GPU mining software is [Ethminer](https://github.com/ethereum-mining/ethminer).
 
-Regardless of the mining method, the blockchain must be fully synced before mining is started, otherwise the miner will build on an outdated side chain, meaning block rewards will not be recognized by the main network. 
-
+Regardless of the mining method, the blockchain must be fully synced before mining is started, otherwise the miner will build on an outdated side chain, meaning block rewards will not be recognized by the main network.
 
 ## GPU Mining
 
@@ -93,7 +91,6 @@ Note that the Geth command `miner.hashrate` only works for CPU mining - it alway
 
 The Ethash algorithm is [memory-hard](https://crypto.stackexchange.com/questions/84002/memory-hard-vs-memory-bound-functions) and requires a large dataset to be loaded into memory. Each GPU requires 4-5 GB of RAM. The error message `Error GPU mining. GPU memory fragmentation?` indicates that there is insufficient memory available.
 
-
 ## CPU Mining with Geth
 
 When Geth is started it is not mining by default. Unless it is specifically instructed to mine, it acts only as a node, not a miner. Geth starts as a (CPU) miner if the `--mine` flag is provided. The `--miner.threads` parameter can be used to set the number parallel mining threads (defaulting to the total number of processor cores).
@@ -105,10 +102,10 @@ geth --mine --miner.threads=4
 CPU mining can also be started and stopped at runtime using the [console](/docs/interface/javascript-console). The command `miner.start` takes an optional parameter for the number of miner threads.
 
 ```js
-miner.start(8)
- true
-miner.stop()
- true
+miner.start(8);
+true;
+miner.stop();
+true;
 ```
 
 Note that mining for real ether only makes sense if you are in sync with the network (since you mine on top of the consensus block). Therefore the Ethereum blockchain downloader/synchroniser will delay mining until syncing is complete, and after that mining automatically starts unless you cancel your intention with `miner.stop()`.
@@ -118,6 +115,7 @@ Like with GPU mining, an etherbase account must be set. This defaults to the pri
 ```shell
 geth --miner.etherbase '0xC95767AC46EA2A9162F0734651d6cF17e5BfcF10' --mine
 ```
+
 If there is no account available an account wil be created and automatically configured to be the coinbase. The Javascript console can be used to reset the etherbase account at runtime:
 
 ```shell
@@ -152,21 +150,20 @@ It is also possible to check which blocks were mined by a particular miner (addr
 function minedBlocks(lastn, addr) {
   addrs = [];
   if (!addr) {
-    addr = eth.coinbase
+    addr = eth.coinbase;
   }
-  limit = eth.blockNumber - lastn
+  limit = eth.blockNumber - lastn;
   for (i = eth.blockNumber; i >= limit; i--) {
     if (eth.getBlock(i).miner == addr) {
-        addrs.push(i)
+      addrs.push(i);
     }
   }
-  return addrs
+  return addrs;
 }
 
 // scans the last 1000 blocks and returns the blocknumbers of blocks mined by your coinbase
 // (more precisely blocks the mining reward for which is sent to your coinbase).
-minedBlocks(1000, eth.coinbase)
-[352708, 352655, 352559]
+minedBlocks(1000, eth.coinbase)[(352708, 352655, 352559)];
 ```
 
 The etherbase balance will fluctuate because quite often a mined block may be re-org'd out of the canonical chain. This means that when the local Geth node includes the mined block in its own local blockchain the account balance appears higher because the block rewards are applied. When the node switches to another version of the chain due to information received from peers, that block may not be included and the block rewards are not applied.
@@ -175,4 +172,4 @@ The logs show locally mined blocks confirmed after 5 blocks.
 
 ## Summary
 
-The page describes how to start Geth as a mining node. Mining can be done on CPUs - in which case Geth's built-in miner can be used - or on GPUs which requires third party software. Mining is no longer used on Ethereum Mainnet so this information is only applicable to private proof-of-work networks or testnets.
+The page describes how to start Geth as a mining node. Mining can be done on CPUs - in which case Geth's built-in miner can be used - or on GPUs which requires third party software. Mining is no longer used on Ethereum Mainnet so this information is only applicable to private proof-of-work networks or testnets.

src/pages/docs/fundamentals/node-architecture.md

@@ -7,14 +7,13 @@ description: Introduction to how Ethereum nodes are organized and where Geth fit
 
 Geth is an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients). Originally, an execution client alone was enough to run a full Ethereum node. However, ever since Ethereum turned off [proof-of-work](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/) and implemented [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/), Geth has needed to be coupled to another piece of software called a [“consensus client”](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients) in order to keep track of the Ethereum blockchain.
 
-The execution client is responsible for transaction handling, transaction gossip, state management and supporting the Ethereum Virtual Machine ([EVM])(https://ethereum.org/en/developers/docs/evm/). However, Geth is **not** responsible for block building, block gossiping or handling consensus logic. These are in the remit of the consensus client.
+The execution client (Geth) is responsible for transaction handling, transaction gossip, state management and supporting the Ethereum Virtual Machine ([EVM])(https://ethereum.org/en/developers/docs/evm/). However, Geth is **not** responsible for block building, block gossiping or handling consensus logic. These are in the remit of the consensus client.
 
 The relationship between the two Ethereum clients is shown in the schematic below. The two clients each connect to their own respective peer-to-peer (P2P) networks. This is because the execution clients gossip transactions over their P2P network enabling them to manage their local transaction pool. The consensus clients gossip blocks over their P2P network, enabling consensus and chain growth.
 
 ![node-architecture](/assets/node_architecture.png)
 
-For this two-client structure to work, consensus clients must be able to pass bundles of transactions to Geth to be executed. Executing the transactions locally is how the client validates that the transactions do not violate any Ethereum rules and that the proposed update to Ethereum’s state is correct. Likewise, when the node is selected to be a block producer the consensus client must be able to request bundles of transactions from Geth to include in the new block. This inter-client communication is handled by a local RPC connection using the [engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md) which is exposed internally over port 8551 by default.
-
+For this two-client structure to work, consensus clients must be able to pass bundles of transactions to Geth to be executed. Executing the transactions locally is how the client validates that the transactions do not violate any Ethereum rules and that the proposed update to Ethereum’s state is correct. Likewise, when the node is selected to be a block producer the consensus client must be able to request bundles of transactions from Geth to include in the new block. This inter-client communication is handled by a local RPC connection using the [engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md).
 
 ## What does Geth do?
 
@@ -22,8 +21,6 @@ As an execution client, Geth is responsible for creating the execution payloads
 
 Geth also offers a user-interface to Ethereum by exposing a set of RPC methods that enable users to query the Ethereum blockchain, submit transactions and deploy smart contracts using the command line, programmatically using Geth's built-in console, web3 development frameworks such as Hardhat and Truffle or via web-apps and wallets.
 
-In summary, Geth is:
-	- a user gateway to Ethereum 
-	- home to the Ethereum Virtual Machine, Ethereum's state and transaction pool.
+In summary, Geth is: - a user gateway to Ethereum - home to the Ethereum Virtual Machine, Ethereum's state and transaction pool.
 
 Read more about [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/).

src/pages/docs/fundamentals/peer-to-peer.md

@@ -2,6 +2,7 @@
 title: Connecting To The Network
 description: Guide to connecting Geth to a peer-to-peer network
 ---
+
 The default behaviour for Geth is to connect to Ethereum Mainnet. However, Geth can also connect to public testnets, [private networks](/docs/getting-started/private-net) and [local testnets](/docs/getting-started/dev-mode). Command line flags are provided for connecting to the popular public testnets:
 
 - `--ropsten`, Ropsten proof-of-work test network
@@ -13,7 +14,7 @@ Providing these flags at startup instructs Geth to connect to the specific publi
 
 **Note:** network selection is not persisted in the config file. To connect to a pre-defined network you must always enable it explicitly, even when using the `--config` flag to load other configuration values. For example:
 
-```shell 
+```shell
 
 # Generate desired config file. You must specify testnet here.
 geth --goerli --syncmode "full" ... dumpconfig > goerli.toml
@@ -25,7 +26,7 @@ geth --goerli --config goerli.toml
 
 ## Finding peers
 
-Geth continuously attempts to connect to other nodes on the network until it has enough peers. If UPnP (Universal Plug and Play) is enabled at the router or Ethereum is run on an Internet-facing server, it will also accept connections from other nodes. Geth finds peers using the [discovery protocol](https://ethereum.org/en/developers/docs/networking-layer/#discovery). In the discovery protocol, nodes exchange connectivity details and then establish sessions ([RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md)). If the nodes support compatible sub-protocols they can start exchanging Ethereum data [on the wire](https://ethereum.org/en/developers/docs/networking-layer/#wire-protocol). 
+Geth continuously attempts to connect to other nodes on the network until it has enough peers. If UPnP (Universal Plug and Play) is enabled at the router or Ethereum is run on an Internet-facing server, it will also accept connections from other nodes. Geth finds peers using the [discovery protocol](https://ethereum.org/en/developers/docs/networking-layer/#discovery). In the discovery protocol, nodes exchange connectivity details and then establish sessions ([RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md)). If the nodes support compatible sub-protocols they can start exchanging Ethereum data [on the wire](https://ethereum.org/en/developers/docs/networking-layer/#wire-protocol).
 
 A new node entering the network for the first time gets introduced to a set of peers by a bootstrap node ("bootnode") whose sole purpose is to connect new nodes to peers. The endpoints for these bootnodes are hardcoded into Geth, but they can also be specified by providing the `--bootnode` flag along with comma-separated bootnode addresses in the form of [enodes](https://ethereum.org/en/developers/docs/networking-layer/network-addresses/#enode) on startup. For example:
 
@@ -37,7 +38,6 @@ geth --bootnodes enode://pubkey1@ip1:port1,enode://pubkey2@ip2:port2,enode://pub
 
 There are scenarios where disabling the discovery process is useful, for example for running a local test node or an experimental test network with known, fixed nodes. This can be achieved by passing the `--nodiscover` flag to Geth at startup.
 
-
 ## Connectivity problems
 
 There are occasions when Geth simply fails to connect to peers. The common reasons for this are:
@@ -50,12 +50,10 @@ There are occasions when Geth simply fails to connect to peers. The common reaso
 
 - The public test network Geth is connecting to might be deprecated or have a low number of active nodes that are hard to find. In this case, the best action is to switch to an alternative test network.
 
-
 ## Checking Connectivity
 
 The `net` module has two attributes that enable checking node connectivity from the [interactive Javascript console](/docs/interface/javascript-console). These are `net.listening` which reports whether the Geth node is listening for inbound requests, and `peerCount` which returns the number of active peers the node is connected to.
 
-
 ```javascript
 
 > net.listening
@@ -118,7 +116,6 @@ The `admin` module also includes functions for gathering information about the l
 
 It is often useful for developers to connect to private test networks rather than public testnets or Etheruem mainnet. These sandbox environments allow block creation without competing against other miners, easy minting of test ether and give freedom to break things without real-world consequences. A private network is started by providing a value to `--networkid` that is not used by any other existing public network ([Chainlist](https://chainlist.org)) and creating a custom `genesis.json` file. Detailed instructions for this are available on the [Private Networks page](/docs/interface/private-network).
 
-
 ## Static nodes
 
 Geth also supports static nodes. Static nodes are specific peers that are always connected to. Geth reconnects to these peers automatically when it is restarted. Specific nodes are defined to be static nodes by adding their enode addresses to a config file. The easiest way to create this config file is to run:
@@ -140,7 +137,9 @@ Ensure the other lines in `config.toml` are also set correctly before starting G
 Static nodes can also be added at runtime in the Javascript console by passing an enode address to `admin.addPeer()`:
 
 ```javascript
-admin.addPeer("enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303")
+admin.addPeer(
+  'enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303'
+);
 ```
 
 ## Peer limit
@@ -160,10 +159,11 @@ Trusted nodes can be added to `config.toml` in the same way as for static nodes.
 Nodes can be added using the `admin.addTrustedPeer()` call in the Javascript console and removed using `admin.removeTrustedPeer()` call.
 
 ```javascript
-admin.addTrustedPeer("enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303")
+admin.addTrustedPeer(
+  'enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303'
+);
 ```
 
-
 ## Summary
 
-Geth connects to Ethereum Mainnet by default. However, this behaviour can be changed using combinations of command line flags and files. This page has described the various options available for connecting a Geth node to Ethereum, public testnets and private networks.
+Geth connects to Ethereum Mainnet by default. However, this behaviour can be changed using combinations of command line flags and files. This page has described the various options available for connecting a Geth node to Ethereum, public testnets and private networks.

src/pages/docs/fundamentals/pruning.md

@@ -2,33 +2,33 @@
 title: Pruning
 description: Instructions for pruning a Geth node
 ---
-{% include note.html content="Offline pruning is only for the hash-based state scheme. Soon, we will have a path-based state scheme which enables the pruning by default. Once the hash-based state scheme is no longer supported, offline pruning will be deprecated." %}
 
+{% include note.html content="Offline pruning is only for the hash-based state scheme. Soon, we will have a path-based state scheme which enables the pruning by default. Once the hash-based state scheme is no longer supported, offline pruning will be deprecated." %}
 
-A snap-sync'd Geth node currently requires more than 650 GB of disk space to store the historic blockchain data. With default cache size the database grows by about 14 GB/week. This means that Geth users will rapidly run out of space on 1TB hard drives. To solve this problem without needing to purchase additional hardware, Geth can be pruned. Pruning is the process of erasing older data to save disk space. Since Geth `v1.10`, users have been able to trigger a snapshot offline prune to bring the total storage back down to the original ~650 GB in about 4-5 hours. This has to be done periodically to keep the total disk storage 
+A snap-sync'd Geth node currently requires more than 650 GB of disk space to store the historic blockchain data. With default cache size the database grows by about 14 GB/week. This means that Geth users will rapidly run out of space on 1TB hard drives. To solve this problem without needing to purchase additional hardware, Geth can be pruned. Pruning is the process of erasing older data to save disk space. Since Geth `v1.10`, users have been able to trigger a snapshot offline prune to bring the total storage back down to the original ~650 GB in about 4-5 hours. This has to be done periodically to keep the total disk storage
 within the bounds of the local hardware (e.g. every month or so for a 1TB disk).
 
 To prune a Geth node at least 40 GB of free disk space is recommended. This means pruning cannot be used to save a hard drive that has been completely filled. A good rule of thumb is to prune before the node fills ~80% of the available disk space.
 
 ## Pruning rules
 
-1) Do not try to prune an archive node. Archive nodes need to maintain ALL historic data by definition.
-2) Ensure there is at least 40 GB of storage space still available on the disk that will be pruned. Failures have been reported with ~25GB of free space.
-3) Geth is at least `v1.10` ideally > `v1.10.3`
-4) Geth is fully sync'd
-5) Geth has finished creating a snapshot that is at least 128 blocks old. This is true when "state snapshot generation" is no longer reported in the logs.
+1. Do not try to prune an archive node. Archive nodes need to maintain ALL historic data by definition.
+2. Ensure there is at least 40 GB of storage space still available on the disk that will be pruned. Failures have been reported with ~25GB of free space.
+3. Geth is at least `v1.10` ideally > `v1.10.3`
+4. Geth is fully sync'd
+5. Geth has finished creating a snapshot that is at least 128 blocks old. This is true when "state snapshot generation" is no longer reported in the logs.
 
 With these rules satisfied, Geth's database can be pruned.
 
 ## How pruning works
 
-Pruning uses snapshots of the state database as an indicator to determine which nodes in the state trie can be kept and which ones are stale and can be discarded. Geth identifies the target state trie based on a stored snapshot layer which has at least 128 block confirmations on top (for surviving reorgs) data that isn't part of the target state trie or genesis state. 
+Pruning uses snapshots of the state database as an indicator to determine which nodes in the state trie can be kept and which ones are stale and can be discarded. Geth identifies the target state trie based on a stored snapshot layer which has at least 128 block confirmations on top (for surviving reorgs) data that isn't part of the target state trie or genesis state.
 
 Geth prunes the database in three stages:
 
-1) Iterating state snapshot: Geth iterates the bottom-most snapshot layer and constructs a bloom filter set for identifying the target trie nodes.
-2) Pruning state data: Geth deletes stale trie nodes from the database which are not in the bloom filter set.
-3) Compacting database: Geth tidies up the new database to reclaim free space.
+1. Iterating state snapshot: Geth iterates the bottom-most snapshot layer and constructs a bloom filter set for identifying the target trie nodes.
+2. Pruning state data: Geth deletes stale trie nodes from the database which are not in the bloom filter set.
+3. Compacting database: Geth tidies up the new database to reclaim free space.
 
 There may be a period of >1 hour during the Compacting Database stage with no log messages at all. This is normal, and the pruning should be left to run until finally a log message containing the phrase `State pruning successful` appears (i.e. do not restart Geth yet!). That message indicates that the pruning is complete and Geth can be started.
 
@@ -51,7 +51,6 @@ sudo systemctl start geth # restart geth
 
 The pruning could take 4-5 hours to complete. Once finished, restart Geth.
 
-
 ## Troubleshooting
 
 Messages about "state snapshot generation" indicate that a snapshot is not fully generated. This suggests either the `--datadir` is not correct or Geth ran out of time to complete the snapshot generation and the pruning began before the snapshot was completed. In either case, the best course of action is to stop Geth, run it normally again (no pruning) until the snapshot is definitely complete and at least 128 blocks exist on top of it, then try pruning again.
@@ -62,4 +61,4 @@ Messages about "state snapshot generation" indicate that a snapshot is not fully
 
 [Pruning Geth guide (@yorickdowne)](https://gist.github.com/yorickdowne/3323759b4cbf2022e191ab058a4276b2)
 
-[Pruning Geth in a RocketPool node](https://docs.rocketpool.net/guides/node/geth-pruning.html)
+[Pruning Geth in a RocketPool node](https://docs.rocketpool.net/guides/node/geth-pruning.html)

src/pages/docs/fundamentals/security.md

@@ -5,15 +5,15 @@ description: A primer on Geth security best practice.
 
 ## Downloading Geth
 
-Download Geth using the links on our [Downloads](/downloads) page. The SHA256 hashes of the downloaded files can be compared to ours to ensure precise consistency with our releases. This protects against malicious code being inadvertently downloaded from an adversarial source. The same measures should also be taken to download trusted consensus client software.
+Download Geth using the links on the [Downloads](/downloads) page. The SHA256 hashes of the downloaded files can be used to confirm precise consistency with our releases. This protects against malicious code being inadvertently downloaded from an adversarial source. The same measures should also be taken to download trusted consensus client software.
 
 ## Networking security
 
 The local machine's firewall settings should:
 
-* Block all traffic to `8545`, or whatever custom port has been defined for JSON-RPC requests to the node, except for traffic from explicitly defined trusted machines. 
-* Allow traffic on `TCP 30303` or whichever custom port has been defined for peer-to-peer communications. This allows the node to connect to peers.
-* Allow traffic on `UDP 30303` or whichever custom port has been defined for peer-to-peer communications. This allows node discovery.
+- Block all traffic to `8545`, or whatever custom port has been defined for JSON-RPC requests to the node, except for traffic from explicitly defined trusted machines.
+- Allow traffic on `TCP 30303` or whichever custom port has been defined for peer-to-peer communications. This allows the node to connect to peers.
+- Allow traffic on `UDP 30303` or whichever custom port has been defined for peer-to-peer communications. This allows node discovery.
 
 ## Account security
 
@@ -23,9 +23,8 @@ Geth has built-in account management tools that are sufficiently secure for most
 
 Geth allows account unlocking by passing account passwords at startup. This unlocks the account all the while that Geth is running. This is not allowed when `http` traffic is enabled, even with appropriate firewall settings. The combination of `http` and `-unlock` poses too much of a security risk because an attacker able to access the node over the exposed HTTP port would be able to make JSON-RPC requests to the node from the unlocked account, including sending funds to other addresses.
 
-**back up your keystore and passwords safely and securely!**
-
+**Back up your keystore and passwords safely and securely!**
 
 ## Other security considerations
 
-Even with a perfectly secure node, users can still be manipulated by attackers into exposing security weaknesses or inadvertently interact with insecure smart contracts. For an overview, please see the Ethereum [security best practise webpage](https://ethereum.org/en/security) and this introduction to [smart contract security](https://ethereum.org/en/developers/docs/smart-contracts/security).
+Even with a perfectly secure node, users can still be manipulated by attackers into exposing security weaknesses or inadvertently interact with insecure smart contracts. For an overview, please see the Ethereum [security best practise webpage](https://ethereum.org/en/security) and this introduction to [smart contract security](https://ethereum.org/en/developers/docs/smart-contracts/security).

src/pages/docs/fundamentals/sync-modes.md

@@ -23,19 +23,19 @@ A full sync generates the current state by executing every block starting from t
 
 ## Archive nodes
 
-An archive node is a node that retains all historical data right back to genesis. There is no need to regenerate any data from checkpoints because all data is directly available in the node's own storage. Archive nodes are therefore ideal for making fast queries about historical states. At the time of writing (September 2022) a full archive node that stores all data since genesis occupies nearly 12 TB of disk space (keep up with the current size on [Etherscan](https://etherscan.io/chartsync/chainarchive)). Archive nodes are created by configuring Geth's garbage collection so that old data is never deleted: `geth --syncmode full --gcmode archive`. 
+An archive node is a node that retains all historical data right back to genesis. There is no need to regenerate any data from checkpoints because all data is directly available in the node's own storage. Archive nodes are therefore ideal for making fast queries about historical states. At the time of writing (September 2022) a full archive node that stores all data since genesis occupies nearly 12 TB of disk space (keep up with the current size on [Etherscan](https://etherscan.io/chartsync/chainarchive)). Archive nodes are created by configuring Geth's garbage collection so that old data is never deleted: `geth --syncmode full --gcmode archive`.
 
 It is also possible to create a partial/recent archive node where the node was synced using `snap` but the state is never pruned. This creates an archive node that saves all state data from the point that the node first syncs. This is configured by starting Geth with `--syncmode snap gcmode archive`.
 
 ## Light nodes
 
-A light node syncs very quickly and stores the bare minimum of blockchain data. Light nodes only process block headers, not entire blocks. This greatly reduces the computation time, storage and bandwidth required relative to a full node. Light nodes are suitable for resource-constrained devices and can catch up to the head of the chain much faster when they are new or have been offline for a while. The trade-off is that light nodes rely heavily on data served by altruistic full nodes. A light client can be used to query data from Ethereum and submit transactions, acting as a locally-hosted Ethereum wallet. However, because they don't keep local copies of the Ethereum state, light nodes can't validate blocks in the same way as full nodes - they have to trust that the data they receive is honest. To start a node in light mode, pass `--syncmode light`. Be aware that full nodes serving light data are relative scarce so light nodes can struggle to find peers.
+A light node syncs very quickly and stores the bare minimum of blockchain data. Light nodes only process block headers, not entire blocks. This greatly reduces the computation time, storage and bandwidth required relative to a full node. This means light nodes are suitable for resource-constrained devices and can catch up to the head of the chain much faster when they are new or have been offline for a while. The trade-off is that light nodes rely heavily on data served by altruistic full nodes. A light client can be used to query data from Ethereum and submit transactions, acting as a locally-hosted Ethereum wallet. However, because they don't keep local copies of the Ethereum state, light nodes can't validate blocks in the same way as full nodes - they have to trust that the data they receive is honest. To start a node in light mode, pass `--syncmode light`. Be aware that full nodes serving light data are relative scarce so light nodes can struggle to find peers.
 
 Read more about light nodes on our [LES page](/content/docs/fundamentals/les.md).
 
 ## Consensus layer syncing
 
-Since Ethereum transitioned to proof-of-stake, all consensus logic and block propagation was handed over to consensus clients. This means that syncing the blockchain is now a process shared between the consensus and execution clients. Blocks are downloaded by the consensus client and verified by the execution client. There are two ways to sync a consensus client: optimistic sync and checkpoint sync. 
+At the transition to proof-of-stake, all consensus logic and block propagation is handed over to consensus clients. This means that syncing the blockchain is a process shared between the consensus and execution clients. Blocks are downloaded by the consensus client and verified by the execution client. There are two ways to sync a consensus client: optimistic sync and checkpoint sync.
 
 ### Optimistic sync
 
@@ -45,10 +45,10 @@ Read more in the [optimistic sync specs](https://github.com/ethereum/consensus-s
 
 ### Checkpoint sync
 
-Alternatively, the consensus client can grab a checkpoint from a trusted source which provides a target state to sync up to, before switching to full sync and verifying each block in turn. In this mode, the node trusts that the checkpoint is correct. There are many possible sources for this checkpoint - the gold standard would be to get it out-of-band from a trusted friend, but it could also come from block explorers or public APIs/web apps.
+Alternatively, the consensus client can grab a checkpoint from a trusted source which provides a target state to sync up to, before switching to full sync and verifying each block in turn. In this mode, the node trusts that the checkpoint is correct. There are many possible sources for this checkpoint - the gold standard would be to get it out-of-band from another trusted friend, but it could also come from block explorers or public APIs/web apps.
 
 **Note** it is not currently possible to use a Geth light node as an execution client on proof-of-stake Ethereum.
 
 ## Summary
 
-There are several ways to sync a Geth node. The default is to use snap sync to create a full node. This verifies all blocks starting at a recent checkpoint. A trust-minimized alternative is full-sync, which verifies every block since genesis. These modes prune the blockchain data older than 128 blocks, keeping only checkpoints that enable on-request regeneration of historical states. For rapid queries of historical data an archive node is required. Archive nodes keep local copies of all historical data right back to genesis - currently about 12 TB and growing. The opposite extreme is a light node that doesn't store any blockchain data - it requests everything from full nodes. These configurations are controlled by passing `full`, `snap` or `light` to `--syncmode` at startup. For an archive node, `--syncmode` should be `full` and `--gcmode` should be set to `archive`. At the transition to proof-of-stake, light-sync will no longer work (until new light client protocols are shipped). 
+There are several ways to sync a Geth node. The default is to use snap sync to create a full node. This verifies all blocks starting at a recent checkpoint. A trust-minimized alternative is full-sync, which verifies every block since genesis. These modes prune the blockchain data older than 128 blocks, keeping only checkpoints that enable on-request regeneration of historical states. For rapid queries of historical data an archive node is required. Archive nodes keep local copies of all historical data right back to genesis - currently about 12 TB and growing. The opposite extreme is a light node that doesn't store any blockchain data - it requests everything from full nodes. These configurations are controlled by passing `full`, `snap` or `light` to `--syncmode` at startup. For an archive node, `--syncmode` should be `full` and `--gcmode` should be set to `archive`. At the transition to proof-of-stake, light-sync will no longer work (until new light client protocols are shipped).

src/pages/docs/getting_started/consensus-clients.md

@@ -3,17 +3,17 @@ title: Connecting to Consensus Clients
 description: Instructions for connecting Geth to a consensus client
 ---
 
-Geth is an [execution client](https://ethereum.org/en/glossary/#execution-client). Historically, an execution client alone was enough to run a full Ethereum node. However, ever since Ethereum swapped from [proof-of-work](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow) (PoW) to [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos) (PoS) based consensus, Geth has needed to be coupled to another piece of software called a ["consensus client"](https://ethereum.org/en/glossary/#consensus-client). 
+Geth is an [execution client](https://ethereum.org/en/glossary/#execution-client). Historically, an execution client alone was enough to run a full Ethereum node. However, ever since Ethereum swapped from [proof-of-work](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow) (PoW) to [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos) (PoS) based consensus, Geth has needed to be coupled to another piece of software called a ["consensus client"](https://ethereum.org/en/glossary/#consensus-client).
 
 There are five consensus clients available, all of which connect to Geth in the same way. This page will outline how Geth can be set up with a consensus client to form a complete Ethereum node.
 
 ## Configuring Geth
 
-Geth can be downloaded and installed according to the instructions on the [Installing Geth](/docs/install-and-build/installing-geth) page. In order to connect to a consensus client, Geth must expose a port for the inter-client RPC connection. 
+Geth can be downloaded and installed according to the instructions on the [Installing Geth](/docs/install-and-build/installing-geth) page. In order to connect to a consensus client, Geth must expose a port for the inter-client RPC connection.
 
 The RPC connection must be authenticated using a `jwtsecret` file. This is created and saved to `<datadir>/geth/jwtsecret` by default but can also be created and saved to a custom location or it can be self-generated and provided to Geth by passing the file path to `--authrpc.jwtsecret`. The `jwtsecret` file is required by both Geth and the consensus client.
 
-The authorization must then be applied to a specific address/port. This is achieved by passing an address to `--authrpc.addr` and a port number to `--authrpc.port`. It is also safe to provide either `localhost` or a wildcard `*` to `--authrpc.vhosts` so that incoming requests from virtual hosts are accepted by Geth because it only applies to the port authenticated using `jwtsecret`. 
+The authorization must then be applied to a specific address/port. This is achieved by passing an address to `--authrpc.addr` and a port number to `--authrpc.port`. It is also safe to provide either `localhost` or a wildcard `*` to `--authrpc.vhosts` so that incoming requests from virtual hosts are accepted by Geth because it only applies to the port authenticated using `jwtsecret`.
 
 A complete command to start Geth so that it can connect to a consensus client looks as follows:
 
@@ -23,18 +23,18 @@ geth --authrpc.addr localhost --authrpc.port 8551 --authrpc.vhosts localhost --a
 
 ## Consensus clients
 
-There are currently four consensus clients that can be run alongside Geth. These are:
- 
+There are currently five consensus clients that can be run alongside Geth. These are:
+
 [Lighthouse](https://lighthouse-book.sigmaprime.io/): written in Rust
- 
+
 [Nimbus](https://nimbus.team/): written in Nim
- 
+
 [Prysm](https://docs.prylabs.network/docs/getting-started/): written in Go
- 
+
 [Teku](https://pegasys.tech/teku): written in Java
 
 [Lodestar](https://lodestar.chainsafe.io/): written in Typescript
- 
+
 It is recommended to consider [client diversity](https://ethereum.org/en/developers/docs/nodes-and-clients/client-diversity) when choosing a consensus client. Instructions for installing each client are provided in the documentation linked in the list above.
 
 The consensus client must be started with the right port configuration to establish an RPC connection to the local Geth instance. In the example above, `localhost:8551` was authorized for this purpose. The consensus clients all have a command similar to `--http-webprovider` that takes the exposed Geth port as an argument.
@@ -49,7 +49,7 @@ Validators are responsible for securing the Ethereum blockchain. Validators have
 
 ## Using Geth
 
-Geth is the portal for users to send transactions to Ethereum. The Geth Javascript console is available for this purpose, and the majority of the [JSON-RPC API](/docs/rpc/server) will remain available via web3js or HTTP requests with commands as json payloads. These options are explained in more detail on the [Javascript Console page](/docs/interface/javascript-console). The Javascript console can be started 
+Geth is the portal for users to send transactions to Ethereum. The Geth Javascript console is available for this purpose, and the majority of the [JSON-RPC API](/docs/rpc/server) will remain available via web3js or HTTP requests with commands as json payloads. These options are explained in more detail on the [Javascript Console page](/docs/interface/javascript-console). The Javascript console can be started
 using the following command in a separate terminal (assuming Geth's IPC file is saved in `datadir`):
 
 ```shell
@@ -59,5 +59,3 @@ geth attach datadir/geth.ipc
 ## Summary
 
 Now that Ethereum has implemented proof-of-stake, Geth users are required to install and run a consensus client. Otherwise, Geth will not be able to track the head of the chain. There are five consensus clients to choose from. This page provided an overview of how to choose a consensus client and configure Geth to connect to it.
-
-

src/pages/docs/getting_started/getting-started-with-clef.md

@@ -16,7 +16,7 @@ In order to get the most value from the tutorials on this page, the following sk
 - Basic knowledge about HTTP and JavaScript
 - Basic knowledge of node architecture and consensus clients
 
-Users that need to revisit these fundamentals can find helpful resources relating to the command line [here](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line), Ethereum and its testnets [here](https://ethereum.org/en/developers/tutorials/), http [here](https://developer.mozilla.org/en-US/docs/Web/HTTP) and Javascript [here](https://www.javascript.com/learn). Information on node architecture can be found [here](/content/docs/fundamentals/node-architecture.md) and our guide for configuring Geth to connect to a 
+Users that need to revisit these fundamentals can find helpful resources relating to the command line [here](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line), Ethereum and its testnets [here](https://ethereum.org/en/developers/tutorials/), http [here](https://developer.mozilla.org/en-US/docs/Web/HTTP) and Javascript [here](https://www.javascript.com/learn). Information on node architecture can be found [here](/content/docs/fundamentals/node-architecture.md) and our guide for configuring Geth to connect to a
 consensus client is [here](/content/docs/getting_started/consensus-clients.md).
 
 {% include note.html content="If Geth was installed from source on Linux, `make` saves the binaries for Geth and the associated tools in `/build/bin`. To run these programs it is convenient to move them to the top level project directory (e.g. running `mv ./build/bin/* ./`) from `/go-ethereum`. Then `./` must be prepended to the commands in the code snippets in order to execute a particular program, e.g. `./geth` instead of simply `geth`. If the executables are not
@@ -24,9 +24,9 @@ moved then either navigate to the `bin` directory to run them (e.g. `cd ./build/
 
 ## Background
 
-Geth is an Ethereum client written in Go. This means running Geth turns a computer into an Ethereum node. Ethereum is a peer-to-peer network where information is shared directly between nodes rather than being managed by a central server. Every 12 seconds one node is randomly selected to generate a new block containing a list of transactions that nodes receiving the block should execute. This "block proposer" node sends the new block to its peers. On receiving a new block, each node checks that it is valid and adds it to their database. The sequence of discrete blocks is called a "blockchain". 
+Geth is an Ethereum client written in Go. This means running Geth turns a computer into an Ethereum node. Ethereum is a peer-to-peer network where information is shared directly between nodes rather than being managed by a central server. Every 12 seconds one node is randomly selected to generate a new block containing a list of transactions that nodes receiving the block should execute. This "block proposer" node sends the new block to its peers. On receiving a new block, each node checks that it is valid and adds it to their database. The sequence of discrete blocks is called a "blockchain".
 
-The information provided in each block is used by Geth to update its "state" - the ether balance of each account on Ethereum and the data stored by each smart contract. There are two types of account: externally-owned accounts (EOAs) and contract accounts. Contract accounts execute contract code when they receive transactions. EOAs are accounts that users manage locally in order to sign and submit transactions. Each EOA is a public-private key pair, where the public key is used to derive a unique address for the user and the private key is used to protect the account and securely sign messages. Therefore, in order to use Ethereum, 
+The information provided in each block is used by Geth to update its "state" - the ether balance of each account on Ethereum and the data stored by each smart contract. There are two types of account: externally-owned accounts (EOAs) and contract accounts. Contract accounts execute contract code when they receive transactions. EOAs are accounts that users manage locally in order to sign and submit transactions. Each EOA is a public-private key pair, where the public key is used to derive a unique address for the user and the private key is used to protect the account and securely sign messages. Therefore, in order to use Ethereum,
 it is first necessary to generate an EOA (hereafter, "account"). This tutorial will guide the user through creating an account, funding it with ether and sending some to another address.
 
 Read more about Ethereum accounts [here](https://ethereum.org/en/developers/docs/accounts/).
@@ -41,7 +41,7 @@ An account is a pair of keys (public and private). Clef needs to know where to s
 clef newaccount --keystore geth-tutorial/keystore
 ```
 
-The specific function from Clef that generates new accounts is `newaccount` and it accepts a parameter, `--keystore`, that tells it where to store the newly generated keys. In this example the keystore location is a new directory that will be created automatically: `geth-tutorial/keystore`. 
+The specific function from Clef that generates new accounts is `newaccount` and it accepts a parameter, `--keystore`, that tells it where to store the newly generated keys. In this example the keystore location is a new directory that will be created automatically: `geth-tutorial/keystore`.
 Clef will return the following result in the terminal:
 
 ```terminal
@@ -63,7 +63,6 @@ Enter 'ok' to proceed:
 
 This is important information. The `geth-tutorial/keystore` directory will soon contain a secret key that can be used to access any funds held in the new account. If it is compromised, the funds can be stolen. If it is lost, there is no way to retrieve the funds. This tutorial will only use dummy funds with no real world value, but when these steps are repeated on Ethereum mainnet is critical that the keystore is kept secure and backed up.
 
-
 Typing `ok` into the terminal and pressing `enter` causes Clef to prompt for a password. Clef requires a password that is at least 10 characters long, and best practice would be to use a combination of numbers, characters and special characters. Entering a suitable password and pressing `enter` returns the following result to the terminal:
 
 ```terminal
@@ -77,9 +76,9 @@ Generated account 0xCe8dBA5e4157c2B284d8853afEEea259344C1653
 
 It is important to save the account address and the password somewhere secure. They will be used again later in this tutorial. Please note that the account address shown in the code snippets above and later in this tutorials are examples - those generated by followers of this tutorial will be different. The account generated above can be used as the main account throughout the remainder of this tutorial. However in order to demonstrate transactions between accounts it is also necessary to have a second account. A second account can be added to the same keystore by precisely repeating the previous steps, providing the same password.
 
-## Step 2:  Start Clef
+## Step 2: Start Clef
 
-The previous commands used Clef's `newaccount` function to add new key pairs to the keystore. Clef uses the private key(s) saved in the keystore is used to sign transactions. In order to do this, Clef needs to be started and left running while Geth is running simultaneously, so that the two programs can communicate between one another. 
+The previous commands used Clef's `newaccount` function to add new key pairs to the keystore. Clef uses the private key(s) saved in the keystore is used to sign transactions. In order to do this, Clef needs to be started and left running while Geth is running simultaneously, so that the two programs can communicate between one another.
 
 To start Clef, run the Clef executable passing as arguments the keystore file location, config directory location and a chain ID. The config directory was automatically created inside the `geth-tutorial` directory during the previous step. The [chain ID](https://chainlist.org/) is an integer that defines which Ethereum network to connect to. Ethereum mainnet has chain ID 1. In this tutorial Chain ID 5 is used which is that of the Goerli testnet. It is very important that this chain ID parameter is set to 5. The following command starts Clef on Goerli:
 
@@ -89,7 +88,7 @@ clef --keystore geth-tutorial/keystore --configdir geth-tutorial/clef --chainid
 
 ```
 
-After running the command above, Clef requests the user to type “ok” to proceed. On typing "ok" and pressing enter, Clef returns the following to the terminal:  
+After running the command above, Clef requests the user to type “ok” to proceed. On typing "ok" and pressing enter, Clef returns the following to the terminal:
 
 ```terminal
 INFO [02-10|13:55:30.812] Using CLI as UI-channel
@@ -112,11 +111,11 @@ INFO [02-10|13:55:30.984] IPC endpoint opened                      url=geth-tuto
 
 This result indicates that Clef is running. This terminal should be left running for the duration of this tutorial. If the tutorial is stopped and restarted later Clef must also be restarted by running the previous command.
 
-## Step 3:  Start Geth
+## Step 3: Start Geth
 
 Geth is the Ethereum client that will connect the computer to the Ethereum network. In this tutorial the network is Goerli, an Ethereum testnet. Testnets are used to test Ethereum client software and smart contracts in an environment where no real-world value is at risk. To start Geth, run the Geth executable file passing argument that define the data directory (where Geth should save blockchain data), signer (points Geth to Clef), the network ID and the sync mode. For this tutorial, snap sync is recommended (see [here](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) for reasons why). The final argument passed to Geth is the `--http` flag. This enables the http-rpc server that allows external programs to interact with Geth by sending it http requests. By default the http server is only exposed locally using port 8545: `localhost:8545`.
 
-The following command should be run in a new terminal, separate to the one running Clef: 
+The following command should be run in a new terminal, separate to the one running Clef:
 
 ```shell
 geth --datadir geth-tutorial --signer=geth-tutorial/clef/clef.ipc --goerli --syncmode snap --http
@@ -148,7 +147,7 @@ WARN [02-10|13:59:06.999] Failed to open wallet                    url=extapi://
 INFO [02-10|13:59:08.793] Block synchronisation started
 ```
 
-This indicates that Geth has started up and is searching for peers to connect to. Once it finds peers it can request block headers from them, starting at the genesis block for the Goerli blockchain. Geth continues to download blocks sequentially, saving the data in files in `/go-ethereum/geth-tutorial/geth/chaindata/`. 
+This indicates that Geth has started up and is searching for peers to connect to. Once it finds peers it can request block headers from them, starting at the genesis block for the Goerli blockchain. Geth continues to download blocks sequentially, saving the data in files in `/go-ethereum/geth-tutorial/geth/chaindata/`.
 This is confirmed by the logs printed to the terminal. There should be a rapidly-growing sequence of logs in the terminal with the following syntax:
 
 ```terminal
@@ -157,35 +156,33 @@ INFO [04-29][15:54:19.393] Imported new block headers    count=2 elapsed=1.127ms
 INFO [04-29][15:54:19:656] Imported new block receipts   count=698  elapsed=4.464ms number=994566 hash=56dc44..007c93 age=13h9m9s
 ```
 
-These logs indicate that Geth is running as expected. Sending an empty Curl request to the http server 
-provides a quick way to confirm that this too has been started without any issues. In a third terminal, 
+These logs indicate that Geth is running as expected. Sending an empty Curl request to the http server
+provides a quick way to confirm that this too has been started without any issues. In a third terminal,
 the following command can be run:
 
 ```shell
 curl http://localhost:8545
 ```
 
-If there is no error message reported to the terminal, everything is OK. Geth must be running in order for a user to interact with the Ethereum network. If this terminal is closed down then Geth must be restarted in a new terminal. Geth can be started and stopped easily, but it must be running for any interaction with 
+If there is no error message reported to the terminal, everything is OK. Geth must be running in order for a user to interact with the Ethereum network. If this terminal is closed down then Geth must be restarted in a new terminal. Geth can be started and stopped easily, but it must be running for any interaction with
 Ethereum to take place. To shut down Geth, simply press `CTRL+C` in the Geth terminal. To start it again, run the previous command `geth --datadir <other commands>`.
 
 {% include note.html content="Snap syncing Goerli will take some time and until the sync is finished you can't use the node to transfer funds. You can also try doing a [light sync](interface/les) which will be much quicker but depends on light servers being available to serve your node the data it needs." %}
 
-## Step 4:  Get Testnet Ether
+## Step 4: Get Testnet Ether
 
 In order to make some transactions, the user must fund their account with ether. On Ethereum mainnet, ether can only be obtained in three ways: 1) by receiving it as a reward for mining/validating; 2) receiving it in a transfer from another Ethereum user or contract; 3) receiving it from an exchange, 3) having paid for it with fiat money. On Ethereum testnets, the ether has no real world value so it 4) can be made freely available via faucets. Faucets allow users to request a transfer of testnet ether to their account.
 
 The address generated by Clef in Step 1 can be pasted into the Paradigm Multifaucet faucet [here](https://fauceth.komputing.org/?chain=1115511). This requires a Twitter login as proof of personhood. The faucets adds ether to the given address on multiple testnets simultaneously, including Goerli. In the next steps Geth will be used to check that the ether has been sent to the given address and send some of it to the second address created earlier.
 
-
 ## Step 5: Interact with Geth
 
-For interacting with the blockchain, Geth provides JSON-RPC APIs. [JSON-RPC](https://ethereum.org/en/developers/docs/apis/json-rpc/) is a way to execute specific 
-tasks by sending instructions to Geth in the form of [JSON](https://www.json.org/json-en.html) objects. RPC stands for "Remote Procedure Call" and it refers to the ability to send these JSON-encoded instructions from locations outside of those managed by Geth. It is possible to interact with Geth by sending these JSON encoded instructions directly over Geth's exposed http port using tools like Curl. However, this is somewhat user-unfriendly and error-prone, especially for more complex instructions. For this reason, there are a set of libraries built on top of JSON-RPC that provide a more user-friendly interface for interacting with Geth. One of the most widely used is Web3.js. 
+For interacting with the blockchain, Geth provides JSON-RPC APIs. [JSON-RPC](https://ethereum.org/en/developers/docs/apis/json-rpc/) is a way to execute specific
+tasks by sending instructions to Geth in the form of [JSON](https://www.json.org/json-en.html) objects. RPC stands for "Remote Procedure Call" and it refers to the ability to send these JSON-encoded instructions from locations outside of those managed by Geth. It is possible to interact with Geth by sending these JSON encoded instructions directly over Geth's exposed http port using tools like Curl. However, this is somewhat user-unfriendly and error-prone, especially for more complex instructions. For this reason, there are a set of libraries built on top of JSON-RPC that provide a more user-friendly interface for interacting with Geth. One of the most widely used is Web3.js.
 
 Geth provides a Javascript console that exposes the Web3.js API. This means that with Geth running in one terminal, a Javascript environment can be opened in another allowing the user to interact with Geth using Web3.js. There are three transport protocols that can be used to connect the Javascript environment to Geth:
 
 - IPC (Inter-Process Communication): Provides unrestricted access to all APIs, but only works when the console is run on the same host as the geth node.
-  
 - HTTP: By default provides access to the `eth`, `web3` and `net` method namespaces.
 
 - Websocket: By default provides access to the `eth`, `web3` and `net` method namespaces.
@@ -210,13 +207,12 @@ To exit, press ctrl-d or type exit
 
 The console is now active and connected to Geth. It can now be used to interact with the Ethereum (Goerli) network.
 
-
 ### List of accounts
 
-In this tutorial, the accounts are managed using Clef. This means that requesting information about the accounts requires explicit approval in Clef, which should still be running in its own terminal. Earlier in this tutorial, two accounts were created using Clef. The following command will display the addresses of those two accounts and any others that might have been added to the keystore before or since. 
+In this tutorial, the accounts are managed using Clef. This means that requesting information about the accounts requires explicit approval in Clef, which should still be running in its own terminal. Earlier in this tutorial, two accounts were created using Clef. The following command will display the addresses of those two accounts and any others that might have been added to the keystore before or since.
 
 ```javascript
-eth.accounts
+eth.accounts;
 ```
 
 The console will hang, because Clef is waiting for approval. The following message will be displayed in the Clef terminal:
@@ -248,13 +244,12 @@ Entering `y` approves the request from the console. In the terminal running the
 
 It is also possible for this request to time out if the Clef approval took too long - in this case simply repeat the request and approval.
 
-
 ### Checking account balance.
 
 Having confirmed that the two addresses created earlier are indeed in the keystore and accessible through the Javascript console, it is possible to retrieve information about how much ether they own. The Goerli faucet should have sent 1 ETH to the address provided, meaning that the balance of one of the accounts should be 1 ether and the other should be 0. The following command displays the account balance in the console:
 
 ```javascript
-web3.fromWei(eth.getBalance("0xca57F3b40B42FCce3c37B8D18aDBca5260ca72EC"), "ether")
+web3.fromWei(eth.getBalance('0xca57F3b40B42FCce3c37B8D18aDBca5260ca72EC'), 'ether');
 ```
 
 There are actually two instructions sent in the above command. The inner one is the `getBalance` function from the `eth` namespace. This takes the account address as its only argument. By default, this returns the account balance in units of Wei. There are 10<sup>18</sup> Wei to one ether. To present the result in units of ether, `getBalance` is wrapped in the `fromWei` function from the `web3` namespace. Running this command should provide the following result (for the account that received faucet funds):
@@ -275,10 +270,10 @@ The command `eth.sendTransaction` can be used to send some ether from one addres
 
 ```javascript
 eth.sendTransaction({
-    from: "0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec",
-    to: "0xce8dba5e4157c2b284d8853afeeea259344c1653",
-    value: web3.toWei(0.1, "ether")
-})
+  from: '0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec',
+  to: '0xce8dba5e4157c2b284d8853afeeea259344c1653',
+  value: web3.toWei(0.1, 'ether')
+});
 ```
 
 Note that submitting this transaction requires approval in Clef. In the Clef terminal, Clef will prompt for approval and request the account password. If the password is correctly entered, Geth proceeds with the transaction. The transaction request summary is presented by Clef in the Clef terminal. This is an opportunity for the sender to review the details and ensure they are correct.
@@ -340,13 +335,12 @@ In the Javascript console, the transaction hash is displayed. This will be used
 
 It is also advised to check the account balances using Geth by repeating the instructions from earlier. At this point in the tutorial, the two accounts in the Clef keystore should have balances just below 0.9 ether (because 0.1 ether has been transferred out and some small amount paid in transaction gas) and 0.1 ether.
 
-
 ### Checking the transaction hash
 
 The transaction hash is a unique identifier for this specific transaction that can be used later to retrieve the transaction details. For example, the transaction details can be viewed by pasting this hash into the [Goerli block explorer](https://goerli.etherscan.io/). The same information can also be retrieved directly from the Geth node. The hash returned in the previous step can be provided as an argument to `eth.getTransaction` to return the transaction information:
 
 ```javascript
-eth.getTransaction("0x99d489d0bd984915fd370b307c2d39320860950666aac3f261921113ae4f95bb")
+eth.getTransaction('0x99d489d0bd984915fd370b307c2d39320860950666aac3f261921113ae4f95bb');
 ```
 
 This returns the following response (although the actual values for each field will vary because they are specific to each transaction):
@@ -381,7 +375,7 @@ Up to this point this tutorial has interacted with Geth using the convenience li
 
 ### Checking account balance
 
-The command below returns the balance of the given account. This is a HTTP POST request to the local port 8545. The `-H` flag is for header information. It is used here to define the format of the incoming payload, which is JSON. The `--data` flag defines the content of the payload, which is a JSON object. That JSON object contains four fields: `jsonrpc` defines the spec version for the JSON-RPC API, `method` is the specific function being invoked, `params` are the function 
+The command below returns the balance of the given account. This is a HTTP POST request to the local port 8545. The `-H` flag is for header information. It is used here to define the format of the incoming payload, which is JSON. The `--data` flag defines the content of the payload, which is a JSON object. That JSON object contains four fields: `jsonrpc` defines the spec version for the JSON-RPC API, `method` is the specific function being invoked, `params` are the function
 arguments, and `id` is used for ordering transactions. The two arguments passed to `eth_getBalance` are the account address whose balance to check and the block to query (here `latest` is used to check the balance in the most recently mined block).
 
 ```shell
@@ -401,6 +395,7 @@ The balance is in the `result` field in the returned JSON object. However, it is
 ```python
 0xc7d54951f87f7c0 / 1e18
 ```
+
 This returns the balance in ether:
 
 ```terminal
@@ -425,8 +420,7 @@ This requires approval in Clef. Once approved, the following information is retu
 
 ### Sending Transactions
 
-Sending a transaction between accounts can also be achieved using Curl. Notice that the value of the transaction is a hexadecimal string in units of Wei. To transfer 0.1 ether, it is first necessary to convert this to Wei by multiplying by 10<sup>18</sup> then converting to hex. 0.1 ether is `"0x16345785d8a0000"` in hex. As before, update the `to` and `from` fields with the addresses in the Clef keystore.  
-
+Sending a transaction between accounts can also be achieved using Curl. Notice that the value of the transaction is a hexadecimal string in units of Wei. To transfer 0.1 ether, it is first necessary to convert this to Wei by multiplying by 10<sup>18</sup> then converting to hex. 0.1 ether is `"0x16345785d8a0000"` in hex. As before, update the `to` and `from` fields with the addresses in the Clef keystore.
 
 ```shell
 curl -X POST http://127.0.0.1:8545 \
@@ -443,5 +437,3 @@ This requires approval in Clef. Once the password for the sender account has bee
 ## Summary
 
 This tutorial has demonstrated how to generate accounts using Clef, fund them with testnet ether and use those accounts to interact with Ethereum (Goerli) through a Geth node. Checking account balances, sending transactions and retrieving transaction details were explained using the web3.js library via the Geth console and using the JSON-RPC directly using Curl. For more detailed information about Clef, please see [the Clef docs](/content/docs/tools/Clef/Tutorial.md).
-
-

src/pages/docs/getting_started/getting-started.md

@@ -11,7 +11,7 @@ accounts in Geth, is sufficiently secure for many purposes and provides a good e
 
 ## Prerequisites
 
-In order to get the most value from the tutorials on this page, the following skills are 
+In order to get the most value from the tutorials on this page, the following skills are
 necessary:
 
 - Experience using the command line
@@ -19,7 +19,7 @@ necessary:
 - Basic knowledge about HTTP and JavaScript
 - Basic knowledge of node architecture and consensus clients
 
-Users that need to revisit these fundamentals can find helpful resources relating to the command line [here](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line), Ethereum and its testnets [here](https://ethereum.org/en/developers/tutorials/), http [here](https://developer.mozilla.org/en-US/docs/Web/HTTP) and Javascript [here](https://www.javascript.com/learn). Information on node architecture can be found [here](/content/docs/fundamentals/node-architecture.md) and our guide for configuring Geth to connect to a 
+Users that need to revisit these fundamentals can find helpful resources relating to the command line [here](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line), Ethereum and its testnets [here](https://ethereum.org/en/developers/tutorials/), http [here](https://developer.mozilla.org/en-US/docs/Web/HTTP) and Javascript [here](https://www.javascript.com/learn). Information on node architecture can be found [here](/content/docs/fundamentals/node-architecture.md) and our guide for configuring Geth to connect to a
 consensus client is [here](/content/docs/getting_started/consensus-clients.md).
 
 {% include note.html content="If Geth was installed from source on Linux, `make` saves the binaries for Geth and the associated tools in `/build/bin`. To run these programs it is convenient to move them to the top level project directory (e.g. running `mv ./build/bin/* ./`) from `/go-ethereum`. Then `./` must be prepended to the commands in the code snippets in order to execute a particular program, e.g. `./geth` instead of simply `geth`. If the executables are not
@@ -28,14 +28,13 @@ moved then either navigate to the `bin` directory to run them (e.g. `cd ./build/
 ## Background
 
 Geth is an Ethereum client written in Go. This means running Geth turns a computer into an Ethereum node. Ethereum is a peer-to-peer network where information is shared directly between nodes rather than being managed by a central server. Every 12 seconds one node is randomly selected to generate a new block
-containing a list of transactions that nodes receiving the block should execute. This "block proposer" node sends the new block to its peers. On receiving a new block, each node checks that it is valid and adds it to their database. The sequence of discrete blocks is called a "blockchain". 
+containing a list of transactions that nodes receiving the block should execute. This "block proposer" node sends the new block to its peers. On receiving a new block, each node checks that it is valid and adds it to their database. The sequence of discrete blocks is called a "blockchain".
 
-The information provided in each block is used by Geth to update its "state" - the ether balance of each account on Ethereum and the data stored by each smart contract. There are two types of account: externally-owned accounts (EOAs) and contract accounts. Contract accounts execute contract code when they receive transactions. EOAs are accounts that users manage locally in order to sign and submit transactions. Each EOA is a public-private key pair, where the public key is used to derive a unique address for the user and the private key is used to protect the account and securely sign messages. Therefore, in order to use Ethereum, 
+The information provided in each block is used by Geth to update its "state" - the ether balance of each account on Ethereum and the data stored by each smart contract. There are two types of account: externally-owned accounts (EOAs) and contract accounts. Contract accounts execute contract code when they receive transactions. EOAs are accounts that users manage locally in order to sign and submit transactions. Each EOA is a public-private key pair, where the public key is used to derive a unique address for the user and the private key is used to protect the account and securely sign messages. Therefore, in order to use Ethereum,
 it is first necessary to generate an EOA (hereafter, "account"). This tutorial will guide the user through creating an account, funding it with ether and sending some to another address.
 
 Read more about Ethereum accounts [here](https://ethereum.org/en/developers/docs/accounts/).
 
-
 ## Step 1: Generating accounts
 
 To generate a new account in Geth:
@@ -49,6 +48,7 @@ This returns a prompt for a password. Once provided, a new account will be creat
 ```sh
 geth account new --keystore geth-tutorial/keystore
 ```
+
 The following will be returned to the console, confirming the new account has been created and added to the keystore.
 
 ```terminal
@@ -67,19 +67,20 @@ Path of the secret key file: /home/go-ethereum/geth-tutorial/keystore/UTC--2022-
 - You must REMEMBER your password! Without the password, it's impossible to decrypt the key!
 ```
 
-It is important to save the account address and the password somewhere secure. They will be used again later in this tutorial. Please note that the account address shown in the code snippets above and later in this tutorials are examples - those generated by followers of this tutorial will be different. The account generated above can be used as the main account throughout the remainder of this tutorial. However in order to demonstrate transactions between accounts it is 
+It is important to save the account address and the password somewhere secure. They will be used again later in this tutorial. Please note that the account address shown in the code snippets above and later in this tutorials are examples - those generated by followers of this tutorial will be different. The account generated above can be used as the main account throughout the remainder of this tutorial. However in order to demonstrate transactions between accounts it is
 also necessary to have a second account. A second account can be added to the same keystore by precisely repeating the previous steps, providing the same password.
 
-Notice that the path to the secret key includes a long filename that starts `UTC--`. This is the name of the file that contains the keys for the new account. It is **extremely important** that this file stays secure because it contains the secret key used to control access to any funds associated with the account. The file should be backed up securely along with the password used to encrypt it. If the file or the password is lost, then so is access to the funds in the account. If someone else gains access to the keyfile and password, they have access to any assets in the account. 
+Notice that the path to the secret key includes a long filename that starts `UTC--`. This is the name of the file that contains the keys for the new account. It is **extremely important** that this file stays secure because it contains the secret key used to control access to any funds associated with the account. The file should be backed up securely along with the password used to encrypt it. If the file or the password is lost, then so is access to the funds in the account. If someone else gains access to the keyfile and password, they have access to any assets in the account.
 
-## Step 2:  Start Geth
+## Step 2: Start Geth
 
-Geth is the Ethereum client that will connect the computer to the Ethereum network. In this tutorial the network is Goerli, an Ethereum testnet. Testnets are used to test Ethereum client software and smart contracts in an environment where no real-world value is at risk. To start Geth, run the Geth executable file passing argument that define the data directory (where Geth should save blockchain data), the network ID and the sync mode. For this tutorial, snap sync is recommended 
-(see [here](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) for reasons why). The following command should be run in the terminal: 
+Geth is the Ethereum client that will connect the computer to the Ethereum network. In this tutorial the network is Goerli, an Ethereum testnet. Testnets are used to test Ethereum client software and smart contracts in an environment where no real-world value is at risk. To start Geth, run the Geth executable file passing argument that define the data directory (where Geth should save blockchain data), the network ID and the sync mode. For this tutorial, snap sync is recommended
+(see [here](https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) for reasons why). The following command should be run in the terminal:
 
 ```shell
 geth --datadir geth-tutorial --goerli --syncmode snap
 ```
+
 Running the above command starts Geth. The terminal should rapidly fill with status updates that look like the following:
 
 ```terminal
@@ -103,7 +104,7 @@ WARN [02-10|13:59:06.998] Light client mode is an experimental feature
 INFO [02-10|13:59:08.793] Block synchronisation started
 ```
 
-This indicates that Geth has started up and is searching for peers to connect to. Once it finds peers it can request block headers from them, starting at the genesis block for the Goerli blockchain. Geth continues to download blocks sequentially, saving the data in files in `/go-ethereum/geth-tutorial/geth/chaindata/`. 
+This indicates that Geth has started up and is searching for peers to connect to. Once it finds peers it can request block headers from them, starting at the genesis block for the Goerli blockchain. Geth continues to download blocks sequentially, saving the data in files in `/go-ethereum/geth-tutorial/geth/chaindata/`.
 This is confirmed by the logs printed to the terminal. There should be a rapidly-growing sequence of logs in the terminal with the following syntax:
 
 ```terminal
@@ -118,22 +119,20 @@ If there is no error message reported to the terminal, everything is OK. Geth mu
 
 {% include note.html content="Snap syncing Goerli will take some time and until the sync is finished you can't use the node to transfer funds. You can also try doing a [light sync](interface/les) which will be much quicker but depends on light servers being available to serve your node the data it needs." %}
 
-## Step 3:  Get Testnet Ether
+## Step 3: Get Testnet Ether
 
 In order to make some transactions, the user must fund their account with ether. On Ethereum mainnet, ether can only be obtained in three ways: 1) by receiving it as a reward for mining/validating; 2) receiving it in a transfer from another Ethereum user or contract; 3) receiving it from an exchange, having paid for it with fiat money. On Ethereum testnets, the ether has no real world value so it can be made freely available via faucets. Faucets allow users to request a transfer of testnet ether to their account.
 
 The address generated by `geth account new` can be pasted into the Paradigm Multifaucet faucet [here](https://fauceth.komputing.org/?chain=1115511). This requires a Twitter login as proof of personhood. The faucets adds ether to the given address on multiple testnets simultaneously, including Goerli. In the next steps Geth will be used to check that the ether has been sent to the given address and send some of it to the second address created earlier.
 
-
 ## Step 4: Interact with Geth
 
-For interacting with the blockchain, Geth provides JSON-RPC APIs. 
-[JSON-RPC](https://ethereum.org/en/developers/docs/apis/json-rpc/) is a way to execute specific tasks by sending instructions to Geth in the form of [JSON](https://www.json.org/json-en.html) objects. RPC stands for "Remote Procedure Call" and it refers to the ability to send these JSON-encoded instructions from locations outside of those managed by Geth. It is possible to interact with Geth by sending these JSON encoded instructions directly to Geth using tools such as Curl. However, this is somewhat user-unfriendly and error-prone, especially for more complex instructions. For this reason, there are a set of libraries built on top of JSON-RPC that provide a more user-friendly interface for interacting with Geth. One of the most widely used is Web3.js. 
+For interacting with the blockchain, Geth provides JSON-RPC APIs.
+[JSON-RPC](https://ethereum.org/en/developers/docs/apis/json-rpc/) is a way to execute specific tasks by sending instructions to Geth in the form of [JSON](https://www.json.org/json-en.html) objects. RPC stands for "Remote Procedure Call" and it refers to the ability to send these JSON-encoded instructions from locations outside of those managed by Geth. It is possible to interact with Geth by sending these JSON encoded instructions directly to Geth using tools such as Curl. However, this is somewhat user-unfriendly and error-prone, especially for more complex instructions. For this reason, there are a set of libraries built on top of JSON-RPC that provide a more user-friendly interface for interacting with Geth. One of the most widely used is Web3.js.
 
 Geth provides a Javascript console that exposes the Web3.js API. This means that with Geth running in one terminal, a Javascript environment can be opened in another allowing the user to interact with Geth using Web3.js. There are three transport protocols that can be used to connect the Javascript environment to Geth:
 
 - IPC (Inter-Process Communication): Provides unrestricted access to all APIs, but only works when the console is run on the same host as the Geth node.
-  
 - HTTP: By default provides access to the `eth`, `web3` and `net` method namespaces.
 
 - Websocket: By default provides access to the `eth`, `web3` and `net` method namespaces.
@@ -161,26 +160,25 @@ The console is now active and connected to Geth. It can now be used to interact
 
 ### List of accounts
 
-Earlier in this tutorial, at least one account was created using `geth account new`. The following command will display the addresses of those two accounts and any others that might have been added to the keystore before or since. 
+Earlier in this tutorial, at least one account was created using `geth account new`. The following command will display the addresses of those two accounts and any others that might have been added to the keystore before or since.
 
 ```javascript
-eth.accounts
+eth.accounts;
 ```
 
 ```terminal
 ["0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec", "0xce8dba5e4157c2b284d8853afeeea259344c1653"]
 ```
 
-
 ### Checking account balance.
 
 Having confirmed that the two addresses created earlier are indeed in the keystore and accessible through the Javascript console, it is possible to retrieve information about how much ether they own. The Goerli faucet should have sent 1 ETH to the address provided, meaning that the balance of one of the accounts should be 1 ether and the other should be 0. The following command displays the account balance in the console:
 
 ```javascript
-web3.fromWei(eth.getBalance("0xca57F3b40B42FCce3c37B8D18aDBca5260ca72EC"), "ether")
+web3.fromWei(eth.getBalance('0xca57F3b40B42FCce3c37B8D18aDBca5260ca72EC'), 'ether');
 ```
 
-There are actually two instructions sent in the above command. The inner one is the `getBalance` function from the `eth` namespace. This takes the account address as its only argument. By default, this returns the account balance in units of Wei. There are 10<sup>18</sup> Wei to one ether. To present the result in units of ether, `getBalance` is wrapped in the `fromWei` function from the `web3` namespace. Running this command should provide the following result (for the account that 
+There are actually two instructions sent in the above command. The inner one is the `getBalance` function from the `eth` namespace. This takes the account address as its only argument. By default, this returns the account balance in units of Wei. There are 10<sup>18</sup> Wei to one ether. To present the result in units of ether, `getBalance` is wrapped in the `fromWei` function from the `web3` namespace. Running this command should provide the following result (for the account that
 received faucet funds):
 
 ```terminal
@@ -199,10 +197,10 @@ The command `eth.sendTransaction` can be used to send some ether from one addres
 
 ```javascript
 eth.sendTransaction({
-    from: "0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec",
-    to: "0xce8dba5e4157c2b284d8853afeeea259344c1653",
-    value: web3.toWei(0.1, "ether")
-})
+  from: '0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec',
+  to: '0xce8dba5e4157c2b284d8853afeeea259344c1653',
+  value: web3.toWei(0.1, 'ether')
+});
 ```
 
 This command will return an error message indicating that `authentication is needed: password or unlock`. This is a security feature that prevents unauthorized access to sensitive account operations. There are two ways to unlock the account. The first is to start Geth with the account permanently unlocked (by passing `--unlock <address>` at startup). This is not recommended because the account remains unlocked all the time Geth is running, creating a security weakness. Instead, it is better to temporarily unlock the account for the specific transaction. This requires using the `sendTransaction` method from the `personal` namespace instead of the `eth` namespace. The password can be provided as a string in the method call as follows:
@@ -228,7 +226,7 @@ It is also advised to check the account balances using Geth by repeating the ins
 The transaction hash is a unique identifier for this specific transaction that can be used later to retrieve the transaction details. For example, the transaction details can be viewed by pasting this hash into the [Goerli block explorer](https://goerli.etherscan.io/). The same information can also be retrieved directly from the Geth node. The hash returned in the previous step can be provided as an argument to `eth.getTransaction` to return the transaction information:
 
 ```javascript
-eth.getTransaction("0x99d489d0bd984915fd370b307c2d39320860950666aac3f261921113ae4f95bb")
+eth.getTransaction('0x99d489d0bd984915fd370b307c2d39320860950666aac3f261921113ae4f95bb');
 ```
 
 This returns the following response (although the actual values for each field will vary because they are specific to each transaction):
@@ -259,7 +257,7 @@ This returns the following response (although the actual values for each field w
 
 ## Using Curl
 
-Up to this point this tutorial has interacted with Geth using the convenience library Web3.js. This library enables the user to send instructions to Geth using a more user-friendly interface compared to sending raw JSON objects. However, it is also possible for the user to send these JSON objects directly to Geth's exposed HTTP port. Curl is a command line tool that sends HTTP requests. This part of the tutorial demonstrates how to check account balances and send a transaction using Curl. This requires Geth to expose an HTTP port to listen for requests. This can be configured at startup by passing the `--http` flag. If no other commands are passed with it, `--http` will expose the default `localhost:8545` port. 
+Up to this point this tutorial has interacted with Geth using the convenience library Web3.js. This library enables the user to send instructions to Geth using a more user-friendly interface compared to sending raw JSON objects. However, it is also possible for the user to send these JSON objects directly to Geth's exposed HTTP port. Curl is a command line tool that sends HTTP requests. This part of the tutorial demonstrates how to check account balances and send a transaction using Curl. This requires Geth to expose an HTTP port to listen for requests. This can be configured at startup by passing the `--http` flag. If no other commands are passed with it, `--http` will expose the default `localhost:8545` port.
 
 ### Checking account balance
 
@@ -282,9 +280,10 @@ The balance is in the `result` field in the returned JSON object. However, it is
 ```python
 0xc7d54951f87f7c0 / 1e18
 ```
+
 This returns the balance in ether:
 
-```terminal 
+```terminal
 0.8999684999998321
 ```
 
@@ -310,7 +309,6 @@ It is possible to send transactions using raw curl requests too, but this requir
 
 ## Summary
 
-This tutorial has demonstrated how to generate accounts using Geth's built-in account management tool, fund them with testnet ether and use those accounts to interact with Ethereum (Goerli) through a Geth node. Checking account balances, sending transactions and retrieving transaction details were explained using 
-the web3.js library via the Geth console and using the JSON-RPC directly using Curl. Note that this is an entry-level tutorial designed to help users get familiar with basic Geth processes, we strongly recommend following this with the [Geth with Clef](/content/docs/getting-started/geth_with_clef) tutorial which will help to 
+This tutorial has demonstrated how to generate accounts using Geth's built-in account management tool, fund them with testnet ether and use those accounts to interact with Ethereum (Goerli) through a Geth node. Checking account balances, sending transactions and retrieving transaction details were explained using
+the web3.js library via the Geth console and using the JSON-RPC directly using Curl. Note that this is an entry-level tutorial designed to help users get familiar with basic Geth processes, we strongly recommend following this with the [Geth with Clef](/content/docs/getting-started/geth_with_clef) tutorial which will help to
 adopt more secure account management practices than those outlined here.
- 

src/pages/docs/getting_started/installing-geth.md

@@ -5,7 +5,6 @@ description: Guide to installing Geth
 
 There are several ways to install Geth, including via a package manager, downloading a pre-built bundle, running as a docker container or building from downloaded source code. On this page the various installation options are explained for several major operating systems. Users prioritizing ease of installation should choose to use a package manager or prebuilt bundle. Users prioritizing customization should build from source. It is important to run the latest version of Geth because each release includes bugfixes and improvement over the previous versions. The stable releases are recommended for most users because they have been fully tested. A list of stable releases can be found [here](https://github.com/ethereum/go-ethereum/releases). Instructions for updating existing Geth installations are also provided in each section.
 
-
 ## Package managers
 
 ### MacOS via Homebrew
@@ -18,7 +17,6 @@ brew -v
 
 If a version number is returned, then Homebrew is installed. If not, Homebrew can be installed by following the instructions [here](https://brew.sh/). With Homebrew installed, the following commands add the Geth tap and install Geth:
 
-
 ```shell
 brew tap ethereum/ethereum
 brew install ethereum
@@ -35,14 +33,13 @@ These commands install the core Geth software and the following developer tools:
 Updating an existing Geth installation to the latest version can be achieved by stopping the node and running the following commands:
 
 ```shell
-brew update 
-brew upgrade 
+brew update
+brew upgrade
 brew reinstall ethereum
 ```
 
 When the node is started again, Geth will automatically use all the data from the previous version and sync the blocks that were missed while the node was offline.
 
-
 ### Ubuntu via PPAs
 
 The easiest way to install Geth on Ubuntu-based distributions is with the built-in launchpad PPAs (Personal Package Archives). A single PPA repository is provided, containing stable and development releases for Ubuntu versions `xenial`, `trusty`, `impish`, `focal`, `bionic`.
@@ -69,7 +66,6 @@ sudo apt-get install ethereum-unstable
 
 These commands install the core Geth software and the following developer tools: `clef`, `devp2p`, `abigen`, `bootnode`, `evm`, `rlpdump` and `puppeth`. The binaries for each of these tools are saved in `/usr/local/bin/`. The full list of command line options can be viewed [here](/content/docs/fundamentals/Command-Line-Options.md) or in the terminal by running `geth --help`.
 
-
 Updating an existing Geth installation to the latest version can be achieved by stopping the node and running the following commands:
 
 ```shell
@@ -80,7 +76,6 @@ sudo apt-get upgrade geth
 
 When the node is started again, Geth will automatically use all the data from the previous version and sync the blocks that were missed while the node was offline.
 
-
 ### Windows
 
 The easiest way to install Geth is to download a pre-compiled binary from the [downloads](/content/downloads.md) page. The page provides an installer as well as a zip file containing the Geth source code. The install wizard offers the user the option to install Geth, or Geth and the developer tools. The installer adds `geth` to the system's `PATH` automatically. The zip file contains the command `.exe` files that can be run from the command prompt. The full list of command line options can be viewed [here](/content/docs/fundamentals/Command-Line-Options.md) or in the terminal by running `geth --help`.
@@ -95,11 +90,10 @@ Geth can be installed on FreeBSD using the package manager `pkg`. The following
 pkg install go-ethereum
 ```
 
-These commands install the core Geth software and the following developer tools: `clef`, `devp2p`, `abigen`, `bootnode`, `evm`, `rlpdump` and `puppeth`. 
+These commands install the core Geth software and the following developer tools: `clef`, `devp2p`, `abigen`, `bootnode`, `evm`, `rlpdump` and `puppeth`.
 
 The full list of command line options can be viewed [here](/content/docs/fundamentals/Command-Line-Options.md) or in the terminal by running `geth --help`.
 
-
 Updating an existing Geth installation to the latest version can be achieved by stopping the node and running the following commands:
 
 ```shell
@@ -108,7 +102,6 @@ pkg upgrade
 
 When the node is started again, Geth will automatically use all the data from the previous version and sync the blocks that were missed while the node was offline.
 
-
 ### FreeBSD via ports
 
 Installing Geth using ports, simply requires navigating to the `net-p2p/go-ethereum` ports directory and running `make install` as root:
@@ -118,11 +111,10 @@ cd /usr/ports/net-p2p/go-ethereum
 make install
 ```
 
-These commands install the core Geth software and the following developer tools: `clef`, `devp2p`, `abigen`, `bootnode`, `evm`, `rlpdump` and `puppeth`. The binaries for each of these tools are saved in `/usr/local/bin/`. 
+These commands install the core Geth software and the following developer tools: `clef`, `devp2p`, `abigen`, `bootnode`, `evm`, `rlpdump` and `puppeth`. The binaries for each of these tools are saved in `/usr/local/bin/`.
 
 The full list of command line options can be viewed [here](/content/docs/fundamentals/Command-Line-Options.md) or in the terminal by running `geth --help`.
 
-
 Updating an existing Geth installation can be achieved by stopping the node and running the following command:
 
 ```shell
@@ -139,7 +131,7 @@ The Geth package is available from the [community repo](https://www.archlinux.or
 pacman -S geth
 ```
 
-These commands install the core Geth software and the following developer tools: `clef`, `devp2p`, `abigen`, `bootnode`, `evm`, `rlpdump` and `puppeth`. The binaries for each of these tools are saved in `/usr/bin/`. 
+These commands install the core Geth software and the following developer tools: `clef`, `devp2p`, `abigen`, `bootnode`, `evm`, `rlpdump` and `puppeth`. The binaries for each of these tools are saved in `/usr/bin/`.
 
 The full list of command line options can be viewed [here](/content/docs/fundamentals/Command-Line-Options.md) or in the terminal by running `geth --help`.
 
@@ -157,10 +149,9 @@ Stable releases and development builds are provided as standalone bundles. These
 
 The following standalone bundles are available:
 
--   32bit, 64bit, ARMv5, ARMv6, ARMv7 and ARM64 archives (`.tar.gz`) on Linux
--   64bit archives (`.tar.gz`) on macOS
--   32bit and 64bit archives (`.zip`) and installers (`.exe`) on Windows
-
+- 32bit, 64bit, ARMv5, ARMv6, ARMv7 and ARM64 archives (`.tar.gz`) on Linux
+- 64bit archives (`.tar.gz`) on macOS
+- 32bit and 64bit archives (`.zip`) and installers (`.exe`) on Windows
 
 Some archives contain only Geth, while other archives containing Geth and the various developer tools (`clef`, `devp2p`, `abigen`, `bootnode`, `evm`, `rlpdump` and `puppeth`). More information about these executables is available at the [`README`](https://github.com/ethereum/go-ethereum#executables).
 
@@ -170,10 +161,10 @@ The standalone bundles can be downloaded from the [Geth Downloads](content/downl
 
 A Docker image with recent snapshot builds from our `develop` branch is maintained on DockerHub to support users who prefer to run containerized processes. There four different Docker images available for running the latest stable or development versions of Geth.
 
--   `ethereum/client-go:latest` is the latest development version of Geth (default)
--   `ethereum/client-go:stable` is the latest stable version of Geth
--   `ethereum/client-go:{version}` is the stable version of Geth at a specific version number
--   `ethereum/client-go:release-{version}` is the latest stable version of Geth at a specific version family
+- `ethereum/client-go:latest` is the latest development version of Geth (default)
+- `ethereum/client-go:stable` is the latest stable version of Geth
+- `ethereum/client-go:{version}` is the stable version of Geth at a specific version number
+- `ethereum/client-go:release-{version}` is the latest stable version of Geth at a specific version family
 
 Pulling an image and starting a node is achieved by running these commands:
 
@@ -184,22 +175,20 @@ docker run -it -p 30303:30303 ethereum/client-go
 
 There are also four different Docker images for running the latest stable or development versions of miscellaneous Ethereum tools.
 
--   `ethereum/client-go:alltools-latest` is the latest development version of the Ethereum tools
--   `ethereum/client-go:alltools-stable` is the latest stable version of the Ethereum tools
--   `ethereum/client-go:alltools-{version}` is the stable version of the Ethereum tools at a specific version number
--   `ethereum/client-go:alltools-release-{version}` is the latest stable version of the Ethereum tools at a specific version family
+- `ethereum/client-go:alltools-latest` is the latest development version of the Ethereum tools
+- `ethereum/client-go:alltools-stable` is the latest stable version of the Ethereum tools
+- `ethereum/client-go:alltools-{version}` is the stable version of the Ethereum tools at a specific version number
+- `ethereum/client-go:alltools-release-{version}` is the latest stable version of the Ethereum tools at a specific version family
 
 The image has the following ports automatically exposed:
 
--   `8545` TCP, used by the HTTP based JSON RPC API
--   `8546` TCP, used by the WebSocket based JSON RPC API
--   `8547` TCP, used by the GraphQL API
--   `30303` TCP and UDP, used by the P2P protocol running the network
-
+- `8545` TCP, used by the HTTP based JSON RPC API
+- `8546` TCP, used by the WebSocket based JSON RPC API
+- `8547` TCP, used by the GraphQL API
+- `30303` TCP and UDP, used by the P2P protocol running the network
 
 **Note:** if you are running an Ethereum client inside a Docker container, you should mount a data volume as the client's data directory (located at `/root/.ethereum` inside the container) to ensure that downloaded data is preserved between restarts and/or container life-cycles.
 
-
 Updating Geth to the latest version simply requires stopping the container, pulling the latest version from Docker and running it:
 
 ```shell
@@ -216,7 +205,6 @@ Geth is written in [Go](https://golang.org/), so building from source code requi
 
 With Go installed, Geth can be downloaded into a `GOPATH` workspace via:
 
-
 ```shell
 go get -d github.com/ethereum/go-ethereum
 ```
@@ -227,17 +215,14 @@ You can also install specific versions via:
 go get -d github.com/ethereum/go-ethereum@v1.9.21
 ```
 
-
 The above commands do not build any executables. To do that you can either build one specifically:
 
 ```shell
 go install github.com/ethereum/go-ethereum/cmd/geth
 ```
 
-
 Alternatively, the following command, run in the project root directory (`ethereum/go-ethereum`) in the GO workspace, builds the entire project and installs Geth and all the developer tools:
 
-
 ```shell
 go install ./...
 ```
@@ -251,12 +236,10 @@ Updating an existing Geth installation can be achieved using `go get`:
 go get -u github.com/ethereum/go-ethereum
 ```
 
-
 ### Windows
 
 The Chocolatey package manager provides an easy way to install the required build tools. Chocolatey can be installed by following these [instructions](https://chocolatey.org). Then, to install the build tool the following commands can be run in an Administrator command prompt:
 
-
 ```
 C:\Windows\system32> choco install git
 C:\Windows\system32> choco install golang
@@ -277,7 +260,6 @@ C:\Users\xxx\src\github.com\ethereum\go-ethereum> go install -v ./cmd/...
 
 To build Geth from source code on FreeBSD, the Geth Github repository can be cloned into a local directory.
 
-
 ```shell
 git clone https://github.com/ethereum/go-ethereum
 ```
@@ -288,7 +270,6 @@ Then, the Go compiler can be used to build Geth:
 pkg install go
 ```
 
-
 If the Go version currently installed is >= 1.5, Geth can be built using the following command:
 
 ```shell
@@ -333,6 +314,3 @@ make geth
 Additionally all the developer tools provided with Geth (`clef`, `devp2p`, `abigen`, `bootnode`, `evm`, `rlpdump` and `puppeth`) can be compiled by running `make all`. More information about these tools can be found [here](https://github.com/ethereum/go-ethereum#executables).
 
 To build a stable release, e.g. v1.9.21, the command `git checkout v1.9.21` retrieves that specific version. Executing that command before running `make geth` switches Geth to a stable branch.
-
-
-

src/pages/docs/interacting-with-geth/javascript-console.md

@@ -3,7 +3,7 @@ title: JavaScript Console
 description: How to interact with Geth using Javascript
 ---
 
-Geth responds to instructions encoded as JSON objects as defined in the [JSON-RPC-API](/docs/rpc/server). A Geth user can send these instructions directly, for example over HTTP using tools like [Curl](https://github.com/curl/curl). The code snippet below shows a request for an account balance sent to a local Geth node with the HTTP port `8545` exposed. 
+Geth responds to instructions encoded as JSON objects as defined in the [JSON-RPC-API](/docs/rpc/server). A Geth user can send these instructions directly, for example over HTTP using tools like [Curl](https://github.com/curl/curl). The code snippet below shows a request for an account balance sent to a local Geth node with the HTTP port `8545` exposed.
 
 ```
 curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
@@ -19,7 +19,6 @@ While this approach is valid, it is also a very low level and rather error-prone
 
 {% include note.html content="The web3.js version that comes bundled with Geth is not up to date with the official Web3.js documentation. There are several Web3.js libraries that are not available in the Geth Javascript Console. There are also administrative APIs included in the Geth console that are not documented in the Web3.js documentation. The full list of libraries available in the Geth console is available on the [JSON-RPC API page](/docs/rpc/server)." %}
 
-
 ## Starting the console
 
 There are two ways to start an interactive session using Geth console. The first is to provide the `console` command when Geth is started up. This starts the node and runs the console in the same terminal. It is therefore convenient to suppress the logs from the node to prevent them from obscuring the console. If the logs are not needed, they can be redirected to the `dev/null` path, effectively muting them. Alternatively, if the logs are required they can be redirected to a text file. The level of detail provided in the logs can be adjusted by providing a value between 1-6 to the `--verbosity` flag as in the example below:
@@ -76,33 +75,34 @@ To exit, press ctrl-d or type exit
 >
 ```
 
-
 ## Interactive use
 
 Once the console has been started, it can be used to interact with Geth. The console supports Javascript and the full Geth [JSON-RPC API](/docs/rpc/server). For example, to create an account:
 
 ```js
-personal.newAccount()
+personal.newAccount();
 ```
 
 To check the balance of the first account already existing in the keystore:
 
 ```js
-eth.getBalance(personal.listAccounts[0])
+eth.getBalance(personal.listAccounts[0]);
 ```
 
-
 To make a transaction (without global account unlocking):
 
 ```js
-personal.sendTransaction({to: eth.accounts[0], to: eth.accounts[1], value: web3.toWei(0.5, "ether")})
+personal.sendTransaction({
+  to: eth.accounts[0],
+  to: eth.accounts[1],
+  value: web3.toWei(0.5, 'ether')
+});
 ```
 
 It is also possible to load pre-written Javascript files into the console by passing the `--preload` flag
 when starting the console. This is useful for setting up complex contract objects or loading frequently-used
 functions.
 
-
 ```shell
 geth console --preload "/my/scripts/folder/utils.js"
 ```
@@ -111,7 +111,7 @@ Once the interactive session is over, the console can be closed down by typing `
 
 ## Non-interactive Use: Script Mode
 
-It is also possible to execute JavaScript code non-interactively by passing the `--exec` and a JSON-RPC-API endpoint 
+It is also possible to execute JavaScript code non-interactively by passing the `--exec` and a JSON-RPC-API endpoint
 to `geth attach` or `geth console`. The result is displayed directly in the terminal rather than in an interactive Javascript console.
 
 For example, to display the accounts in the keystore:
@@ -120,7 +120,6 @@ For example, to display the accounts in the keystore:
 geth attach --exec eth.accounts
 ```
 
-
 ```shell
 geth attach --exec eth.blockNumber
 ```
@@ -136,12 +135,10 @@ geth attach http://geth.example.org:8545 --jspath "/tmp" --exec 'loadScript("che
 The `--jspath` flag is used to set a library directory for the Javascript scripts. Any parameters passed to `loadScript()`
 that do not explicitly define an absolute path will be interpreted relative to the `jspath` directory.
 
-
 ## Timers
 
 In addition to the full functionality of JS (as per ECMA5), the Ethereum Javascript Runtime Environment (JSRE) is augmented with various timers. It implements `setInterval`, `clearInterval`, `setTimeout`, `clearTimeout` which some users will be familiar with from browser windows. It also provides implementation for `admin.sleep(seconds)` and a block based timer, `admin.sleepBlocks(n)` which sleeps till the number of new blocks added is equal to or greater than `n`.
 
-
 ## Caveats
 
 Geth's console is built using the [GoJa JS Virtual Machine](https://github.com/dop251/goja) which is compatible with ECMAScript 5.1. This does not support promises or `async` functions. Web3js depends upon the `bignumber.js` library. This is auto-loaded into the console.

src/pages/docs/interacting-with-geth/rpc/batch.md

@@ -6,28 +6,34 @@ description: How to make batch requests using JSON-RPC API
 The JSON-RPC [specification](https://www.jsonrpc.org/specification#batch) outlines how clients can send multiple requests at the same time by filling the request objects in an array. This feature is implemented by Geth's API and can be used to cut network delays. Batching offers visible speed-ups specially when used for fetching larger amounts of mostly independent data objects. Below is an example for fetching a list of blocks in JS:
 
 ```javascript
-import fetch from 'node-fetch'
+import fetch from 'node-fetch';
 
 async function main() {
-    const endpoint = 'http://127.0.0.1:8545'
-    const from = parseInt(process.argv[2])
-    const to = parseInt(process.argv[3])
-
-    const reqs = []
-    for (let i = from; i < to; i++) {
-        reqs.push({
-            method: 'eth_getBlockByNumber',
-            params: [`0x${i.toString(16)}`, false],
-            id: i-from,
-            jsonrpc: '2.0',
-        })
-    }
-
-    const res = await fetch(endpoint, {method: 'POST', body: JSON.stringify(reqs), headers: {'Content-Type': 'application/json'}})
-    const data = await res.json()
+  const endpoint = 'http://127.0.0.1:8545';
+  const from = parseInt(process.argv[2]);
+  const to = parseInt(process.argv[3]);
+
+  const reqs = [];
+  for (let i = from; i < to; i++) {
+    reqs.push({
+      method: 'eth_getBlockByNumber',
+      params: [`0x${i.toString(16)}`, false],
+      id: i - from,
+      jsonrpc: '2.0'
+    });
+  }
+
+  const res = await fetch(endpoint, {
+    method: 'POST',
+    body: JSON.stringify(reqs),
+    headers: { 'Content-Type': 'application/json' }
+  });
+  const data = await res.json();
 }
 
-main().then().catch((err) => console.log(err))
+main()
+  .then()
+  .catch(err => console.log(err));
 ```
 
 In this case there's no dependency between the requests. Often the retrieved data from one request is needed to issue a second one. Let's take the example of fetching all the receipts for a range of blocks. The JSON-RPC API provides `eth_getTransactionReceipt` which takes in a transaction hash and returns the corresponding receipt object, but no method to fetch receipt objects for a whole block. We need to get the list of transactions in a block, and then call `eth_getTransactionReceipt` for each of them. We can break this into 2 batch requests:

src/pages/docs/interacting-with-geth/rpc/graphql.md

@@ -5,7 +5,7 @@ description: Documentation for Geth's GraphQL API
 
 In addition to the [JSON-RPC APIs](/content/docs/interacting_with_geth/RPC/server.md), Geth supports the GraphQL API as specified by [EIP-1767](https://eips.ethereum.org/EIPS/eip-1767). GraphQL lets you specify which fields of an objects you need as part of the query, eliminating the extra load on the client for filling in fields which are not needed. It also allows for combining several traditional JSON-RPC requests into one query which translates into less overhead and more performance.
 
-The GraphQL endpoint piggybacks on the HTTP transport used by JSON-RPC. Hence the relevant `--http` flags and the `--graphql` flag  should be passed to Geth:
+The GraphQL endpoint piggybacks on the HTTP transport used by JSON-RPC. Hence the relevant `--http` flags and the `--graphql` flag should be passed to Geth:
 
 ```bash
 geth --http --graphql
@@ -17,19 +17,30 @@ Now queries can be raised against `http://localhost:8545/graphql`. To change the
 geth --http --http.port 9545 --graphql
 ```
 
-### GraphiQL
+## GraphiQL
 
 An easy way to try out queries is the GraphiQL interface shipped with Geth. To open it visit `http://localhost:8545/graphql/ui`. To see how this works let's read the sender, recipient and value of all transactions in block number 6000000. In GraphiQL:
 
 ```graphql
 query txInfo {
-    block (number: 6000000) { transactions { hash from { address } to { address } value } }
+  block(number: 6000000) {
+    transactions {
+      hash
+      from {
+        address
+      }
+      to {
+        address
+      }
+      value
+    }
+  }
 }
 ```
 
 GraphiQL also provides a way to explore the schema Geth provides to help you formulate your queries, which you can see on the right sidebar. Under the title `Root Types` click on `Query` to see the high-level types and their fields.
 
-### Query
+## Query
 
 Reading out data from Geth is the biggest use-case for GraphQL. In addition to using the UI queries can also be sent programmatically. The official GraphQL[docs](https://graphql.org/code/) explain how to find bindings for many languages, or send http requests from the terminal using tools such as Curl.
 
@@ -49,15 +60,21 @@ Alternatively store the JSON-ified query in a file (let's call it `block-num.que
 Executing a simple query in JS looks as follows. Here the lightweight library `graphql-request` is used to perform the request. Note the use of variables instead of hardcoding the block number in the query:
 
 ```javascript
-const { request, gql } = require('graphql-request')
+const { request, gql } = require('graphql-request');
 
 const query = gql`
-    query blockInfo($number: Long) {
-        block (number: $number) { hash stateRoot }
+  query blockInfo($number: Long) {
+    block(number: $number) {
+      hash
+      stateRoot
     }
-`
+  }
+`;
 request('http://localhost:8545/graphql', query, { number: '6004067' })
-    .then((res) => { console.log(res) })
-    .catch((err) => { console.log(err) })
+  .then(res => {
+    console.log(res);
+  })
+  .catch(err => {
+    console.log(err);
+  });
 ```
-

src/pages/docs/interacting-with-geth/rpc/ns-admin.md

@@ -5,81 +5,80 @@ description: Documentation for the JSON-RPC API "admin" namespace
 
 The `admin` API gives access to several non-standard RPC methods, which allows fine grained control over a Geth instance, including but not limited to network peer and RPC endpoint management.
 
-
-### admin_addPeer
+## admin_addPeer
 
 The `addPeer` administrative method requests adding a new remote node to the list of tracked static nodes. The node will try to maintain connectivity to these nodes at all times, reconnecting every once in a while if the remote connection goes down.
 
 The method accepts a single argument, the [`enode`](https://ethereum.org/en/developers/docs/networking-layer/network-addresses/#enode) URL of the remote peer to start tracking and returns a `BOOL` indicating whether the peer was accepted for tracking or some error occurred.
 
 | Client  | Method invocation                              |
-|:--------|------------------------------------------------|
+| :------ | ---------------------------------------------- |
 | Go      | `admin.AddPeer(url string) (bool, error)`      |
 | Console | `admin.addPeer(url)`                           |
 | RPC     | `{"method": "admin_addPeer", "params": [url]}` |
 
-#### Example
+### Example
 
 ```javascript
 > admin.addPeer("enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303")
 true
 ```
 
-### admin_addTrustedPeer
+## admin_addTrustedPeer
 
 Adds the given node to a reserved trusted list which allows the node to always connect, even if the slots are full. It returns a `BOOL` to indicate whether the peer was successfully added to the list.
 
-| Client  | Method invocation                              |
-|:--------|------------------------------------------------|
+| Client  | Method invocation                                     |
+| :------ | ----------------------------------------------------- |
 | Console | `admin.addTrustedPeer(url)`                           |
 | RPC     | `{"method": "admin_addTrustedPeer", "params": [url]}` |
 
-### admin_datadir
+## admin_datadir
 
 The `datadir` administrative property can be queried for the absolute path the running Geth node currently uses to store all its databases.
 
 | Client  | Method invocation                 |
-|:--------|-----------------------------------|
+| :------ | --------------------------------- |
 | Go      | `admin.Datadir() (string, error`) |
 | Console | `admin.datadir`                   |
 | RPC     | `{"method": "admin_datadir"}`     |
 
-#### Example
+### Example
 
 ```javascript
 > admin.datadir
 "/home/john/.ethereum"
 ```
 
-### admin_exportChain
+## admin_exportChain
 
 Exports the current blockchain into a local file. It optionally takes a first and last block number, in which case it exports only that range of blocks. It returns a boolean indicating whether the operation succeeded.
 
 | Client  | Method invocation                                                     |
-|:--------|---------------------------------------------------------------------- |
+| :------ | --------------------------------------------------------------------- |
 | Console | `admin.exportChain(file, first, last)`                                |
 | RPC     | `{"method": "admin_exportChain", "params": [string, uint64, uint64]}` |
 
-### admin_importChain
+## admin_importChain
 
 Imports an exported list of blocks from a local file. Importing involves processing the blocks and inserting them into the canonical chain. The state from the parent block of this range is required. It returns a boolean indicating whether the operation succeeded.
 
 | Client  | Method invocation                                     |
-|:--------|-------------------------------------------------------|
+| :------ | ----------------------------------------------------- |
 | Console | `admin.importChain(file)`                             |
 | RPC     | `{"method": "admin_importChain", "params": [string]}` |
 
-### admin_nodeInfo
+## admin_nodeInfo
 
 The `nodeInfo` administrative property can be queried for all the information known about the running Geth node at the networking granularity. These include general information about the node itself as a participant of the [ÐΞVp2p](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) P2P overlay protocol, as well as specialized information added by each of the running application protocols (e.g. `eth`, `les`, `shh`, `bzz`).
 
 | Client  | Method invocation                         |
-|:--------|-------------------------------------------|
+| :------ | ----------------------------------------- |
 | Go      | `admin.NodeInfo() (*p2p.NodeInfo, error`) |
 | Console | `admin.nodeInfo`                          |
 | RPC     | `{"method": "admin_nodeInfo"}`            |
 
-#### Example
+### Example
 
 ```javascript
 > admin.nodeInfo
@@ -104,7 +103,7 @@ The `nodeInfo` administrative property can be queried for all the information kn
 }
 ```
 
-### admin_peerEvents
+## admin_peerEvents
 
 PeerEvents creates an [RPC subscription](/docs/rpc/pubsub) which receives peer events from the node's p2p server. The type of events emitted by the server are as follows:
 
@@ -113,17 +112,17 @@ PeerEvents creates an [RPC subscription](/docs/rpc/pubsub) which receives peer e
 - `msgsend`: emitted when a message is successfully sent to a peer
 - `msgrecv`: emitted when a message is received from a peer
 
-### admin_peers
+## admin_peers
 
 The `peers` administrative property can be queried for all the information known about the connected remote nodes at the networking granularity. These include general information about the nodes themselves as participants of the [ÐΞVp2p](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) P2P overlay protocol, as well as specialized information added by each of the running application protocols (e.g. `eth`, `les`, `shh`, `bzz`).
 
 | Client  | Method invocation                        |
-|:--------|------------------------------------------|
+| :------ | ---------------------------------------- |
 | Go      | `admin.Peers() ([]*p2p.PeerInfo, error`) |
 | Console | `admin.peers`                            |
 | RPC     | `{"method": "admin_peers"}`              |
 
-#### Example
+### Example
 
 ```javascript
 > admin.peers
@@ -160,100 +159,100 @@ The `peers` administrative property can be queried for all the information known
 }]
 ```
 
-### admin_removePeer
+## admin_removePeer
 
 Disconnects from a remote node if the connection exists. It returns a boolean indicating validations succeeded. Note a `true` value doesn't necessarily mean that there was a connection which was disconnected.
 
 | Client  | Method invocation                                    |
-|:--------|----------------------------------------------------- |
+| :------ | ---------------------------------------------------- |
 | Console | `admin.removePeer(url)`                              |
 | RPC     | `{"method": "admin_removePeer", "params": [string]}` |
 
-### admin_removeTrustedPeer
+## admin_removeTrustedPeer
 
 Removes a remote node from the trusted peer set, but it does not disconnect it automatically. It returns a boolean indicating validations succeeded.
 
-| Client  | Method invocation                                    |
-|:--------|----------------------------------------------------- |
+| Client  | Method invocation                                           |
+| :------ | ----------------------------------------------------------- |
 | Console | `admin.removeTrustedPeer(url)`                              |
 | RPC     | `{"method": "admin_removeTrustedPeer", "params": [string]}` |
 
-### admin_startHTTP
+## admin_startHTTP
 
 The `startHTTP` administrative method starts an HTTP based JSON-RPC [API](/docs/rpc/server) webserver to handle client requests. All the parameters are optional:
 
-* `host`: network interface to open the listener socket on (defaults to `"localhost"`)
-* `port`: network port to open the listener socket on (defaults to `8545`)
-* `cors`: [cross-origin resource sharing](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) header to use (defaults to `""`)
-* `apis`: API modules to offer over this interface (defaults to `"eth,net,web3"`)
+- `host`: network interface to open the listener socket on (defaults to `"localhost"`)
+- `port`: network port to open the listener socket on (defaults to `8545`)
+- `cors`: [cross-origin resource sharing](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) header to use (defaults to `""`)
+- `apis`: API modules to offer over this interface (defaults to `"eth,net,web3"`)
 
 The method returns a boolean flag specifying whether the HTTP RPC listener was opened or not. Please note, only one HTTP endpoint is allowed to be active at any time.
 
-| Client  | Method invocation                                                                             |
-|:--------|-----------------------------------------------------------------------------------------------|
+| Client  | Method invocation                                                                              |
+| :------ | ---------------------------------------------------------------------------------------------- |
 | Go      | `admin.StartHTTP(host *string, port *rpc.HexNumber, cors *string, apis *string) (bool, error)` |
 | Console | `admin.startHTTP(host, port, cors, apis)`                                                      |
 | RPC     | `{"method": "admin_startHTTP", "params": [host, port, cors, apis]}`                            |
 
-#### Example
+### Example
 
 ```javascript
 > admin.startHTTP("127.0.0.1", 8545)
 true
 ```
 
-### admin_startWS
+## admin_startWS
 
 The `startWS` administrative method starts an WebSocket based [JSON RPC](https://www.jsonrpc.org/specification) API webserver to handle client requests. All the parameters are optional:
 
-* `host`: network interface to open the listener socket on (defaults to `"localhost"`)
-* `port`: network port to open the listener socket on (defaults to `8546`)
-* `cors`: [cross-origin resource sharing](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) header to use (defaults to `""`)
-* `apis`: API modules to offer over this interface (defaults to `"eth,net,web3"`)
+- `host`: network interface to open the listener socket on (defaults to `"localhost"`)
+- `port`: network port to open the listener socket on (defaults to `8546`)
+- `cors`: [cross-origin resource sharing](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) header to use (defaults to `""`)
+- `apis`: API modules to offer over this interface (defaults to `"eth,net,web3"`)
 
 The method returns a boolean flag specifying whether the WebSocket RPC listener was opened or not. Please note, only one WebSocket endpoint is allowed to be active at any time.
 
-| Client  | Method invocation                                                                             |
-|:--------|-----------------------------------------------------------------------------------------------|
+| Client  | Method invocation                                                                            |
+| :------ | -------------------------------------------------------------------------------------------- |
 | Go      | `admin.StartWS(host *string, port *rpc.HexNumber, cors *string, apis *string) (bool, error)` |
 | Console | `admin.startWS(host, port, cors, apis)`                                                      |
 | RPC     | `{"method": "admin_startWS", "params": [host, port, cors, apis]}`                            |
 
-#### Example
+### Example
 
 ```javascript
 > admin.startWS("127.0.0.1", 8546)
 true
 ```
 
-### admin_stopHTTP
+## admin_stopHTTP
 
 The `stopHTTP` administrative method closes the currently open HTTP RPC endpoint. As the node can only have a single HTTP endpoint running, this method takes no parameters, returning a boolean whether the endpoint was closed or not.
 
-| Client  | Method invocation               |
-|:--------|---------------------------------|
+| Client  | Method invocation                |
+| :------ | -------------------------------- |
 | Go      | `admin.StopHTTP() (bool, error`) |
 | Console | `admin.stopHTTP()`               |
 | RPC     | `{"method": "admin_stopHTTP"`    |
 
-#### Example
+### Example
 
 ```javascript
 > admin.stopHTTP()
 true
 ```
 
-### admin_stopWS
+## admin_stopWS
 
 The `stopWS` administrative method closes the currently open WebSocket RPC endpoint. As the node can only have a single WebSocket endpoint running, this method takes no parameters, returning a boolean whether the endpoint was closed or not.
 
 | Client  | Method invocation              |
-|:--------|--------------------------------|
+| :------ | ------------------------------ |
 | Go      | `admin.StopWS() (bool, error`) |
 | Console | `admin.stopWS()`               |
 | RPC     | `{"method": "admin_stopWS"`    |
 
-#### Example
+### Example
 
 ```javascript
 > admin.stopWS()

src/pages/docs/interacting-with-geth/rpc/ns-clique.md

@@ -5,13 +5,13 @@ description: Documentation for the JSON-RPC API "clique" namespace
 
 The `clique` API provides access to the state of the clique consensus engine. This API cna be used to manage signer votes and to check the health of a private network.
 
-### clique_getSnapshot
+## clique_getSnapshot
 
 Retrieves a snapshot of all clique state at a given block.
 
-| Client  | Method invocation                                          |
-|:--------|------------------------------------------------------------|
-| Console | `clique.getSnapshot(blockNumber)`                          |
+| Client  | Method invocation                                           |
+| :------ | ----------------------------------------------------------- |
+| Console | `clique.getSnapshot(blockNumber)`                           |
 | RPC     | `{"method": "clique_getSnapshot", "params": [blockNumber]}` |
 
 Example:
@@ -41,70 +41,70 @@ Example:
 }
 ```
 
-### clique_getSnapshotAtHash
+## clique_getSnapshotAtHash
 
 Retrieves the state snapshot at a given block.
 
-| Client  | Method invocation                                        |
-|:--------|----------------------------------------------------------|
-| Console | `clique.getSnapshotAtHash(blockHash)`                    |
+| Client  | Method invocation                                               |
+| :------ | --------------------------------------------------------------- |
+| Console | `clique.getSnapshotAtHash(blockHash)`                           |
 | RPC     | `{"method": "clique_getSnapshotAtHash", "params": [blockHash]}` |
 
-### clique_getSigner
+## clique_getSigner
 
 Returns the signer for a specific clique block. Can be called with either a blocknumber, blockhash or an rlp encoded blob. The RLP encoded blob can either be a block or a header.
 
 | Client  | Method invocation                                    |
-|:--------|------------------------------------------------------|
+| :------ | ---------------------------------------------------- |
 | Console | `clique.getSigner(blockNrOrHashOrRlp)`               |
 | RPC     | `{"method": "clique_getSigner", "params": [string]}` |
 
-### clique_getSigners
+## clique_getSigners
 
 Retrieves the list of authorized signers at the specified block number.
 
 | Client  | Method invocation                                          |
-|:--------|------------------------------------------------------------|
+| :------ | ---------------------------------------------------------- |
 | Console | `clique.getSigners(blockNumber)`                           |
 | RPC     | `{"method": "clique_getSigners", "params": [blockNumber]}` |
 
-### clique_getSignersAtHash
+## clique_getSignersAtHash
 
 Retrieves the list of authorized signers at the specified block hash.
 
 | Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
+| :------ | ----------------------------------------------------------- |
 | Console | `clique.getSignersAtHash(blockHash)`                        |
 | RPC     | `{"method": "clique_getSignersAtHash", "params": [string]}` |
 
-### clique_proposals
+## clique_proposals
 
 Returns the current proposals the node is voting on.
 
 | Client  | Method invocation                              |
-|:--------|------------------------------------------------|
+| :------ | ---------------------------------------------- |
 | Console | `clique.proposals()`                           |
 | RPC     | `{"method": "clique_proposals", "params": []}` |
 
-### clique_propose
+## clique_propose
 
 Adds a new authorization proposal that the signer will attempt to push through. If the `auth` parameter is true, the local signer votes for the given address to be included in the set of authorized signers. With `auth` set to `false`, the vote is against the address.
 
 | Client  | Method invocation                                         |
-|:--------|-----------------------------------------------------------|
+| :------ | --------------------------------------------------------- |
 | Console | `clique.propose(address, auth)`                           |
 | RPC     | `{"method": "clique_propose", "params": [address, auth]}` |
 
-### clique_discard
+## clique_discard
 
 This method drops a currently running proposal. The signer will not cast further votes (either for or against) the address.
 
 | Client  | Method invocation                                   |
-|:--------|-----------------------------------------------------|
+| :------ | --------------------------------------------------- |
 | Console | `clique.discard(address)`                           |
 | RPC     | `{"method": "clique_discard", "params": [address]}` |
 
-### clique_status
+## clique_status
 
 This is a debugging method which returns statistics about signer activity for the last 64 blocks. The returned object contains the following fields:
 
@@ -113,9 +113,9 @@ This is a debugging method which returns statistics about signer activity for th
   of blocks signed by them
 - `numBlocks`: number of blocks analyzed
 
-| Client  | Method invocation                                   |
-|:--------|-----------------------------------------------------|
-| Console | `clique.status()`                                   |
+| Client  | Method invocation                           |
+| :------ | ------------------------------------------- |
+| Console | `clique.status()`                           |
 | RPC     | `{"method": "clique_status", "params": []}` |
 
 Example:

src/pages/docs/interacting-with-geth/rpc/ns-debug.md

@@ -5,76 +5,71 @@ description: Documentation for the JSON-RPC API "clique" namespace
 
 The `debug` API gives access to several non-standard RPC methods, which allow inspection, debugging and setting certain debugging flags during runtime.
 
-
-### debug_accountRange
+## debug_accountRange
 
 Enumerates all accounts at a given block with paging capability. `maxResults` are returned in the page and the items have keys that come after the `start` key (hashed address).
 
 If `incompletes` is false, then accounts for which the key preimage (i.e: the `address`) doesn't exist in db are skipped. NB: geth by default does not store preimages.
 
 | Client  | Method invocation                                                                                                |
-|:--------|------------------------------------------------------------------------------------------------------------------|
+| :------ | ---------------------------------------------------------------------------------------------------------------- |
 | Console | `debug.accountRange(blockNrOrHash, start, maxResults, nocode, nostorage, incompletes)`                           |
 | RPC     | `{"method": "debug_getHeaderRlp", "params": [blockNrOrHash, start, maxResults, nocode, nostorage, incompletes]}` |
 
-### debug_backtraceAt
+## debug_backtraceAt
 
 Sets the logging backtrace location. When a backtrace location is set and a log message is emitted at that location, the stack of the goroutine executing the log statement will be printed to stderr.
 
 The location is specified as `<filename>:<line>`.
 
 | Client  | Method invocation                                     |
-|:--------|-------------------------------------------------------|
+| :------ | ----------------------------------------------------- |
 | Console | `debug.backtraceAt(string)`                           |
 | RPC     | `{"method": "debug_backtraceAt", "params": [string]}` |
 
 Example:
 
-``` javascript
+```javascript
 > debug.backtraceAt("server.go:443")
 ```
 
-### debug_blockProfile
+## debug_blockProfile
 
 Turns on block profiling for the given duration and writes profile data to disk. It uses a profile rate of 1 for most accurate information. If a different rate is desired, set the rate and write the profile manually using `debug_writeBlockProfile`.
 
 | Client  | Method invocation                                              |
-|:--------|----------------------------------------------------------------|
+| :------ | -------------------------------------------------------------- |
 | Console | `debug.blockProfile(file, seconds)`                            |
 | RPC     | `{"method": "debug_blockProfile", "params": [string, number]}` |
 
-
-### debug_chaindbCompact
+## debug_chaindbCompact
 
 Flattens the entire key-value database into a single level, removing all unused slots and merging all keys.
 
 | Client  | Method invocation                                  |
-|:--------|----------------------------------------------------|
+| :------ | -------------------------------------------------- |
 | Console | `debug.chaindbCompact()`                           |
 | RPC     | `{"method": "debug_chaindbCompact", "params": []}` |
 
-
-### debug_chaindbProperty
+## debug_chaindbProperty
 
 Returns leveldb properties of the key-value database.
 
-| Client  | Method invocation                                              |
-|:--------|----------------------------------------------------------------|
-| Console | `debug.chaindbProperty(property string)`                       |
-| RPC     | `{"method": "debug_chaindbProperty", "params": [property]}`    |
-
+| Client  | Method invocation                                           |
+| :------ | ----------------------------------------------------------- |
+| Console | `debug.chaindbProperty(property string)`                    |
+| RPC     | `{"method": "debug_chaindbProperty", "params": [property]}` |
 
-### debug_cpuProfile
+## debug_cpuProfile
 
 Turns on CPU profiling for the given duration and writes profile data to disk.
 
 | Client  | Method invocation                                            |
-|:--------|--------------------------------------------------------------|
+| :------ | ------------------------------------------------------------ |
 | Console | `debug.cpuProfile(file, seconds)`                            |
 | RPC     | `{"method": "debug_cpuProfile", "params": [string, number]}` |
 
-
-### debug_dbAncient
+## debug_dbAncient
 
 Retrieves an ancient binary blob from the freezer. The freezer is a collection of append-only immutable files. The first argument `kind` specifies which table to look up data from. The list of all table kinds are as follows:
 
@@ -85,41 +80,39 @@ Retrieves an ancient binary blob from the freezer. The freezer is a collection o
 - `diffs`: total difficulty table (block number -> td)
 
 | Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
+| :------ | ----------------------------------------------------------- |
 | Console | `debug.dbAncient(kind string, number uint64)`               |
 | RPC     | `{"method": "debug_dbAncient", "params": [string, number]}` |
 
-### debug_dbAncients
+## debug_dbAncients
 
 Returns the number of ancient items in the ancient store.
 
 | Client  | Method invocation                |
-|:--------|----------------------------------|
+| :------ | -------------------------------- |
 | Console | `debug.dbAncients()`             |
 | RPC     | `{"method": "debug_dbAncients"}` |
 
-### debug_dbGet
+## debug_dbGet
 
 Returns the raw value of a key stored in the database.
 
-| Client  | Method invocation                                              |
-|:--------|----------------------------------------------------------------|
-| Console | `debug.dbGet(key string)`                                      |
-| RPC     | `{"method": "debug_dbGet", "params": [key]}`                   |
-
-
+| Client  | Method invocation                            |
+| :------ | -------------------------------------------- |
+| Console | `debug.dbGet(key string)`                    |
+| RPC     | `{"method": "debug_dbGet", "params": [key]}` |
 
-### debug_dumpBlock
+## debug_dumpBlock
 
 Retrieves the state that corresponds to the block number and returns a list of accounts (including storage and code).
 
 | Client  | Method invocation                                     |
-|:--------|-------------------------------------------------------|
+| :------ | ----------------------------------------------------- |
 | Go      | `debug.DumpBlock(number uint64) (state.World, error)` |
 | Console | `debug.traceBlockByHash(number, [options])`           |
 | RPC     | `{"method": "debug_dumpBlock", "params": [number]}`   |
 
-#### Example
+### Example
 
 ```javascript
 > debug.dumpBlock(10)
@@ -145,203 +138,193 @@ Retrieves the state that corresponds to the block number and returns a list of a
 }
 ```
 
-### debug_freeOSMemory
+## debug_freeOSMemory
 
 Forces garbage collection
 
-| Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
-| Go      | `debug.FreeOSMemory()`                            |
-| Console | `debug.freeOSMemory()`                            |
-| RPC     | `{"method": "debug_freeOSMemory", "params": []}`  |
-
-
+| Client  | Method invocation                                |
+| :------ | ------------------------------------------------ |
+| Go      | `debug.FreeOSMemory()`                           |
+| Console | `debug.freeOSMemory()`                           |
+| RPC     | `{"method": "debug_freeOSMemory", "params": []}` |
 
-### debug_freezeClient
+## debug_freezeClient
 
 Forces a temporary client freeze, normally when the server is overloaded. Available as part of LES light server.
 
 | Client  | Method invocation                                    |
-|:--------|------------------------------------------------------|
+| :------ | ---------------------------------------------------- |
 | Console | `debug.freezeClient(node string)`                    |
 | RPC     | `{"method": "debug_freezeClient", "params": [node]}` |
 
-
-
-### debug_gcStats
+## debug_gcStats
 
 Returns garbage collection statistics.
 
 See https://golang.org/pkg/runtime/debug/#GCStats for information about the fields of the returned object.
 
-| Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
-| Console | `debug.gcStats()`                                 |
-| RPC     | `{"method": "debug_gcStats", "params": []}`       |
-
+| Client  | Method invocation                           |
+| :------ | ------------------------------------------- |
+| Console | `debug.gcStats()`                           |
+| RPC     | `{"method": "debug_gcStats", "params": []}` |
 
-### debug_getAccessibleState
+## debug_getAccessibleState
 
 Returns the first number where the node has accessible state on disk. This is the post-state of that block and the pre-state of the next block. The (from, to) parameters are the sequence of blocks to search, which can go either forwards or backwards.
 
-| Client  | Method invocation                                                     |
-|:--------|-----------------------------------------------------------------------|
-| Console | `debug.getAccessibleState(from, to rpc.BlockNumber)`      |
-| RPC     | `{"method": "debug_getAccessibleState", "params": [from, to]}`  |
-
+| Client  | Method invocation                                              |
+| :------ | -------------------------------------------------------------- |
+| Console | `debug.getAccessibleState(from, to rpc.BlockNumber)`           |
+| RPC     | `{"method": "debug_getAccessibleState", "params": [from, to]}` |
 
-### debug_getBadBlocks
+## debug_getBadBlocks
 
 Returns a list of the last 'bad blocks' that the client has seen on the network and returns them as a JSON list of block-hashes.
 
-| Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
-| Console | `debug.getBadBlocks()`                      |
-| RPC     | `{"method": "debug_getBadBlocks", "params": []}`  |
-
+| Client  | Method invocation                                |
+| :------ | ------------------------------------------------ |
+| Console | `debug.getBadBlocks()`                           |
+| RPC     | `{"method": "debug_getBadBlocks", "params": []}` |
 
-### debug_getBlockRlp
+## debug_getBlockRlp
 
 Retrieves and returns the RLP encoded block by number.
 
 | Client  | Method invocation                                     |
-|:--------|-------------------------------------------------------|
+| :------ | ----------------------------------------------------- |
 | Go      | `debug.GetBlockRlp(number uint64) (string, error)`    |
 | Console | `debug.getBlockRlp(number, [options])`                |
 | RPC     | `{"method": "debug_getBlockRlp", "params": [number]}` |
 
 References: [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/#top)
 
-### debug_getHeaderRlp
+## debug_getHeaderRlp
 
 Returns an RLP-encoded header.
 
 | Client  | Method invocation                                   |
-|:--------|-----------------------------------------------------|
+| :------ | --------------------------------------------------- |
 | Console | `debug.getHeaderRlp(blockNum)`                      |
 | RPC     | `{"method": "debug_getHeaderRlp", "params": [num]}` |
 
-### debug_getModifiedAccountsByHash
+## debug_getModifiedAccountsByHash
 
 Returns all accounts that have changed between the two blocks specified. A change is defined as a difference in nonce, balance, code hash, or storage hash. With one parameter, returns the list of accounts modified in the specified block.
 
 | Client  | Method invocation                                                               |
-|:--------|---------------------------------------------------------------------------------|
+| :------ | ------------------------------------------------------------------------------- |
 | Console | `debug.getModifiedAccountsByHash(startHash, endHash)`                           |
 | RPC     | `{"method": "debug_getModifiedAccountsByHash", "params": [startHash, endHash]}` |
 
-### debug_getModifiedAccountsByNumber
+## debug_getModifiedAccountsByNumber
 
 Returns all accounts that have changed between the two blocks specified. A change is defined as a difference in nonce, balance, code hash or storage hash.
 
 | Client  | Method invocation                                                               |
-|:--------|---------------------------------------------------------------------------------|
+| :------ | ------------------------------------------------------------------------------- |
 | Console | `debug.getModifiedAccountsByNumber(startNum uint64, endNum uint64)`             |
 | RPC     | `{"method": "debug_getModifiedAccountsByNumber", "params": [startNum, endNum]}` |
 
-### debug_getRawReceipts
+## debug_getRawReceipts
 
 Returns the consensus-encoding of all receipts in a single block.
 
 | Client  | Method invocation                                               |
-|:--------|-----------------------------------------------------------------|
+| :------ | --------------------------------------------------------------- |
 | Console | `debug.getRawReceipts(blockNrOrHash)`                           |
 | RPC     | `{"method": "debug_getRawReceipts", "params": [blockNrOrHash]}` |
 
-### debug_goTrace
+## debug_goTrace
 
 Turns on Go runtime tracing for the given duration and writes trace data to disk.
 
 | Client  | Method invocation                                         |
-|:--------|-----------------------------------------------------------|
+| :------ | --------------------------------------------------------- |
 | Console | `debug.goTrace(file, seconds)`                            |
 | RPC     | `{"method": "debug_goTrace", "params": [string, number]}` |
 
-### debug_intermediateRoots
+## debug_intermediateRoots
 
 Executes a block (bad- or canon- or side-), and returns a list of intermediate roots: the stateroot after each transaction.
 
 | Client  | Method invocation                                                  |
-|:--------|--------------------------------------------------------------------|
+| :------ | ------------------------------------------------------------------ |
 | Console | `debug.intermediateRoots(blockHash, [options])`                    |
 | RPC     | `{"method": "debug_intermediateRoots", "params": [blockHash, {}]}` |
 
-### debug_memStats
+## debug_memStats
 
 Returns detailed runtime memory statistics.
 
 See https://golang.org/pkg/runtime/#MemStats for information about the fields of the returned object.
 
-| Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
-| Console | `debug.memStats()`                                |
-| RPC     | `{"method": "debug_memStats", "params": []}`      |
+| Client  | Method invocation                            |
+| :------ | -------------------------------------------- |
+| Console | `debug.memStats()`                           |
+| RPC     | `{"method": "debug_memStats", "params": []}` |
 
-### debug_mutexProfile
+## debug_mutexProfile
 
 Turns on mutex profiling for nsec seconds and writes profile data to file. It uses a profile rate of 1 for most accurate information. If a different rate is desired, set the rate and write the profile manually.
 
 | Client  | Method invocation                                          |
-|:--------|------------------------------------------------------------|
+| :------ | ---------------------------------------------------------- |
 | Console | `debug.mutexProfile(file, nsec)`                           |
 | RPC     | `{"method": "debug_mutexProfile", "params": [file, nsec]}` |
 
-### debug_preimage
+## debug_preimage
 
 Returns the preimage for a sha3 hash, if known.
 
 | Client  | Method invocation                                |
-|:--------|--------------------------------------------------|
+| :------ | ------------------------------------------------ |
 | Console | `debug.preimage(hash)`                           |
 | RPC     | `{"method": "debug_preimage", "params": [hash]}` |
 
-
-### debug_printBlock
+## debug_printBlock
 
 Retrieves a block and returns its pretty printed form.
 
-| Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
-| Console | `debug.printBlock(number uint64)`                                |
-| RPC     | `{"method": "debug_printBlock", "params": [number]}`      |
-
+| Client  | Method invocation                                    |
+| :------ | ---------------------------------------------------- |
+| Console | `debug.printBlock(number uint64)`                    |
+| RPC     | `{"method": "debug_printBlock", "params": [number]}` |
 
-### debug_seedHash
+## debug_seedHash
 
 Fetches and retrieves the seed hash of the block by number
 
 | Client  | Method invocation                                  |
-|:--------|----------------------------------------------------|
+| :------ | -------------------------------------------------- |
 | Go      | `debug.SeedHash(number uint64) (string, error)`    |
 | Console | `debug.seedHash(number, [options])`                |
 | RPC     | `{"method": "debug_seedHash", "params": [number]}` |
 
-### debug_setBlockProfileRate
+## debug_setBlockProfileRate
 
 Sets the rate (in samples/sec) of goroutine block profile data collection. A non-zero rate enables block profiling, setting it to zero stops the profile. Collected profile data can be written using `debug_writeBlockProfile`.
 
 | Client  | Method invocation                                             |
-|:--------|---------------------------------------------------------------|
+| :------ | ------------------------------------------------------------- |
 | Console | `debug.setBlockProfileRate(rate)`                             |
 | RPC     | `{"method": "debug_setBlockProfileRate", "params": [number]}` |
 
-### debug_setGCPercent
+## debug_setGCPercent
 
 Sets the garbage collection target percentage. A negative value disables garbage collection.
 
 | Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
-| Go      | `debug.SetGCPercent(v int)`                    |
+| :------ | ------------------------------------------------- |
+| Go      | `debug.SetGCPercent(v int)`                       |
 | Console | `debug.setGCPercent(v)`                           |
 | RPC     | `{"method": "debug_setGCPercent", "params": [v]}` |
 
+## debug_setHead
 
-### debug_setHead
-
-Sets the current head of the local chain by block number. **Note**, this is a destructive action and may severely damage the chain. Use with *extreme* caution.
+Sets the current head of the local chain by block number. **Note**, this is a destructive action and may severely damage the chain. Use with _extreme_ caution.
 
 | Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
+| :------ | ------------------------------------------------- |
 | Go      | `debug.SetHead(number uint64)`                    |
 | Console | `debug.setHead(number)`                           |
 | RPC     | `{"method": "debug_setHead", "params": [number]}` |
@@ -349,35 +332,34 @@ Sets the current head of the local chain by block number. **Note**, this is a de
 References:
 [Ethash](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining-algorithms/ethash)
 
-### debug_setMutexProfileFraction
+## debug_setMutexProfileFraction
 
 Sets the rate of mutex profiling.
 
 | Client  | Method invocation                                               |
-|:--------|-----------------------------------------------------------------|
+| :------ | --------------------------------------------------------------- |
 | Console | `debug.setMutexProfileFraction(rate int)`                       |
 | RPC     | `{"method": "debug_setMutexProfileFraction", "params": [rate]}` |
 
-### debug_stacks
+## debug_stacks
 
 Returns a printed representation of the stacks of all goroutines. Note that the web3 wrapper for this method takes care of the printing and does not return the string.
 
-| Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
-| Console | `debug.stacks()`                                  |
-| RPC     | `{"method": "debug_stacks", "params": []}`        |
-
+| Client  | Method invocation                          |
+| :------ | ------------------------------------------ |
+| Console | `debug.stacks()`                           |
+| RPC     | `{"method": "debug_stacks", "params": []}` |
 
-### debug_standardTraceBlockToFile
+## debug_standardTraceBlockToFile
 
 When JS-based tracing (see below) was first implemented, the intended usecase was to enable long-running tracers that could stream results back via a subscription channel. This method works a bit differently. (For full details, see [PR](https://github.com/ethereum/go-ethereum/pull/17914))
 
 - It streams output to disk during the execution, to not blow up the memory usage on the node
 - It uses `jsonl` as output format (to allow streaming)
 - Uses a cross-client standardized output, so called 'standard json'
-  * Uses `op` for string-representation of opcode, instead of `op`/`opName` for numeric/string, and other simlar small differences.
-  * has `refund`
-  * Represents memory as a contiguous chunk of data, as opposed to a list of `32`-byte segments like `debug_traceTransaction`
+  - Uses `op` for string-representation of opcode, instead of `op`/`opName` for numeric/string, and other simlar small differences.
+  - has `refund`
+  - Represents memory as a contiguous chunk of data, as opposed to a list of `32`-byte segments like `debug_traceTransaction`
 
 This means that this method is only 'useful' for callers who control the node -- at least sufficiently to be able to read the artefacts from the filesystem after the fact.
 
@@ -387,12 +369,15 @@ The method can be used to dump a certain transaction out of a given block:
 > debug.standardTraceBlockToFile("0x0bbe9f1484668a2bf159c63f0cf556ed8c8282f99e3ffdb03ad2175a863bca63", {txHash:"0x4049f61ffbb0747bb88dc1c85dd6686ebf225a3c10c282c45a8e0c644739f7e9", disableMemory:true})
 ["/tmp/block_0x0bbe9f14-14-0x4049f61f-099048234"]
 ```
+
 Or all txs from a block:
+
 ```sh
 > debug.standardTraceBlockToFile("0x0bbe9f1484668a2bf159c63f0cf556ed8c8282f99e3ffdb03ad2175a863bca63", {disableMemory:true})
 ["/tmp/block_0x0bbe9f14-0-0xb4502ea7-409046657", "/tmp/block_0x0bbe9f14-1-0xe839be8f-954614764", "/tmp/block_0x0bbe9f14-2-0xc6e2052f-542255195", "/tmp/block_0x0bbe9f14-3-0x01b7f3fe-209673214", "/tmp/block_0x0bbe9f14-4-0x0f290422-320999749", "/tmp/block_0x0bbe9f14-5-0x2dc0fb80-844117472", "/tmp/block_0x0bbe9f14-6-0x35542da1-256306111", "/tmp/block_0x0bbe9f14-7-0x3e199a08-086370834", "/tmp/block_0x0bbe9f14-8-0x87778b88-194603593", "/tmp/block_0x0bbe9f14-9-0xbcb081ba-629580052", "/tmp/block_0x0bbe9f14-10-0xc254381a-578605923", "/tmp/block_0x0bbe9f14-11-0xcc434d58-405931366", "/tmp/block_0x0bbe9f14-12-0xce61967d-874423181", "/tmp/block_0x0bbe9f14-13-0x05a20b35-267153288", "/tmp/block_0x0bbe9f14-14-0x4049f61f-606653767", "/tmp/block_0x0bbe9f14-15-0x46d473d2-614457338", "/tmp/block_0x0bbe9f14-16-0x35cf5500-411906321", "/tmp/block_0x0bbe9f14-17-0x79222961-278569788", "/tmp/block_0x0bbe9f14-18-0xad84e7b1-095032683", "/tmp/block_0x0bbe9f14-19-0x4bd48260-019097038", "/tmp/block_0x0bbe9f14-20-0x1517411d-292624085", "/tmp/block_0x0bbe9f14-21-0x6857e350-971385904", "/tmp/block_0x0bbe9f14-22-0xbe3ae2ca-236639695"]
 
 ```
+
 Files are created in a temp-location, with the naming standard `block_<blockhash:4>-<txindex>-<txhash:4>-<random suffix>`. Each opcode immediately streams to file, with no in-geth buffering aside from whatever buffering the os normally does.
 
 On the server side, it also adds some more info when regenerating historical state, namely, the reexec-number if `required historical state is not avaiable` is encountered, so a user can experiment with increasing that setting. It also prints out the remaining block until it reaches target:
@@ -416,71 +401,70 @@ type StdTraceConfig struct {
 }
 ```
 
-### debug_standardTraceBadBlockToFile
+## debug_standardTraceBadBlockToFile
 
 This method is similar to `debug_standardTraceBlockToFile`, but can be used to obtain info about a block which has been _rejected_ as invalid (for some reason).
 
-
-### debug_startCPUProfile
+## debug_startCPUProfile
 
 Turns on CPU profiling indefinitely, writing to the given file.
 
 | Client  | Method invocation                                         |
-|:--------|-----------------------------------------------------------|
+| :------ | --------------------------------------------------------- |
 | Console | `debug.startCPUProfile(file)`                             |
 | RPC     | `{"method": "debug_startCPUProfile", "params": [string]}` |
 
-### debug_startGoTrace
+## debug_startGoTrace
 
 Starts writing a Go runtime trace to the given file.
 
 | Client  | Method invocation                                      |
-|:--------|--------------------------------------------------------|
+| :------ | ------------------------------------------------------ |
 | Console | `debug.startGoTrace(file)`                             |
 | RPC     | `{"method": "debug_startGoTrace", "params": [string]}` |
 
-### debug_stopCPUProfile
+## debug_stopCPUProfile
 
 Stops an ongoing CPU profile.
 
 | Client  | Method invocation                                  |
-|:--------|----------------------------------------------------|
+| :------ | -------------------------------------------------- |
 | Console | `debug.stopCPUProfile()`                           |
 | RPC     | `{"method": "debug_stopCPUProfile", "params": []}` |
 
-### debug_stopGoTrace
+## debug_stopGoTrace
 
 Stops writing the Go runtime trace.
 
-| Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
-| Console | `debug.startGoTrace(file)`                        |
-| RPC     | `{"method": "debug_stopGoTrace", "params": []}`   |
+| Client  | Method invocation                               |
+| :------ | ----------------------------------------------- |
+| Console | `debug.startGoTrace(file)`                      |
+| RPC     | `{"method": "debug_stopGoTrace", "params": []}` |
 
-### debug_storageRangeAt
+## debug_storageRangeAt
 
 Returns the storage at the given block height and transaction index. The result can be paged by providing a `maxResult` to cap the number of storage slots returned as well as specifying the offset via `keyStart` (hash of storage key).
 
 | Client  | Method invocation                                                                                        |
-|:--------|----------------------------------------------------------------------------------------------------------|
+| :------ | -------------------------------------------------------------------------------------------------------- |
 | Console | `debug.storageRangeAt(blockHash, txIdx, contractAddress, keyStart, maxResult)`                           |
 | RPC     | `{"method": "debug_storageRangeAt", "params": [blockHash, txIdx, contractAddress, keyStart, maxResult]}` |
 
-### debug_traceBadBlock
+## debug_traceBadBlock
 
 Returns the structured logs created during the execution of EVM against a block pulled from the pool of bad ones and returns them as a JSON object.
 
 | Client  | Method invocation                                              |
-|:--------|----------------------------------------------------------------|
+| :------ | -------------------------------------------------------------- |
 | Console | `debug.traceBadBlock(blockHash, [options])`                    |
 | RPC     | `{"method": "debug_traceBadBlock", "params": [blockHash, {}]}` |
 
-### debug_traceBlock
+## debug_traceBlock
 
 The `traceBlock` method will return a full stack trace of all invoked opcodes of all transaction that were included in this block. **Note**, the parent of this block must be present or it will fail.
 
 | Client  | Method invocation                                                        |
-|:--------|--------------------------------------------------------------------------|
+| :------ | ------------------------------------------------------------------------ |
 | Go      | `debug.TraceBlock(blockRlp []byte, config. *vm.Config) BlockTraceResult` |
 | Console | `debug.traceBlock(tblockRlp, [options])`                                 |
 | RPC     | `{"method": "debug_traceBlock", "params": [blockRlp, {}]}`               |
@@ -488,7 +472,7 @@ The `traceBlock` method will return a full stack trace of all invoked opcodes of
 References:
 [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp)
 
-#### Example
+### Example
 
 ```javascript
 > debug.traceBlock("0xblock_rlp")
@@ -524,12 +508,12 @@ References:
   }]
 ```
 
-### debug_traceBlockByNumber
+## debug_traceBlockByNumber
 
 Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByNumber` accepts a block number and will replay the block that is already present in the database.
 
 | Client  | Method invocation                                                              |
-|:--------|--------------------------------------------------------------------------------|
+| :------ | ------------------------------------------------------------------------------ |
 | Go      | `debug.TraceBlockByNumber(number uint64, config. *vm.Config) BlockTraceResult` |
 | Console | `debug.traceBlockByNumber(number, [options])`                                  |
 | RPC     | `{"method": "debug_traceBlockByNumber", "params": [number, {}]}`               |
@@ -537,12 +521,12 @@ Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByNumber` accepts a
 References:
 [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp)
 
-### debug_traceBlockByHash
+## debug_traceBlockByHash
 
 Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByHash` accepts a block hash and will replay the block that is already present in the database.
 
 | Client  | Method invocation                                                               |
-|:--------|---------------------------------------------------------------------------------|
+| :------ | ------------------------------------------------------------------------------- |
 | Go      | `debug.TraceBlockByHash(hash common.Hash, config. *vm.Config) BlockTraceResult` |
 | Console | `debug.traceBlockByHash(hash, [options])`                                       |
 | RPC     | `{"method": "debug_traceBlockByHash", "params": [hash {}]}`                     |
@@ -550,13 +534,12 @@ Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByHash` accepts a b
 References:
 [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp)
 
-
-### debug_traceBlockFromFile
+## debug_traceBlockFromFile
 
 Similar to [debug_traceBlock](#debug_traceblock), `traceBlockFromFile` accepts a file containing the RLP of the block.
 
 | Client  | Method invocation                                                                |
-|:--------|----------------------------------------------------------------------------------|
+| :------ | -------------------------------------------------------------------------------- |
 | Go      | `debug.TraceBlockFromFile(fileName string, config. *vm.Config) BlockTraceResult` |
 | Console | `debug.traceBlockFromFile(fileName, [options])`                                  |
 | RPC     | `{"method": "debug_traceBlockFromFile", "params": [fileName, {}]}`               |
@@ -564,17 +547,17 @@ Similar to [debug_traceBlock](#debug_traceblock), `traceBlockFromFile` accepts a
 References:
 [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp)
 
-### debug_traceCall
+## debug_traceCall
 
 The `debug_traceCall` method enables running an `eth_call` within the context of the given block execution using the final state of parent block as the base. The first argument (just as in `eth_call`) is a [transaction object](/docs/rpc/objects#transaction-call-object). The block can be specified either by hash or by number as the second argument. A tracer can be specified as a third argument, similar to `debug_traceTransaction`. It returns the same output as `debug_traceTransaction`.
 
-| Client  | Method invocation                 |
-|:-------:|-----------------------------------|
-| Go      | `debug.TraceCall(args ethapi.CallArgs, blockNrOrHash rpc.BlockNumberOrHash, config *TraceConfig) (*ExecutionResult, error)` |
-| Console | `debug.traceCall(object, blockNrOrHash, [options])`                   |
-| RPC     | `{"method": "debug_traceCall", "params": [object, blockNrOrHash, {}]}`     |
+| Client  | Method invocation                                                                                                           |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------- |
+|   Go    | `debug.TraceCall(args ethapi.CallArgs, blockNrOrHash rpc.BlockNumberOrHash, config *TraceConfig) (*ExecutionResult, error)` |
+| Console | `debug.traceCall(object, blockNrOrHash, [options])`                                                                         |
+|   RPC   | `{"method": "debug_traceCall", "params": [object, blockNrOrHash, {}]}`                                                      |
 
-#### Example
+### Example
 
 No specific call options:
 
@@ -587,6 +570,7 @@ No specific call options:
   structLogs: []
 }
 ```
+
 Tracing a call with a destination and specific sender, disabling the storage and memory output (less data returned over RPC)
 
 ```sh
@@ -599,16 +583,16 @@ debug.traceCall({
 	"latest", {"disableStorage": true, "disableMemory": true})
 ```
 
-It is possible to supply 'overrides' for both state-data (accounts/storage) and block data (number, timestamp etc). In the example below, a call which executes `NUMBER` is performed, and the overridden number is placed on the stack: 
+It is possible to supply 'overrides' for both state-data (accounts/storage) and block data (number, timestamp etc). In the example below, a call which executes `NUMBER` is performed, and the overridden number is placed on the stack:
 
 ```sh
 > debug.traceCall({
-	from: eth.accounts[0], 
+	from: eth.accounts[0],
 	value:"0x1",
-	gasPrice: "0xffffffff", 
-	gas: "0xffff", 
+	gasPrice: "0xffffffff",
+	gas: "0xffff",
 	input: "0x43"},
-	"latest", 
+	"latest",
 	{"blockoverrides":
 		{"number": "0x50"}
 	})
@@ -634,13 +618,14 @@ It is possible to supply 'overrides' for both state-data (accounts/storage) and
 }
 ```
 
-Curl example: 
+Curl example:
+
 ```sh
 > curl -H "Content-Type: application/json" -X POST  localhost:8545 --data '{"jsonrpc":"2.0","method":"debug_traceCall","params":[null, "pending"],"id":1}'
 {"jsonrpc":"2.0","id":1,"result":{"gas":53000,"failed":false,"returnValue":"","structLogs":[]}}
 ```
 
-### debug_traceChain
+## debug_traceChain
 
 Returns the structured logs created during the execution of EVM between two blocks (excluding start) as a JSON object. This endpoint must be invoked via `debug_subscribe` as follows:
 
@@ -648,30 +633,29 @@ Returns the structured logs created during the execution of EVM between two bloc
 
 please refer to the [subscription page](https://geth.ethereum.org/docs/rpc/pubsub) for more details.
 
-
-### debug_traceTransaction
+## debug_traceTransaction
 
 **OBS** In most scenarios, `debug.standardTraceBlockToFile` is better suited for tracing!
 
 The `traceTransaction` debugging method will attempt to run the transaction in the exact same manner as it was executed on the network. It will replay any transaction that may have been executed prior to this one before it will finally attempt to execute the transaction that corresponds to the given
 hash.
 
-In addition to the hash of the transaction it can take a secondary *optional* argument, which specifies the options for this specific call. The possible options are:
+In addition to the hash of the transaction it can take a secondary _optional_ argument, which specifies the options for this specific call. The possible options are:
 
-* `disableStorage`: `BOOL`. Setting this to true will disable storage capture (default = false).
-* `disableStack`: `BOOL`. Setting this to true will disable stack capture (default = false).
-* `enableMemory`: `BOOL`. Setting this to true will enable memory capture (default = false).
-* `enableReturnData`: `BOOL`. Setting this to true will enable return data capture (default = false).
-* `tracer`: `STRING`. Setting this will enable JavaScript-based transaction tracing, described below. If set, the previous four arguments will be ignored.
-* `timeout`: `STRING`. Overrides the default timeout of 5 seconds for JavaScript-based tracing calls. Valid values are described [here](https://golang.org/pkg/time/#ParseDuration).
+- `disableStorage`: `BOOL`. Setting this to true will disable storage capture (default = false).
+- `disableStack`: `BOOL`. Setting this to true will disable stack capture (default = false).
+- `enableMemory`: `BOOL`. Setting this to true will enable memory capture (default = false).
+- `enableReturnData`: `BOOL`. Setting this to true will enable return data capture (default = false).
+- `tracer`: `STRING`. Setting this will enable JavaScript-based transaction tracing, described below. If set, the previous four arguments will be ignored.
+- `timeout`: `STRING`. Overrides the default timeout of 5 seconds for JavaScript-based tracing calls. Valid values are described [here](https://golang.org/pkg/time/#ParseDuration).
 
 | Client  | Method invocation                                                                            |
-|:--------|----------------------------------------------------------------------------------------------|
+| :------ | -------------------------------------------------------------------------------------------- |
 | Go      | `debug.TraceTransaction(txHash common.Hash, logger *vm.LogConfig) (*ExecutionResult, error)` |
 | Console | `debug.traceTransaction(txHash, [options])`                                                  |
 | RPC     | `{"method": "debug_traceTransaction", "params": [txHash, {}]}`                               |
 
-#### Example
+### Example
 
 ```javascript
 > debug.traceTransaction("0x2059dd53ecac9827faad14d364f9e04b1d5fe5b506e3acc886eff7a6f88a696a")
@@ -707,30 +691,29 @@ In addition to the hash of the transaction it can take a secondary *optional* ar
   }]
 ```
 
-
-#### JavaScript-based tracing
+### JavaScript-based tracing
 
 Specifying the `tracer` option in the second argument enables JavaScript-based tracing. In this mode, `tracer` is interpreted as a JavaScript expression that is expected to evaluate to an object which must expose the `result` and `fault` methods. There exist 3 additional methods, namely: `step`, `enter` and `exit`. One of either `step`, or `enter` AND `exit` must be provided(i.e. `enter` and `exit` must be exposed together). All three can be provided together.
 
-##### Step
+#### Step
 
 `step`is a function that takes two arguments, log and db, and is called for each step of the EVM, or when an error occurs, as the specified transaction is traced.
 
 `log` has the following fields:
 
- - `op`: Object, an OpCode object representing the current opcode
- - `stack`: Object, a structure representing the EVM execution stack
- - `memory`: Object, a structure representing the contract's memory space
- - `contract`: Object, an object representing the account executing the current operation
+- `op`: Object, an OpCode object representing the current opcode
+- `stack`: Object, a structure representing the EVM execution stack
+- `memory`: Object, a structure representing the contract's memory space
+- `contract`: Object, an object representing the account executing the current operation
 
 and the following methods:
 
- - `getPC()` - returns a Number with the current program counter
- - `getGas()` - returns a Number with the amount of gas remaining
- - `getCost()` - returns the cost of the opcode as a Number
- - `getDepth()` - returns the execution depth as a Number
- - `getRefund()` - returns the amount to be refunded as a Number
- - `getError()` - returns information about the error if one occured, otherwise returns `undefined`
+- `getPC()` - returns a Number with the current program counter
+- `getGas()` - returns a Number with the amount of gas remaining
+- `getCost()` - returns the cost of the opcode as a Number
+- `getDepth()` - returns the execution depth as a Number
+- `getRefund()` - returns the amount to be refunded as a Number
+- `getError()` - returns information about the error if one occured, otherwise returns `undefined`
 
 If error is non-empty, all other fields should be ignored.
 
@@ -748,19 +731,19 @@ But this step function will:
 
 `log.op` has the following methods:
 
- - `isPush()` - returns true iff the opcode is a PUSHn
- - `toString()` - returns the string representation of the opcode
- - `toNumber()` - returns the opcode's number
+- `isPush()` - returns true iff the opcode is a PUSHn
+- `toString()` - returns the string representation of the opcode
+- `toNumber()` - returns the opcode's number
 
 `log.memory` has the following methods:
 
- - `slice(start, stop)` - returns the specified segment of memory as a byte slice
- - `getUint(offset)` - returns the 32 bytes at the given offset
+- `slice(start, stop)` - returns the specified segment of memory as a byte slice
+- `getUint(offset)` - returns the 32 bytes at the given offset
 
 `log.stack` has the following methods:
 
- - `peek(idx)` - returns the idx-th element from the top of the stack (0 is the topmost element) as a big.Int
- - `length()` - returns the number of elements in the stack
+- `peek(idx)` - returns the idx-th element from the top of the stack (0 is the topmost element) as a big.Int
+- `length()` - returns the number of elements in the stack
 
 `log.contract` has the following methods:
 
@@ -771,15 +754,15 @@ But this step function will:
 
 `db` has the following methods:
 
- - `getBalance(address)` - returns a `big.Int` with the specified account's balance
- - `getNonce(address)` - returns a Number with the specified account's nonce
- - `getCode(address)` - returns a byte slice with the code for the specified account
- - `getState(address, hash)` - returns the state value for the specified account and the specified hash
- - `exists(address)` - returns true if the specified address exists
+- `getBalance(address)` - returns a `big.Int` with the specified account's balance
+- `getNonce(address)` - returns a Number with the specified account's nonce
+- `getCode(address)` - returns a byte slice with the code for the specified account
+- `getState(address, hash)` - returns the state value for the specified account and the specified hash
+- `exists(address)` - returns true if the specified address exists
 
 If the step function throws an exception or executes an illegal operation at any point, it will not be called on any further VM steps, and the error will be returned to the caller.
 
-##### Result
+#### Result
 
 `result` is a function that takes two arguments `ctx` and `db`, and is expected to return a JSON-serializable value to return to the RPC caller.
 
@@ -796,11 +779,11 @@ If the step function throws an exception or executes an illegal operation at any
 - `gasUsed` - Number, amount of gas used in executing the transaction (excludes txdata costs)
 - `time` - String, execution runtime
 
-##### Fault
+#### Fault
 
 `fault` is a function that takes two arguments, `log` and `db`, just like `step` and is invoked when an error happens during the execution of an opcode which wasn't reported in `step`. The method `log.getError()` has information about the error.
 
-##### Enter & Exit
+#### Enter & Exit
 
 `enter` and `exit` are respectively invoked on stepping in and out of an internal call. More specifically they are invoked on the `CALL` variants, `CREATE` variants and also for the transfer implied by a `SELFDESTRUCT`.
 
@@ -817,9 +800,9 @@ If the step function throws an exception or executes an illegal operation at any
 
 - `getGasUsed()` - returns amount of gas used throughout the frame as a Number
 - `getOutput()` - returns the output as a buffer
-` -getError()` - returns an error if one occured during execution and `undefined` otherwise 
+  ` -getError()` - returns an error if one occured during execution and `undefined` otherwise
 
-##### Usage
+#### Usage
 
 Note that several values are Golang big.Int objects, not JavaScript numbers or JS bigints. As such, they have the same interface as described in the godocs. Their default serialization to JSON is as a Javascript number; to serialize large numbers accurately call `.String()` on them. For convenience, `big.NewInt(x)` is provided, and will convert a uint to a Go BigInt.
 
@@ -829,78 +812,76 @@ Usage example, returns the top element of the stack at each CALL opcode only:
 debug.traceTransaction(txhash, {tracer: '{data: [], fault: function(log) {}, step: function(log) { if(log.op.toString() == "CALL") this.data.push(log.stack.peek(0)); }, result: function() { return this.data; }}'});
 ```
 
-### debug_verbosity
+## debug_verbosity
 
 Sets the logging verbosity ceiling. Log messages with level up to and including the given level will be printed.
 
 The verbosity of individual packages and source files can be raised using `debug_vmodule`.
 
 | Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
+| :------ | ------------------------------------------------- |
 | Console | `debug.verbosity(level)`                          |
 | RPC     | `{"method": "debug_vmodule", "params": [number]}` |
 
-### debug_vmodule
+## debug_vmodule
 
 Sets the logging verbosity pattern.
 
 | Client  | Method invocation                                 |
-|:--------|---------------------------------------------------|
+| :------ | ------------------------------------------------- |
 | Console | `debug.vmodule(string)`                           |
 | RPC     | `{"method": "debug_vmodule", "params": [string]}` |
 
-
-#### Examples
+### Examples
 
 To see messages from a particular Go package (directory) and all subdirectories, use:
 
-``` javascript
+```javascript
 > debug.vmodule("eth/*=6")
 ```
 
 To restrict messages to a particular package (e.g. p2p)
 but exclude subdirectories, use:
 
-``` javascript
+```javascript
 > debug.vmodule("p2p=6")
 ```
 
 To see log messages from a particular source file, use
 
-``` javascript
+```javascript
 > debug.vmodule("server.go=6")
 ```
 
 To see all output from peer.go in a package below eth (eth/peer.go, eth/downloader/peer.go) as well as output from package p2p at level <= 5, use:
 
-``` javascript
-debug.vmodule("eth/*/peer.go=6,p2p=5")
+```javascript
+debug.vmodule('eth/*/peer.go=6,p2p=5');
 ```
 
-### debug_writeBlockProfile
+## debug_writeBlockProfile
 
 Writes a goroutine blocking profile to the given file.
 
 | Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
+| :------ | ----------------------------------------------------------- |
 | Console | `debug.writeBlockProfile(file)`                             |
 | RPC     | `{"method": "debug_writeBlockProfile", "params": [string]}` |
 
-### debug_writeMemProfile
+## debug_writeMemProfile
 
 Writes an allocation profile to the given file. Note that the profiling rate cannot be set through the API, it must be set on the command line using the `--pprof.memprofilerate` flag.
 
 | Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
+| :------ | ----------------------------------------------------------- |
 | Console | `debug.writeMemProfile(file string)`                        |
 | RPC     | `{"method": "debug_writeBlockProfile", "params": [string]}` |
 
-### debug_writeMutexProfile
+## debug_writeMutexProfile
 
 Writes a goroutine blocking profile to the given file.
 
 | Client  | Method invocation                                         |
-|:--------|-----------------------------------------------------------|
+| :------ | --------------------------------------------------------- |
 | Console | `debug.writeMutexProfile(file)`                           |
 | RPC     | `{"method": "debug_writeMutexProfile", "params": [file]}` |
-

src/pages/docs/interacting-with-geth/rpc/ns-eth.md

@@ -1,6 +1,6 @@
 ---
 title: eth Namespace
-sort_key: Documentation for the JSON-RPC API "eth" namespace
+description: Documentation for the JSON-RPC API "eth" namespace
 ---
 
 Geth provides several extensions to the standard "eth" JSON-RPC namespace.
@@ -19,29 +19,29 @@ The method takes 3 parameters: an unsigned transaction object to execute in read
 
 ##### 1. `Object` - Transaction call object
 
-The *transaction call object* is mandatory. Please see [here](/content/docs/interacting_with_geth/RPC/objects.md) for details.
+The _transaction call object_ is mandatory. Please see [here](/content/docs/interacting_with_geth/RPC/objects.md) for details.
 
 ##### 2. `Quantity | Tag` - Block number or the string `latest` or `pending`
 
-The *block number* is mandatory and defines the context (state) against which the specified transaction should be executed. It is not possible to execute calls against reorged blocks; or blocks older than 128 (unless the node is an archive node).
+The _block number_ is mandatory and defines the context (state) against which the specified transaction should be executed. It is not possible to execute calls against reorged blocks; or blocks older than 128 (unless the node is an archive node).
 
 ##### 3. `Object` - State override set
 
-The *state override set* is an optional address-to-state mapping, where each entry specifies some state to be ephemerally overridden prior to executing the call. Each address maps to an object containing:
+The _state override set_ is an optional address-to-state mapping, where each entry specifies some state to be ephemerally overridden prior to executing the call. Each address maps to an object containing:
 
-| Field       | Type       | Bytes | Optional | Description |
-|:------------|:-----------|:------|:---------|:------------|
-| `balance`   | `Quantity` | <32   | Yes      | Fake balance to set for the account before executing the call. |
-| `nonce`     | `Quantity` | <8    | Yes      | Fake nonce to set for the account before executing the call. |
-| `code`      | `Binary`   | any   | Yes      | Fake EVM bytecode to inject into the account before executing the call. |
-| `state`     | `Object`   | any   | Yes      | Fake key-value mapping to override **all** slots in the account storage before executing the call. |
+| Field       | Type       | Bytes | Optional | Description                                                                                               |
+| :---------- | :--------- | :---- | :------- | :-------------------------------------------------------------------------------------------------------- |
+| `balance`   | `Quantity` | <32   | Yes      | Fake balance to set for the account before executing the call.                                            |
+| `nonce`     | `Quantity` | <8    | Yes      | Fake nonce to set for the account before executing the call.                                              |
+| `code`      | `Binary`   | any   | Yes      | Fake EVM bytecode to inject into the account before executing the call.                                   |
+| `state`     | `Object`   | any   | Yes      | Fake key-value mapping to override **all** slots in the account storage before executing the call.        |
 | `stateDiff` | `Object`   | any   | Yes      | Fake key-value mapping to override **individual** slots in the account storage before executing the call. |
 
-The goal of the *state override set* is manyfold:
+The goal of the _state override set_ is manyfold:
 
- * It can be used by DApps to reduce the amount of contract code needed to be deployed on chain. Code that simply returns internal state or does pre-defined validations can be kept off chain and fed to the node on-demand.
- * It can be used for smart contract analysis by extending the code deployed on chain with custom methods and invoking them. This avoids having to download and reconstruct the entire state in a sandbox to run custom code against.
- * It can be used to debug smart contracts in an already deployed large suite of contracts by selectively overriding some code or state and seeing how execution changes. Specialized tooling will probably be necessary.
+- It can be used by DApps to reduce the amount of contract code needed to be deployed on chain. Code that simply returns internal state or does pre-defined validations can be kept off chain and fed to the node on-demand.
+- It can be used for smart contract analysis by extending the code deployed on chain with custom methods and invoking them. This avoids having to download and reconstruct the entire state in a sandbox to run custom code against.
+- It can be used to debug smart contracts in an already deployed large suite of contracts by selectively overriding some code or state and seeing how execution changes. Specialized tooling will probably be necessary.
 
 Example:
 
@@ -75,9 +75,9 @@ And the result is an Ethereum ABI encoded list of accounts:
 
 ```json
 {
-  "id":      1,
+  "id": 1,
   "jsonrpc": "2.0",
-  "result":  "0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000004000000000000000000000000d9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f300000000000000000000000078d1ad571a1a09d60d9bbf25894b44e4c8859595000000000000000000000000286834935f4a8cfb4ff4c77d5770c2775ae2b0e7000000000000000000000000b86e2b0ab5a4b1373e40c51a7c712c70ba2f9f8e"
+  "result": "0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000004000000000000000000000000d9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f300000000000000000000000078d1ad571a1a09d60d9bbf25894b44e4c8859595000000000000000000000000286834935f4a8cfb4ff4c77d5770c2775ae2b0e7000000000000000000000000b86e2b0ab5a4b1373e40c51a7c712c70ba2f9f8e"
 }
 ```
 
@@ -92,7 +92,7 @@ Just for the sake of completeness, decoded the response is:
 
 #### Override example
 
-The above *simple example* showed how to call a method already exposed by an on-chain smart contract. What if we want to access some data not exposed by it?
+The above _simple example_ showed how to call a method already exposed by an on-chain smart contract. What if we want to access some data not exposed by it?
 
 We can gut out the [original](https://github.com/ethereum/go-ethereum/blob/master/contracts/checkpointoracle/contract/oracle.sol) checkpoint oracle contract with one that retains the same fields (to retain the same storage layout), but one that includes a different method set:
 
@@ -126,9 +126,9 @@ And the result is the Ethereum ABI encoded threshold number:
 
 ```json
 {
-  "id":      1,
+  "id": 1,
   "jsonrpc": "2.0",
-  "result":  "0x0000000000000000000000000000000000000000000000000000000000000002"
+  "result": "0x0000000000000000000000000000000000000000000000000000000000000002"
 }
 ```
 
@@ -140,10 +140,10 @@ This method creates an [EIP2930](https://eips.ethereum.org/EIPS/eip-2930) type `
 
 #### Parameters
 
-| Field              | Type       | Description          |
-|:-------------------|:-----------|:---------------------|
-| `transaction`      | `Object`   | `TransactionCall` object |
-| `blockNumberOrTag` | `Object`   | Optional, blocknumber or `latest` or `pending` |
+| Field              | Type     | Description                                    |
+| :----------------- | :------- | :--------------------------------------------- |
+| `transaction`      | `Object` | `TransactionCall` object                       |
+| `blockNumberOrTag` | `Object` | Optional, blocknumber or `latest` or `pending` |
 
 #### Usage
 
@@ -158,6 +158,7 @@ The method `eth_createAccessList` returns list of addresses and storage keys use
 That is, it gives the list of addresses and storage keys that will be used by that transaction, plus the gas consumed if the access list is included. Like `eth_estimateGas`, this is an estimation; the list could change when the transaction is actually mined. Adding an `accessList` to a transaction does not necessary result in lower gas usage compared to a transaction without an access list.
 
 Example:
+
 ```json
 {
   "accessList": [

src/pages/docs/interacting-with-geth/rpc/ns-les.md

@@ -5,18 +5,17 @@ description: Documentation for the JSON-RPC API "les" namespace
 
 The `les` API is for managing LES server settings, including client parameters and payment settings for prioritized clients. It also provides functions to query checkpoint information in both server and client mode.
 
-
-### les_serverInfo
+## les_serverInfo
 
 Get information about currently connected and total/individual allowed connection capacity.
 
-| Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
-| Go      | `les.ServerInfo() map[string]interface{}`                   |
-| Console | `les.serverInfo()`                                          |
-| RPC     | `{"method": "les_serverInfo", "params": []}`                |
+| Client  | Method invocation                            |
+| :------ | -------------------------------------------- |
+| Go      | `les.ServerInfo() map[string]interface{}`    |
+| Console | `les.serverInfo()`                           |
+| RPC     | `{"method": "les_serverInfo", "params": []}` |
 
-#### Example
+### Example
 
 ```javascript
 > les.serverInfo
@@ -30,17 +29,17 @@ Get information about currently connected and total/individual allowed connectio
 }
 ```
 
-### les_clientInfo
+## les_clientInfo
 
 Get individual client information (connection, balance, pricing) on the specified list of clients or for all connected clients if the ID list is empty.
 
-| Client  | Method invocation                                                         |
-|:--------|---------------------------------------------------------------------------|
-| Go      | `les.ClientInfo(ids []enode.ID) map[enode.ID]map[string]interface{}`      |
-| Console | `les.clientInfo([id, ...])`                                               |
-| RPC     | `{"method": "les_clientInfo", "params": [[id, ...]]}`                     |
+| Client  | Method invocation                                                    |
+| :------ | -------------------------------------------------------------------- |
+| Go      | `les.ClientInfo(ids []enode.ID) map[enode.ID]map[string]interface{}` |
+| Console | `les.clientInfo([id, ...])`                                          |
+| RPC     | `{"method": "les_clientInfo", "params": [[id, ...]]}`                |
 
-#### Example
+### Example
 
 ```javascript
 > les.clientInfo([])
@@ -102,17 +101,17 @@ Get individual client information (connection, balance, pricing) on the specifie
 }
 ```
 
-### les_priorityClientInfo
+## les_priorityClientInfo
 
 Get individual client information on clients with a positive balance in the specified ID range, `start` included, `stop` excluded. If `stop` is zero then results are returned until the last existing balance entry. `maxCount` limits the number of returned results. If the count limit is reached but there are more IDs in the range then the first missing ID is included in the result with an empty value assigned to it.
 
-| Client  | Method invocation                                                                                  |
-|:--------|----------------------------------------------------------------------------------------------------|
-| Go      | `les.PriorityClientInfo(start, stop enode.ID, maxCount int) map[enode.ID]map[string]interface{}`   |
-| Console | `les.priorityClientInfo(id, id, number)`                                                           |
-| RPC     | `{"method": "les_priorityClientInfo", "params": [id, id, number]}`                                 |
+| Client  | Method invocation                                                                                |
+| :------ | ------------------------------------------------------------------------------------------------ |
+| Go      | `les.PriorityClientInfo(start, stop enode.ID, maxCount int) map[enode.ID]map[string]interface{}` |
+| Console | `les.priorityClientInfo(id, id, number)`                                                         |
+| RPC     | `{"method": "les_priorityClientInfo", "params": [id, id, number]}`                               |
 
-#### Example
+### Example
 
 ```javascript
 > les.priorityClientInfo("0x0000000000000000000000000000000000000000000000000000000000000000", "0x0000000000000000000000000000000000000000000000000000000000000000", 100)
@@ -197,34 +196,34 @@ Get individual client information on clients with a positive balance in the spec
 }
 ```
 
-### les_addBalance
+## les_addBalance
 
 Add signed value to the token balance of the specified client and update its `meta` tag. The balance cannot go below zero or over `2^^63-1`. The balance values before and after the update are returned. The `meta` tag can be used to store a sequence number or reference to the last processed incoming payment, token expiration info, balance in other currencies or any application-specific additional information.
 
-| Client  | Method invocation                                                                 |
-|:--------|-----------------------------------------------------------------------------------|
-| Go      | `les.AddBalance(id enode.ID, value int64, meta string) ([2]uint64, error)}`       |
-| Console | `les.addBalance(id, number, string)`                                              |
-| RPC     | `{"method": "les_addBalance", "params": [id, number, string]}`                    |
+| Client  | Method invocation                                                           |
+| :------ | --------------------------------------------------------------------------- |
+| Go      | `les.AddBalance(id enode.ID, value int64, meta string) ([2]uint64, error)}` |
+| Console | `les.addBalance(id, number, string)`                                        |
+| RPC     | `{"method": "les_addBalance", "params": [id, number, string]}`              |
 
-#### Example
+### Example
 
 ```javascript
 > les.addBalance("0x6a47fe7bb23fd335df52ef1690f37ab44265a537b1d18eb616a3e77f898d9e77", 1000000000, "qwerty")
 [968379616, 1968379616]
 ```
 
-### les_setClientParams
+## les_setClientParams
 
 Set capacity and pricing factors for the specified list of connected clients or for all connected clients if the ID list is empty.
 
-| Client  | Method invocation                                                                 |
-|:--------|-----------------------------------------------------------------------------------|
-| Go      | `les.SetClientParams(ids []enode.ID, params map[string]interface{}) error`        |
-| Console | `les.setClientParams([id, ...], {string: value, ...})`                            |
-| RPC     | `{"method": "les_setClientParams", "params": [[id, ...], {string: value, ...}]}`  |
+| Client  | Method invocation                                                                |
+| :------ | -------------------------------------------------------------------------------- |
+| Go      | `les.SetClientParams(ids []enode.ID, params map[string]interface{}) error`       |
+| Console | `les.setClientParams([id, ...], {string: value, ...})`                           |
+| RPC     | `{"method": "les_setClientParams", "params": [[id, ...], {string: value, ...}]}` |
 
-#### Example
+### Example
 
 ```javascript
 > les.setClientParams(["0x6a47fe7bb23fd335df52ef1690f37ab44265a537b1d18eb616a3e77f898d9e77"], {
@@ -239,17 +238,17 @@ Set capacity and pricing factors for the specified list of connected clients or
 null
 ```
 
-### les_setDefaultParams
+## les_setDefaultParams
 
 Set default pricing factors for subsequently connected clients.
 
-| Client  | Method invocation                                                                 |
-|:--------|-----------------------------------------------------------------------------------|
-| Go      | `les.SetDefaultParams(params map[string]interface{}) error`                       |
-| Console | `les.setDefaultParams({string: value, ...})`                                      |
-| RPC     | `{"method": "les_setDefaultParams", "params": [{string: value, ...}]}`            |
+| Client  | Method invocation                                                      |
+| :------ | ---------------------------------------------------------------------- |
+| Go      | `les.SetDefaultParams(params map[string]interface{}) error`            |
+| Console | `les.setDefaultParams({string: value, ...})`                           |
+| RPC     | `{"method": "les_setDefaultParams", "params": [{string: value, ...}]}` |
 
-#### Example
+### Example
 
 ```javascript
 > les.setDefaultParams({
@@ -263,54 +262,53 @@ Set default pricing factors for subsequently connected clients.
 null
 ```
 
-### les_latestCheckpoint
+## les_latestCheckpoint
 
 Get the index and hashes of the latest known checkpoint.
 
-| Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
-| Go      | `les.LatestCheckpoint() ([4]string, error)`                 |
-| Console | `les.latestCheckpoint()`                                    |
-| RPC     | `{"method": "les_latestCheckpoint", "params": []}`          |
+| Client  | Method invocation                                  |
+| :------ | -------------------------------------------------- |
+| Go      | `les.LatestCheckpoint() ([4]string, error)`        |
+| Console | `les.latestCheckpoint()`                           |
+| RPC     | `{"method": "les_latestCheckpoint", "params": []}` |
 
-#### Example
+### Example
 
 ```javascript
 > les.latestCheckpoint
 ["0x110", "0x6eedf8142d06730b391bfcbd32e9bbc369ab0b46ae226287ed5b29505a376164", "0x191bb2265a69c30201a616ae0d65a4ceb5937c2f0c94b125ff55343d707463e5", "0xf58409088a5cb2425350a59d854d546d37b1e7bef8bbf6afee7fd15f943d626a"]
 ```
 
-### les_getCheckpoint
+## les_getCheckpoint
 
 Get checkpoint hashes by index.
 
-| Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
-| Go      | `les.GetCheckpoint(index uint64) ([3]string, error)`        |
-| Console | `les.getCheckpoint(number)`                                 |
-| RPC     | `{"method": "les_getCheckpoint", "params": [number]}`       |
+| Client  | Method invocation                                     |
+| :------ | ----------------------------------------------------- |
+| Go      | `les.GetCheckpoint(index uint64) ([3]string, error)`  |
+| Console | `les.getCheckpoint(number)`                           |
+| RPC     | `{"method": "les_getCheckpoint", "params": [number]}` |
 
-#### Example
+### Example
 
 ```javascript
 > les.getCheckpoint(256)
 ["0x93eb4af0b224b1097e09181c2e51536fe0a3bf3bb4d93e9a69cab9eb3e28c75f", "0x0eb055e384cf58bc72ca20ca5e2b37d8d4115dce80ab4a19b72b776502c4dd5b", "0xda6c02f7c51f9ecc3eca71331a7eaad724e5a0f4f906ce9251a2f59e3115dd6a"]
 ```
 
-### les_getCheckpointContractAddress
+## les_getCheckpointContractAddress
 
 Get the address of the checkpoint oracle contract.
 
-| Client  | Method invocation                                                 |
-|:--------|-------------------------------------------------------------------|
-| Go      | `les.GetCheckpointContractAddress() (string, error)`              |
-| Console | `les.checkpointContractAddress()`                                 |
-| RPC     | `{"method": "les_getCheckpointContractAddress", "params": []}`    |
+| Client  | Method invocation                                              |
+| :------ | -------------------------------------------------------------- |
+| Go      | `les.GetCheckpointContractAddress() (string, error)`           |
+| Console | `les.checkpointContractAddress()`                              |
+| RPC     | `{"method": "les_getCheckpointContractAddress", "params": []}` |
 
-#### Example
+### Example
 
 ```javascript
 > les.checkpointContractAddress
 "0x9a9070028361F7AAbeB3f2F2Dc07F82C4a98A02a"
 ```
-

src/pages/docs/interacting-with-geth/rpc/ns-miner.md

@@ -5,80 +5,80 @@ description: Documentation for the JSON-RPC API "miner" namespace
 
 The `miner` API is **now deprecated** because mining was switched off at the transition to proof-of-stake. It existed to provide remote control the node's mining operation and set various mining specific settings. It is provided here for historical interest!
 
-### miner_getHashrate
+## miner_getHashrate
 
 Get hashrate in H/s (Hash operations per second).
 
-| Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
-| Console | `miner.getHashrate()`                                       |
-| RPC     | `{"method": "miner_getHashrate", "params": []}`             |
+| Client  | Method invocation                               |
+| :------ | ----------------------------------------------- |
+| Console | `miner.getHashrate()`                           |
+| RPC     | `{"method": "miner_getHashrate", "params": []}` |
 
-### miner_setExtra
+## miner_setExtra
 
 Sets the extra data a miner can include when miner blocks. This is capped at 32 bytes.
 
 | Client  | Method invocation                                  |
-|:--------|----------------------------------------------------|
+| :------ | -------------------------------------------------- |
 | Go      | `miner.setExtra(extra string) (bool, error)`       |
 | Console | `miner.setExtra(string)`                           |
 | RPC     | `{"method": "miner_setExtra", "params": [string]}` |
 
-### miner_setGasPrice
+## miner_setGasPrice
 
 Sets the minimal accepted gas price when mining transactions. Any transactions that are below this limit are excluded from the mining process.
 
 | Client  | Method invocation                                     |
-|:--------|-------------------------------------------------------|
+| :------ | ----------------------------------------------------- |
 | Go      | `miner.setGasPrice(number *rpc.HexNumber) bool`       |
 | Console | `miner.setGasPrice(number)`                           |
 | RPC     | `{"method": "miner_setGasPrice", "params": [number]}` |
 
-### miner_setRecommitInterval
+## miner_setRecommitInterval
 
 Updates the interval for recomitting the miner sealing work.
 
 | Client  | Method invocation                                             |
-|:--------|---------------------------------------------------------------|
+| :------ | ------------------------------------------------------------- |
 | Console | `miner.setRecommitInterval(interval int)`                     |
 | RPC     | `{"method": "miner_setRecommitInterval", "params": [number]}` |
 
-### miner_start
+## miner_start
 
 Start the CPU mining process with the given number of threads and generate a new DAG if need be.
 
 | Client  | Method invocation                                   |
-|:--------|-----------------------------------------------------|
+| :------ | --------------------------------------------------- |
 | Go      | `miner.Start(threads *rpc.HexNumber) (bool, error)` |
 | Console | `miner.start(number)`                               |
 | RPC     | `{"method": "miner_start", "params": [number]}`     |
 
-### miner_stop
+## miner_stop
 
 Stop the CPU mining operation.
 
-| Client  | Method invocation                            |
-|:--------|----------------------------------------------|
-| Go      | `miner.Stop() bool`                          |
-| Console | `miner.stop()`                               |
-| RPC     | `{"method": "miner_stop", "params": []}`     |
+| Client  | Method invocation                        |
+| :------ | ---------------------------------------- |
+| Go      | `miner.Stop() bool`                      |
+| Console | `miner.stop()`                           |
+| RPC     | `{"method": "miner_stop", "params": []}` |
 
-### miner_setEtherbase
+## miner_setEtherbase
 
 Sets the etherbase, where mining rewards will go.
 
-| Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
-| Go      | `miner.SetEtherbase(common.Address) bool`                   |
-| Console | `miner.setEtherbase(address)`                               |
-| RPC     | `{"method": "miner_setEtherbase", "params": [address]}`     |
+| Client  | Method invocation                                       |
+| :------ | ------------------------------------------------------- |
+| Go      | `miner.SetEtherbase(common.Address) bool`               |
+| Console | `miner.setEtherbase(address)`                           |
+| RPC     | `{"method": "miner_setEtherbase", "params": [address]}` |
 
-### miner_setGasLimit
+## miner_setGasLimit
 
-Sets the gas limit the miner will target when mining. Note: on networks where EIP-1559 is activated, this should be set to twice the gas target (i.e. the effective gas used on average per block) to be. 
+Sets the gas limit the miner will target when mining. Note: on networks where EIP-1559 is activated, this should be set to twice the gas target (i.e. the effective gas used on average per block) to be.
 
-| Client  | Method invocation                                           |
-|:--------|-------------------------------------------------------------|
-| Go      | `miner.SetGasLimit(number *rpc.HexNumber) bool`             |
-| Console | `miner.SetGasLimit(number)`                                 |
-| RPC     | `{"method": "miner_setGasLimit", "params": [number]}`       |
+| Client  | Method invocation                                     |
+| :------ | ----------------------------------------------------- |
+| Go      | `miner.SetGasLimit(number *rpc.HexNumber) bool`       |
+| Console | `miner.SetGasLimit(number)`                           |
+| RPC     | `{"method": "miner_setGasLimit", "params": [number]}` |

src/pages/docs/interacting-with-geth/rpc/ns-net.md

@@ -5,30 +5,29 @@ description: Documentation for the JSON-RPC API "net" namespace
 
 The `net` API provides insight about the networking aspect of the client.
 
-
-### net_listening
+## net_listening
 
 Returns an indication if the node is listening for network connections.
 
 | Client  | Method invocation             |
-|:--------|-------------------------------|
+| :------ | ----------------------------- |
 | Console | `net.listening`               |
 | RPC     | `{"method": "net_listening"}` |
 
-### net_peerCount
+## net_peerCount
 
 Returns the number of connected peers.
 
 | Client  | Method invocation             |
-|:--------|-------------------------------|
+| :------ | ----------------------------- |
 | Console | `net.peerCount`               |
 | RPC     | `{"method": "net_peerCount"}` |
 
-### net_version
+## net_version
 
 Returns the devp2p network ID (e.g. 1 for mainnet, 5 for goerli).
 
 | Client  | Method invocation           |
-|:--------|-----------------------------|
+| :------ | --------------------------- |
 | Console | `net.version`               |
 | RPC     | `{"method": "net_version"}` |

src/pages/docs/interacting-with-geth/rpc/ns-personal.md

@@ -5,63 +5,63 @@ description: Documentation for the JSON-RPC API "personal" namespace
 
 The personal API manages private keys in the key store.
 
-### personal_deriveAccount
+## personal_deriveAccount
 
 Requests a HD wallet to derive a new account, optionally pinning it for later reuse.
 
-| Client   | Method invocation                                                        |
-| :--------| ------------------------------------------------------------------------ |
-| Console  | `personal.deriveAccount(url, path, pin)`                                 |
-| RPC      | `{"method": "personal_deriveAccount", "params": [string, string, bool]}` |
+| Client  | Method invocation                                                        |
+| :------ | ------------------------------------------------------------------------ |
+| Console | `personal.deriveAccount(url, path, pin)`                                 |
+| RPC     | `{"method": "personal_deriveAccount", "params": [string, string, bool]}` |
 
-### personal_importRawKey
+## personal_importRawKey
 
 Imports the given unencrypted private key (hex string) into the key store, encrypting it with the passphrase.
 
 Returns the address of the new account.
- 
-| Client   | Method invocation                                                 |
-| :--------| ----------------------------------------------------------------- |
-| Console  | `personal.importRawKey(keydata, passphrase)`                      |
-| RPC      | `{"method": "personal_importRawKey", "params": [string, string]}` |
 
-### personal_initializeWallets
+| Client  | Method invocation                                                 |
+| :------ | ----------------------------------------------------------------- |
+| Console | `personal.importRawKey(keydata, passphrase)`                      |
+| RPC     | `{"method": "personal_importRawKey", "params": [string, string]}` |
+
+## personal_initializeWallets
 
 Initializes a new wallet at the provided URL by generating and returning a new private key.
 
-| Client   | Method invocation                                             |
-| :--------| ------------------------------------------------------------- |
-| Console  | `personal.initializeWallet(url)`                              |
-| RPC      | `{"method": "personal_initializeWallet", "params": [string]}` |
+| Client  | Method invocation                                             |
+| :------ | ------------------------------------------------------------- |
+| Console | `personal.initializeWallet(url)`                              |
+| RPC     | `{"method": "personal_initializeWallet", "params": [string]}` |
 
-### personal_listAccounts
+## personal_listAccounts
 
 Returns all the Ethereum account addresses of all keys in the key store.
 
-| Client   | Method invocation                                   |
-| :--------| --------------------------------------------------- |
-| Console  | `personal.listAccounts`                             |
-| RPC      | `{"method": "personal_listAccounts", "params": []}` |
+| Client  | Method invocation                                   |
+| :------ | --------------------------------------------------- |
+| Console | `personal.listAccounts`                             |
+| RPC     | `{"method": "personal_listAccounts", "params": []}` |
 
-#### Example
+### Example
 
-``` javascript
+```javascript
 > personal.listAccounts
 ["0x5e97870f263700f46aa00d967821199b9bc5a120", "0x3d80b31a78c30fc628f20b2c89d7ddbf6e53cedc"]
 ```
 
-### personal_listWallets
+## personal_listWallets
 
 Returns a list of wallets this node manages.
 
-| Client   | Method invocation                                   |
-| :--------| --------------------------------------------------- |
-| Console  | `personal.listWallets`                              |
-| RPC      | `{"method": "personal_listWallets", "params": []}`  |
+| Client  | Method invocation                                  |
+| :------ | -------------------------------------------------- |
+| Console | `personal.listWallets`                             |
+| RPC     | `{"method": "personal_listWallets", "params": []}` |
 
-#### Example
+### Example
 
-``` javascript
+```javascript
 > personal.listWallets
 [{
   accounts: [{
@@ -73,52 +73,52 @@ Returns a list of wallets this node manages.
 }]
 ```
 
-### personal_lockAccount
+## personal_lockAccount
 
 Removes the private key with given address from memory. The account can no longer be used to send transactions.
- 
-| Client   | Method invocation                                        |
-| :--------| -------------------------------------------------------- |
-| Console  | `personal.lockAccount(address)`                          |
-| RPC      | `{"method": "personal_lockAccount", "params": [string]}` |
 
-### personal_newAccount
+| Client  | Method invocation                                        |
+| :------ | -------------------------------------------------------- |
+| Console | `personal.lockAccount(address)`                          |
+| RPC     | `{"method": "personal_lockAccount", "params": [string]}` |
+
+## personal_newAccount
 
 Generates a new private key and stores it in the key store directory. The key file is encrypted with the given passphrase.
 Returns the address of the new account. At the geth console, `newAccount` will prompt for a passphrase when it is not supplied as the argument.
 
-| Client   | Method invocation                                       |
-| :--------| ---------------------------------------------------     |
-| Console  | `personal.newAccount()`                                 |
-| RPC      | `{"method": "personal_newAccount", "params": [string]}` |
+| Client  | Method invocation                                       |
+| :------ | ------------------------------------------------------- |
+| Console | `personal.newAccount()`                                 |
+| RPC     | `{"method": "personal_newAccount", "params": [string]}` |
+
+### Example
 
-#### Example
- 
-``` javascript
+```javascript
 > personal.newAccount()
-Passphrase: 
-Repeat passphrase: 
+Passphrase:
+Repeat passphrase:
 "0x5e97870f263700f46aa00d967821199b9bc5a120"
 ```
 
 The passphrase can also be supplied as a string.
 
-``` javascript
+```javascript
 > personal.newAccount("h4ck3r")
 "0x3d80b31a78c30fc628f20b2c89d7ddbf6e53cedc"
 ```
 
-### personal_openWallet
+## personal_openWallet
 
 Initiates a hardware wallet opening procedure by establishing a USB connection and then attempting to authenticate via the provided passphrase. Note,
 the method may return an extra challenge requiring a second open (e.g. the Trezor PIN matrix challenge).
 
-| Client   | Method invocation                                               |
-| :--------| -----------------------------------------------------------     |
-| Console  | `personal.openWallet(url, passphrase)`                          |
-| RPC      | `{"method": "personal_openWallet", "params": [string, string]}` |
+| Client  | Method invocation                                               |
+| :------ | --------------------------------------------------------------- |
+| Console | `personal.openWallet(url, passphrase)`                          |
+| RPC     | `{"method": "personal_openWallet", "params": [string, string]}` |
 
-### personal_unlockAccount
+## personal_unlockAccount
 
 Decrypts the key with the given address from the key store.
 
@@ -126,24 +126,24 @@ Both passphrase and unlock duration are optional when using the JavaScript conso
 the passphrase interactively. The unencrypted key will be held in memory until the unlock duration expires. If the unlock duration defaults to 300 seconds. An explicit duration of zero seconds unlocks the key until geth exits.
 
 The account can be used with `eth_sign` and `eth_sendTransaction` while it is unlocked.
- 
-| Client   | Method invocation                                                          |
-| :--------| -------------------------------------------------------------------------- |
-| Console  | `personal.unlockAccount(address, passphrase, duration)`                    |
-| RPC      | `{"method": "personal_unlockAccount", "params": [string, string, number]}` |
 
-#### Examples
+| Client  | Method invocation                                                          |
+| :------ | -------------------------------------------------------------------------- |
+| Console | `personal.unlockAccount(address, passphrase, duration)`                    |
+| RPC     | `{"method": "personal_unlockAccount", "params": [string, string, number]}` |
 
-``` javascript
+### Examples
+
+```javascript
 > personal.unlockAccount("0x5e97870f263700f46aa00d967821199b9bc5a120")
 Unlock account 0x5e97870f263700f46aa00d967821199b9bc5a120
-Passphrase: 
+Passphrase:
 true
 ```
 
 Supplying the passphrase and unlock duration as arguments:
 
-``` javascript
+```javascript
 > personal.unlockAccount("0x5e97870f263700f46aa00d967821199b9bc5a120", "foo", 30)
 true
 ```
@@ -153,40 +153,40 @@ To type in the passphrase and still override the default unlock duration, pass `
 ```
 > personal.unlockAccount("0x5e97870f263700f46aa00d967821199b9bc5a120", null, 30)
 Unlock account 0x5e97870f263700f46aa00d967821199b9bc5a120
-Passphrase: 
+Passphrase:
 true
 ```
 
-### personal_unpair
+## personal_unpair
 
 Deletes a pairing between wallet and Geth.
 
-| Client   | Method invocation                                           |
-| :--------| ----------------------------------------------------------- |
-| Console  | `personal.unpair(url, pin)`                                 |
-| RPC      | `{"method": "personal_unpair", "params": [string, string]}` |
+| Client  | Method invocation                                           |
+| :------ | ----------------------------------------------------------- |
+| Console | `personal.unpair(url, pin)`                                 |
+| RPC     | `{"method": "personal_unpair", "params": [string, string]}` |
 
-### personal_sendTransaction
+## personal_sendTransaction
 
 Validate the given passphrase and submit transaction.
 
 The transaction is the same argument as for `eth_sendTransaction` (i.e. [transaction object](/docs/rpc/objects#transaction-call-object)) and contains the `from` address. If the passphrase can be used to decrypt the private key belogging to `tx.from` the transaction is verified, signed and send onto the network. The account is not unlocked globally in the node and cannot be used in other RPC calls.
 
-| Client   | Method invocation                                                |
-| :--------| -----------------------------------------------------------------|
-| Console  | `personal.sendTransaction(tx, passphrase)`                       |
-| RPC      | `{"method": "personal_sendTransaction", "params": [tx, string]}` |
+| Client  | Method invocation                                                |
+| :------ | ---------------------------------------------------------------- |
+| Console | `personal.sendTransaction(tx, passphrase)`                       |
+| RPC     | `{"method": "personal_sendTransaction", "params": [tx, string]}` |
 
-#### Examples
+### Examples
 
-``` javascript
+```javascript
 > var tx = {from: "0x391694e7e0b0cce554cb130d723a9d27458f9298", to: "0xafa3f8684e54059998bc3a7b0d2b0da075154d66", value: web3.toWei(1.23, "ether")}
 undefined
 > personal.sendTransaction(tx, "passphrase")
 0x8474441674cdd47b35b875fd1a530b800b51a5264b9975fb21129eeb8c18582f
 ```
 
-### personal_sign
+## personal_sign
 
 The sign method calculates an Ethereum specific signature with:
 `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message))`.
@@ -195,41 +195,39 @@ By adding a prefix to the message makes the calculated signature recognisable as
 
 See ecRecover to verify the signature.
 
-| Client  | Method invocation                                     |
-|:--------|-------------------------------------------------------|   
-| Console | `personal.sign(message, account, [password])`                |
+| Client  | Method invocation                                                     |
+| :------ | --------------------------------------------------------------------- |
+| Console | `personal.sign(message, account, [password])`                         |
 | RPC     | `{"method": "personal_sign", "params": [message, account, password]}` |
 
+### Examples
 
-#### Examples
-
-``` javascript
+```javascript
 > personal.sign("0xdeadbeaf", "0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "")
 "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
 ```
 
-### personal_signTransaction
+## personal_signTransaction
 
 SignTransaction will create a transaction from the given arguments and tries to sign it with the key associated with `tx.from`. If the given passwd isn't able to decrypt the key it fails. The transaction is returned in RLP-form, not broadcast to other nodes. The first argument is a [transaction object](/content/docs/interacting_with_geth/RPC/objects.md) and the second argument is the password, similar to `personal_sendTransaction`.
 
-| Client   | Method invocation                                                |
-| :--------| -----------------------------------------------------------------|
-| Console  | `personal.signTransaction(tx, passphrase)`                       |
-| RPC      | `{"method": "personal_signTransaction", "params": [tx, string]}` |
+| Client  | Method invocation                                                |
+| :------ | ---------------------------------------------------------------- |
+| Console | `personal.signTransaction(tx, passphrase)`                       |
+| RPC     | `{"method": "personal_signTransaction", "params": [tx, string]}` |
 
-### personal_ecRecover
+## personal_ecRecover
 
-`ecRecover` returns the address associated with the private key that was used to calculate the signature in `personal_sign`. 
+`ecRecover` returns the address associated with the private key that was used to calculate the signature in `personal_sign`.
 
-| Client  | Method invocation                                     |
-|:--------|-------------------------------------------------------|   
-| Console | `personal.ecRecover(message, signature)`                 |
+| Client  | Method invocation                                                  |
+| :------ | ------------------------------------------------------------------ |
+| Console | `personal.ecRecover(message, signature)`                           |
 | RPC     | `{"method": "personal_ecRecover", "params": [message, signature]}` |
 
+### Examples
 
-#### Examples
-
-``` javascript
+```javascript
 > personal.sign("0xdeadbeaf", "0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "")
 "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
 > personal.ecRecover("0xdeadbeaf", "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b")

src/pages/docs/interacting-with-geth/rpc/ns-txpool.md

@@ -5,7 +5,7 @@ description: Documentation for the JSON-RPC API "txpool" namespace
 
 The `txpool` API gives access to several non-standard RPC methods to inspect the contents of the transaction pool containing all the currently pending transactions as well as the ones queued for future processing.
 
-### txpool_content
+## txpool_content
 
 The `content` inspection property can be queried to list the exact details of all the transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only.
 
@@ -14,12 +14,12 @@ The result is an object with two fields `pending` and `queued`. Each of these fi
 Please note, there may be multiple transactions associated with the same account and nonce. This can happen if the user broadcast mutliple ones with varying gas allowances (or even completely different transactions).
 
 | Client  | Method invocation                                                     |
-|:-------:|-----------------------------------------------------------------------|
-| Go      | `txpool.Content() (map[string]map[string]map[string]*RPCTransaction)` |
+| :-----: | --------------------------------------------------------------------- |
+|   Go    | `txpool.Content() (map[string]map[string]map[string]*RPCTransaction)` |
 | Console | `txpool.content`                                                      |
-| RPC     | `{"method": "txpool_content"}`                                        |
+|   RPC   | `{"method": "txpool_content"}`                                        |
 
-#### Example
+### Example
 
 ```javascript
 > txpool.content
@@ -104,16 +104,16 @@ Please note, there may be multiple transactions associated with the same account
 }
 ```
 
-### txpool_contentFrom
+## txpool_contentFrom
 
 Retrieves the transactions contained within the txpool, returning pending as well as queued transactions of this address, grouped by nonce.
 
 | Client  | Method invocation                                      |
-|:-------:|--------------------------------------------------------|
+| :-----: | ------------------------------------------------------ |
 | Console | `txpool.contentFrom(address)`                          |
-| RPC     | `{"method": "txpool_contentFrom, "params": [string]"}` |
+|   RPC   | `{"method": "txpool_contentFrom, "params": [string]"}` |
 
-### txpool_inspect
+## txpool_inspect
 
 The `inspect` inspection property can be queried to list a textual summary of all the transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only. This is a method specifically tailored to developers to quickly see the transactions in the pool and find any potential issues.
 
@@ -122,12 +122,12 @@ The result is an object with two fields `pending` and `queued`. Each of these fi
 Please note, there may be multiple transactions associated with the same account and nonce. This can happen if the user broadcast mutliple ones with varying gas allowances (or even completely different transactions).
 
 | Client  | Method invocation                                            |
-|:-------:|--------------------------------------------------------------|
-| Go      | `txpool.Inspect() (map[string]map[string]map[string]string)` |
+| :-----: | ------------------------------------------------------------ |
+|   Go    | `txpool.Inspect() (map[string]map[string]map[string]string)` |
 | Console | `txpool.inspect`                                             |
-| RPC     | `{"method": "txpool_inspect"}`                               |
+|   RPC   | `{"method": "txpool_inspect"}`                               |
 
-#### Example
+### Example
 
 ```javascript
 > txpool.inspect
@@ -182,19 +182,19 @@ Please note, there may be multiple transactions associated with the same account
 }
 ```
 
-### txpool_status
+## txpool_status
 
-The `status` inspection property can be queried for the number of transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only. 
+The `status` inspection property can be queried for the number of transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only.
 
 The result is an object with two fields `pending` and `queued`, each of which is a counter representing the number of transactions in that particular state.
 
 | Client  | Method invocation                             |
-|:--------|-----------------------------------------------|
+| :------ | --------------------------------------------- |
 | Go      | `txpool.Status() (map[string]*rpc.HexNumber)` |
 | Console | `txpool.status`                               |
 | RPC     | `{"method": "txpool_status"}`                 |
 
-#### Example
+### Example
 
 ```javascript
 > txpool.status

src/pages/docs/interacting-with-geth/rpc/objects.md

@@ -0,0 +1,72 @@
+---
+title: Objects
+description: Data structures used for RPC methods
+---
+
+The following are data structures which are used for various RPC methods.
+
+## Transaction call object
+
+The _transaction call object_ contains all the necessary parameters for executing an EVM contract method.
+
+| Field                  | Type         | Bytes | Optional | Description                                                                                                                                                                                                                                                                               |
+| :--------------------- | :----------- | :---- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `from`                 | `Address`    | 20    | Yes      | Address the transaction is simulated to have been sent from. Defaults to first account in the local keystore or the `0x00..0` address if no local accounts are available.                                                                                                                 |
+| `to`                   | `Address`    | 20    | No       | Address the transaction is sent to.                                                                                                                                                                                                                                                       |
+| `gas`                  | `Quantity`   | <8    | Yes      | Maximum gas allowance for the code execution to avoid infinite loops. Defaults to `2^63` or whatever value the node operator specified via `--rpc.gascap`.                                                                                                                                |
+| `gasPrice`             | `Quantity`   | <32   | Yes      | Number of `wei` to simulate paying for each unit of gas during execution. Defaults to `1 gwei`.                                                                                                                                                                                           |
+| `maxFeePerGas`         | `Quantity`   | <32   | Yes      | Maximum fee per gas the transaction should pay in total. Relevant for type-2 transactions.                                                                                                                                                                                                |
+| `maxPriorityFeePerGas` | `Quantity`   | <32   | Yes      | Maximum tip per gas that's given directly to the miner. Relevant for type-2 transactions.                                                                                                                                                                                                 |
+| `value`                | `Quantity`   | <32   | Yes      | Amount of `wei` to simulate sending along with the transaction. Defaults to `0`.                                                                                                                                                                                                          |
+| `nonce`                | `Quantity`   | <8    | Yes      | Nonce of sender account.                                                                                                                                                                                                                                                                  |
+| `input`                | `Binary`     | any   | Yes      | Binary data to send to the target contract. Generally the 4 byte hash of the method signature followed by the ABI encoded parameters. For details please see the [Ethereum Contract ABI](https://docs.soliditylang.org/en/v0.7.0/abi-spec.html). This field was previously called `data`. |
+| `accessList`           | `AccessList` | any   | Yes      | A list of addresses and storage keys that the transaction plans to access. Used in non-legacy, i.e. type 1 and 2 transactions.                                                                                                                                                            |
+| `chainId`              | `Quantity`   | <32   | Yes      | Transaction only valid on networks with this chain ID. Used in non-legacy, i.e. type 1 and 2 transactions.                                                                                                                                                                                |
+
+Example for a legacy transaction:
+
+```json
+{
+  "from": "0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3",
+  "to": "0xebe8efa441b9302a0d7eaecc277c09d20d684540",
+  "gas": "0x1bd7c",
+  "data": "0xd459fc46000000000000000000000000000000000000000000000000000000000046c650dbb5e8cb2bac4d2ed0b1e6475d37361157738801c494ca482f96527eb48f9eec488c2eba92d31baeccfb6968fad5c21a3df93181b43b4cf253b4d572b64172ef000000000000000000000000000000000000000000000000000000000000008c00000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000001c000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000002b85c0c828d7a98633b4e1b65eac0c017502da909420aeade9a280675013df36bdc71cffdf420cef3d24ba4b3f9b980bfbb26bd5e2dcf7795b3519a3fd22ffbb2000000000000000000000000000000000000000000000000000000000000000238fb6606dc2b5e42d00c653372c153da8560de77bd9afaba94b4ab6e4aa11d565d858c761320dbf23a94018d843772349bd9d92301b0ca9ca983a22d86a70628"
+}
+```
+
+Example for a type-1 transaction:
+
+```json
+{
+  "from": "0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3",
+  "to":   "0xebe8efa441b9302a0d7eaecc277c09d20d684540",
+  "gas":  "0x1bd7c",
+  "data": "0xd459fc46000000000000000000000000000000000000000000000000000000000046c650dbb5e8cb2bac4d2ed0b1e6475d37361157738801c494ca482f96527eb48f9eec488c2eba92d31baeccfb6968fad5c21a3df93181b43b4cf253b4d572b64172ef000000000000000000000000000000000000000000000000000000000000008c00000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000001c000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000002b85c0c828d7a98633b4e1b65eac0c017502da909420aeade9a280675013df36bdc71cffdf420cef3d24ba4b3f9b980bfbb26bd5e2dcf7795b3519a3fd22ffbb2000000000000000000000000000000000000000000000000000000000000000238fb6606dc2b5e42d00c653372c153da8560de77bd9afaba94b4ab6e4aa11d565d858c761320dbf23a94018d843772349bd9d92301b0ca9ca983a22d86a70628",
+  "chainId": "0x1",
+  "accessList":  [
+    {
+      "address": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
+      "storageKeys": ["0xda650992a54ccb05f924b3a73ba785211ba39a8912b6d270312f8e2c223fb9b1", "0x10d6a54a4754c8869d6886b5f5d7fbfa5b4
+                  522237ea5c60d11bc4e7a1ff9390b"]
+    }, {
+      "address": "0xa2327a938febf5fec13bacfb16ae10ecbc4cbdcf",
+      "storageKeys": []
+    },
+  ]
+}
+```
+
+Example for a type-2 transaction:
+
+```json
+{
+  "from": "0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3",
+  "to": "0xebe8efa441b9302a0d7eaecc277c09d20d684540",
+  "gas": "0x1bd7c",
+  "maxFeePerGas": "0x6b44b0285",
+  "maxPriorityFeePerGas": "0x6b44b0285",
+  "data": "0xd459fc46000000000000000000000000000000000000000000000000000000000046c650dbb5e8cb2bac4d2ed0b1e6475d37361157738801c494ca482f96527eb48f9eec488c2eba92d31baeccfb6968fad5c21a3df93181b43b4cf253b4d572b64172ef000000000000000000000000000000000000000000000000000000000000008c00000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000001c000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000002b85c0c828d7a98633b4e1b65eac0c017502da909420aeade9a280675013df36bdc71cffdf420cef3d24ba4b3f9b980bfbb26bd5e2dcf7795b3519a3fd22ffbb2000000000000000000000000000000000000000000000000000000000000000238fb6606dc2b5e42d00c653372c153da8560de77bd9afaba94b4ab6e4aa11d565d858c761320dbf23a94018d843772349bd9d92301b0ca9ca983a22d86a70628",
+  "chainId": "0x1",
+  "accessList": []
+}
+```

src/pages/docs/interacting-with-geth/rpc/pubsub.md

@@ -22,6 +22,7 @@ returns
 {"jsonrpc":"2.0","method":"eth_subscription","params":{"subscription":"0xcd0c3e8af590364c09d0fa6a1210faf5","result":{"difficulty":"0xd9263f42a87",<...>, "uncles":[]}}}
 {"jsonrpc":"2.0","method":"eth_subscription","params":{"subscription":"0xcd0c3e8af590364c09d0fa6a1210faf5","result":{"difficulty":"0xd90b1a7ad02", <...>, "uncles":["0x80aacd1ea4c9da32efd8c2cc9ab38f8f70578fcd46a1a4ed73f82f3e0957f936"]}}}
 ```
+
 to cancel the subscription:
 
 ```sh
@@ -29,7 +30,8 @@ to cancel the subscription:
 {"id": 1, "method": "eth_unsubscribe", "params": ["0xcd0c3e8af590364c09d0fa6a1210faf5"]}
 {"jsonrpc":"2.0","id":1,"result":true}
 ```
-### Considerations
+
+## Considerations
 
 1. Notifications are sent for current events and not for past events. For use cases that depend on not to miss any notifications subscriptions are probably not the best option.
 2. Subscriptions require a full duplex connection. Geth offers such connections in the form of WebSocket and IPC (enabled by default).
@@ -57,6 +59,7 @@ Subscriptions are created with a regular RPC call with `eth_subscribe` as method
 Subscriptions are cancelled with a regular RPC call with `eth_unsubscribe` as method and the subscription id as first parameter. It returns a bool indicating if the subscription was cancelled successful.
 
 ### Parameters
+
 1. subscription id
 
 ### Example
@@ -119,15 +122,17 @@ In case of a chain reorganization previous sent logs that are on the old chain w
 #### Parameters
 
 1. `object` with the following (optional) fields
-    - **address**, either an address or an array of addresses. Only logs that are created from these addresses are returned (optional)
-    - **topics**, only logs which match the specified topics (optional)
-
+   - **address**, either an address or an array of addresses. Only logs that are created from these addresses are returned (optional)
+   - **topics**, only logs which match the specified topics (optional)
 
 #### Example
+
 ```sh
 {"id": 1, "method": "eth_subscribe", "params": ["logs", {"address": "0x8320fe7702b96808f7bbc0d4a888ed1468216cfd", "topics": ["0xd78a0cb8bb633d06981248b816e7bd33c2a35a6089241d099fa519e361cab902"]}]}
 ```
+
 returns
+
 ```sh
 {"jsonrpc":"2.0","id":2,"result":"0x4a8a4c0517381924f9838102c5a4dcb7"}
 

src/pages/docs/interacting-with-geth/rpc/server.md

@@ -1,16 +1,15 @@
 ---
 title: JSON-RPC Server
-sort_key: Introduction to the JSON-RPC server
+description: Introduction to the JSON_RPC server
 ---
 
 Interacting with Geth requires sending requests to specific JSON-RPC API methods. Geth supports all standard [JSON-RPC API](https://github.com/ethereum/execution-apis) endpoints.
 The RPC requests must be sent to the node and the response returned to the client using some transport protocol. This page outlines the available transport protocols in Geth, providing the information users require to choose a transport protocol for a specific user scenario.
 
-
 ## Introduction
 
 JSON-RPC is provided on multiple transports. Geth supports JSON-RPC over HTTP, WebSocket and Unix Domain Sockets. Transports must be enabled through
-command-line flags. 
+command-line flags.
 
 Ethereum JSON-RPC APIs use a name-space system. RPC methods are grouped into several categories depending on their purpose. All method names are composed of
 the namespace, an underscore, and the actual method name within the namespace. For example, the `eth_call` method resides in the `eth` namespace.
@@ -45,7 +44,7 @@ The default whitelist allows access to the `eth`, `net` and `web3` namespaces. T
 geth --http --http.api personal,eth,net,web3
 ```
 
-Since the HTTP server is reachable from any local application, additional protection is built into the server to prevent misuse of the API from web pages. To enable access to the API from a web page (for example to use the online IDE, [Remix](https://remix.ethereum.org)), the server needs to be configured to accept Cross-Origin requests. This is achieved using the `--http.corsdomain` flag. 
+Since the HTTP server is reachable from any local application, additional protection is built into the server to prevent misuse of the API from web pages. To enable access to the API from a web page (for example to use the online IDE, [Remix](https://remix.ethereum.org)), the server needs to be configured to accept Cross-Origin requests. This is achieved using the `--http.corsdomain` flag.
 
 ```sh
 geth --http --http.corsdomain https://remix.ethereum.org
@@ -81,7 +80,6 @@ As with `--http.corsdomain`, using the wildcard `--ws.origins '*'` allows access
 
 {% include note.html content=" By default, **account unlocking is forbidden when HTTP or Websocket access is enabled** (i.e. by passing `--http` or `ws` flag). This is because an attacker that manages to access the node via the externally-exposed HTTP/WS port can then control the unlocked account. It is possible to force account unlock by including the `--allow-insecure-unlock` flag but this is unsafe and **not recommended** except for expert users that completely understand how it can be used safely. This is not a hypothetical risk: **there are bots that continually scan for http-enabled Ethereum nodes to attack**" %}
 
-
 ### IPC Server
 
 IPC is normally available for use in local environments where the node and the console exist on the same machine. Geth creates a pipe in the computers local file system (at `ipcpath`) that configures a connection between node and console. The `geth.ipc` file can also be used by other processes on the same machine to interact with Geth.
@@ -107,15 +105,20 @@ using the `--ipcdisable` flag.
 
 The following table summarizes the relative strengths and weaknesses of each transport protocol so that users can make informed decisions about which to use.
 
-|                                     |     HTTP    |     WS   |   IPC   |
-| :----------------------------------:|:-----------:|:--------:|:-------:|
-| Event subscription                  |      N      |   **Y**  |   **Y** |
-| Remote connection                   |    **Y**    |   **Y**  |     N   |
-| Per-message metadata overhead       |     high    |    low   |    low  |
+|                               | HTTP  |  WS   |  IPC  |
+| :---------------------------: | :---: | :---: | :---: |
+|      Event subscription       |   N   | **Y** | **Y** |
+|       Remote connection       | **Y** | **Y** |   N   |
+| Per-message metadata overhead | high  |  low  |  low  |
 
 As a general rule IPC is most secure because it is limited to interactions on the local machine and cannot be exposed to external traffic. It can also be used
 to subscribe to events. HTTP is a familiar and idempotent transport that closes connections between requests and can therefore have lower overall overheads if the number of requests is fairly low. Websockets provides a continuous open channel that can enable event subscriptions and streaming and handle large volumes of requests with smaller per-message overheads.
 
+## Engine-API
+
+The Engine-API is a set of RPC methods that enable communication between Geth and the [consensus client](/docs/getting_started/consensus-clients.md). These are not designed to be exposed to the user - instead they are called automatically by the clients when they need to exchange information. The Engine API is enabled by default - the user is not required to pass any instruction to Geth to enable these methods.
+
+Read more in the [Engine API spec](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md).
 
 ## Summary
 

src/pages/docs/monitoring/dashboards.md

@@ -3,7 +3,7 @@ title: Monitoring Geth with InfluxDB and Grafana
 description: introduction to monitoring Geth nodes with Grafana
 ---
 
-There are several ways to monitor the performance of a Geth node. Insights into a node's performance are useful for debugging, tuning and understanding what is really happening when Geth is running. 
+There are several ways to monitor the performance of a Geth node. Insights into a node's performance are useful for debugging, tuning and understanding what is really happening when Geth is running.
 
 ## Prerequisites {#prerequisites}
 
@@ -148,4 +148,4 @@ Some users might also be interested in automatic [alerting](https://grafana.com/
 
 ## Summary
 
-This page has outlined how to set up a simple node monitoring dashboard using Grafana.
+This page has outlined how to set up a simple node monitoring dashboard using Grafana.

src/pages/docs/monitoring/ethstats.md

@@ -7,29 +7,30 @@ Ethstats is a service that displays real time and historical statistics about in
 nodes connected to a network and about the network itself. Individual node statistics include
 the last received block, block time, propagation time, connected peers, latency etc. Network
 metrics include the number of nodes, average block times, node geolocation,
-transaction counts etc. 
+transaction counts etc.
 
 These statistics are presented to the user in the form of a dashboard served to a web browser.
 This can be configured using the public Ethstats server for Ethereum mainnet or some
-public testnets, or using a local copy of Ethstats for private networks. This page will 
+public testnets, or using a local copy of Ethstats for private networks. This page will
 demonstrate how to set up an Ethstats dashboard for private and public networks.
 
 ## Prerequisites
 
 To follow the instructions on this page the following are required:
 
-* Geth
-* Node
-* NPM
-* Git
+- Geth
+- Node
+- NPM
+- Git
 
 ## Ethstats
 
-Ethstats has three components: 
-* a server that consumes data sent to it by each individual node on a network and serves 
-	statistics generated from that data.
-* a client that queries a node and sends its data to the server
-* a dashboard that displays the statistics generated by the server
+Ethstats has three components:
+
+- a server that consumes data sent to it by each individual node on a network and serves
+  statistics generated from that data.
+- a client that queries a node and sends its data to the server
+- a dashboard that displays the statistics generated by the server
 
 The summary dashboard for Ethereum Mainnet can be viewed at [ethstats.net](https://ethstats.net/).
 
@@ -41,10 +42,10 @@ individual nodes. Therefore, many nodes are omitted from the summary statistics.
 
 ## How to use
 
-To report statistics about the local node to Ethstats, an Ethstats server and Ethstats client both have 
+To report statistics about the local node to Ethstats, an Ethstats server and Ethstats client both have
 to be installed alongside Geth. There are several options for installing Ethstats clients and servers,
 each with detailed installation instructions. They all share the common trait that an Ethstats service is
-started with a specific URL that can be passed to Geth. 
+started with a specific URL that can be passed to Geth.
 
 [EthNetStats "Classic"](https://github.com/ethereum/eth-netstats)
 [EthNet Intelligence API](https://github.com/ethereum/eth-net-intelligence-api)
@@ -52,7 +53,7 @@ started with a specific URL that can be passed to Geth.
 [Goerli Ethstats server](https://github.com/goerli/ethstats-server)
 
 If enabled, Geth spins up a minimal Ethstats reporting daemon that pushes statistics about the
-local node to the Ethstats server. 
+local node to the Ethstats server.
 
 To enable this, start Geth with the `ethstats` flag, passing the Ethstats service (nodename:secret@host:port) URL.
 
@@ -65,10 +66,7 @@ accessed via the web browser.
 
 ## Note on WS_secret
 
-The `WS_secret` parameter is required for connecting to an Ethstats server. For a local network this can be user-defined 
-on startup by providing it as an environment variable. However, for Ethereum mainnet and the public testnets predefined 
+The `WS_secret` parameter is required for connecting to an Ethstats server. For a local network this can be user-defined
+on startup by providing it as an environment variable. However, for Ethereum mainnet and the public testnets predefined
 values must be known. Historically these have been made available on Gitter and Skype channels or of a forum, but these are
 no longer in use. The user will have to track down existing Ethstats users to request the `WS_secret`.
-
-
-

src/pages/docs/monitoring/metrics.md

@@ -7,40 +7,37 @@ Geth includes a variety of optional metrics that can be reported to the user. Ho
 
 The goal of the Geth metrics system is that - similar to logs - arbitrary metric collections can be added to any part of the code without requiring fancy constructs to analyze them (counter variables, public interfaces, crossing over the APIs, console hooks, etc). Instead, metrics should be "updated" whenever and wherever needed and be automatically collected, surfaced through the APIs, queryable and visualizable for analysis.
 
-
 ## Metric types
 
 Geth's metrics can be classified into four types: meters, timers, counters and guages.
 
 ### Meters
 
-Analogous to physical meters (electricity, water, etc), Geth's meters are capable of measuring the *amount* of "things" that pass through and at the *rate* at which they do. A meter doesn't have a specific unit of measure (byte, block, malloc, etc), it just counts arbitrary *events*. At any point in time a meter can report:
-
-* *Total number of events* that passed through the meter
-* *Mean throughput rate* of the meter since startup (events / second)
-* *Weighted throughput rate* in the last *1*, *5* and *15* minutes (events / second)
-  ("weighted" means that recent seconds count more that in older ones*)
+Analogous to physical meters (electricity, water, etc), Geth's meters are capable of measuring the _amount_ of "things" that pass through and at the _rate_ at which they do. A meter doesn't have a specific unit of measure (byte, block, malloc, etc), it just counts arbitrary _events_. At any point in time a meter can report:
 
+- _Total number of events_ that passed through the meter
+- _Mean throughput rate_ of the meter since startup (events / second)
+- _Weighted throughput rate_ in the last _1_, _5_ and _15_ minutes (events / second)
+  ("weighted" means that recent seconds count more that in older ones\*)
 
 ### Timers
 
-Timers are extensions of *meters*, the *duration* of an event is collected alongside a log of its occurrence. Similarly to meters, a timer can also measure arbitrary events but each requires a duration to be assigned individually. In addition generating all of the meter report types, a timer also reports:
+Timers are extensions of _meters_, the _duration_ of an event is collected alongside a log of its occurrence. Similarly to meters, a timer can also measure arbitrary events but each requires a duration to be assigned individually. In addition generating all of the meter report types, a timer also reports:
 
-* *Percentiles (5, 20, 50, 80, 95)*, reporting that some percentage of the events took less than the reported time to execute (*e.g. Percentile 20 = 1.5s would mean that 20% of the measured events took less time than 1.5 seconds to execute; inherently 80%(=100%-20%) took more that 1.5s*)
-* Percentile 5: minimum durations (this is as fast as it gets)
-* Percentile 50: well behaved samples (boring, just to give an idea)
-* Percentile 80: general performance (these should be optimised)
-* Percentile 95: worst case outliers (rare, just handle gracefully)
+- _Percentiles (5, 20, 50, 80, 95)_, reporting that some percentage of the events took less than the reported time to execute (_e.g. Percentile 20 = 1.5s would mean that 20% of the measured events took less time than 1.5 seconds to execute; inherently 80%(=100%-20%) took more that 1.5s_)
+- Percentile 5: minimum durations (this is as fast as it gets)
+- Percentile 50: well behaved samples (boring, just to give an idea)
+- Percentile 80: general performance (these should be optimised)
+- Percentile 95: worst case outliers (rare, just handle gracefully)
 
-### Counters: 
+### Counters:
 
 A counter is a single int64 value that can be incremented and decremented. The current value of the counter can be queried.
 
-### Gauges: 
+### Gauges:
 
 A gauge is a single int64 value. Its value can increment and decrement - as with a counter - but can also be set arbitrarily.
 
-
 ## Querying metrics
 
 Geth collects metrics if the `--metrics` flag is provided at startup. Those metrics are available via an HTTP server if the `--metrics.addr` flag is also provided. By default the metrics are served at `127.0.0.1:6060/debug/metrics` but a custom IP address can be provided. A custom port can also be provided to the `--metrics.port` flag. More computationally expensive metrics are toggled on or off by providing or omitting the `--metrics.expensive` flag. For example, to serve all metrics at the default address and port:
@@ -98,7 +95,7 @@ meter := metrics.NewOrRegisteredMeter("system/memory/allocs")
 timer := metrics.NewOrRegisteredTimer("chain/inserts")
 ```
 
-The name given to the metric can be any arbitrary string. However, since Geth assumes it to be some meaningful sub-system hierarchy, it should be named accordingly. 
+The name given to the metric can be any arbitrary string. However, since Geth assumes it to be some meaningful sub-system hierarchy, it should be named accordingly.
 
 Metrics can then be updated:
 
@@ -112,4 +109,4 @@ timer.Time(function)    // Measure and record the execution of `function`
 
 ## Summary
 
-Geth can be configured to report metrics to an HTTP server or database. These functions are disabled by default but can be configured by passing the appropriate commands on startup. Users can easily create custom metrics by adding them to the Geth source code, following the instructions on this page. 
+Geth can be configured to report metrics to an HTTP server or database. These functions are disabled by default but can be configured by passing the appropriate commands on startup. Users can easily create custom metrics by adding them to the Geth source code, following the instructions on this page.