diff --git a/public/images/clef_qubes_http.png b/public/images/docs/clef_qubes_http.png similarity index 100% rename from public/images/clef_qubes_http.png rename to public/images/docs/clef_qubes_http.png diff --git a/public/images/clef_qubes_qrexec.png b/public/images/docs/clef_qubes_qrexec.png similarity index 100% rename from public/images/clef_qubes_qrexec.png rename to public/images/docs/clef_qubes_qrexec.png diff --git a/public/images/clef_sign_flow.png b/public/images/docs/clef_sign_flow.png similarity index 100% rename from public/images/clef_sign_flow.png rename to public/images/docs/clef_sign_flow.png diff --git a/public/images/devcon2_labelled.webp b/public/images/docs/devcon2_labelled.webp similarity index 100% rename from public/images/devcon2_labelled.webp rename to public/images/docs/devcon2_labelled.webp diff --git a/public/images/ethstats-mainnet.png b/public/images/docs/ethstats-mainnet.png similarity index 100% rename from public/images/ethstats-mainnet.png rename to public/images/docs/ethstats-mainnet.png diff --git a/public/images/grafana1.png b/public/images/docs/grafana1.png similarity index 100% rename from public/images/grafana1.png rename to public/images/docs/grafana1.png diff --git a/public/images/grafana2.png b/public/images/docs/grafana2.png similarity index 100% rename from public/images/grafana2.png rename to public/images/docs/grafana2.png diff --git a/public/images/grafana3.png b/public/images/docs/grafana3.png similarity index 100% rename from public/images/grafana3.png rename to public/images/docs/grafana3.png diff --git a/public/images/grafana4.png b/public/images/docs/grafana4.png similarity index 100% rename from public/images/grafana4.png rename to public/images/docs/grafana4.png diff --git a/public/images/grafana5.png b/public/images/docs/grafana5.png similarity index 100% rename from public/images/grafana5.png rename to public/images/docs/grafana5.png diff --git a/public/images/grafana6.png b/public/images/docs/grafana6.png similarity index 100% rename from public/images/grafana6.png rename to public/images/docs/grafana6.png diff --git a/public/images/grafana7.png b/public/images/docs/grafana7.png similarity index 100% rename from public/images/grafana7.png rename to public/images/docs/grafana7.png diff --git a/public/images/grafana8.png b/public/images/docs/grafana8.png similarity index 100% rename from public/images/grafana8.png rename to public/images/docs/grafana8.png diff --git a/public/images/node_architecture.png b/public/images/docs/node_architecture.png similarity index 100% rename from public/images/node_architecture.png rename to public/images/docs/node_architecture.png diff --git a/public/images/node_basic.png b/public/images/docs/node_basic.png similarity index 100% rename from public/images/node_basic.png rename to public/images/docs/node_basic.png diff --git a/public/images/qrexec-example.png b/public/images/docs/qrexec-example.png similarity index 100% rename from public/images/qrexec-example.png rename to public/images/docs/qrexec-example.png diff --git a/public/images/qubes_newaccount-1.png b/public/images/docs/qubes_newaccount-1.png similarity index 100% rename from public/images/qubes_newaccount-1.png rename to public/images/docs/qubes_newaccount-1.png diff --git a/public/images/qubes_newaccount-2.png b/public/images/docs/qubes_newaccount-2.png similarity index 100% rename from public/images/qubes_newaccount-2.png rename to public/images/docs/qubes_newaccount-2.png diff --git a/public/images/remix-compiler.png b/public/images/docs/remix-compiler.png similarity index 100% rename from public/images/remix-compiler.png rename to public/images/docs/remix-compiler.png diff --git a/public/images/remix-deploy.png b/public/images/docs/remix-deploy.png similarity index 100% rename from public/images/remix-deploy.png rename to public/images/docs/remix-deploy.png diff --git a/public/images/remix-func.png b/public/images/docs/remix-func.png similarity index 100% rename from public/images/remix-func.png rename to public/images/docs/remix-func.png diff --git a/public/images/remix.png b/public/images/docs/remix.png similarity index 100% rename from public/images/remix.png rename to public/images/docs/remix.png diff --git a/public/images/wireframe1.png b/public/images/docs/wireframe1.png similarity index 100% rename from public/images/wireframe1.png rename to public/images/docs/wireframe1.png diff --git a/public/images/wireframe2.png b/public/images/docs/wireframe2.png similarity index 100% rename from public/images/wireframe2.png rename to public/images/docs/wireframe2.png diff --git a/public/images/wireframe3.png b/public/images/docs/wireframe3.png similarity index 100% rename from public/images/wireframe3.png rename to public/images/docs/wireframe3.png diff --git a/public/images/wireframe4.png b/public/images/docs/wireframe4.png similarity index 100% rename from public/images/wireframe4.png rename to public/images/docs/wireframe4.png diff --git a/public/images/wireframe5.png b/public/images/docs/wireframe5.png similarity index 100% rename from public/images/wireframe5.png rename to public/images/docs/wireframe5.png diff --git a/public/images/pages/glyph-home-light.svg b/public/images/pages/glyph-home-light.svg new file mode 100644 index 0000000000..2570757c50 --- /dev/null +++ b/public/images/pages/glyph-home-light.svg @@ -0,0 +1,8 @@ + + + + + + + + diff --git a/public/images/pages/gopher-home-front.svg b/public/images/pages/gopher-home-front.svg new file mode 100644 index 0000000000..5729375b7d --- /dev/null +++ b/public/images/pages/gopher-home-front.svg @@ -0,0 +1,453 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/public/images/pages/gopher-home-nodes.svg b/public/images/pages/gopher-home-nodes.svg new file mode 100644 index 0000000000..6c412aa7d1 --- /dev/null +++ b/public/images/pages/gopher-home-nodes.svg @@ -0,0 +1,298 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/public/images/pages/gopher-home-side-desktop.svg b/public/images/pages/gopher-home-side-desktop.svg new file mode 100644 index 0000000000..e823d8927b --- /dev/null +++ b/public/images/pages/gopher-home-side-desktop.svg @@ -0,0 +1,417 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/public/images/pages/gopher-home-side-mobile.svg b/public/images/pages/gopher-home-side-mobile.svg new file mode 100644 index 0000000000..a4bfbbd93c --- /dev/null +++ b/public/images/pages/gopher-home-side-mobile.svg @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/src/components/MDXComponents.tsx b/src/components/MDXComponents.tsx index 4e309b4812..27b2e65aa8 100644 --- a/src/components/MDXComponents.tsx +++ b/src/components/MDXComponents.tsx @@ -43,6 +43,7 @@ const MDXComponents = { {children} diff --git a/src/components/UI/.delete-me b/src/components/UI/.delete-me deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/src/components/UI/homepage/Gopher.tsx b/src/components/UI/homepage/Gopher.tsx new file mode 100644 index 0000000000..a98275fd17 --- /dev/null +++ b/src/components/UI/homepage/Gopher.tsx @@ -0,0 +1,10 @@ +import { Image, Stack } from '@chakra-ui/react'; +import { FC } from 'react'; + +export const Gopher: FC = () => { + return ( + + Gopher greeting + + ); +}; diff --git a/src/components/UI/homepage/HomeHero.tsx b/src/components/UI/homepage/HomeHero.tsx new file mode 100644 index 0000000000..b72354f27c --- /dev/null +++ b/src/components/UI/homepage/HomeHero.tsx @@ -0,0 +1,55 @@ +import { Box, Button, Flex, Stack, Text } from '@chakra-ui/react'; +import { FC } from 'react'; +import NextLink from 'next/link'; + +import { DOCS_PAGE, DOWNLOADS_PAGE } from '../../../constants'; + +export const HomeHero: FC = () => { + return ( + + + + go-ethereum + + + + Official Go implementation of the Ethereum protocol + + + + + + + + + + + Get our latest releases + + + + + + + + + + Read our documentation + + + + + ); +}; diff --git a/src/components/UI/homepage/HomeSection.tsx b/src/components/UI/homepage/HomeSection.tsx new file mode 100644 index 0000000000..2287d34a5d --- /dev/null +++ b/src/components/UI/homepage/HomeSection.tsx @@ -0,0 +1,61 @@ +import { Box, Image, Link, Stack, Text } from '@chakra-ui/react'; +import { FC } from 'react'; +import NextLink from 'next/link'; + +interface Props { + imgSrc?: string; + imgAltText?: string; + sectionTitle: string; + linkLabel: string; + buttonHref: string; + children?: React.ReactNode; +} + +export const HomeSection: FC = ({ + imgSrc, + imgAltText, + sectionTitle, + linkLabel, + buttonHref, + children +}) => { + return ( + + {!!imgSrc && ( + + {/* TODO: use NextImage */} + {imgAltText} + + )} + + + + {sectionTitle} + + + + + {children} + + + + + + {linkLabel} + + + + + ); +}; diff --git a/src/components/UI/homepage/QuickLinks.tsx b/src/components/UI/homepage/QuickLinks.tsx new file mode 100644 index 0000000000..370226f288 --- /dev/null +++ b/src/components/UI/homepage/QuickLinks.tsx @@ -0,0 +1,141 @@ +import { Box, Grid, GridItem, Link, Stack, Text } from '@chakra-ui/react'; +import { FC } from 'react'; +import NextLink from 'next/link'; + +import { CONTRIBUTING_PAGE, DOCS_PAGE, FAQ_PAGE } from '../../../constants'; + +export const QuickLinks: FC = () => { + return ( + + + + Quick Links + + + + + {/* get started */} + + + + Don't know where to start? + + + We can help. + + + + + + + Get started + + + + + + {/* faq */} + + + + Have doubts? + + + Check the FAQ section in the documentation. + + + + + + + Go to the FAQ + + + + + + {/* how to contribute */} + + + + Want to know how to contribute? + + + Get more information in the documentation. + + + + + + + How to contribute + + + + + + + ); +}; diff --git a/src/components/UI/homepage/index.ts b/src/components/UI/homepage/index.ts new file mode 100644 index 0000000000..861cb5112f --- /dev/null +++ b/src/components/UI/homepage/index.ts @@ -0,0 +1,4 @@ +export * from './Gopher'; +export * from './HomeHero'; +export * from './HomeSection'; +export * from './QuickLinks'; diff --git a/src/components/layouts/Layout.tsx b/src/components/layouts/Layout.tsx index 0e1b011e2b..c78ec5a3ab 100644 --- a/src/components/layouts/Layout.tsx +++ b/src/components/layouts/Layout.tsx @@ -5,9 +5,10 @@ interface Props { children?: React.ReactNode; } +// TODO: if mobile, getMobileLayout, else getDesktopLayout export const Layout: FC = ({ children }) => { return ( - + {children} ); diff --git a/src/constants.ts b/src/constants.ts new file mode 100644 index 0000000000..1f481b1b0d --- /dev/null +++ b/src/constants.ts @@ -0,0 +1,12 @@ +// internal pages +export const DOWNLOADS_PAGE = '/downloads'; +export const DOCS_PAGE = '/docs'; +export const FAQ_PAGE = '/docs/faq'; +export const CONTRIBUTING_PAGE = `${DOCS_PAGE}/developers/contributing`; + +// external links +export const ETHEREUM_ORG_URL = 'https://ethereum.org'; +export const ETHEREUM_ORG_RUN_A_NODE_URL = 'https://ethereum.org/en/run-a-node/'; +export const ETHEREUM_FOUNDATION_URL = 'https://ethereum.foundation'; +export const GETH_REPO_URL = 'https://github.com/ethereum/go-ethereum'; +export const GO_URL = 'https://go.dev/'; diff --git a/src/pages/_document.tsx b/src/pages/_document.tsx new file mode 100644 index 0000000000..9a0ff9aa9e --- /dev/null +++ b/src/pages/_document.tsx @@ -0,0 +1,29 @@ +import { Html, Head, Main, NextScript } from 'next/document'; + +export default function Document() { + return ( + + + {/* fonts are being loaded here to enable optimization (https://nextjs.org/docs/basic-features/font-optimization) */} + {/* JetBrains Mono */} + + + + + {/* Inter */} + + + + +
+ + + + ); +} diff --git a/src/pages/docs/developers/dapp-developer/native.md b/src/pages/docs/developers/dapp-developer/native.md index 953d787033..318cf0a628 100644 --- a/src/pages/docs/developers/dapp-developer/native.md +++ b/src/pages/docs/developers/dapp-developer/native.md @@ -25,7 +25,7 @@ The libraries are updated synchronously with the Geth Github repository. The Go Péter Szilágyi (@karalabe) gave a high level overview of the Go libraries in a talk at DevCon2 in Shanghai in 2016. The slides are still a useful resource ([available here](https://ethereum.karalabe.com/talks/2016-devcon.html)) and the talk itself can be viewed by clicking the image below (it is also archived on [IPFS](https://ipfs.io/ipfs/QmQRuKPKWWJAamrMqAp9rytX6Q4NvcXUKkhvu3kuREKqXR)). -[![Peter's Devcon2 talk](/images/devcon2_labelled.webp)](https://www.youtube.com/watch?v=R0Ia1U9Gxjg) +[![Peter's Devcon2 talk](/images/docs/devcon2_labelled.webp)](https://www.youtube.com/watch?v=R0Ia1U9Gxjg) ## Go packages diff --git a/src/pages/docs/developers/geth-developer/dev-mode.md b/src/pages/docs/developers/geth-developer/dev-mode.md index 69ec6e14d7..a57db2a225 100644 --- a/src/pages/docs/developers/geth-developer/dev-mode.md +++ b/src/pages/docs/developers/geth-developer/dev-mode.md @@ -196,15 +196,15 @@ Solidity is a high-level language that makes code executable by the Ethereum vir In a web browser, open . 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. -![Remix](/images/remix.png) +![Remix](/images/docs/remix.png) The Solidity logo is present as an icon in the Remix side-bar. Clicking this icon opens the Solidity compiler wizard. This can be used to compile `Storage.sol` ready. With `Solidity.sol` open in the editor window, simply click the `Compile 1_Storage.sol` button. A green tick will appear next to the Solidity icon to confirm that the contract has compiled successfully. This means the contract bytecode is available. -![Remix-compiler](/images/remix-compiler.png) +![Remix-compiler](/images/docs/remix-compiler.png) 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](/images/remix-deploy.png) +![Remix-deploy](/images/docs/remix-deploy.png) To deploy `Storage.sol`, click `DEPLOY`. @@ -224,7 +224,7 @@ The contract is now deployed on a local testnet version of the Etheruem blockcha 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. -![Remix-func](/images/remix-func.png) +![Remix-func](/images/docs/remix-func.png) In the Geth terminal, the following logs confirm that the transaction was successful (the actual values will vary from the example below): diff --git a/src/pages/docs/fundamentals/logs.md b/src/pages/docs/fundamentals/logs.md index 2a15a35372..a6c09d122c 100644 --- a/src/pages/docs/fundamentals/logs.md +++ b/src/pages/docs/fundamentals/logs.md @@ -7,7 +7,6 @@ A Geth node continually reports messages to the console allowing users to monito Note that there are a large number of log messages covering a wide range of possible scenarios for a Geth node. This page will only address a subset of commonly seen messages. For more, see the [Geth Github](https://github.com/ethereum/go-ethereum), [Discord](https://discord.gg/WHNkYDsAKU) or search on [ethereum.stackexchange](https://ethereum.stackexchange.com/). Log messages are usually sufficiently self-descrining that they do not require additional explanation. - ## Configuring log messages Log messages are displayed to the console by default. The messages can be tuned to be more or less detailed by passing `--verbosity` and a value between 0 and 6 to Geth at startup: @@ -20,6 +19,7 @@ Log messages are displayed to the console by default. The messages can be tuned 4 = debug (all info plus additional messages for debugging) 5 = detail (all info plus detailed debugging messages) ``` + The default is `--verbosity 3`. Log messages can also be redirected so they are saved to a text file instead of being displayed in the console. In Linux the syntax `>> 2>&1` redirects both `stdout` and `stderr` messages to ``. For example: @@ -36,12 +36,13 @@ When Geth starts up it immediately reports a fairly long page of configuration d ``` MESSAGE_TYPE [MONTH-DAY][TIME] MESSAGE VALUE ``` + Where `MESSAGE_TYPE` can be `INFO`, `WARN`, `ERROR` or `DEBUG`. These tags categorize log messages according to their purpose. `INFO` messages inform the user about Geth's current configuration and status. `WARN` messages are for alerting the user to details that affect the way Geth is running. `ERROR` messages are for alerting the user to problems. `DEBUG` is for messages that are relevant to troubleshooting or for developers working on Geth. The messages displayed on startup break down as follows: ``` -INFO [10-04|10:20:52.028] Starting Geth on Ethereum mainnet... +INFO [10-04|10:20:52.028] Starting Geth on Ethereum mainnet... INFO [10-04|10:20:52.028] Bumping default cache on mainnet provided=1024 updated=4096 INFO [10-04|10:20:52.030] Maximum peer count ETH=50 LES=0 total=50 INFO [10-04|10:20:52.031] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory" @@ -52,47 +53,46 @@ INFO [10-04|10:20:52.128] Opened ancient database database=/hom INFO [10-04|10:20:52.129] Disk storage enabled for ethash caches dir=/home/go-ethereum/devnet/geth/ethash count=3 INFO [10-04|10:20:52.129] Disk storage enabled for ethash DAGs dir=/home/.ethash count=2 INFO [10-04|10:20:52.129] Initialising Ethereum protocol network=1 dbversion= -INFO [10-04|10:20:52.129] Writing default main-net genesis block +INFO [10-04|10:20:52.129] Writing default main-net genesis block INFO [10-04|10:20:52.372] Persisted trie from memory database nodes=12356 size=1.78MiB time=21.535537ms gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B ``` -The logs above show the user that the node is connecting to Ethereum Mainnet and some low level configuration details. The cache size is bumped to the Mainnet default (4096). The maximum peer count is the highest number of peers this node is allowed to connect to and can be used to control the bandwidth requirements of the node. Logs relating to `ethash` are out of date since Ethereum moved to proof-of-stake based consensus and can safely be ignored. - +The logs above show the user that the node is connecting to Ethereum Mainnet and some low level configuration details. The cache size is bumped to the Mainnet default (4096). The maximum peer count is the highest number of peers this node is allowed to connect to and can be used to control the bandwidth requirements of the node. Logs relating to `ethash` are out of date since Ethereum moved to proof-of-stake based consensus and can safely be ignored. ``` ---------------------------------------------------------------------------------------------------------------------------------------------------------- -INFO [10-04|10:20:52.386] Chain ID: 1 (mainnet) -INFO [10-04|10:20:52.386] Consensus: Beacon (proof-of-stake), merged from Ethash (proof-of-work) -INFO [10-04|10:20:52.386] -INFO [10-04|10:20:52.386] Pre-Merge hard forks: -INFO [10-04|10:20:52.386] - Homestead: 1150000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/homestead.md) -INFO [10-04|10:20:52.386] - DAO Fork: 1920000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/dao-fork.md) -INFO [10-04|10:20:52.386] - Tangerine Whistle (EIP 150): 2463000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/tangerine-whistle.md) -INFO [10-04|10:20:52.386] - Spurious Dragon/1 (EIP 155): 2675000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/spurious-dragon.md) -INFO [10-04|10:20:52.386] - Spurious Dragon/2 (EIP 158): 2675000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/spurious-dragon.md) -INFO [10-04|10:20:52.386] - Byzantium: 4370000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/byzantium.md) -INFO [10-04|10:20:52.386] - Constantinople: 7280000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/constantinople.md) -INFO [10-04|10:20:52.386] - Petersburg: 7280000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/petersburg.md) -INFO [10-04|10:20:52.386] - Istanbul: 9069000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/istanbul.md) -INFO [10-04|10:20:52.387] - Muir Glacier: 9200000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/muir-glacier.md) -INFO [10-04|10:20:52.387] - Berlin: 12244000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/berlin.md) -INFO [10-04|10:20:52.387] - London: 12965000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/london.md) -INFO [10-04|10:20:52.387] - Arrow Glacier: 13773000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/arrow-glacier.md) +--------------------------------------------------------------------------------------------------------------------------------------------------------- +INFO [10-04|10:20:52.386] Chain ID: 1 (mainnet) +INFO [10-04|10:20:52.386] Consensus: Beacon (proof-of-stake), merged from Ethash (proof-of-work) +INFO [10-04|10:20:52.386] +INFO [10-04|10:20:52.386] Pre-Merge hard forks: +INFO [10-04|10:20:52.386] - Homestead: 1150000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/homestead.md) +INFO [10-04|10:20:52.386] - DAO Fork: 1920000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/dao-fork.md) +INFO [10-04|10:20:52.386] - Tangerine Whistle (EIP 150): 2463000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/tangerine-whistle.md) +INFO [10-04|10:20:52.386] - Spurious Dragon/1 (EIP 155): 2675000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/spurious-dragon.md) +INFO [10-04|10:20:52.386] - Spurious Dragon/2 (EIP 158): 2675000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/spurious-dragon.md) +INFO [10-04|10:20:52.386] - Byzantium: 4370000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/byzantium.md) +INFO [10-04|10:20:52.386] - Constantinople: 7280000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/constantinople.md) +INFO [10-04|10:20:52.386] - Petersburg: 7280000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/petersburg.md) +INFO [10-04|10:20:52.386] - Istanbul: 9069000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/istanbul.md) +INFO [10-04|10:20:52.387] - Muir Glacier: 9200000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/muir-glacier.md) +INFO [10-04|10:20:52.387] - Berlin: 12244000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/berlin.md) +INFO [10-04|10:20:52.387] - London: 12965000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/london.md) +INFO [10-04|10:20:52.387] - Arrow Glacier: 13773000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/arrow-glacier.md) INFO [10-04|10:20:52.387] - Gray Glacier: 15050000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/gray-glacier.md) ``` The above block of messages are related to past Ethereum hard forks. The names are the names of the hard forks and the numbers are the blocks at which the hard fork occurs. This means that blocks with numbers that exceed these values have the configuration required by that hard fork. The specification of each hard fork is available at the provided links (and more information is available on [ethereum.org](https://ethereum.org/en/history/)). The message `Consensus: Beacon (proof-of-stake), merged from Ethash (proof-of-work)` indicates that the node requires a Beacon node to follow the canonical chain - Geth cannot participate in consensus on its own. ``` -INFO [10-04|10:20:52.387] Merge configured: -INFO [10-04|10:20:52.387] - Hard-fork specification: https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md -INFO [10-04|10:20:52.387] - Network known to be merged: true -INFO [10-04|10:20:52.387] - Total terminal difficulty: 58750000000000000000000 -INFO [10-04|10:20:52.387] - Merge netsplit block: -INFO [10-04|10:20:52.387] -INFO [10-04|10:20:52.388] Chain post-merge, sync via beacon client +INFO [10-04|10:20:52.387] Merge configured: +INFO [10-04|10:20:52.387] - Hard-fork specification: https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md +INFO [10-04|10:20:52.387] - Network known to be merged: true +INFO [10-04|10:20:52.387] - Total terminal difficulty: 58750000000000000000000 +INFO [10-04|10:20:52.387] - Merge netsplit block: +INFO [10-04|10:20:52.387] +INFO [10-04|10:20:52.388] Chain post-merge, sync via beacon client WARN [10-04|10:20:52.388] Engine API enabled protocol=eth ---------------------------------------------------------------------------------------------------------------------------------------------------------- +--------------------------------------------------------------------------------------------------------------------------------------------------------- ``` The messages above relate to [The Merge](https://ethereum.org/en/upgrades/merge/). The Merge was Ethereum's transition from proof-of-work to proof-of-stake based consensus. In Geth, The Merge came in the form of the Paris hard fork which was triggered at a [terminal total difficulty](https://ethereum.org/en/glossary/#terminal-total-difficulty) of 58750000000000000000000 instead of a preconfigured block number like previous hard forks. The hard fork specification is linked in the log message. The message `network known to be merged: true` indicates that the node is following a chain that has passed the terminal total difficulty and undergone the Paris hard fork. Since September 15 2022 this will always be true for nodes on Ethereum Mainnet (and the merged testnets Sepolia and Goerli). The warning `Engine API enabled` informs the user that Geth is exposing the set of API methods required for communication with a consensus client. @@ -114,10 +114,9 @@ INFO [10-04|10:21:03.100] Looking for peers peercount=0 t The logs above relate to Geth starting up its peer-to-peer components and seeking other nodes to connect to. The long address reported to `Started P2P networking` is the nodes own enode address. The `IPC Endpoint` is the location of the node's IPC file that can be used to connect a Javascript console. There is a log message confirming that a JWT secret was generated and reporting its path. This is required to authenticate communication between Geth and the consensus client. There are also messages here reporting on the HTTP server that can be used to send requests to Geth. There should be two HTTP servers - one for interacting with Geth (defaults to `localhost:8545`) and one for communication with the consensus client (defaults to `localhost:8551`). - ### Syncing -The default for Geth is to sync in snap mode. This requires a block header to be provided to Geth by the consensus client. The header is then used as a target to sync to. Geth requests block headers from its peers that are parents of the target until there is a continuous chain of sequential headers of sufficient length. Then, Geth requests block bodies and receipts for each header and simultaneously starts downloading state data. This state data is stored in the form of a [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/). Only the leaves of the trie are downloaded, the full trie structure is then locally regenerated from the leaves up. Meanwhile, the blockchain continues to progress and the target header is updated. This means some of the regenerated state data needs to be updated. This is known as *healing*. +The default for Geth is to sync in snap mode. This requires a block header to be provided to Geth by the consensus client. The header is then used as a target to sync to. Geth requests block headers from its peers that are parents of the target until there is a continuous chain of sequential headers of sufficient length. Then, Geth requests block bodies and receipts for each header and simultaneously starts downloading state data. This state data is stored in the form of a [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/). Only the leaves of the trie are downloaded, the full trie structure is then locally regenerated from the leaves up. Meanwhile, the blockchain continues to progress and the target header is updated. This means some of the regenerated state data needs to be updated. This is known as _healing_. Assuming Geth has a synced consensus client and some peers it will start importing headers, block bodies and receipts. The log messages for data downloading look as follows: @@ -140,7 +139,7 @@ INFO [09-06|01:31:59.910] Resuming state snapshot generation root=bc64d4..fc1edd There are other log messages that are commonly seen during syncing. For example: ```sh -WARN [09-28|11:06:01.363] Snapshot extension registration failed +WARN [09-28|11:06:01.363] Snapshot extension registration failed ``` This warning is nothing to worry about - it is reporting a configuration mismatch between the node and a peer. It does not mean syncing is stalling or failing, it simply results in the peer being dropped and replaced. @@ -152,7 +151,6 @@ INFO [10-03|15:34:01.336] Forkchoice requested sync to new head number=15,670 The message above indicates that the fork choice algorithm, which is run by the consensus client, has identified a new target Geth should sync up to. This redirects the sync to prevent syncing to an outdated target and is a natural part of syncing a live blockchain. - ## Transaction logs Transactions submitted over local IPC, Websockets or HTTP connections are reported in the console logs. For example, a simple ETH transaction appears in the console logs as follows: @@ -165,7 +163,7 @@ Other user actions have similar log messages that are displayed to the console. ## Common warnings -There are many warnings that can be emitted by Geth as part of its normal operation. However, some are asked about especially frequently on the [Geth Github](https://github.com/ethereum/go-ethereum) and [Discord](https://discord.gg/WHNkYDsAKU) channel. +There are many warnings that can be emitted by Geth as part of its normal operation. However, some are asked about especially frequently on the [Geth Github](https://github.com/ethereum/go-ethereum) and [Discord](https://discord.gg/WHNkYDsAKU) channel. ```sh WARN [10-03|18:00:40.413] Unexpected trienode heal packet peer=9f0e8fbf reqid=6,915,308,639,612,522,441 @@ -187,4 +185,4 @@ The message above indicates that a consensus client is present but not working c ## Summary -There are a wide range of log messages that are emitted while Geth is running. The level of detail in the logs can be configured using the `verbosity` flag at startup. This page has outlined some of the common messages users can expect to see when Geth is run with default verbosity, without attempting to be comprehensive. For more, please see the [Geth Github](https://github.com/ethereum/go-ethereum) and [Discord](https://discord.gg/WHNkYDsAKU). \ No newline at end of file +There are a wide range of log messages that are emitted while Geth is running. The level of detail in the logs can be configured using the `verbosity` flag at startup. This page has outlined some of the common messages users can expect to see when Geth is run with default verbosity, without attempting to be comprehensive. For more, please see the [Geth Github](https://github.com/ethereum/go-ethereum) and [Discord](https://discord.gg/WHNkYDsAKU). diff --git a/src/pages/docs/fundamentals/mining.md b/src/pages/docs/fundamentals/mining.md index 1a704d2b9b..32faf7543e 100644 --- a/src/pages/docs/fundamentals/mining.md +++ b/src/pages/docs/fundamentals/mining.md @@ -5,20 +5,19 @@ description: Introduction to proof-of-work mining with Geth {% include note.html content=" Proof-of-work mining is no longer used to secure Ethereum Mainnet. The information below is included because the Ethash code is still part of Geth and it could be used to create a private proof-of-work network or testnet." %} -Blockchains grow when individual nodes create valid blocks and distribute them to their peers who check the blocks and add them to their own local databases. -Nodes that add blocks are rewarded with ether payouts. On Ethereum Mainnet, the proof-of-stake consensus engine randomly selects a node to produce each block. +Blockchains grow when individual nodes create valid blocks and distribute them to their peers who check the blocks and add them to their own local databases. +Nodes that add blocks are rewarded with ether payouts. On Ethereum Mainnet, the proof-of-stake consensus engine randomly selects a node to produce each block. Ethereum wasn't always secured this way. Originally, a proof-of-work based consensus mechanism was used instead. Under proof-of-work, block producers are not selected randomly in each slot. Instead they compete for the right to add a block. The node that is fastest to compute a certain value that can only be found using brute force calculations is the one that gets to add a 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 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 +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-algorithms/ethash). ## CPU vs GPU Ethereum mining used 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. Everything required to mine on a CPU is bundled with Geth. However, to mine using GPUs an additional piece of third-party software is required. The most commonly used 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 @@ -28,7 +27,6 @@ The Ethminer software can be installed from a downloaded binary or built from so ### Using Ethminer with Geth - An account to receive block rewards must first be defined. The address of the account is all that is required to start mining - the mining rewards will be credited to that address. This can be an existing address or one that is newly created by Geth. More detailed instructions on creating and importing accounts are available on the [Account Management](/docs/interface/managing-your-accounts) page. The account address can be provided to `--mining.etherbase` when Geth is started. This instructs Geth to direct any block rewards to this address. Once started, Geth will sync the blockchain. If Geth has not connected to this network before, or if the data directory has been deleted, this can take several days. Also, enable HTTP traffic with the `--http` command. @@ -93,11 +91,10 @@ Benchmarking on platform: { "platform": "NVIDIA CUDA", "device": "GeForce GTX 75 Benchmarking on platform: { "platform": "Apple", "device": "Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz", "version": "OpenCL 1.2 " } ``` -Note that the Geth command `miner.hashrate` only works for CPU mining - it always reports zero for GPU mining. To check the GPU mining hashrate, check the logs `ethminer` displays to its terminal. +Note that the Geth command `miner.hashrate` only works for CPU mining - it always reports zero for GPU mining. To check the GPU mining hashrate, check the logs `ethminer` displays to its terminal. More verbose logs can be configured using `-v` and a value between 0-9. 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). @@ -109,10 +106,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 only makes sense if you are in sync with the network (since you mine on top of the consensus block). Therefore the blockchain downloader/synchroniser will delay mining until syncing is complete, and after that mining automatically starts unless you cancel with `miner.stop()`. @@ -157,22 +154,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 if a mined block is re-org'd out of the canonical chain. This means that when the local Geth node includes the mined block diff --git a/src/pages/docs/fundamentals/node-architecture.md b/src/pages/docs/fundamentals/node-architecture.md index 8b1ec0185e..9c976c5dd1 100644 --- a/src/pages/docs/fundamentals/node-architecture.md +++ b/src/pages/docs/fundamentals/node-architecture.md @@ -11,7 +11,7 @@ The execution client (Geth) is responsible for transaction handling, transaction 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](/images/node_architecture.png) +![node-architecture](/images/docs/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). diff --git a/src/pages/docs/fundamentals/peer-to-peer.md b/src/pages/docs/fundamentals/peer-to-peer.md index b5a18919ab..0c051c4a2e 100644 --- a/src/pages/docs/fundamentals/peer-to-peer.md +++ b/src/pages/docs/fundamentals/peer-to-peer.md @@ -12,7 +12,7 @@ These testnets started as proof-of-work and proof-of-authority testnets, but the **Note:** Network selection is not persisted from a 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 @@ -22,7 +22,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: @@ -44,12 +44,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 true @@ -110,7 +108,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: @@ -130,7 +127,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 @@ -148,7 +147,9 @@ 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 diff --git a/src/pages/docs/fundamentals/sync-modes.md b/src/pages/docs/fundamentals/sync-modes.md index 18284b4ab5..3fc9b1a47d 100644 --- a/src/pages/docs/fundamentals/sync-modes.md +++ b/src/pages/docs/fundamentals/sync-modes.md @@ -13,10 +13,11 @@ There are two types of full node that use different mechanisms to sync up to the A snap sync'd node holds the most recent 128 block states in memory, so transactions in that range are always quickly 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. Snap-sync'd nodes are therefore full nodes, with the only difference being the initial synchronization required a checkpoint block to sync from instead of independently verifying the chain all the way from genesis. Snap sync then only verifies the proof-of-work and ancestor-child block progression and assumes that the state transitions are correct rather than re-executing the transactions in each block to verify the state changes. Snap sync is much faster than block-by-block sync. To start a node with snap sync pass `--syncmode snap` at startup. -Snap sync starts by downloading the headers for a chunk of blocks. Once the headers have been verified, the block bodies and receipts for those blocks are downloaded. In parallel, Geth also sync begins state-sync. In state-sync, Geth first downloads the leaves of the state trie for each block without the intermediate nodes along with a range proof. The state trie is then regenerated locally. The state download is the part of the snap-sync that takes the most time to complete and the progress can be monitored using the ETA values in the log messages. However, the blockchain is also progressing at the same time and invalidating some of the regenerated state data. This means it is also necessary to have a 'healing' phase where errors in the state are fixed. It is not possible to monitor the progress of the state heal because the extent of the errors cannot be known until the current state has already been regenerated. +Snap sync starts by downloading the headers for a chunk of blocks. Once the headers have been verified, the block bodies and receipts for those blocks are downloaded. In parallel, Geth also sync begins state-sync. In state-sync, Geth first downloads the leaves of the state trie for each block without the intermediate nodes along with a range proof. The state trie is then regenerated locally. The state download is the part of the snap-sync that takes the most time to complete and the progress can be monitored using the ETA values in the log messages. However, the blockchain is also progressing at the same time and invalidating some of the regenerated state data. This means it is also necessary to have a 'healing' phase where errors in the state are fixed. It is not possible to monitor the progress of the state heal because the extent of the errors cannot be known until the current state has already been regenerated. The healing has to outpace the growth of the blockchain, otherwise the node will never catch up to the current state. There are some hardware factors that determine the speed of the state healing (speed of disk read/write and internet connection) and also the total gas used in each block (more gas means more changes to the state that have to be handled). To summarize, snap sync progresses in the following sequence: + - download and verify headers - download block bodies and receipts. In parallel, download raw state data and build state trie - heal state trie to account for newly arriving data @@ -25,13 +26,13 @@ To summarize, snap sync progresses in the following sequence: ### Full -A full sync generates the current state by executing every block starting from the genesis block. A full sync indendently verifies proof-of-work and block provenance as well as all state transitions by re-executing the transactions in the entire historical sequence of blocks. Only the most recent 128 block states are stored in a full node - older block states are pruned periodically and represented as a series of checkpoints from which any previous state can be regenerated on request. 128 blocks is about 25.6 minutes of history with a block time of 12 seconds. +A full sync generates the current state by executing every block starting from the genesis block. A full sync indendently verifies proof-of-work and block provenance as well as all state transitions by re-executing the transactions in the entire historical sequence of blocks. Only the most recent 128 block states are stored in a full node - older block states are pruned periodically and represented as a series of checkpoints from which any previous state can be regenerated on request. 128 blocks is about 25.6 minutes of history with a block time of 12 seconds. To create a full node pass `--syncmode full` at startup. ## 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`. @@ -43,7 +44,7 @@ Read more about light nodes on our [LES page](/docs/interface/les.md). ## Consensus layer syncing -Now that Ethereum has switched to proof-of-stake, all consensus logic and block propagation is handled by 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. In order for Geth to sync, it requires a header from its connected consensus client. Geth does not import any data until it is instructed to by the consensus client. +Now that Ethereum has switched to proof-of-stake, all consensus logic and block propagation is handled by 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. In order for Geth to sync, it requires a header from its connected consensus client. Geth does not import any data until it is instructed to by the consensus client. Once a header is available to use as a syncing target, Geth retrieves all headers between that target header and the local header chain in reverse chronological order. These headers show that the sequence of blocks is correct because the parenthashes link one block to the next right up to the target block. Eventually, the sync will reach a block held in the local database, at which point the local data and the target data are considered 'linked' and there is a very high chance the node is syncing the correct chain. The block bodies are then downloaded and then the state data. The consensus client can update the target header - as long as the syncing outpaces the growth of the blockchain then the node will eventually get in sync. @@ -63,4 +64,4 @@ Alternatively, the consensus client can grab a checkpoint from a trusted source ## 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 using some recent block that is old enough to be safe from re-orgs as a sync target. A trust-minimized alternative is full-sync, which verifies every block since genesis. These modes drop state 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`. Currently, due to the transition to proof-of-stake, light-sync does not work (new light client protocols are being developed). \ No newline at end of file +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 using some recent block that is old enough to be safe from re-orgs as a sync target. A trust-minimized alternative is full-sync, which verifies every block since genesis. These modes drop state 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`. Currently, due to the transition to proof-of-stake, light-sync does not work (new light client protocols are being developed). diff --git a/src/pages/docs/getting-started/hardware-requirements.md b/src/pages/docs/getting-started/hardware-requirements.md index 39e787a277..5ff883b8e9 100644 --- a/src/pages/docs/getting-started/hardware-requirements.md +++ b/src/pages/docs/getting-started/hardware-requirements.md @@ -3,7 +3,7 @@ title: Hardware requirements description: Overview of the hardware needed to run an Ethereum node --- -The hardware requirements for running a Geth node depend upon the node configuration and can change over time as upgrades to the network are implemented. Ethereum nodes can be run on low power, resource-constrained devices such as Raspberry Pi's. Prebuilt, dedicated staking machines are available from several companies - these might be good choices for users who want plug-and-play hardware specifically designed for Ethereum. However, many users will choose to run nodes on laptop or desktop computers. +The hardware requirements for running a Geth node depend upon the node configuration and can change over time as upgrades to the network are implemented. Ethereum nodes can be run on low power, resource-constrained devices such as Raspberry Pi's. Prebuilt, dedicated staking machines are available from several companies - these might be good choices for users who want plug-and-play hardware specifically designed for Ethereum. However, many users will choose to run nodes on laptop or desktop computers. ## Processor @@ -18,10 +18,8 @@ It is recommended to use at least 16GB RAM. Disk space is usually the primary bottleneck for node operators. At the time of writing (September 2022) a 2TB SSD is recommended for a full node running Geth and a consensus client. Geth itself requires >650GB of disk space for a snap-synced full node and, with the default cache size, grows about 14GB/week. Pruning brings the total storage back down to the original 650GB. Archive nodes require additional space. A "full" archive node that keeps all state back to genesis requires more than 12TB of space. Partial archive nodes can also be created by turning off the garbage collector after some initial sync - the storage requirement depends how much state is saved. - -As well as storage capacity, Geth nodes rely on fast read and write operations. This means HDDs and cheaper HDDS can sometimes struggle to sync the blockchain. A list of SSD models that users report being able and unable to sync Geth is available in this [Github Gist](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038). Please note that the list has *not* been verified by the Geth team. - +As well as storage capacity, Geth nodes rely on fast read and write operations. This means HDDs and cheaper HDDS can sometimes struggle to sync the blockchain. A list of SSD models that users report being able and unable to sync Geth is available in this [Github Gist](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038). Please note that the list has _not_ been verified by the Geth team. ## Bandwidth -It is important to have a stable and reliable internet connection, especially for running a validator because downtime can result in missed rewards or penalties. It is recommended to have at least 25Mbps download speed to run a node. Running a node also requires a lot of data to be uploaded and downloaded so it is better to use an ISP that does not have a capped data allowance. \ No newline at end of file +It is important to have a stable and reliable internet connection, especially for running a validator because downtime can result in missed rewards or penalties. It is recommended to have at least 25Mbps download speed to run a node. Running a node also requires a lot of data to be uploaded and downloaded so it is better to use an ISP that does not have a capped data allowance. diff --git a/src/pages/docs/getting-started/getting-started.md b/src/pages/docs/getting-started/index.md similarity index 100% rename from src/pages/docs/getting-started/getting-started.md rename to src/pages/docs/getting-started/index.md diff --git a/src/pages/docs/index.md b/src/pages/docs/index.md index e921647ee1..b613f1e432 100644 --- a/src/pages/docs/index.md +++ b/src/pages/docs/index.md @@ -26,4 +26,4 @@ If you want to help develop Geth or build decentralized apps on top of it, head ## More resources -We have a library of videos and articles on our [Resources](/pages/docs/resources.md) page and answers to common questions on the [FAQs](/pages/docs/faq.md) page. \ No newline at end of file +We have a library of videos and articles on our [Resources](/pages/docs/resources.md) page and answers to common questions on the [FAQs](/pages/docs/faq.md) page. diff --git a/src/pages/docs/monitoring/dashboards.md b/src/pages/docs/monitoring/dashboards.md index 411f383557..421b116475 100644 --- a/src/pages/docs/monitoring/dashboards.md +++ b/src/pages/docs/monitoring/dashboards.md @@ -112,35 +112,35 @@ sudo systemctl start grafana-server When Grafana is up and running, it should be reachable at `localhost:3000`. A browser can be pointed to that URL to access a visualization dashboard. The browser will prompt for login credentials (user: `admin` and password: `admin`). When prompted, the default password should be changed and saved. -![](/images/grafana1.png) +![](/images/docs/grafana1.png) The browser first redirects to the Grafana home page to set up the source data. Click on the configuration icon in the left bar and select "Data sources". -![](/images/grafana2.png) +![](/images/docs/grafana2.png) There aren't any data sources yet, click on "Add data source" to define one. -![](/images/grafana3.png) +![](/images/docs/grafana3.png) Select "InfluxDB" and proceed. -![](/images/grafana4.png) +![](/images/docs/grafana4.png) Data source configuration is pretty straight forward if the tools run on the same machine as Geth. The InfluxDB address and details for accessing the database must be set. Refer to the image below. -![](/images/grafana5.png) +![](/images/docs/grafana5.png) If everything is complete and InfluxDB is reachable, click on "Save and test" and wait for the confirmation to pop up. -![](/images/grafana6.png) +![](/images/docs/grafana6.png) Grafana is now set up to read data from InfluxDB. Now a dashboard can be created to interpret and display it. Dashboards properties are encoded in JSON files which can be created by anybody and easily imported. On the left bar, click on "Create and Import". -![](/images/grafana7.png) +![](/images/docs/grafana7.png) For a Geth monitoring dashboard, copy the ID of [this dashboard](https://grafana.com/grafana/dashboards/13877/) and paste it in the "Import page" in Grafana. After saving the dashboard, it should look like this: -![](/images/grafana8.png) +![](/images/docs/grafana8.png) The dashboards can be customized further. Each panel can be edited, moved, removed or added. To learn more about how dashboards work, refer to [Grafana's documentation](https://grafana.com/docs/grafana/latest/dashboards/). diff --git a/src/pages/docs/monitoring/ethstats.md b/src/pages/docs/monitoring/ethstats.md index d809daeabf..22c6defd76 100644 --- a/src/pages/docs/monitoring/ethstats.md +++ b/src/pages/docs/monitoring/ethstats.md @@ -34,7 +34,7 @@ Ethstats has three components: The summary dashboard for Ethereum Mainnet can be viewed at [ethstats.net](https://ethstats.net/). -![Ethstats](/images/ethstats-mainnet.png) +![Ethstats](/images/docs/ethstats-mainnet.png) Note that the Ethstats dashboard is not a reliable source of information about the entire Ethereum network because submitting data to the Ethstats server is voluntary and has to be configured by diff --git a/src/pages/docs/tools/clef/Introduction.md b/src/pages/docs/tools/clef/Introduction.md index 2afd8ea81c..33882720aa 100644 --- a/src/pages/docs/tools/clef/Introduction.md +++ b/src/pages/docs/tools/clef/Introduction.md @@ -72,7 +72,7 @@ The external API never handles any sensitive data directly, but it can be used t The general flow for a basic transaction-signing operation using Clef and an Ethereum node such as Geth is as follows: -![Clef signing logic](/images/clef_sign_flow.png) +![Clef signing logic](/images/docs/clef_sign_flow.png) In the case illustrated in the schematic above, Geth would be started with `--signer :` and would relay requests to `eth.sendTransaction`. Text in `mono` font positioned along arrows shows the objects passed between each component. @@ -86,7 +86,7 @@ Clef is started on the command line using the `clef` command. Clef can be config clef --keystore /my/keystore --chainid 5 ``` -On starting Clef, the following welcome messgae is displayed in the terminal: +On starting Clef, the following welcome message is displayed in the terminal: ```terminal WARNING! diff --git a/src/pages/docs/tools/clef/rules.md b/src/pages/docs/tools/clef/rules.md index 76f78a7977..9228398291 100644 --- a/src/pages/docs/tools/clef/rules.md +++ b/src/pages/docs/tools/clef/rules.md @@ -23,7 +23,7 @@ This page will explain how rules are implemented in Clef and how best to manage The ruleset engine acts as a gatekeeper to the command line interface - it auto-approves any requests that meet the conditions defined in a set of authenticated rule files. This prevents the user from having to manually approve or reject every request - instead they can define common patterns in a rule file and abstract that task away to the ruleset engine. The general architecture is as follows: -![Clef ruleset logic](/images/images/clef_ruleset.png) +![Clef ruleset logic](/images/docs/clef_ruleset.png) When Clef receives a request, the ruleset engine evaluates a Javascript file for each method defined in the internal [UI API docs](/content/docs/tools/Clef/apis.md). For example the code snippet below is an example ruleset that calls the function `ApproveTx`. The call to `ApproveTx` is invoking the `ui_approveTx` [JSON_RPC API endpoint](/content/docs/tools/Clef/apis.md). Every time an RPC method is invoked the Javascript code is executed in a freshly instantiated virtual machine. diff --git a/src/pages/docs/tools/clef/setup.md b/src/pages/docs/tools/clef/setup.md index 14781c4c94..af5522a3ff 100644 --- a/src/pages/docs/tools/clef/setup.md +++ b/src/pages/docs/tools/clef/setup.md @@ -35,7 +35,7 @@ There are two ways that this can be achieved: integrated via Qubes or integrated Qubes provides a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request to another qube. The OS then asks the user if the call is permitted. -![Example](/images/qrexec-example.png) +![Example](/images/docs/qrexec-example.png) A policy-file can be created to allow such interaction. On the `target` domain, a service is invoked which can read the `stdin` from the `client` qube. @@ -43,7 +43,7 @@ This is how [Split GPG](https://www.qubes-os.org/doc/split-gpg/) is implemented. ##### Server -![Clef via qrexec](/images/clef_qubes_qrexec.png) +![Clef via qrexec](/images/docs/clef_qubes_qrexec.png) On the `target` qubes, we need to define the RPC service. @@ -122,11 +122,11 @@ $ cat newaccnt.json| qrexec-client-vm debian-work qubes.Clefsign A dialog should pop up first to allow the IPC call: -![one](/images/qubes_newaccount-1.png) +![one](/images/docs/qubes_newaccount-1.png) Followed by a GTK-dialog to approve the operation: -![two](/images/qubes_newaccount-2.png) +![two](/images/docs/qubes_newaccount-2.png) To test the full flow, start the client wrapper on the `client` qube: @@ -165,7 +165,7 @@ However, it comes with a couple of drawbacks: The second way to set up Clef on a qubes system is to allow networking, and have Clef listen to a port which is accessible from other qubes. -![Clef via http](/images/clef_qubes_http.png) +![Clef via http](/images/docs/clef_qubes_http.png) ## USBArmory diff --git a/src/pages/docs/tools/clef/tutorial.md b/src/pages/docs/tools/clef/tutorial.md index e6e5b69c79..2392dbd486 100644 --- a/src/pages/docs/tools/clef/tutorial.md +++ b/src/pages/docs/tools/clef/tutorial.md @@ -204,7 +204,7 @@ For most users, manually confirming every transaction is the right way to use Cl For example, well defined rules such as: - Auto-approve transactions with Uniswap v2, with value between 0.1 and 0.5 ETH per 24h period -- Auto-approve transactions to address `0xD9C9Cd5f6779558b6e0eD4e6Acf6b1947E7fA1F3` as long as gas < 44k and gasPrice < 80Gwei can be encoded and intepreted by Clef's built-in ruleset engine. +- Auto-approve transactions to address `0xD9C9Cd5f6779558b6e0eD4e6Acf6b1947E7fA1F3` as long as gas < 44k and gasPrice < 80Gwei can be encoded and interpreted by Clef's built-in ruleset engine. ### Rule files @@ -507,7 +507,7 @@ More examples, including a ruleset for a rate-limited window, are available on t ## Under the hood -The examples on this page have provided step-by-step instructions for verious operations using Clef. However, they have not provided much detail as to what is happening under the hood. This section will provide some more details about how Clef organizes itself locally. +The examples on this page have provided step-by-step instructions for various operations using Clef. However, they have not provided much detail as to what is happening under the hood. This section will provide some more details about how Clef organizes itself locally. Initializing Clef with a master password and providing an account password to `clef setpw` and attesting a ruleset creates the following files in the directory `~/.clef/` (this path is independent of the paths provided to `--keystore` and `--configdir` on startup): diff --git a/src/pages/homepage.md b/src/pages/homepage.md deleted file mode 100644 index a57c0a78f7..0000000000 --- a/src/pages/homepage.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Home -description: Geth homepage ---- - -## What is Geth? - -Geth (go-ethereum) is a [Go](https://go.dev/) implementation of [Ethereum](http://ethereum.org) - a gateway into the decentralized web. - -Geth has been a core part of Etheruem since the very beginning. Geth was one of the original Ethereum implementations making it the most battle-hardened and tested client. - -Geth is an Ethereum _execution client_ meaning it handles transactions, deployment and execution of smart contracts and contains an embedded computer known as the _Ethereum Virtual Machine_. - -Running Geth alongside a consensus client turns a computer into an Ethereum node. - -## What is Ethereum? - -Ethereum is a technology for building apps and organizations, holding assets, transacting and communicating without being controlled by a central authority. It is the base of a new, decentralized internet. - -Read more on our [Ethereum page](/ethereum) or on [ethereum.org](http://ethereum.org). - -## Why run a node? - -Running your own node enables you to use Ethereum in a truly private, self-sufficient and trustless manner. You don't need to trust information you receive because you can verify the data yourself using your Geth instance. - -**"Don't trust, verify"** - -[Read more about running a node](http://https://ethereum.org/en/run-a-node/#main-content) - -## Contribute to Geth - -We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes! If you'd like to contribute to the Geth source code, please fork the [Github repository](https://github.com/ethereum/go-ethereum), fix, commit and send a pull request for the maintainers to review and merge into the main code base. See our [contribution guidelines](/content/docs/developers/contributing.md) for more information. - -## About the Team - -The Geth team comprises 10 developers distributed across the world. The Geth team is funded directly by [The Ethereum Foundation](https://ethereum.foundation). diff --git a/src/pages/index.tsx b/src/pages/index.tsx index 817ca2ac72..b8bced19fb 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -1,62 +1,143 @@ +import { Link, Stack, Text } from '@chakra-ui/react'; import type { NextPage } from 'next'; -import Head from 'next/head'; -import Image from 'next/image'; -const Home: NextPage = () => { +import { Gopher, HomeHero, HomeSection, QuickLinks } from '../components/UI/homepage'; + +import { + CONTRIBUTING_PAGE, + DOCS_PAGE, + ETHEREUM_FOUNDATION_URL, + ETHEREUM_ORG_RUN_A_NODE_URL, + ETHEREUM_ORG_URL, + GETH_REPO_URL, + GO_URL, +} from '../constants'; + +const HomePage: NextPage = ({}) => { return ( -
- - Create Next App - - - + <> + {/* TODO: add PageMetadata */}
-

- Welcome to Next.js! -

+ + -

- Get started by editing pages/index.tsx -

+ {/* SECTION: What is Geth */} + + + Geth (go-ethereum) is a{' '} + + Go + {' '} + implementation of{' '} + + Ethereum + {' '} + - a gateway into the decentralized web. + -
- -

Documentation →

-

Find in-depth information about Next.js features and API.

- + + Geth has been a core part of Etheruem since the very beginning. Geth was one of the + original Ethereum implementations making it the most battle-hardened and tested + client. + - -

Learn →

-

Learn about Next.js in an interactive course with quizzes!

- + + Geth is an Ethereum{' '} + + execution client + {' '} + meaning it handles transactions, deployment and execution of smart contracts and + contains an embedded computer known as the{' '} + + Ethereum Virtual Machine + + . + - -

Examples →

-

Discover and deploy boilerplate example Next.js projects.

- + + Running Geth alongside a consensus client turns a computer into an Ethereum node. + + - -

Deploy →

-

Instantly deploy your Next.js site to a public URL with Vercel.

- -
+ {/* SECTION: What is Ethereum */} + + + Ethereum is a technology for building apps and organizations, holding assets, + transacting and communicating without being controlled by a central authority. It is + the base of a new, decentralized internet. + + + + {/* SECTION: Why run a Node */} + + + Running your own node enables you to use Ethereum in a truly private, self-sufficient + and trustless manner. You don't need to trust information you receive because you + can verify the data yourself using your Geth instance. + + + + “Don't trust, verify” + + + + {/* SECTION:Contribute to Geth */} + + + We welcome contributions from anyone on the internet, and are grateful for even the + smallest of fixes! If you'd like to contribute to the Geth source code, please + fork the{' '} + + Github repository + + , fix, commit and send a pull request for the maintainers to review and merge into the + main code base. + + + + {/* SECTION: About the Team */} + + + The Geth team comprises 10 developers distributed across the world. The Geth team is + funded directly by The Ethereum Foundation. + + + + {/* TODO: replace with animated/video version */} + + + +
- - -
+ ); }; -export default Home; +export default HomePage; diff --git a/src/theme/components/.delete-me b/src/theme/components/.delete-me deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/src/theme/components/Button.ts b/src/theme/components/Button.ts new file mode 100644 index 0000000000..5d953f46c0 --- /dev/null +++ b/src/theme/components/Button.ts @@ -0,0 +1,17 @@ +export const Button = { + variants: { + primary: { + py: '8px', + px: '32px', + borderRadius: 0, + width: { base: '188px', md: 'auto' }, + bg: 'brand.light.primary', + _hover: { bg: 'brand.light.secondary' }, + _focus: { + bg: 'brand.light.primary', + boxShadow: 'inset 0 0 0 2px #06fece !important' + }, + _active: { borderTop: '4px solid', borderColor: 'green.200', pt: '4px' } + } + } +}; diff --git a/src/theme/components/Link.ts b/src/theme/components/Link.ts new file mode 100644 index 0000000000..295f82f5ff --- /dev/null +++ b/src/theme/components/Link.ts @@ -0,0 +1,30 @@ +export const Link = { + variants: { + 'button-link-secondary': { + color: 'brand.light.primary', + bg: 'green.50', + _hover: { textDecoration: 'none', bg: 'brand.light.primary', color: 'yellow.50' }, + _focus: { + textDecoration: 'none', + bg: 'brand.light.primary', + color: 'yellow.50', + boxShadow: 'inset 0 0 0 3px #f0f2e2 !important' + }, + _active: { textDecoration: 'none', bg: 'brand.light.secondary', color: 'yellow.50' } + }, + light: { + textDecoration: 'underline', + color: 'brand.light.primary', + _hover: { color: 'brand.light.body', textDecorationColor: 'brand.light.body' }, + _focus: { + color: 'brand.light.primary', + boxShadow: '0 0 0 1px #11866f !important', + textDecoration: 'none' + }, + _pressed: { + color: 'brand.light.secondary', + textDecorationColor: 'brand.light.secondary' + } + } + } +}; diff --git a/src/theme/components/index.ts b/src/theme/components/index.ts new file mode 100644 index 0000000000..4b249348b6 --- /dev/null +++ b/src/theme/components/index.ts @@ -0,0 +1,2 @@ +export * from './Button'; +export * from './Link'; diff --git a/src/theme/foundations/breakpoints.ts b/src/theme/foundations/breakpoints.ts deleted file mode 100644 index f43deba731..0000000000 --- a/src/theme/foundations/breakpoints.ts +++ /dev/null @@ -1,9 +0,0 @@ -export const breakpoints = { - xs: '320px', - sm: '360px', - md: '768px', - lg: '1096px', - xl: '1200px', - '2xl': '1600px', - '3xl': '2000px' -}; diff --git a/src/theme/foundations/colors.ts b/src/theme/foundations/colors.ts new file mode 100644 index 0000000000..2fc5df88a2 --- /dev/null +++ b/src/theme/foundations/colors.ts @@ -0,0 +1,16 @@ +export const colors = { + brand: { + light: { + primary: '#11866f', + secondary: '#25453f', + body: '#1d242c' + } + }, + green: { + 50: '#d7f5ef', + 200: '#06fece' + }, + yellow: { + 50: '#f0f2e2' + } +}; diff --git a/src/theme/foundations/index.ts b/src/theme/foundations/index.ts index 05b3824cdc..3e6332ffc5 100644 --- a/src/theme/foundations/index.ts +++ b/src/theme/foundations/index.ts @@ -1,2 +1,3 @@ -export * from './breakpoints'; +export * from './colors'; export * from './sizes'; +export * from './textStyles'; diff --git a/src/theme/foundations/sizes.ts b/src/theme/foundations/sizes.ts index cfde7b2388..7cd50316be 100644 --- a/src/theme/foundations/sizes.ts +++ b/src/theme/foundations/sizes.ts @@ -1,7 +1,8 @@ export const sizes = { container: { - sm: '448px', + sm: '480px', lg: '1096px', - xl: '1200px' + xl: '1200px', + '2xl': '1536px' } }; diff --git a/src/theme/foundations/textStyles.ts b/src/theme/foundations/textStyles.ts new file mode 100644 index 0000000000..fa4bd9b9ae --- /dev/null +++ b/src/theme/foundations/textStyles.ts @@ -0,0 +1,60 @@ +export const textStyles = { + h1: { + fontFamily: '"JetBrains Mono", monospace', + fontWeight: 700, + fontSize: '2.75rem', + lineHeight: '3.375rem', + letterSpacing: '5%', + color: 'brand.light.body' + }, + h2: { + fontFamily: '"JetBrains Mono", monospace', + fontWeight: 400, + fontSize: '1.5rem', + lineHeight: 'auto', + letterSpacing: '4%', + color: 'brand.light.body' + }, + 'homepage-description': { + fontFamily: '"JetBrains Mono", monospace', + fontWeight: 700, + lineHeight: '21px', + letterSpacing: '0.05em', + textAlign: { base: 'center', md: 'left' } + }, + 'homepage-primary-label': { + fontFamily: '"JetBrains Mono", monospace', + color: 'yellow.50', + fontWeight: 700, + textTransform: 'uppercase' + }, + 'home-section-link-label': { + fontFamily: '"JetBrains Mono", monospace', + fontWeight: 700, + textTransform: 'uppercase', + textAlign: 'center', + p: 4 + }, + 'quick-link-text': { + fontFamily: '"Inter", sans-serif', + lineHeight: '26px' + }, + 'quick-link-label': { + fontFamily: '"JetBrains Mono", monospace', + fontWeight: 700, + textTransform: 'uppercase', + textAlign: 'center', + color: 'brand.light.primary', + _groupHover: { color: 'yellow.50' }, + _groupActive: { color: 'yellow.50' }, + _groupFocus: { color: 'yellow.50' } + }, + 'hero-text-small': { + fontSize: '13px', + fontFamily: '"Inter", sans-serif' + }, + // TODO: refactor w/ semantic tokens for light/dark mode + 'link-light': {}, + // TODO: refactor w/ semantic tokens for light/dark mode + 'text-light': {} +}; diff --git a/src/theme/index.ts b/src/theme/index.ts index f9be847dc2..cccdd60e09 100644 --- a/src/theme/index.ts +++ b/src/theme/index.ts @@ -1,10 +1,23 @@ import { extendTheme } from '@chakra-ui/react'; -import { breakpoints, sizes } from './foundations'; +import { colors, sizes, textStyles } from './foundations'; +import { Button, Link } from './components'; const overrides = { - breakpoints, - sizes + colors, + components: { + Button, + Link + }, + sizes, + styles: { + global: () => ({ + body: { + bg: 'yellow.50' + } + }) + }, + textStyles }; export default extendTheme(overrides);