Merge branch 'master' into footer

pull/26459/head^2
Corwin Smith 2 years ago committed by GitHub
commit e682ab41e3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
  1. 9
      public/images/pages/gopher-downloads-front-light.svg
  2. 3
      public/images/pages/linux-penguin.svg
  3. 3
      public/images/pages/macos-logo.svg
  4. 3
      public/images/pages/source-branch.svg
  5. 3
      public/images/pages/windows-logo.svg
  6. 95
      src/components/UI/DataTable.tsx
  7. 107
      src/components/UI/downloads/DownloadsHero.tsx
  8. 44
      src/components/UI/downloads/DownloadsSection.tsx
  9. 99
      src/components/UI/downloads/DownloadsTable.tsx
  10. 3
      src/components/UI/downloads/index.ts
  11. 58
      src/constants.ts
  12. 122
      src/data/test/download-testdata.ts
  13. 32
      src/data/test/pgpbuild-testdata.ts
  14. 20
      src/data/test/pgpdeveloper-testdata.ts
  15. 2
      src/pages/docs/developers/dapp-developer/native-bindings.md
  16. 2
      src/pages/docs/developers/geth-developer/dns-discovery-setup.md
  17. 2
      src/pages/docs/developers/geth-developer/private-network.md
  18. 16
      src/pages/docs/developers/index.md
  19. 5
      src/pages/docs/fundamentals/command-line-options.md
  20. 15
      src/pages/docs/fundamentals/index.md
  21. 32
      src/pages/docs/fundamentals/logs.md
  22. 16
      src/pages/docs/fundamentals/sync-modes.md
  23. 6
      src/pages/docs/getting-started/consensus-clients.md
  24. 8
      src/pages/docs/index.md
  25. 0
      src/pages/docs/interacting-with-geth/rpc/index.md
  26. 4
      src/pages/docs/interacting-with-geth/rpc/ns-eth.md
  27. 4
      src/pages/docs/resources.md
  28. 2
      src/pages/docs/tools/devp2p.md
  29. 1
      src/pages/downloads.md
  30. 229
      src/pages/downloads.tsx
  31. 1
      src/theme/foundations/index.ts
  32. 3
      src/theme/foundations/shadows.ts
  33. 13
      src/theme/foundations/textStyles.ts
  34. 3
      src/theme/index.ts

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 419 KiB

