diff --git a/public/images/pages/gopher-downloads-front-light.svg b/public/images/pages/gopher-downloads-front-light.svg new file mode 100644 index 0000000000..41c2984306 --- /dev/null +++ b/public/images/pages/gopher-downloads-front-light.svg @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/public/images/pages/linux-penguin.svg b/public/images/pages/linux-penguin.svg new file mode 100644 index 0000000000..f66b859b43 --- /dev/null +++ b/public/images/pages/linux-penguin.svg @@ -0,0 +1,3 @@ + + + diff --git a/public/images/pages/macos-logo.svg b/public/images/pages/macos-logo.svg new file mode 100644 index 0000000000..6c6180ff5e --- /dev/null +++ b/public/images/pages/macos-logo.svg @@ -0,0 +1,3 @@ + + + diff --git a/public/images/pages/source-branch.svg b/public/images/pages/source-branch.svg new file mode 100644 index 0000000000..0ae94f6e20 --- /dev/null +++ b/public/images/pages/source-branch.svg @@ -0,0 +1,3 @@ + + + diff --git a/public/images/pages/windows-logo.svg b/public/images/pages/windows-logo.svg new file mode 100644 index 0000000000..13729fe7ff --- /dev/null +++ b/public/images/pages/windows-logo.svg @@ -0,0 +1,3 @@ + + + diff --git a/src/components/UI/DataTable.tsx b/src/components/UI/DataTable.tsx new file mode 100644 index 0000000000..c1a260293b --- /dev/null +++ b/src/components/UI/DataTable.tsx @@ -0,0 +1,95 @@ +import { + Table, + Thead, + Tr, + Th, + TableContainer, + Text, + Tbody, + Td, +} from '@chakra-ui/react'; +import { FC } from 'react'; + +interface Props { + columnHeaders: string[] + data: any +} + +export const DataTable: FC = ({ + columnHeaders, + data, +}) => { + return ( + + + + + { + columnHeaders.map((columnHeader, idx) => { + return ( + + ) + }) + } + + + + { + data.map((item: any, idx: number) => { + return ( + + { + columnHeaders.map((columnHeader, idx) => { + // TODO: Make the font size smaller (refer to design system) + return ( + + ) + }) + } + + ) + }) + } + +
+ + {columnHeader} + +
+ {item[columnHeader.toLowerCase()]} +
+ + ) +} \ No newline at end of file diff --git a/src/components/UI/downloads/DownloadsHero.tsx b/src/components/UI/downloads/DownloadsHero.tsx new file mode 100644 index 0000000000..67b30355be --- /dev/null +++ b/src/components/UI/downloads/DownloadsHero.tsx @@ -0,0 +1,107 @@ +import { Box, Button, Image, Link, Stack, HStack, Text } from '@chakra-ui/react'; +import { FC } from 'react'; +import NextLink from 'next/link'; + +import { DOWNLOAD_HEADER_BUTTONS } from '../../../constants' + +interface DownloadsHero { + currentBuildName: string + currentBuildVersion: string + linuxBuildURL: string + macOSBuildURL: string + releaseNotesURL: string + sourceCodeURL: string + windowsBuildURL: string +} + +export const DownloadsHero: FC = ({ + currentBuildName, + currentBuildVersion, + linuxBuildURL, + macOSBuildURL, + releaseNotesURL, + sourceCodeURL, + windowsBuildURL +}) => { + DOWNLOAD_HEADER_BUTTONS.linuxBuild.buildURL = linuxBuildURL + DOWNLOAD_HEADER_BUTTONS.macOSBuild.buildURL = macOSBuildURL + DOWNLOAD_HEADER_BUTTONS.windowsBuild.buildURL = windowsBuildURL + DOWNLOAD_HEADER_BUTTONS.sourceCode.buildURL = sourceCodeURL + + return ( + + + Gopher plugged in + + + + + Download go-ethereum + + + + {currentBuildName} ({currentBuildVersion}) + + + + You can download the latest 64-bit stable release of Geth for our primary platforms below. Packages for all supported platforms, as well as develop builds, can be found further down the page. If you're looking to install Geth and/or associated tools via your favorite package manager, please check our installation guide. + + + { + Object.keys(DOWNLOAD_HEADER_BUTTONS).map((key: string) => { + return ( + + + + ) + }) + } + + + + Release notes for {currentBuildName} {currentBuildVersion} + + + + + ); +}; diff --git a/src/components/UI/downloads/DownloadsSection.tsx b/src/components/UI/downloads/DownloadsSection.tsx new file mode 100644 index 0000000000..5e0fdf26a2 --- /dev/null +++ b/src/components/UI/downloads/DownloadsSection.tsx @@ -0,0 +1,44 @@ +import { Box, Image, Stack } from '@chakra-ui/react'; +import { FC } from 'react'; + +interface Props { + children: React.ReactNode; + id: string; + imgSrc?: string; + imgAltText?: string; + sectionTitle: string +} + +export const DownloadsSection: FC = ({ + children, + imgSrc, + imgAltText, + sectionTitle, + id +}) => { + return ( + + {!!imgSrc && ( + + {/* TODO: use NextImage */} + {imgAltText} + + )} + + + + {sectionTitle} + + + + + {children} + + + ) +} \ No newline at end of file diff --git a/src/components/UI/downloads/DownloadsTable.tsx b/src/components/UI/downloads/DownloadsTable.tsx new file mode 100644 index 0000000000..6fc7288b35 --- /dev/null +++ b/src/components/UI/downloads/DownloadsTable.tsx @@ -0,0 +1,99 @@ +import { + Stack, + Tabs, + TabList, + Tab, + Text, + TabPanel, + TabPanels, +} from '@chakra-ui/react'; +import { FC } from 'react'; + +import { + DOWNLOAD_TABS, + DOWNLOAD_TAB_COLUMN_HEADERS +} from '../../../constants' + +import { DataTable } from '../DataTable' + +interface Props { + data: any +} + +export const DownloadsTable: FC = ({ + data +}) => { + return ( + + + + { + DOWNLOAD_TABS.map((tab, idx) => { + return ( + + + {tab} + + + ) + }) + } + + + + + + + + + + + + + + + + + + + + + ) +} \ No newline at end of file diff --git a/src/components/UI/downloads/index.ts b/src/components/UI/downloads/index.ts new file mode 100644 index 0000000000..597af494c8 --- /dev/null +++ b/src/components/UI/downloads/index.ts @@ -0,0 +1,3 @@ +export * from './DownloadsHero'; +export * from './DownloadsSection' +export * from './DownloadsTable' \ No newline at end of file diff --git a/src/constants.ts b/src/constants.ts index fdca5bca65..7e80dc5e7f 100644 --- a/src/constants.ts +++ b/src/constants.ts @@ -12,3 +12,61 @@ export const GETH_REPO_URL = 'https://github.com/ethereum/go-ethereum'; export const GETH_TWITTER_URL = 'https://twitter.com/go_ethereum'; export const GETH_DISCORD_URL = 'https://discord.com/invite/nthXNEv'; export const GO_URL = 'https://go.dev/'; + +// Downloads +export const DEFAULT_BUILD_AMOUNT_TO_SHOW = 10; +export const DOWNLOAD_HEADER_BUTTONS: {[index: string]: {name: string; image: string; imageAlt: string; buildURL: string;}} = { + linuxBuild: { + name: 'Linux', + image: '/images/pages/linux-penguin.svg', + imageAlt: 'Linux logo', + buildURL: '' + }, + macOSBuild: { + name: 'macOS', + image: '/images/pages/macos-logo.svg', + imageAlt: 'macOS logo', + buildURL: '' + }, + windowsBuild: { + name: 'Windows', + image: '/images/pages/windows-logo.svg', + imageAlt: 'Windows logo', + buildURL: '' + }, + sourceCode: { + name: 'Sources', + image: '/images/pages/source-branch.svg', + imageAlt: 'Source branch logo', + buildURL: '' + } +} +export const DOWNLOAD_TABS = [ + 'Linux', + 'macOS', + 'Windows', + 'iOS', + 'Android' +] +export const DOWNLOAD_TAB_COLUMN_HEADERS = [ + 'Release', + 'Commit', + 'Kind', + 'Arch', + 'Size', + 'Published', + 'Signature', + 'Checksum (MD5)' +] +export const DOWNLOAD_OPENPGP_BUILD_HEADERS = [ + 'Build Server', + 'Unique ID', + 'OpenPGP Key', + 'Fingerprint' +] +export const DOWNLOAD_OPENPGP_DEVELOPER_HEADERS = [ + 'Developer', + 'Unique ID', + 'OpenPGP Key', + 'Fingerprint' +] \ No newline at end of file diff --git a/src/data/test/download-testdata.ts b/src/data/test/download-testdata.ts new file mode 100644 index 0000000000..910e7c1936 --- /dev/null +++ b/src/data/test/download-testdata.ts @@ -0,0 +1,122 @@ +export const testDownloadData = [ + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, + { + release: 'Geth 1.10.23', + commit: 'd901d853…', + kind: 'archive', + arch: '64-bit', + size: '11.71 MB', + published: 'Last Wednesday at 11:11 AM', + signature: 'Signature', + "checksum (md5)": 'c93b0339413a8f2b95aa4b23b32d64af' + }, +] \ No newline at end of file diff --git a/src/data/test/pgpbuild-testdata.ts b/src/data/test/pgpbuild-testdata.ts new file mode 100644 index 0000000000..a016016edf --- /dev/null +++ b/src/data/test/pgpbuild-testdata.ts @@ -0,0 +1,32 @@ +export const pgpBuildTestData = [ + { + "build server": "Android Builder", + "unique id": "Go Ethereum Android Builder ", + "openpgp key": "F9585DE6", + "fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6" + }, + { + "build server": "iOS Builder", + "unique id": "Go Ethereum iOS Builder ", + "openpgp key": "F9585DE6", + "fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6" + }, + { + "build server": "Linux Builder", + "unique id": "Go Ethereum Linux Builder ", + "openpgp key": "F9585DE6", + "fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6" + }, + { + "build server": "macOS Builder", + "unique id": "Go Ethereum macOS Builder ", + "openpgp key": "F9585DE6", + "fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6" + }, + { + "build server": "Windows Builder", + "unique id": "Go Ethereum Windows Builder ", + "openpgp key": "F9585DE6", + "fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6" + }, +] \ No newline at end of file diff --git a/src/data/test/pgpdeveloper-testdata.ts b/src/data/test/pgpdeveloper-testdata.ts new file mode 100644 index 0000000000..85d16adfd6 --- /dev/null +++ b/src/data/test/pgpdeveloper-testdata.ts @@ -0,0 +1,20 @@ +export const pgpDeveloperTestData = [ + { + "developer": "Felix Lange", + "unique id": "Felix Lange ", + "openpgp key": "F9585DE6", + "fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6" + }, + { + "developer": "Martin Holst Swende", + "unique id": "Martin Holst Swende ", + "openpgp key": "F9585DE6", + "fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6" + }, + { + "developer": "Péter Szilágyi", + "unique id": "Péter Szilágyi ", + "openpgp key": "F9585DE6", + "fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6" + }, +] \ No newline at end of file diff --git a/src/pages/docs/developers/dapp-developer/native-bindings.md b/src/pages/docs/developers/dapp-developer/native-bindings.md index e56bde9c6c..a682792fa4 100644 --- a/src/pages/docs/developers/dapp-developer/native-bindings.md +++ b/src/pages/docs/developers/dapp-developer/native-bindings.md @@ -1,6 +1,6 @@ --- title: Go Contract Bindings -description: Intriduction to generating bindings for using Geth features in Go native applications +description: Introduction to generating bindings for using Geth features in Go native applications --- This page introduces the concept of server-side native dapps. Geth provides the tools required to generate [Go](https://github.com/golang/go/wiki#getting-started-with-go) language bindings to any Ethereum contract that is compile-time type safe, highly performant and can be generated completely automatically from a compiled contract. diff --git a/src/pages/docs/developers/geth-developer/dns-discovery-setup.md b/src/pages/docs/developers/geth-developer/dns-discovery-setup.md index 685b842886..90f7d78645 100644 --- a/src/pages/docs/developers/geth-developer/dns-discovery-setup.md +++ b/src/pages/docs/developers/geth-developer/dns-discovery-setup.md @@ -57,7 +57,7 @@ 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. +- `-eth-network ( mainnet | sepolia | goerli )` selects an Ethereum network. - `-les-server` selects LES server nodes. - `-ip ` restricts nodes to the given IP range. - `-min-age ` restricts the result to nodes which have been live for the diff --git a/src/pages/docs/developers/geth-developer/private-network.md b/src/pages/docs/developers/geth-developer/private-network.md index 560c543930..eade1a89d4 100644 --- a/src/pages/docs/developers/geth-developer/private-network.md +++ b/src/pages/docs/developers/geth-developer/private-network.md @@ -23,7 +23,7 @@ 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: +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. The key differences between the consensus algorithms available in Geth are: #### Ethash diff --git a/src/pages/docs/developers/index.md b/src/pages/docs/developers/index.md new file mode 100644 index 0000000000..8c64ddd20a --- /dev/null +++ b/src/pages/docs/developers/index.md @@ -0,0 +1,16 @@ +--- +title: Developer docs +description: Documentation for Geth developers and dapp developers +--- + +Welcome to the Geth Developer docs! + +This section includes information for builders. If you are building decentralized apps on top of Geth, head to the `dapp-developer` docs. If you are developing Geth itself, explore the `geth-developer` docs. + +## Dapp developers + +Geth has many features that support dapp developers. There are many built-in tracers implemented in Go or Javascript that allow developers to monitor what is happening in Geth from inside an app, and users can build their own custom tracers too. Geth also includes a suite of tools for interacting with Ethereum smart contracts using Geth functions using Go functions inside Go native applications. There is also information for Geth mobile developers. + +## Geth developers + +Geth developers add/remove features and fix bugs in Geth. The `geth-developer` section includes contribution guidelines and documentation relating to testing and disclosing vulnerabilities that willhep you get started with working on Geth. diff --git a/src/pages/docs/fundamentals/command-line-options.md b/src/pages/docs/fundamentals/command-line-options.md index 57aed02a1e..5dfbcd54d5 100644 --- a/src/pages/docs/fundamentals/command-line-options.md +++ b/src/pages/docs/fundamentals/command-line-options.md @@ -55,7 +55,7 @@ ETHEREUM OPTIONS: --keystore value Directory for the keystore (default = inside the datadir) --usb Enable monitoring and management of USB hardware wallets --pcscdpath value Path to the smartcard daemon (pcscd) socket file - --networkid value Explicitly set network id (integer)(For testnets: use --ropsten, --rinkeby, --goerli instead) (default: 1) + --networkid value Explicitly set network id (integer)(For testnets: use --sepolia, --goerli instead) (default: 1) --syncmode value Blockchain sync mode ("snap", "full" or "light") (default: snap) --exitwhensynced Exits after block synchronisation completes --gcmode value Blockchain garbage collection mode ("full", "archive") (default: "full") @@ -65,11 +65,8 @@ ETHEREUM OPTIONS: --lightkdf Reduce key-derivation RAM & CPU usage at some expense of KDF strength --eth.requiredblocks value Comma separated block number-to-hash mappings to require for peering (=) --mainnet Ethereum mainnet - --ropsten Ropsten network: pre-configured proof-of-stake test network - --rinkeby Rinkeby network: pre-configured proof-of-authority test network --goerli Görli network: pre-configured proof-of-authority test network --sepolia Sepolia network: pre-configured proof-of-work test network - --kiln Kiln network: pre-configured proof-of-work to proof-of-stake test network --datadir value Data directory for the databases and keystore (default: "~/.ethereum") --datadir.ancient value Data directory for ancient chain segments (default = inside chaindata) --remotedb value URL for remote database diff --git a/src/pages/docs/fundamentals/index.md b/src/pages/docs/fundamentals/index.md new file mode 100644 index 0000000000..7b9dcb38a5 --- /dev/null +++ b/src/pages/docs/fundamentals/index.md @@ -0,0 +1,15 @@ +--- +title: Geth fundamentals +description: Documentation for foundational Geth topics +--- + +## Geth fundamentals + +This section includes documentation for foundational topics in Geth. The pages here will help you to understand how Geth works from a user perspective and under the hood. + +This is where you will find information about how to manage a Geth node and understand how it functions. + +For example, the pages here will help you to understand the underlying architecture of your Geth node, how to start it in different configurations using command line options, how to sync the blockchain and how to manage accounts. There is a page on security practices that will help you to keep your Geth node safe from adversaries. + +Note also that there is a page explaining common log messages that are often queried on the Geth discord and Github - this will help users to interpret the messages displayed to the console and know what actions to take. + diff --git a/src/pages/docs/fundamentals/logs.md b/src/pages/docs/fundamentals/logs.md index a6c09d122c..75c9213767 100644 --- a/src/pages/docs/fundamentals/logs.md +++ b/src/pages/docs/fundamentals/logs.md @@ -128,7 +128,7 @@ INFO [07-28|10:30:18.658] Imported new block headers count=1 el INFO [07-28|10:30:21.665] Imported new state entries ``` -For state sync, Geth reports when the state heal is in progress. This can takea long time. The log message includes values for the number of `accounts`, `slots`, `codes` and `nodes` that were downloaded in the current healing phase, and the pending field is the number of state entires waiting to be downloaded. The `pending` value is not necessarily the number of state entries remaining until the healing is finished. As the blockchain progresses the state trie is updated and therefore the data that needs to be downloaded to heal the trie can increase as well as decrease over time. Ultimately, the state should heal faster than the blockchain progresses so the node can get in sync. When the state healing is finished there is a post-sync snapshot generation phase. The node is not in sync until the state healing phase is over. +For state sync, Geth reports when the state heal is in progress. This can takea long time. The log message includes values for the number of `accounts`, `slots`, `codes` and `nodes` that were downloaded in the current healing phase, and the pending field is the number of state entires waiting to be downloaded. The `pending` value is not necessarily the number of state entries remaining until the healing is finished. As the blockchain progresses the state trie is updated and therefore the data that needs to be downloaded to heal the trie can increase as well as decrease over time. Ultimately, the state should heal faster than the blockchain progresses so the node can get in sync. When the state healing is finished there is a post-sync snapshot generation phase. The node is not in sync until the state healing phase is over. If the node is still regularly reporting `State heal in progress` it is not yet in sync - the state healing is still ongoing. ``` INFO [07-28|10:30:21.965] State heal in progress accounts=169,633@7.48MiB slots=57314@4.17MiB codes=4895@38.14MiB nodes=43,293,196@11.70GiB pending=112,626 @@ -136,6 +136,30 @@ INFO [09-06|01:31:59.885] Rebuilding state snapshot INFO [09-06|01:31:59.910] Resuming state snapshot generation root=bc64d4..fc1edd accounts=0 slots=0 storage=0.00B dangling=0 elapsed=18.838ms ``` +The sync can be confirmed using [`eth.syncing`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_syncing) - it will return `false` if the node is in sync. If `eth.syncing` returns anything other than `false` it has not finished syncing. Generally, if syncing is still ongoing, `eth.syncing` will return block info that looks as follows: + +```json +> eth.sycing +{ + currentBlock: 15285946, + healedBytecodeBytes: 991164713, + healedBytecodes: 130880, + healedTrienodeBytes: 489298493475, + healedTrienodes: 1752917331, + healingBytecode: 0, + healingTrienodes: 1745, + highestBlock: 16345003, + startingBlock: 12218525, + syncedAccountBytes: 391561544809, + syncedAccounts: 136498212, + syncedBytecodeBytes: 2414143936, + syncedBytecodes: 420599, + syncedStorage: 496503178, + syncedStorageBytes: 103368240246 +} +``` + + There are other log messages that are commonly seen during syncing. For example: ```sh @@ -183,6 +207,12 @@ WARN [10-03 |13:10:26.499] Beacon client online, but never received consensus up The message above indicates that a consensus client is present but not working correctly. The most likely reason for this is that the client is not yet in sync. Waiting for the consensus client to sync should solve the issue. + +```sh +WARN [10-03 | 13:15:56.543] Dropping unsynced node during sync id = e2fdc0d92d70953 conn = ... +``` +This message indicates that a peer is being dropped because it is not fully synced. This is normal - the necessary data will be requested from an alternative peer instead. + ## 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). diff --git a/src/pages/docs/fundamentals/sync-modes.md b/src/pages/docs/fundamentals/sync-modes.md index 3fc9b1a47d..abec82faa6 100644 --- a/src/pages/docs/fundamentals/sync-modes.md +++ b/src/pages/docs/fundamentals/sync-modes.md @@ -3,7 +3,7 @@ title: Sync modes description: Introduction to Geth's sync modes --- -Syncing is the process by which Geth catches up to the latest Ethereum block and current global state. There are several ways to sync a Geth node that differ in their speed, storage requirements and trust assumptions. This page outlines three sync configurations for full nodes and one for light nodes. +Syncing is the process by which Geth catches up to the latest Ethereum block and current global state. There are several ways to sync a Geth node that differ in their speed, storage requirements and trust assumptions. Now that Ethereum uses proof-of-stake based consensus, a consensus client is required for Geth to sync. ## Full nodes @@ -13,7 +13,8 @@ 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. Geth regularly reports `Syncing, state heal in progress` regularly during state heal - this informs the user that state heal has not finished. It is also possible to confirm this using `eth.syncing` - if this command returns `false` then the node is in sync. If it returns anything other than `false` then syncing is still in progress. + 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: @@ -22,8 +23,10 @@ To summarize, snap sync progresses in the following sequence: - download block bodies and receipts. In parallel, download raw state data and build state trie - heal state trie to account for newly arriving data + **Note** Snap sync is the default behaviour, so if the `--syncmode` value is not passed to Geth at startup, Geth will use snap sync. A node that is started using `snap` will switch to block-by-block sync once it has caught up to the head of the chain. + ### 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. @@ -38,13 +41,13 @@ It is also possible to create a partial/recent archive node where the node was s ## 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. 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 receive a proof from the full node and verify it against their local header chain. 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 receive a proof from the full node and verify it against their local header chain. 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. **Light nodes are not currently working on proof-of-stake Ethereum**. 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. **Geth cannot sync without being connected to a consensus client**. This includes block-by-block syncing from genesis. 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. @@ -58,9 +61,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 another 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](https://eth-clients.github.io/checkpoint-sync-endpoints/). + +Please see the pages on [syncing](/docs/interface/sync-modes.md) for more detail. For troubleshooting, please see the `Syncing` section on the [console log messages](/docs/interface/logs.md) page. -**Note** it is not currently possible to use a Geth light node as an execution client on proof-of-stake Ethereum. ## Summary diff --git a/src/pages/docs/getting-started/consensus-clients.md b/src/pages/docs/getting-started/consensus-clients.md index d38e544a93..0b821d2c44 100644 --- a/src/pages/docs/getting-started/consensus-clients.md +++ b/src/pages/docs/getting-started/consensus-clients.md @@ -47,6 +47,12 @@ The consensus clients all expose a [Beacon API](https://ethereum.github.io/beaco Validators are responsible for securing the Ethereum blockchain. Validators have staked at least 32 ETH into a deposit contract and run validator software. Each of the consensus clients have their own validator software that is described in detail in their respective documentation. The easiest way to handle staking and validator key generation is to use the Ethereum Foundation [Staking Launchpad](https://launchpad.ethereum.org/). The Launchpad guides users through the process of generating validator keys and connecting the validator to the consensus client. +## Syncing + +Geth cannot sync until the connected consensus client is synced. This is because Geth needs a target head to sync to. The fastest way to sync a consensus client is using checkpoint sync. To do this, a checkpoint or a url to a checkpoint provider can be provided to the consensus client on startup. There are several sources for these checkpoints. The ideal scenario is to get one from a trusted node operator, organized out-of-band, and verified against a third node or a block explorer or checkpoint provider. Some clients also allow checkpoint syncing by HTTP API access to an existing Beacon node. There are also several [public checkpoint sync endpoints](https://eth-clients.github.io/checkpoint-sync-endpoints/). + +Please see the pages on [syncing](/src/pages/docs/fundamentals/sync-modes.md) for more detail. For troubleshooting, please see the `Syncing` section on the [console log messages](/src/pages/docs/fundamentals/logs.md) page. + ## 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 diff --git a/src/pages/docs/index.md b/src/pages/docs/index.md index b613f1e432..8342de6655 100644 --- a/src/pages/docs/index.md +++ b/src/pages/docs/index.md @@ -10,11 +10,11 @@ These documentation pages are intended to help users download, install and use G ## Where to go from here -First, make sure you have sufficient [hardware](/pages/docs/getting-started/hardware-requirements.md), then [download](/pages/downloads) and [install](/pages/docs/getting-started/installing-geth.md) Geth. Make sure you are familiar with the [security considerations](/pages/docs/fundamentals/security.md) and have your firewall set up. +First, make sure you have sufficient [hardware](/pages/docs/getting-started/hardware-requirements), then [download](/pages/downloads) and [install](/pages/docs/getting-started/installing-geth) Geth. Make sure you are familiar with the [security considerations](/pages/docs/fundamentals/security) and have your firewall set up. -If you are just starting out with Geth, head to the [Getting started](src/pages/docs/getting-started/getting-started.md) page. That page guides a new user through some basic functions of Geth such as creating and securing accounts and making a transaction using Geth's built-in account tools. +If you are just starting out with Geth, head to the [Getting started](src/pages/docs/getting-started/getting-started) page. That page guides a new user through some basic functions of Geth such as creating and securing accounts and making a transaction using Geth's built-in account tools. -A more secure but slightly more advanced setup is to use an external signer instead of Geth's built-in account manager. We have a [getting started](src/pages/docs/getting-started/getting-started-with-clef.md) guide for that too. +A more secure but slightly more advanced setup is to use an external signer instead of Geth's built-in account manager. We have a [getting started](src/pages/docs/getting-started/getting-started-with-clef) guide for that too. Then, it is recommended to read the material in the [Fundamentals](src/pages/docs/fundamentals) section - these pages will help build a foundational understanding of how Geth works from a user perspective and under the hood. @@ -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. +We have a library of videos and articles on our [Resources](/pages/docs/resources) page and answers to common questions on the [FAQs](/pages/docs/faq) page. diff --git a/src/pages/docs/interacting-with-geth/rpc/server.md b/src/pages/docs/interacting-with-geth/rpc/index.md similarity index 100% rename from src/pages/docs/interacting-with-geth/rpc/server.md rename to src/pages/docs/interacting-with-geth/rpc/index.md diff --git a/src/pages/docs/interacting-with-geth/rpc/ns-eth.md b/src/pages/docs/interacting-with-geth/rpc/ns-eth.md index b610e41afb..e10aa1279a 100644 --- a/src/pages/docs/interacting-with-geth/rpc/ns-eth.md +++ b/src/pages/docs/interacting-with-geth/rpc/ns-eth.md @@ -3,7 +3,8 @@ title: eth Namespace description: Documentation for the JSON-RPC API "eth" namespace --- -Geth provides several extensions to the standard "eth" JSON-RPC namespace. + +Documentation for the API methods in the `eth` namespace can be found on [ethereum.org](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_protocolversion). Geth provides several extensions to the standard "eth" JSON-RPC namespace that are defined below. ### eth_subscribe, eth_unsubscribe @@ -64,6 +65,7 @@ Example: The method returns a single `Binary` consisting the return value of the executed contract call. #### Simple example +**note that this example uses the Rinkeby network, which is now deprecated** With a synced Rinkeby node with RPC exposed on localhost (`geth --rinkeby --http`) we can make a call against the [CheckpointOracle](https://rinkeby.etherscan.io/address/0xebe8efa441b9302a0d7eaecc277c09d20d684540) to retrieve the list of administrators: diff --git a/src/pages/docs/resources.md b/src/pages/docs/resources.md index 76fa404a0a..adaac2792f 100644 --- a/src/pages/docs/resources.md +++ b/src/pages/docs/resources.md @@ -13,6 +13,10 @@ Here are more resources for a deeper understanding of Geth and related topics. ## Watch +[Geth team AMA at Devcon 6, Bogota](https://youtu.be/Wr_SHOmz4lc?t=10714) + +[Sina's EVM tracing workshop at Devcon 6, Bogota](https://youtu.be/b8RdmGsilfU) + [Péter at ETH Prage 2022: Ethereum in numbers: where TPS meets physics](https://www.youtube.com/watch?v=TdsaVoJiy3g) [Marius at ETH Amsterdam 2022: Deep dive into Geth](https://www.youtube.com/watch?v=c4N79UXZqSc) diff --git a/src/pages/docs/tools/devp2p.md b/src/pages/docs/tools/devp2p.md index 05623e76fa..f22fa0366d 100644 --- a/src/pages/docs/tools/devp2p.md +++ b/src/pages/docs/tools/devp2p.md @@ -62,7 +62,7 @@ Run `devp2p nodeset filter ` to write a new, filte - `-limit ` limits the output set to N entries, taking the top N nodes by score - `-ip ` filters nodes by IP subnet - `-min-age ` filters nodes by 'first seen' time -- `-eth-network ` filters nodes by "eth" ENR entry +- `-eth-network ` filters nodes by "eth" ENR entry - `-les-server` filters nodes by LES server support - `-snap` filters nodes by snap protocol support diff --git a/src/pages/downloads.md b/src/pages/downloads.md deleted file mode 100644 index 0f700ee2a1..0000000000 --- a/src/pages/downloads.md +++ /dev/null @@ -1 +0,0 @@ -beep diff --git a/src/pages/downloads.tsx b/src/pages/downloads.tsx new file mode 100644 index 0000000000..72c098f71b --- /dev/null +++ b/src/pages/downloads.tsx @@ -0,0 +1,229 @@ +import { + Code, + Link, + ListItem, + Stack, + Text, + UnorderedList, +} from '@chakra-ui/react'; +import type { NextPage } from 'next'; +import { useState } from 'react' + +import { + DownloadsHero, + DownloadsSection, + DownloadsTable, +} from '../components/UI/downloads'; +import { DataTable } from '../components/UI/DataTable'; + +import { + DEFAULT_BUILD_AMOUNT_TO_SHOW, + DOWNLOAD_OPENPGP_BUILD_HEADERS, + DOWNLOAD_OPENPGP_DEVELOPER_HEADERS, + GETH_REPO_URL +} from '../constants' + +import { testDownloadData } from '../data/test/download-testdata' +import { pgpBuildTestData } from '../data/test/pgpbuild-testdata'; +import { pgpDeveloperTestData } from '../data/test/pgpdeveloper-testdata'; + +const DownloadsPage: NextPage = () => { + const [amountStableReleases, updateAmountStables] = useState(DEFAULT_BUILD_AMOUNT_TO_SHOW) + const [amountDevelopBuilds, updateAmountDevelopBuilds] = useState(DEFAULT_BUILD_AMOUNT_TO_SHOW) + + const showMoreStableReleases = () => { + updateAmountStables(amountStableReleases+10) + } + + const showMoreDevelopBuilds = () => { + updateAmountDevelopBuilds(amountDevelopBuilds+10) + } + + return ( + <> + {/* TODO: add PageMetadata */} + +
+ + {/* TODO: replace hardcoded strings with build information */} + + + + + + If you're looking for a specific release, operating system or architecture, below you will find: + + + + + + All stable and develop builds of Geth and tools + + + + + Archives for non-primary processor architectures + + + + + Android library archives and iOS XCode frameworks + + + + + + Please select your desired platform from the lists below and download your bundle of choice. Please be aware that the MD5 checksums are provided by our binary hosting platform (Azure Blobstore) to help check for download errors. For security guarantees please verify any downloads via the attached PGP signature files (see{' '} + + OpenPGP + {' '} + Signatures for details). + + + + + + + + These are the current and previous stable releases of go-ethereum, updated automatically when a new version is tagged in our{' '} + + GitHub repository. + + + + + {/* TODO: swap test data for real data */} + + + + + + Show older releases + + + + + + + + + These are the develop snapshots of go-ethereum, updated automatically when a new commit is pushed into our{' '} + + GitHub repository. + + + + + {/* TODO: swap for real data */} + + + + + + Show older releases + + + + + + + + + All the binaries available from this page are signed via our build server PGP keys: + + + + {/* TODO: swap for real data */} + + + + + {/* TODO: swap for real data */} + + + + + + + + + You can import the build server public keys by grabbing the individual keys directly from the keyserver network: + + + {/* TODO: These keys depends on the binary */} + + gpg --recv-keys F9585DE6 C2FF8BBF 9BA28146 7B9E2481 D2A67EAC + + + + + + Similarly you can import all the developer public keys by grabbing them directly from the keyserver network: + + + {/* TODO: These are developer keys, do we need to change? */} + + gpg --recv-keys E058A81C 05A5DDF0 1CCB7DD2 + + + + + + From the download listings above you should see a link both to the downloadable archives as well as detached signature files. To verify the authenticity of any downloaded data, grab both files and then run: + + + {/* TODO: These keys depends on the binary */} + + gpg --verify geth-linux-amd64-1.5.0-d0c820ac.tar.gz.asc + + + + +
+ + ) +} + +export default DownloadsPage \ No newline at end of file diff --git a/src/theme/foundations/index.ts b/src/theme/foundations/index.ts index 3e6332ffc5..b18404055e 100644 --- a/src/theme/foundations/index.ts +++ b/src/theme/foundations/index.ts @@ -1,3 +1,4 @@ export * from './colors'; +export * from './shadows'; export * from './sizes'; export * from './textStyles'; diff --git a/src/theme/foundations/shadows.ts b/src/theme/foundations/shadows.ts new file mode 100644 index 0000000000..d870a80e6b --- /dev/null +++ b/src/theme/foundations/shadows.ts @@ -0,0 +1,3 @@ +export const shadows = { + linkBoxShadow: '0 0 0 1px #11866f !important' +} \ No newline at end of file diff --git a/src/theme/foundations/textStyles.ts b/src/theme/foundations/textStyles.ts index f5d381ee0b..75238fb899 100644 --- a/src/theme/foundations/textStyles.ts +++ b/src/theme/foundations/textStyles.ts @@ -59,6 +59,19 @@ export const textStyles = { fontWeight: 400, fontSize: '12px' }, + 'downloads-button-label': { + fontFamily:'"JetBrains Mono", monospace', + color:'yellow.50', + fontSize:'xs', + textTransform:'uppercase', + }, + 'download-tab-label': { + fontFamily: '"JetBrains Mono", monospace', + fontWeight: 700, + textTransform: 'uppercase', + textAlign: 'center', + fontSize: 'sm', + }, // TODO: refactor w/ semantic tokens for light/dark mode 'link-light': {}, // TODO: refactor w/ semantic tokens for light/dark mode diff --git a/src/theme/index.ts b/src/theme/index.ts index cccdd60e09..746344cbd2 100644 --- a/src/theme/index.ts +++ b/src/theme/index.ts @@ -1,6 +1,6 @@ import { extendTheme } from '@chakra-ui/react'; -import { colors, sizes, textStyles } from './foundations'; +import { colors, shadows, sizes, textStyles } from './foundations'; import { Button, Link } from './components'; const overrides = { @@ -9,6 +9,7 @@ const overrides = { Button, Link }, + shadows, sizes, styles: { global: () => ({