@ -0,0 +1,3 @@
<svg width="27" height="36" viewBox="0 0 27 36" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M26.305 28.2798C25.4843 27.6294 25.8036 26.1929 24.9516 25.4842C25.7768 20.5769 23.4638 16.2515 20.7061 13.4792C18.3916 11.1531 19.1378 8.88979 19.1378 6.93125C19.1378 3.80167 17.8231 0.5 13.8403 0.5C9.5829 0.5 8.41597 3.97083 8.37418 5.95125C8.27271 10.7083 9.35758 11.945 6.50887 15.4071C3.15729 19.4802 2.66335 23.5431 3.41992 25.6985C3.06626 26.101 2.58874 26.5473 1.69637 26.9163C-0.768819 27.9663 1.03829 29.7235 0.356336 30.9704C0.162343 31.3248 0.0698242 31.6952 0.0698242 32.0496C0.0698242 33.1433 0.959204 34.0898 2.57531 33.9483C4.75548 33.7588 6.76703 35.2681 8.06827 35.2681C9.2173 35.2681 10.1604 34.6294 10.5991 33.75C12.654 33.2556 15.1908 33.3183 17.2441 33.836C17.6127 34.8438 18.6125 35.5 19.7242 35.5C22.1581 35.5 22.6266 32.8035 25.4186 31.8906C26.4244 31.5625 26.9303 30.6088 26.9303 29.7206C26.9303 29.1519 26.7229 28.6108 26.305 28.2798ZM12.6554 13.0183C12.1794 13.0183 11.7855 12.6421 11.1632 12.19C10.3753 11.6183 9.57395 11.2888 9.58291 10.6879C9.58291 10.2752 10.1485 10.1483 10.8797 9.69479C11.6646 9.20917 11.9705 8.71625 12.7435 8.71625C13.5344 8.71625 13.7731 9.10708 14.8476 9.56063C15.9041 10.0083 16.6397 10.1833 16.6397 10.6879C16.6397 11.2056 15.534 11.576 14.9117 11.9538C13.997 12.505 13.5269 13.0183 12.6554 13.0183ZM15.14 5.41313C16.4562 5.61875 16.6039 7.87917 15.9742 8.99187L15.4445 8.78042C15.719 7.98854 15.7146 6.68479 14.7953 6.60167C14.2119 6.54917 13.8358 7.30167 13.7552 7.94625C13.5269 7.85292 13.2777 7.78583 12.9748 7.76104C13.0673 6.415 13.9567 5.22792 15.14 5.41313ZM10.0619 5.89583C11.0707 5.65083 11.6661 6.79708 11.6706 7.98854L11.208 8.26562C11.1453 7.76542 10.917 6.9575 10.344 7.12958C9.73064 7.31625 9.83062 8.70896 10.1723 8.99479L9.71572 9.24271C9.08897 8.21167 9.09046 6.13208 10.0619 5.89583ZM6.90581 33.9585C3.97653 32.6563 2.9812 32.9523 2.42161 32.9523C1.26213 32.9523 0.883099 32.1079 1.31884 31.3088C1.68891 30.6306 1.57401 29.9204 1.48298 29.3502C1.34271 28.4767 1.31734 28.1923 2.19628 27.816C3.41246 27.3115 3.95265 26.6625 4.35556 26.1769C5.48668 24.8104 6.62825 26.96 7.56389 28.8748C8.17124 30.1158 9.36653 30.7444 9.73512 32.1196C10.0739 33.3898 8.67562 34.746 6.90581 33.9585ZM17.3321 31.2256C15.2669 32.2071 12.636 32.6577 10.6678 31.6617C10.3768 30.8406 9.9112 30.3098 9.4098 29.776C10.2141 29.569 10.811 28.589 10.0962 27.6046C9.3337 26.5531 7.77579 25.8196 6.20147 24.6296C4.72862 23.5169 4.26304 20.7738 6.26862 17.7083C5.2912 20.4237 5.86273 22.9263 6.35368 23.6423C6.45515 22.2015 6.57155 19.7952 8.58608 16.9121C9.6023 15.4567 9.61723 13.5346 9.63961 12.3329L10.5648 12.9513C11.2453 13.4427 11.8153 13.9838 12.6331 13.9838C13.8418 13.9838 14.5103 13.3042 15.4415 12.7398C15.8056 12.521 16.3562 12.2994 16.8188 11.9917C17.5948 15.6025 20.8091 19.9454 20.9896 22.4188C21.7373 20.9137 20.7778 17.2942 20.7778 17.2942C22.0342 19.1681 22.1342 20.73 22.1894 22.6462C23.0684 22.9977 24.0115 23.9135 24.098 25.1196L23.7324 25.0788C23.5444 23.7385 19.8421 21.7698 19.5093 24.2927C17.7336 24.5567 18.3797 27.3056 18.0216 29.0877C17.8574 29.9029 17.553 30.5475 17.3321 31.2256ZM24.5636 31.1658C23.0937 31.72 22.1014 32.8969 21.4194 33.6275C20.1062 35.0363 18.3693 34.361 18.1842 33.0427C17.9887 31.634 18.7214 30.8654 19.0378 29.289C19.3258 27.8496 19.0035 25.6344 19.6809 25.3981C20.1212 27.9546 22.7639 26.8798 23.3668 26.1827C24.3472 26.1827 24.4293 26.5065 24.6486 27.4033C24.7859 27.9648 24.9754 28.4373 25.5112 28.9929C26.1349 29.6448 25.9439 30.6452 24.5636 31.1658ZM12.6256 12.1988C11.6541 12.1988 10.9274 11.5673 10.3365 11.0773C10.0336 10.8279 10.4111 10.3671 10.714 10.6179C11.2915 11.0963 11.8735 11.6023 12.6256 11.6023C13.5314 11.6023 14.3297 10.8454 15.4116 10.4283C15.7802 10.2869 15.9906 10.844 15.625 10.9854C14.5745 11.3894 13.7314 12.1988 12.6256 12.1988Z" fill="#F0F2E2"/>
</svg>

After

Width:  |  Height:  |  Size: 3.8 KiB

@ -0,0 +1,3 @@
<svg width="25" height="30" viewBox="0 0 25 30" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M25.0003 22.0095C24.0178 24.8596 21.0764 29.906 18.0463 29.961C16.0363 29.9997 15.39 28.7697 13.0924 28.7697C10.7961 28.7697 10.0773 29.9235 8.17728 29.9985C4.96217 30.1222 -0.000488281 22.7145 -0.000488281 16.2543C-0.000488281 10.3203 4.13465 7.37899 7.74726 7.32524C9.68483 7.29024 11.5149 8.63153 12.6962 8.63153C13.8825 8.63153 16.105 7.01898 18.4414 7.25523C19.4189 7.29649 22.1652 7.649 23.9278 10.2266C19.2514 13.2792 19.9802 19.6631 25.0003 22.0095ZM18.4726 0C14.94 0.142505 12.0574 3.84887 12.4599 6.91397C15.725 7.16773 18.8576 3.50761 18.4726 0Z" fill="#F0F2E2"/>
</svg>

After

Width:  |  Height:  |  Size: 687 B

@ -0,0 +1,3 @@
<svg width="22" height="30" viewBox="0 0 22 30" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M21.875 4.125C21.875 2.12279 20.2522 0.5 18.25 0.5C16.2478 0.5 14.625 2.12279 14.625 4.125C14.625 5.72363 15.6654 7.06488 17.1021 7.547C17.3051 12.7368 14.66 13.3035 11.0628 14.0611C8.99779 14.4961 6.66208 14.9976 4.95833 16.5805V7.52767C6.36363 7.02863 7.375 5.70188 7.375 4.125C7.375 2.12279 5.75221 0.5 3.75 0.5C1.74779 0.5 0.125 2.12279 0.125 4.125C0.125 5.70188 1.13638 7.02863 2.54167 7.52767V22.4711C1.13638 22.9714 0.125 24.2981 0.125 25.875C0.125 27.8772 1.74779 29.5 3.75 29.5C5.75221 29.5 7.375 27.8772 7.375 25.875C7.375 24.3102 6.37933 22.9895 4.99096 22.482C5.31721 17.7429 8.09637 17.1557 11.5607 16.4258C15.2316 15.6525 19.7459 14.6834 19.5103 7.51196C20.889 6.99842 21.875 5.68254 21.875 4.125ZM1.575 4.125C1.575 2.92513 2.55013 1.95 3.75 1.95C4.94988 1.95 5.925 2.92513 5.925 4.125C5.925 5.32488 4.94988 6.3 3.75 6.3C2.55013 6.3 1.575 5.32488 1.575 4.125ZM5.925 25.875C5.925 27.0749 4.94988 28.05 3.75 28.05C2.55013 28.05 1.575 27.0749 1.575 25.875C1.575 24.6751 2.55013 23.7 3.75 23.7C4.94988 23.7 5.925 24.6751 5.925 25.875ZM18.25 6.3C17.0501 6.3 16.075 5.32488 16.075 4.125C16.075 2.92513 17.0501 1.95 18.25 1.95C19.4499 1.95 20.425 2.92513 20.425 4.125C20.425 5.32488 19.4499 6.3 18.25 6.3Z" fill="#F0F2E2"/>
</svg>

After

Width:  |  Height:  |  Size: 1.3 KiB

@ -0,0 +1,3 @@
<svg width="25" height="24" viewBox="0 0 25 24" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M0.5 12V3.354L10.5 1.999V12H0.5ZM11.5 12H24.5V0L11.5 1.807V12ZM10.5 13H0.5V20.646L10.5 22.001V13ZM11.5 13V22.194L24.5 24V13H11.5Z" fill="#F0F2E2"/>
</svg>

After

Width:  |  Height:  |  Size: 260 B

@ -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<Props> = ({
columnHeaders,
data,
}) => {
return (
<TableContainer
// Note: This wont work on firefox, we are ok with this.
css={{
"&::-webkit-scrollbar": {
borderTop: '2px solid #11866f',
height: 18
},
"&::-webkit-scrollbar-thumb": {
background: "#11866f",
},
}}
pt={4}
pb={4}
>
<Table variant='unstyled'>
<Thead>
<Tr>
{
columnHeaders.map((columnHeader, idx) => {
return (
<Th
key={idx}
textTransform='none'
minW={'130.5px'}
px={4}
>
<Text
fontFamily='"JetBrains Mono", monospace'
fontWeight={700}
fontSize='md'
color='#868b87'
>
{columnHeader}
</Text>
</Th>
)
})
}
</Tr>
</Thead>
<Tbody>
{
data.map((item: any, idx: number) => {
return (
<Tr
key={idx}
// TODO: Get new background color from nuno for hover
transition={'all 0.5s'}
_hover={{background: 'green.50', transition: 'all 0.5s'}}
>
{
columnHeaders.map((columnHeader, idx) => {
// TODO: Make the font size smaller (refer to design system)
return (
<Td
key={idx}
px={4}
fontSize='13px'
>
{item[columnHeader.toLowerCase()]}
</Td>
)
})
}
</Tr>
)
})
}
</Tbody>
</Table>
</TableContainer>
)
}

@ -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<DownloadsHero> = ({
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 (
<Stack border='3px solid' borderColor='brand.light.primary' py={4} px={4}>
<Stack alignItems='center'>
<Image src='/images/pages/gopher-downloads-front-light.svg' alt='Gopher plugged in' />
</Stack>
<Box mb={4}>
<Box
as='h1'
textStyle='h1'
>
Download go-ethereum
</Box>
<Text
// TODO: move text style to theme
fontFamily='"JetBrains Mono", monospace'
lineHeight='21px'
mb={8}
>
{currentBuildName} ({currentBuildVersion})
</Text>
<Text mb={4}>
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&apos;re looking to install Geth and/or associated tools via your favorite package manager, please check our installation guide.
</Text>
{
Object.keys(DOWNLOAD_HEADER_BUTTONS).map((key: string) => {
return (
<NextLink
key={key}
href={DOWNLOAD_HEADER_BUTTONS[key].buildURL}
passHref
>
<Button
as='a'
variant='primary'
width={{ base: '100%' }}
p={8}
mb={4}
>
<HStack spacing={4}>
<Stack alignItems='center'>
<Image
src={DOWNLOAD_HEADER_BUTTONS[key].image}
alt={DOWNLOAD_HEADER_BUTTONS[key].imageAlt}
/>
</Stack>
<Box>
<Text textStyle='downloads-button-label'>
For {DOWNLOAD_HEADER_BUTTONS[key].name}
</Text>
<Text textStyle='downloads-button-label'>
geth {currentBuildName}
</Text>
</Box>
</HStack>
</Button>
</NextLink>
)
})
}
<Box textAlign={'center'}>
<Link
href={releaseNotesURL}
isExternal
variant='light'
>
Release notes for {currentBuildName} {currentBuildVersion}
</Link>
</Box>
</Box>
</Stack>
);
};

@ -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<Props> = ({
children,
imgSrc,
imgAltText,
sectionTitle,
id
}) => {
return (
<Stack border='2px solid' borderColor='brand.light.primary' id={id}>
{!!imgSrc && (
<Stack alignItems='center' p={4} borderBottom='2px solid' borderColor='brand.light.primary'>
{/* TODO: use NextImage */}
<Image src={imgSrc} alt={imgAltText} />
</Stack>
)}
<Stack
p={4}
borderBottom='2px solid'
borderColor='brand.light.primary'
sx={{ mt: '0 !important' }}
>
<Box as='h2' textStyle='h2'>
{sectionTitle}
</Box>
</Stack>
<Stack spacing={4}>
{children}
</Stack>
</Stack>
)
}

@ -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<Props> = ({
data
}) => {
return (
<Stack
sx={{ mt: '0 !important' }}
borderBottom='2px solid'
borderColor='brand.light.primary'
>
<Tabs variant='unstyled'>
<TabList
color='brand.light.primary'
bg='green.50'
>
{
DOWNLOAD_TABS.map((tab, idx) => {
return (
<Tab
key={tab}
w={'20%'}
p={4}
_selected={{
bg: 'brand.light.primary',
color: 'yellow.50',
}}
borderBottom='2px solid'
borderRight={
idx === (DOWNLOAD_TABS.length - 1)
?'none'
:'2px solid'
}
borderColor='brand.light.primary'
>
<Text textStyle='download-tab-label'>
{tab}
</Text>
</Tab>
)
})
}
</TabList>
<TabPanels>
<TabPanel p={0}>
<DataTable
columnHeaders={DOWNLOAD_TAB_COLUMN_HEADERS}
data={data}
/>
</TabPanel>
<TabPanel p={0}>
<DataTable
columnHeaders={DOWNLOAD_TAB_COLUMN_HEADERS}
data={data}
/>
</TabPanel>
<TabPanel p={0}>
<DataTable
columnHeaders={DOWNLOAD_TAB_COLUMN_HEADERS}
data={data}
/>
</TabPanel>
<TabPanel p={0}>
<DataTable
columnHeaders={DOWNLOAD_TAB_COLUMN_HEADERS}
data={data}
/>
</TabPanel>
<TabPanel p={0}>
<DataTable
columnHeaders={DOWNLOAD_TAB_COLUMN_HEADERS}
data={data}
/>
</TabPanel>
</TabPanels>
</Tabs>
</Stack>
)
}

@ -0,0 +1,3 @@
export * from './DownloadsHero';
export * from './DownloadsSection'
export * from './DownloadsTable'

@ -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_TWITTER_URL = 'https://twitter.com/go_ethereum';
export const GETH_DISCORD_URL = 'https://discord.com/invite/nthXNEv'; export const GETH_DISCORD_URL = 'https://discord.com/invite/nthXNEv';
export const GO_URL = 'https://go.dev/'; 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'
]

@ -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'
},
]

@ -0,0 +1,32 @@
export const pgpBuildTestData = [
{
"build server": "Android Builder",
"unique id": "Go Ethereum Android Builder <geth-ci@ethereum.org>",
"openpgp key": "F9585DE6",
"fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6"
},
{
"build server": "iOS Builder",
"unique id": "Go Ethereum iOS Builder <geth-ci@ethereum.org>",
"openpgp key": "F9585DE6",
"fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6"
},
{
"build server": "Linux Builder",
"unique id": "Go Ethereum Linux Builder <geth-ci@ethereum.org>",
"openpgp key": "F9585DE6",
"fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6"
},
{
"build server": "macOS Builder",
"unique id": "Go Ethereum macOS Builder <geth-ci@ethereum.org>",
"openpgp key": "F9585DE6",
"fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6"
},
{
"build server": "Windows Builder",
"unique id": "Go Ethereum Windows Builder <geth-ci@ethereum.org>",
"openpgp key": "F9585DE6",
"fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6"
},
]

@ -0,0 +1,20 @@
export const pgpDeveloperTestData = [
{
"developer": "Felix Lange",
"unique id": "Felix Lange <fjl@ethereum.org>",
"openpgp key": "F9585DE6",
"fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6"
},
{
"developer": "Martin Holst Swende",
"unique id": "Martin Holst Swende <martin.swende@ethereum.org>",
"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 <peter@ethereum.org>",
"openpgp key": "F9585DE6",
"fingerprint": "8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6"
},
]

@ -1,6 +1,6 @@
--- ---
title: Go Contract Bindings 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. 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.

@ -57,7 +57,7 @@ devp2p nodeset filter all-nodes.json -eth-network mainnet > mainnet.nodes.exampl
The following filter flags are available: 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. - `-les-server` selects LES server nodes.
- `-ip <mask>` restricts nodes to the given IP range. - `-ip <mask>` restricts nodes to the given IP range.
- `-min-age <duration>` restricts the result to nodes which have been live for the - `-min-age <duration>` restricts the result to nodes which have been live for the

@ -23,7 +23,7 @@ geth --networkid 12345
### Choosing A Consensus Algorithm ### 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 #### Ethash

@ -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.

@ -55,7 +55,7 @@ ETHEREUM OPTIONS:
--keystore value Directory for the keystore (default = inside the datadir) --keystore value Directory for the keystore (default = inside the datadir)
--usb Enable monitoring and management of USB hardware wallets --usb Enable monitoring and management of USB hardware wallets
--pcscdpath value Path to the smartcard daemon (pcscd) socket file --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) --syncmode value Blockchain sync mode ("snap", "full" or "light") (default: snap)
--exitwhensynced Exits after block synchronisation completes --exitwhensynced Exits after block synchronisation completes
--gcmode value Blockchain garbage collection mode ("full", "archive") (default: "full") --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 --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 (<number>=<hash>) --eth.requiredblocks value Comma separated block number-to-hash mappings to require for peering (<number>=<hash>)
--mainnet Ethereum mainnet --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 --goerli Görli network: pre-configured proof-of-authority test network
--sepolia Sepolia network: pre-configured proof-of-work 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 value Data directory for the databases and keystore (default: "~/.ethereum")
--datadir.ancient value Data directory for ancient chain segments (default = inside chaindata) --datadir.ancient value Data directory for ancient chain segments (default = inside chaindata)
--remotedb value URL for remote database --remotedb value URL for remote database

@ -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.

@ -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 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 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 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: There are other log messages that are commonly seen during syncing. For example:
```sh ```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. 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 ## 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). 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).

@ -3,7 +3,7 @@ title: Sync modes
description: Introduction to Geth's 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 ## 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. 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). 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: 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 - download block bodies and receipts. In parallel, download raw state data and build state trie
- heal state trie to account for newly arriving data - 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. **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 ### 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.
@ -38,13 +41,13 @@ It is also possible to create a partial/recent archive node where the node was s
## Light nodes ## 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). Read more about light nodes on our [LES page](/docs/interface/les.md).
## Consensus layer syncing ## 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. 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 ### 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 ## Summary

@ -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. 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 ## Using Geth
Geth is the portal for users to send transactions to Ethereum. The Geth Javascript console is available for this purpose, and the majority of the [JSON-RPC API](/docs/rpc/server) will remain available via web3js or HTTP requests with commands as json payloads. These options are explained in more detail on the [Javascript Console page](/docs/interface/javascript-console). The Javascript console can be started Geth is the portal for users to send transactions to Ethereum. The Geth Javascript console is available for this purpose, and the majority of the [JSON-RPC API](/docs/rpc/server) will remain available via web3js or HTTP requests with commands as json payloads. These options are explained in more detail on the [Javascript Console page](/docs/interface/javascript-console). The Javascript console can be started

@ -10,11 +10,11 @@ These documentation pages are intended to help users download, install and use G
## Where to go from here ## 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. 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 ## 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.

@ -3,7 +3,8 @@ title: eth Namespace
description: Documentation for the JSON-RPC API "eth" namespace description: Documentation for the JSON-RPC API "eth" namespace
--- ---
Geth provides several extensions to the standard "eth" JSON-RPC namespace.
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 ### eth_subscribe, eth_unsubscribe
@ -64,6 +65,7 @@ Example:
The method returns a single `Binary` consisting the return value of the executed contract call. The method returns a single `Binary` consisting the return value of the executed contract call.
#### Simple example #### 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: 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:

@ -13,6 +13,10 @@ Here are more resources for a deeper understanding of Geth and related topics.
## Watch ## 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) [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) [Marius at ETH Amsterdam 2022: Deep dive into Geth](https://www.youtube.com/watch?v=c4N79UXZqSc)

@ -62,7 +62,7 @@ Run `devp2p nodeset filter <nodes.json> <filter flags...>` to write a new, filte
- `-limit <N>` limits the output set to N entries, taking the top N nodes by score - `-limit <N>` limits the output set to N entries, taking the top N nodes by score
- `-ip <CIDR>` filters nodes by IP subnet - `-ip <CIDR>` filters nodes by IP subnet
- `-min-age <duration>` filters nodes by 'first seen' time - `-min-age <duration>` filters nodes by 'first seen' time
- `-eth-network <mainnet/rinkeby/goerli/ropsten>` filters nodes by "eth" ENR entry - `-eth-network <mainnet/goerli/sepolia>` filters nodes by "eth" ENR entry
- `-les-server` filters nodes by LES server support - `-les-server` filters nodes by LES server support
- `-snap` filters nodes by snap protocol support - `-snap` filters nodes by snap protocol support

@ -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 */}
<main>
<Stack spacing={4}>
{/* TODO: replace hardcoded strings with build information */}
<DownloadsHero
currentBuildName={'Sentry Omega'}
currentBuildVersion={'v1.10.23'}
linuxBuildURL={'https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-1.10.25-69568c55.tar.gz'}
macOSBuildURL={'https://gethstore.blob.core.windows.net/builds/geth-darwin-amd64-1.10.25-69568c55.tar.gz'}
releaseNotesURL={''}
sourceCodeURL={'https://github.com/ethereum/go-ethereum/archive/v1.10.25.tar.gz'}
windowsBuildURL={'https://gethstore.blob.core.windows.net/builds/geth-windows-amd64-1.10.25-69568c55.exe'}
/>
<DownloadsSection
imgSrc='/images/pages/gopher-home-side-desktop.svg'
imgAltText='Gopher facing right'
sectionTitle='Specific Versions'
id='specificversions'
>
<Stack p={4}>
<Text textStyle='quick-link-text'>
If you&apos;re looking for a specific release, operating system or architecture, below you will find:
</Text>
<UnorderedList px={4}>
<ListItem>
<Text textStyle='quick-link-text'>
All stable and develop builds of Geth and tools
</Text>
</ListItem>
<ListItem>
<Text textStyle='quick-link-text'>
Archives for non-primary processor architectures
</Text>
</ListItem>
<ListItem>
<Text textStyle='quick-link-text'>
Android library archives and iOS XCode frameworks
</Text>
</ListItem>
</UnorderedList>
<Text textStyle='quick-link-text'>
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{' '}
<Link
href={'#pgpsignatures'}
variant='light'
>
OpenPGP
</Link>{' '}
Signatures for details).
</Text>
</Stack>
</DownloadsSection>
<DownloadsSection sectionTitle='Stable releases' id='stablereleases'>
<Stack p={4} borderBottom='2px solid' borderColor='brand.light.primary'>
<Text textStyle='quick-link-text'>
These are the current and previous stable releases of go-ethereum, updated automatically when a new version is tagged in our{' '}
<Link
href={GETH_REPO_URL}
isExternal
variant='light'
>
GitHub repository.
</Link>
</Text>
</Stack>
{/* TODO: swap test data for real data */}
<DownloadsTable data={testDownloadData.slice(0, amountStableReleases)}/>
<Stack sx={{ mt: '0 !important' }}>
<Link as='button' variant='button-link-secondary' onClick={showMoreStableReleases}>
<Text
fontFamily='"JetBrains Mono", monospace'
fontWeight={700}
textTransform='uppercase'
textAlign='center'
p={4}
>
Show older releases
</Text>
</Link>
</Stack>
</DownloadsSection>
<DownloadsSection sectionTitle='Develop builds' id='developbuilds'>
<Stack p={4} borderBottom='2px solid' borderColor='brand.light.primary'>
<Text textStyle='quick-link-text'>
These are the develop snapshots of go-ethereum, updated automatically when a new commit is pushed into our{' '}
<Link
href={GETH_REPO_URL}
isExternal
variant='light'
>
GitHub repository.
</Link>
</Text>
</Stack>
{/* TODO: swap for real data */}
<DownloadsTable data={testDownloadData.slice(0, amountDevelopBuilds)} />
<Stack sx={{ mt: '0 !important' }}>
<Link as='button' variant='button-link-secondary' onClick={showMoreDevelopBuilds}>
<Text
fontFamily='"JetBrains Mono", monospace'
fontWeight={700}
textTransform='uppercase'
textAlign='center'
p={4}
>
Show older releases
</Text>
</Link>
</Stack>
</DownloadsSection>
<DownloadsSection sectionTitle='OpenPGP Signatures' id='pgpsignatures'>
<Stack p={4} borderBottom='2px solid' borderColor='brand.light.primary'>
<Text textStyle='quick-link-text'>
All the binaries available from this page are signed via our build server PGP keys:
</Text>
</Stack>
{/* TODO: swap for real data */}
<Stack borderBottom='2px solid' borderColor='brand.light.primary'>
<DataTable
columnHeaders={DOWNLOAD_OPENPGP_BUILD_HEADERS}
data={pgpBuildTestData}
/>
</Stack>
{/* TODO: swap for real data */}
<Stack>
<DataTable
columnHeaders={DOWNLOAD_OPENPGP_DEVELOPER_HEADERS}
data={pgpDeveloperTestData}
/>
</Stack>
</DownloadsSection>
<DownloadsSection sectionTitle='Importing keys and verifying builds' id='importingkeys'>
<Stack p={4} borderBottom='2px solid' borderColor='brand.light.primary'>
<Text textStyle='quick-link-text'>
You can import the build server public keys by grabbing the individual keys directly from the keyserver network:
</Text>
{/* TODO: These keys depends on the binary */}
<Code p={4}>
gpg --recv-keys F9585DE6 C2FF8BBF 9BA28146 7B9E2481 D2A67EAC
</Code>
</Stack>
<Stack p={4} borderBottom='2px solid' borderColor='brand.light.primary'>
<Text textStyle='quick-link-text'>
Similarly you can import all the developer public keys by grabbing them directly from the keyserver network:
</Text>
{/* TODO: These are developer keys, do we need to change? */}
<Code p={4}>
gpg --recv-keys E058A81C 05A5DDF0 1CCB7DD2
</Code>
</Stack>
<Stack p={4}>
<Text textStyle='quick-link-text'>
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:
</Text>
{/* TODO: These keys depends on the binary */}
<Code p={4}>
gpg --verify geth-linux-amd64-1.5.0-d0c820ac.tar.gz.asc
</Code>
</Stack>
</DownloadsSection>
</Stack>
</main>
</>
)
}
export default DownloadsPage

@ -1,3 +1,4 @@
export * from './colors'; export * from './colors';
export * from './shadows';
export * from './sizes'; export * from './sizes';
export * from './textStyles'; export * from './textStyles';

@ -0,0 +1,3 @@
export const shadows = {
linkBoxShadow: '0 0 0 1px #11866f !important'
}

@ -59,6 +59,19 @@ export const textStyles = {
fontWeight: 400, fontWeight: 400,
fontSize: '12px' 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 // TODO: refactor w/ semantic tokens for light/dark mode
'link-light': {}, 'link-light': {},
// TODO: refactor w/ semantic tokens for light/dark mode // TODO: refactor w/ semantic tokens for light/dark mode

@ -1,6 +1,6 @@
import { extendTheme } from '@chakra-ui/react'; import { extendTheme } from '@chakra-ui/react';
import { colors, sizes, textStyles } from './foundations'; import { colors, shadows, sizes, textStyles } from './foundations';
import { Button, Link } from './components'; import { Button, Link } from './components';
const overrides = { const overrides = {
@ -9,6 +9,7 @@ const overrides = {
Button, Button,
Link Link
}, },
shadows,
sizes, sizes,
styles: { styles: {
global: () => ({ global: () => ({

Loading…
Cancel
Save