diff --git a/src/components/UI/Header.tsx b/src/components/UI/Header.tsx index 300c38116f..cb7641849c 100644 --- a/src/components/UI/Header.tsx +++ b/src/components/UI/Header.tsx @@ -17,14 +17,12 @@ export const Header: FC = () => { p={4} justifyContent='center' alignItems='flex-start' - borderRight={{ base: 'none', sm: '2px solid #11866f'}} + borderRight={{ base: 'none', sm: '2px solid #11866f' }} flexGrow={2} > - - go-ethereum - + go-ethereum @@ -96,10 +94,7 @@ export const Header: FC = () => { {/* DARK MODE SWITCH */} - + diff --git a/src/components/UI/downloads/DownloadsHero.tsx b/src/components/UI/downloads/DownloadsHero.tsx index 2c01270953..397357cb14 100644 --- a/src/components/UI/downloads/DownloadsHero.tsx +++ b/src/components/UI/downloads/DownloadsHero.tsx @@ -1,4 +1,14 @@ -import { Box, Button, Image, Link, Stack, HStack, Text } from '@chakra-ui/react'; +import { + Box, + Center, + Button, + Grid, + Image, + Link, + Stack, + HStack, + Text +} from '@chakra-ui/react'; import { FC } from 'react'; import NextLink from 'next/link'; @@ -29,61 +39,101 @@ export const DownloadsHero: FC = ({ DOWNLOAD_HEADER_BUTTONS.sourceCode.buildURL = sourceCodeURL; return ( - - - Gopher plugged in - + + + + + + Download go-ethereum + - - - Download go-ethereum - + + {currentBuildName} ({currentBuildVersion}) + - - {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. + + - - 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. - + +
+ Gopher plugged in +
+ + - {Object.keys(DOWNLOAD_HEADER_BUTTONS).map((key: string) => { - return ( - - - - ); - })} + + {Object.keys(DOWNLOAD_HEADER_BUTTONS).map((key: string) => { + return ( + + + + ); + })} + Release notes for {currentBuildName} {currentBuildVersion} - - + + +
+ Gopher plugged in +
+ ); }; diff --git a/src/components/UI/downloads/DownloadsSection.tsx b/src/components/UI/downloads/DownloadsSection.tsx index 365bb49411..adf55abe6e 100644 --- a/src/components/UI/downloads/DownloadsSection.tsx +++ b/src/components/UI/downloads/DownloadsSection.tsx @@ -1,4 +1,4 @@ -import { Box, Image, Stack } from '@chakra-ui/react'; +import { Center, Flex, Image, Stack, Text } from '@chakra-ui/react'; import { FC } from 'react'; interface Props { @@ -6,10 +6,18 @@ interface Props { id: string; imgSrc?: string; imgAltText?: string; + sectionDescription?: React.ReactNode; sectionTitle: string; } -export const DownloadsSection: FC = ({ children, imgSrc, imgAltText, sectionTitle, id }) => { +export const DownloadsSection: FC = ({ + children, + imgSrc, + imgAltText, + sectionDescription, + sectionTitle, + id +}) => { return ( {!!imgSrc && ( @@ -19,18 +27,33 @@ export const DownloadsSection: FC = ({ children, imgSrc, imgAltText, sect )} - - - {sectionTitle} - - + +
+ + {sectionTitle} + +
+ + + {sectionDescription && ( +
+ {sectionDescription} +
+ )} + - {children} + + {children} + ); }; diff --git a/src/components/UI/downloads/SpecificVersionsSection.tsx b/src/components/UI/downloads/SpecificVersionsSection.tsx new file mode 100644 index 0000000000..d7f9279771 --- /dev/null +++ b/src/components/UI/downloads/SpecificVersionsSection.tsx @@ -0,0 +1,42 @@ +import { Box, Flex, Image, Stack } from '@chakra-ui/react'; +import { FC } from 'react'; + +interface Props { + children: React.ReactNode; +} + +export const SpecificVersionsSection: FC = ({ children }) => { + return ( + + + {/* TODO: use NextImage */} + Gopher facing right + + + + + Specific Versions + + + {children} + + + ); +}; diff --git a/src/components/UI/downloads/index.ts b/src/components/UI/downloads/index.ts index 11310c63fc..9c5b9ae8c4 100644 --- a/src/components/UI/downloads/index.ts +++ b/src/components/UI/downloads/index.ts @@ -1,3 +1,4 @@ export * from './DownloadsHero'; export * from './DownloadsSection'; export * from './DownloadsTable'; +export * from './SpecificVersionsSection'; diff --git a/src/components/UI/homepage/HomeHero.tsx b/src/components/UI/homepage/HomeHero.tsx index 600c6715de..cb68860bdb 100644 --- a/src/components/UI/homepage/HomeHero.tsx +++ b/src/components/UI/homepage/HomeHero.tsx @@ -19,7 +19,7 @@ export const HomeHero: FC = () => { textStyle='h1' mb={{ base: 2, md: 4 }} textAlign={{ base: 'center', md: 'left' }} - fontSize={{ base: '3rem', md: '6rem'}} + fontSize={{ base: '5xl', md: '8xl' }} lineHeight={{ md: '6rem' }} fontWeight='500' > diff --git a/src/components/UI/icons/DiscordIcon.tsx b/src/components/UI/icons/DiscordIcon.tsx index cea1987697..d1fe20d402 100644 --- a/src/components/UI/icons/DiscordIcon.tsx +++ b/src/components/UI/icons/DiscordIcon.tsx @@ -2,10 +2,13 @@ import { createIcon } from '@chakra-ui/icons'; export const DiscordIcon = createIcon({ displayName: 'DiscordIcon', - viewBox:"0 0 32 24", + viewBox: '0 0 32 24', path: ( - - + + ) -}); \ No newline at end of file +}); diff --git a/src/components/UI/icons/GitHubIcon.tsx b/src/components/UI/icons/GitHubIcon.tsx index 42d2da8667..6db81bbf91 100644 --- a/src/components/UI/icons/GitHubIcon.tsx +++ b/src/components/UI/icons/GitHubIcon.tsx @@ -2,10 +2,13 @@ import { createIcon } from '@chakra-ui/icons'; export const GitHubIcon = createIcon({ displayName: 'GitHubIcon', - viewBox:"0 0 26 24", + viewBox: '0 0 26 24', path: ( - - + + ) -}); \ No newline at end of file +}); diff --git a/src/components/UI/icons/TwitterIcon.tsx b/src/components/UI/icons/TwitterIcon.tsx index c544ba6041..516702e0b8 100644 --- a/src/components/UI/icons/TwitterIcon.tsx +++ b/src/components/UI/icons/TwitterIcon.tsx @@ -2,10 +2,13 @@ import { createIcon } from '@chakra-ui/icons'; export const TwitterIcon = createIcon({ displayName: 'TwitterIcon', - viewBox:"0 0 28 22", + viewBox: '0 0 28 22', path: ( - - + + ) -}); \ No newline at end of file +}); diff --git a/src/components/UI/icons/index.ts b/src/components/UI/icons/index.ts index 9759dcea9b..5266e3513c 100644 --- a/src/components/UI/icons/index.ts +++ b/src/components/UI/icons/index.ts @@ -1,6 +1,6 @@ -export * from './DiscordIcon' -export * from './GitHubIcon' +export * from './DiscordIcon'; +export * from './GitHubIcon'; export * from './HamburguerIcon'; export * from './LensIcon'; export * from './MoonIcon'; -export * from './TwitterIcon' +export * from './TwitterIcon'; diff --git a/src/components/layouts/Footer.tsx b/src/components/layouts/Footer.tsx index 2d88d6d638..6917c4b5f5 100644 --- a/src/components/layouts/Footer.tsx +++ b/src/components/layouts/Footer.tsx @@ -8,23 +8,16 @@ import { GETH_DISCORD_URL, GETH_REPO_URL, GETH_TWITTER_URL -} from '../../constants' +} from '../../constants'; -import { - DiscordIcon, - GitHubIcon, - TwitterIcon -} from '../UI/icons'; +import { DiscordIcon, GitHubIcon, TwitterIcon } from '../UI/icons'; export const Footer: FC = () => { return ( - + @@ -177,5 +170,5 @@ export const Footer: FC = () => { {`© 2013–${new Date().getFullYear()}. The go-ethereum Authors.`} - ) -} \ No newline at end of file + ); +}; diff --git a/src/components/layouts/Layout.tsx b/src/components/layouts/Layout.tsx index b37103c187..81d2621ea4 100644 --- a/src/components/layouts/Layout.tsx +++ b/src/components/layouts/Layout.tsx @@ -4,7 +4,7 @@ import { FC } from 'react'; // Components import { Header } from '../UI'; -import { Footer } from './Footer' +import { Footer } from './Footer'; interface Props { children?: React.ReactNode; diff --git a/src/pages/docs/developers/evm-tracing/built-in-tracers.md b/src/pages/docs/developers/evm-tracing/built-in-tracers.md index fe7363a12f..ddddedb9a4 100644 --- a/src/pages/docs/developers/evm-tracing/built-in-tracers.md +++ b/src/pages/docs/developers/evm-tracing/built-in-tracers.md @@ -3,7 +3,7 @@ title: Built-in tracers description: Explanation of the tracers that come bundled in Geth as part of the tracing API. --- -Geth comes bundled with a choice of tracers that can be invoked via the [tracing API](/docs/rpc/ns-debug). Some of these built-in tracers are implemented natively in Go, and others in Javascript. The default tracer is the opcode logger (otherwise known as struct logger) which is the default tracer for all the methods. Other tracers have to be specified by passing their name to the `tracer` parameter in the API call. +Geth comes bundled with a choice of tracers that can be invoked via the [tracing API](/docs/rpc/ns-debug). Some of these built-in tracers are implemented natively in Go, and others in Javascript. The default tracer is the opcode logger (otherwise known as struct logger) which is the default tracer for all the methods. Other tracers have to be specified by passing their name to the `tracer` parameter in the API call. ## Struct/opcode logger @@ -85,7 +85,7 @@ Return: } }, - ... + ... ``` @@ -93,7 +93,6 @@ Return: The following tracers are implement in Go. This means they are much more performant than other tracers that are written in Javascript. The tracers are selected by passing their name to the `tracer` parameter when invoking a tracing API method, e.g. `debug.traceTransaction(, { tracer: 'callTracer' })`. - ### 4byteTracer Solidity contract functions are [addressed](https://docs.soliditylang.org/en/develop/abi-spec.html#function-selector) using the first four four byte of the Keccak-256 hash of their signature. Therefore when calling the function of a contract, the caller must send this function selector as well as the ABI-encoded arguments as call data. @@ -135,7 +134,6 @@ The `callTracer` tracks all the call frames executed during a transaction, inclu | error | string | error, if any | | calls | []callframe | list of sub-calls | - Example Call: ```sh @@ -178,7 +176,6 @@ Things to note about the call tracer: - Calls to precompiles are also included in the result - In case a frame reverts, the field `output` will contain the raw return data, unlike [revertReasonTracer](#revertreasontracer) which parses the data and returns the revert message - ### prestateTracer The prestate tracer has two modes: `prestate` and `diff`. The `prestate` mode returns the accounts necessary to execute a given transaction. `diff` mode returns the differences between the transaction's pre and post-state (i.e. what changed because the transaction happened). The `prestateTracer` defaults to `prestate` mode. It reexecutes the given transaction and tracks every part of state that is touched. This is similar to the concept of a [stateless witness](https://ethresear.ch/t/the-stateless-client-concept/172), the difference being this tracer doesn't return any cryptographic proof, rather only the trie leaves. The result is an object. The keys are addresses of accounts. The value is an object with the following fields: @@ -195,7 +192,15 @@ To run this tracer in `diff` mode, pass `tracerConfig: {diffMode: true}` in the Example: ```js -debug.traceCall({from: "0x35a9f94af726f07b5162df7e828cc9dc8439e7d0", to: "0xc8ba32cab1757528daf49033e3673fae77dcf05d", data: "0xd1a2eab2000000000000000000000000000000000000000000000000000000000024aea100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000050000000204895cd480cc8412691a880028a25aec86786f1ed2aa5562bc400000000000000c6403c14f35be1da6f433eadbb6e9178a47fbc7c6c1d568d2f2b876e929089c8d8db646304fd001a187dc8a600000000000000000000000000000000"}, 'latest', {tracer: 'prestateTracer'}) +debug.traceCall( + { + from: '0x35a9f94af726f07b5162df7e828cc9dc8439e7d0', + to: '0xc8ba32cab1757528daf49033e3673fae77dcf05d', + data: '0xd1a2eab2000000000000000000000000000000000000000000000000000000000024aea100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000050000000204895cd480cc8412691a880028a25aec86786f1ed2aa5562bc400000000000000c6403c14f35be1da6f433eadbb6e9178a47fbc7c6c1d568d2f2b876e929089c8d8db646304fd001a187dc8a600000000000000000000000000000000' + }, + 'latest', + { tracer: 'prestateTracer' } +); ``` Return: @@ -244,7 +249,6 @@ Return (same call with `{diffMode: True}`): } ``` - ### revertReasonTracer The `revertReasonTracer` is useful for analyzing failed transactions. If the transaction reverted, the reason for the revert (according to the Solidity contract) is returned. For any other failure, the error message is returned. @@ -265,7 +269,6 @@ Returns: This tracer is noop. It returns an empty object and is only meant for testing the setup. - ## Javascript tracers There are also a set of tracers written in Javascript. These are less performant than the Go native tracers because of overheads associated with interpreting the Javascript in Geth's Go environment. @@ -277,7 +280,15 @@ There are also a set of tracers written in Javascript. These are less performant Example: ```js -debug.traceCall({from: "0x35a9f94af726f07b5162df7e828cc9dc8439e7d0", to: "0xc8ba32cab1757528daf49033e3673fae77dcf05d", data: "0xd1a2eab2000000000000000000000000000000000000000000000000000000000024aea100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000050000000204895cd480cc8412691a880028a25aec86786f1ed2aa5562bc400000000000000c6403c14f35be1da6f433eadbb6e9178a47fbc7c6c1d568d2f2b876e929089c8d8db646304fd001a187dc8a600000000000000000000000000000000"}, 'latest', {tracer: 'bigramTracer'}) +debug.traceCall( + { + from: '0x35a9f94af726f07b5162df7e828cc9dc8439e7d0', + to: '0xc8ba32cab1757528daf49033e3673fae77dcf05d', + data: '0xd1a2eab2000000000000000000000000000000000000000000000000000000000024aea100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000050000000204895cd480cc8412691a880028a25aec86786f1ed2aa5562bc400000000000000c6403c14f35be1da6f433eadbb6e9178a47fbc7c6c1d568d2f2b876e929089c8d8db646304fd001a187dc8a600000000000000000000000000000000' + }, + 'latest', + { tracer: 'bigramTracer' } +); ``` Returns: @@ -371,7 +382,15 @@ Returns: Example: ```js -debug.traceCall({from: "0x35a9f94af726f07b5162df7e828cc9dc8439e7d0", to: "0xc8ba32cab1757528daf49033e3673fae77dcf05d", data: "0xd1a2eab2000000000000000000000000000000000000000000000000000000000024aea100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000050000000204895cd480cc8412691a880028a25aec86786f1ed2aa5562bc400000000000000c6403c14f35be1da6f433eadbb6e9178a47fbc7c6c1d568d2f2b876e929089c8d8db646304fd001a187dc8a600000000000000000000000000000000"}, 'latest', {tracer: 'opcountTracer'}) +debug.traceCall( + { + from: '0x35a9f94af726f07b5162df7e828cc9dc8439e7d0', + to: '0xc8ba32cab1757528daf49033e3673fae77dcf05d', + data: '0xd1a2eab2000000000000000000000000000000000000000000000000000000000024aea100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000050000000204895cd480cc8412691a880028a25aec86786f1ed2aa5562bc400000000000000c6403c14f35be1da6f433eadbb6e9178a47fbc7c6c1d568d2f2b876e929089c8d8db646304fd001a187dc8a600000000000000000000000000000000' + }, + 'latest', + { tracer: 'opcountTracer' } +); ``` Returns: @@ -381,15 +400,25 @@ Returns: ``` ### trigram + `trigramTracer` counts the opcode trigrams. Trigrams are the possible combinations of three opcodes this tracer reports how many times each combination is seen during execution. Example: ```js -debug.traceCall({from: "0x35a9f94af726f07b5162df7e828cc9dc8439e7d0", to: "0xc8ba32cab1757528daf49033e3673fae77dcf05d", data: "0xd1a2eab2000000000000000000000000000000000000000000000000000000000024aea100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000050000000204895cd480cc8412691a880028a25aec86786f1ed2aa5562bc400000000000000c6403c14f35be1da6f433eadbb6e9178a47fbc7c6c1d568d2f2b876e929089c8d8db646304fd001a187dc8a600000000000000000000000000000000"}, 'latest', {tracer: 'trigramTracer'}) +debug.traceCall( + { + from: '0x35a9f94af726f07b5162df7e828cc9dc8439e7d0', + to: '0xc8ba32cab1757528daf49033e3673fae77dcf05d', + data: '0xd1a2eab2000000000000000000000000000000000000000000000000000000000024aea100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000050000000204895cd480cc8412691a880028a25aec86786f1ed2aa5562bc400000000000000c6403c14f35be1da6f433eadbb6e9178a47fbc7c6c1d568d2f2b876e929089c8d8db646304fd001a187dc8a600000000000000000000000000000000' + }, + 'latest', + { tracer: 'trigramTracer' } +); ``` Returns: + ```terminal { --PUSH1: 1, @@ -414,17 +443,18 @@ Returns: } ``` - ### unigram `unigramTracer` counts the frequency of occurrance of each opcode. Example: + ```js > debug.traceCall({from: "0x35a9f94af726f07b5162df7e828cc9dc8439e7d0", to: "0xc8ba32cab1757528daf49033e3673fae77dcf05d", data: "0xd1a2eab2000000000000000000000000000000000000000000000000000000000024aea100000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000050000000204895cd480cc8412691a880028a25aec86786f1ed2aa5562bc400000000000000c6403c14f35be1da6f433eadbb6e9178a47fbc7c6c1d568d2f2b876e929089c8d8db646304fd001a187dc8a600000000000000000000000000000000"}, 'latest', {tracer: 'unigramTracer'}) ``` Returns: + ```terminal { ADD: 36, @@ -447,10 +477,9 @@ Returns: ## State overrides -It is possible to give temporary state modifications to Geth in order to simulate the effects of `eth_call`. For example, some new byetcode could be deployed to some address *temporarily just for the duration of the execution* and then a transaction interacting with that address canm be traced. This can be used for scenario testing or determining the outcome of some hypothetical transaction before executing for real. - +It is possible to give temporary state modifications to Geth in order to simulate the effects of `eth_call`. For example, some new byetcode could be deployed to some address _temporarily just for the duration of the execution_ and then a transaction interacting with that address canm be traced. This can be used for scenario testing or determining the outcome of some hypothetical transaction before executing for real. -To do this, the tracer is written as normal, but the parameter `stateOverrides` is passed an address and some bytecode. +To do this, the tracer is written as normal, but the parameter `stateOverrides` is passed an address and some bytecode. ```js var code = //contract bytecode @@ -460,4 +489,4 @@ debug.traceCall({from: , to: , input: }, 'latest', {stateOverrides: {'0x...': {c ## Summary -This page showed how to use the tracers that come bundled with Geth. There are a set written in Go and a set written in Javascript. They are invoked by passing their names when calling an API method. \ No newline at end of file +This page showed how to use the tracers that come bundled with Geth. There are a set written in Go and a set written in Javascript. They are invoked by passing their names when calling an API method. diff --git a/src/pages/docs/developers/evm-tracing/custom-tracer.md b/src/pages/docs/developers/evm-tracing/custom-tracer.md index a6ca62d247..e2b65075ea 100644 --- a/src/pages/docs/developers/evm-tracing/custom-tracer.md +++ b/src/pages/docs/developers/evm-tracing/custom-tracer.md @@ -411,4 +411,4 @@ Every method of the [EVMLogger interface](https://pkg.go.dev/github.com/ethereum ## Summary -This page described how to write custom tracers for Geth. Custom tracers can be written in Javascript or Go. \ No newline at end of file +This page described how to write custom tracers for Geth. Custom tracers can be written in Javascript or Go. diff --git a/src/pages/docs/developers/evm-tracing/index.md b/src/pages/docs/developers/evm-tracing/index.md index e7d8e6041a..df310a2d26 100644 --- a/src/pages/docs/developers/evm-tracing/index.md +++ b/src/pages/docs/developers/evm-tracing/index.md @@ -4,8 +4,10 @@ description: Introduction to tracing EVM transactions using Geth --- --- + title: EVM Tracing sort-key: A + --- Tracing allows users to examine precisely what was executed by the EVM during some specific transaction or set of transactions. There are two different types of [transactions](https://ethereum.org/en/developers/docs/transactions) in Ethereum: value transfers and contract executions. A value transfer just moves ETH from one account to another. A contract interaction executes some code stored at a contract address which can include altering stored data and transacting multiple times with other contracts and externally-owned accounts. A contract execution transaction can therefore be a complicated web of interactions that can be difficult to unpick. The transaction receipt contains a status code that shows whether the transaction succeeded or failed, but more detailed information is not readily available, meaning it is very difficult to know what a contract execution actually did, what data was modified and which addresses were touched. This is the problem that EVM tracing solves. Geth traces transactions by re-running them locally and collecting data about precisely what was executed by the EVM. @@ -33,13 +35,12 @@ This means there are limits on the transactions that can be traced imposed by th availability **cannot** be reasonably assumed. ![state pruning options](/public/images/state-pruning.png) - -*This image shows the state stored by each sync-mode - red indicates stored state. The full width of each line represents origin to present head* - +_This image shows the state stored by each sync-mode - red indicates stored state. The full width of each line represents origin to present head_ + More detailed information about syncing is available on the [sync modes page](/pages/docs/fundamentals/sync-modes.md). -When a trace of a specific transaction is executed, the state is prepared by fetching the state of the parent block from the database. If it is not available, Geth will crawl backwards in time to find the next available state but only up to a limit defined in the `reexec` parameter which defaults to 128 blocks. If no state is available within the `reexec` window then the trace fails with `Error: required historical state unavailable` and the `reexec` parameter must be increased. If a valid state *is* found in the `reexec` window, then Geth sequentially re-executes the transcations in each block between the last available state and the target block. The greater the value of `reexec` the longer the tracing will take because more blocks have to be re-executed to regenerate the target state. +When a trace of a specific transaction is executed, the state is prepared by fetching the state of the parent block from the database. If it is not available, Geth will crawl backwards in time to find the next available state but only up to a limit defined in the `reexec` parameter which defaults to 128 blocks. If no state is available within the `reexec` window then the trace fails with `Error: required historical state unavailable` and the `reexec` parameter must be increased. If a valid state _is_ found in the `reexec` window, then Geth sequentially re-executes the transcations in each block between the last available state and the target block. The greater the value of `reexec` the longer the tracing will take because more blocks have to be re-executed to regenerate the target state. The `debug_getAccessibleStates` endpoint is a useful tool for estimating a suitable value for `reexec`. Passing the number of the block that contains the target transaction and a search distance to this endpoint will return the number of blocks behind the current head where the most recent available state exists. This value can be passed to the tracer as `re-exec`. @@ -51,14 +52,13 @@ _There are exceptions to the above rules when running batch traces of entire blo ### Built-in tracers -The tracing API accepts an optional `tracer` parameter that defines how the data returned to the API call should be processed. If this parameter is ommitted the default tracer is used. The default is the struct (or 'opcode') logger. These raw opcode traces are sometimes useful, but the returned data is very low level and can be too extensive and awkward to read for many use-cases. A full opcode trace can easily go into the hundreds of megabytes, making them very resource intensive to get out of the node and process externally. For these reasons, there are a set of non-default built-in tracers that can be named in the API call to return different data from the method. Under the hood, these tracers are Go or Javascript +The tracing API accepts an optional `tracer` parameter that defines how the data returned to the API call should be processed. If this parameter is ommitted the default tracer is used. The default is the struct (or 'opcode') logger. These raw opcode traces are sometimes useful, but the returned data is very low level and can be too extensive and awkward to read for many use-cases. A full opcode trace can easily go into the hundreds of megabytes, making them very resource intensive to get out of the node and process externally. For these reasons, there are a set of non-default built-in tracers that can be named in the API call to return different data from the method. Under the hood, these tracers are Go or Javascript functions that do some specific preprocessing on the trace data before it is returned. -More information about Geth's built-in tracers is available on the -[built-in tracers](/pages/docs/developers/evm-tracing/built-in-tracers.md) +More information about Geth's built-in tracers is available on the +[built-in tracers](/pages/docs/developers/evm-tracing/built-in-tracers.md) page. - ### Custom tracers In addition to built-in tracers, it is possible to provide custom code that hooks to events in the EVM to process and return data in a consumable format. Custom tracers can be written either in Javascript or Go. JS tracers are good for quick prototyping and experimentation as well as for less intensive applications. Go tracers are performant but require the tracer to be compiled together with the Geth source code. This means developers only have to gather the data they actually need, and do any processing at the source. @@ -67,4 +67,4 @@ More information about custom tracers is available on the [custom tracers](/page ## Summary -This page gave an introduction to the concept of tracing and explained issues around state availability. More detailed information on Geth's built-in and custom tracers can be found on their dedicated pages. on their dedicated pages. \ No newline at end of file +This page gave an introduction to the concept of tracing and explained issues around state availability. More detailed information on Geth's built-in and custom tracers can be found on their dedicated pages. on their dedicated pages. diff --git a/src/pages/docs/developers/geth-developer/dev-guide.md b/src/pages/docs/developers/geth-developer/dev-guide.md index 4a3508b828..bbc57cd1cd 100644 --- a/src/pages/docs/developers/geth-developer/dev-guide.md +++ b/src/pages/docs/developers/geth-developer/dev-guide.md @@ -83,7 +83,8 @@ created by github.com/ethereum/go-ethereum/p2p.newDialScheduler github.com/ethereum/go-ethereum/p2p/dial.go:179 +0x425 ``` -and +and + ```sh debug.stacks("consolecmd.go") ``` diff --git a/src/pages/docs/fundamentals/account-management.md b/src/pages/docs/fundamentals/account-management.md index c88222b098..4005a9a900 100644 --- a/src/pages/docs/fundamentals/account-management.md +++ b/src/pages/docs/fundamentals/account-management.md @@ -50,10 +50,9 @@ geth --sepolia --datadir sepolia --signer=sepolia-data/clef/clef.i Remember that it is also necessary to have a consensus client running too, which requires `--http` and several `authrpc` values to be provided to Geth. A complete set of startup commands for the Geth-Lodestar client combinaton plus Clef is provided as an example in this [Gist](https://gist.github.com/jmcook1186/ea5de9215ecedb1b0105bcfa9c30d44c) - adapt it for different client combinations and configurations. - ## Interacting with Clef -There are two modes of interaction with Clef. One is direct interaction, which is achieved by passing requests by HTTP or IPC with JSON-RPC data as defined in Clef's external API. This is the way to do things in Clef that don't require Geth, such as creating and listing accounts, or signing data offline. The other way is via Geth. With Geth started with Clef as an external signer, requests made to Geth that touch account data will route via Clef for approval. By default, the user approves or denies interactions manually by typing `y` or `n` into the Clef console when prompted, but custom rules can also be created to automate common tasks. +There are two modes of interaction with Clef. One is direct interaction, which is achieved by passing requests by HTTP or IPC with JSON-RPC data as defined in Clef's external API. This is the way to do things in Clef that don't require Geth, such as creating and listing accounts, or signing data offline. The other way is via Geth. With Geth started with Clef as an external signer, requests made to Geth that touch account data will route via Clef for approval. By default, the user approves or denies interactions manually by typing `y` or `n` into the Clef console when prompted, but custom rules can also be created to automate common tasks. ### Creating accounts @@ -70,6 +69,7 @@ The same can be achieved using raw JSON requests (this example send the request ```shell curl -X POST --data '{"id": 0, "jsonrpc": "2.0", "method": "account_new", "params": []}' http://localhost:8550 -H "Content-Type: application/json" ``` + The console will hang because Clef is waiting for manual approval. Switch to the Clef terminal and approve the action. Clef will prompt for a account password and then confirm the account creation in the terminal logs. A new keyfile has been added to the keystore in `go-ethereum/sepolia-data`. A JSON response is returned to the terminal the request originated from, containing the new account address in the `result` field. ```terminal @@ -84,7 +84,6 @@ The newly generated key files can be viewed in `/keystore/`. The file n `UTC--2022-05-19T12-34-36.47413510Z--0b85e5a13e118466159b1e1b6a4234e5f9f784bb` - An account can also be created by importing a raw private key (hex string) using `clef importraw` as follows: ```sh @@ -94,18 +93,17 @@ clef importraw The terminal will respond with the following message, indicating the account has been created successfully: ```terminal -## Info +## Info Key imported: Address 0x9160DC9105f7De5dC5E7f3d97ef11DA47269BdA6 Keystore file: /home/user/.ethereum/keystore/UTC--2022-10-28T12-03-13.976383602Z--9160dc9105f7de5dc5e7f3d97ef11da47269bda6 -The key is now encrypted; losing the password will result in permanently losing +The key is now encrypted; losing the password will result in permanently losing access to the key and all associated funds! Make sure to backup keystore and passwords in a safe location. ``` - ### Listing accounts The accounts in the keystore can be listed to the terminal using a simple CLI command as follows: @@ -196,7 +194,7 @@ Clef can be used to set and remove passwords for an existing keystore file. To s clef setpw a94f5374fce5edbc8e2a8697c15331677e6ebf0b ``` -This will cause Clef to prompt for a new password, twice, and then the Clef master password to decrypt the keyfile. +This will cause Clef to prompt for a new password, twice, and then the Clef master password to decrypt the keyfile. Geth's `account update` subcommand can also be used to update the account password: @@ -216,7 +214,6 @@ Updating the account using `geth account update` replaces the original file with With Clef, indiscriminate account unlocking is no longer a feature. Instead, Clef unlocks are locked until actions are explicitly approved manually by a user, unless they conform to some specific scenario that has been encoded in a ruleset. Please refer to our Clef docs for instructions for how to create rulesets. - ### Transactions Transactions can be sent using raw JSON requests to Geth or using `web3js` in the Javascript console. Either way, with Clef acting as the signer the transactions will not get sent until approval is given in Clef. The following code snippet shows how a transaction could be sent between two accounts in the keystore using the Javascript console. diff --git a/src/pages/docs/fundamentals/logs.md b/src/pages/docs/fundamentals/logs.md index 75c9213767..548e0fc6a1 100644 --- a/src/pages/docs/fundamentals/logs.md +++ b/src/pages/docs/fundamentals/logs.md @@ -159,7 +159,6 @@ The sync can be confirmed using [`eth.syncing`](https://ethereum.org/en/develope } ``` - There are other log messages that are commonly seen during syncing. For example: ```sh @@ -207,10 +206,10 @@ 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 diff --git a/src/pages/docs/fundamentals/node-architecture.md b/src/pages/docs/fundamentals/node-architecture.md index 26b2528aac..c3d24a319b 100644 --- a/src/pages/docs/fundamentals/node-architecture.md +++ b/src/pages/docs/fundamentals/node-architecture.md @@ -4,6 +4,7 @@ description: Introduction to how Ethereum nodes are organized and where Geth fit --- ## Node architecture + An Ethereum node is composed of two clients: an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients) and a [consensus client](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients). Geth is an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients). Originally, an execution client alone was enough to run a full Ethereum node. However, ever since Ethereum turned off [proof-of-work](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/) and implemented [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/), Geth has needed to be coupled to another piece of software called a [“consensus client”](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients) in order to keep track of the Ethereum blockchain. The execution client (Geth) is responsible for transaction handling, transaction gossip, state management and supporting the Ethereum Virtual Machine ([EVM])(https://ethereum.org/en/developers/docs/evm/). However, Geth is **not** responsible for block building, block gossiping or handling consensus logic. These are in the remit of the consensus client. @@ -29,4 +30,3 @@ The consensus client deals with all the logic that enables a node to stay in syn Validators can be added to consensus clients if 32 ETH have been sent to the deposit contract. The validator client comes bundled with the consensus client and can be added to a node at any time. The validator handles attestations and block proposals. They enable a node to accrue rewards or lose ETH via penalties or slashing. Running the validator software also makes a node eligible to be selected to propose a new block. Read more about [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/). - diff --git a/src/pages/docs/fundamentals/sync-modes.md b/src/pages/docs/fundamentals/sync-modes.md index 3fed6d05af..08c2afb1c4 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. Now that Ethereum uses proof-of-stake based consensus, a consensus client is required for Geth to sync. +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,7 @@ 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. 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. +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). @@ -23,10 +23,8 @@ 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. @@ -69,7 +67,6 @@ Alternatively, the consensus client can grab a checkpoint from a trusted source 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. - ## Summary There are several ways to sync a Geth node. The default is to use snap sync to create a full node. This verifies all blocks using some recent block that is old enough to be safe from re-orgs as a sync target. A trust-minimized alternative is full-sync, which verifies every block since genesis. These modes drop state data older than 128 blocks, keeping only checkpoints that enable on-request regeneration of historical states. For rapid queries of historical data an archive node is required. Archive nodes keep local copies of all historical data right back to genesis - currently about 12 TB and growing. The opposite extreme is a light node that doesn't store any blockchain data - it requests everything from full nodes. These configurations are controlled by passing `full`, `snap` or `light` to `--syncmode` at startup. For an archive node, `--syncmode` should be `full` and `--gcmode` should be set to `archive`. Currently, due to the transition to proof-of-stake, light-sync does not work (new light client protocols are being developed). diff --git a/src/pages/docs/interacting-with-geth/javascript-console.md b/src/pages/docs/interacting-with-geth/javascript-console.md index 95f3bd2999..152679328e 100644 --- a/src/pages/docs/interacting-with-geth/javascript-console.md +++ b/src/pages/docs/interacting-with-geth/javascript-console.md @@ -15,7 +15,7 @@ This returns a result which is also a JSON object, with values expressed as hexa {"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"} ``` -This is a low level and rather error-prone way to interact with Geth. Most developers prefer to use convenience libraries that abstract away some of the more tedious and awkward tasks such as converting values from hexadecimal strings into numbers, or converting between denominations of ether (Wei, Gwei, etc). One such library is [Web3.js](https://web3js.readthedocs.io/en/v1.7.3/). +This is a low level and rather error-prone way to interact with Geth. Most developers prefer to use convenience libraries that abstract away some of the more tedious and awkward tasks such as converting values from hexadecimal strings into numbers, or converting between denominations of ether (Wei, Gwei, etc). One such library is [Web3.js](https://web3js.readthedocs.io/en/v1.7.3/). The purpose of Geth's Javascript console is to provide a built-in environment to use a subset of the Web3.js libraries to interact with a Geth node. {% include note.html content="The web3.js version that comes bundled with Geth is not up to date with the official Web3.js documentation. There are several Web3.js libraries that are not available in the Geth Javascript Console. There are also administrative APIs included in the Geth console that are not documented in the Web3.js documentation. The full list of libraries available in the Geth console is available on the [JSON-RPC API page](/docs/rpc/server)." %} diff --git a/src/pages/docs/interacting-with-geth/javascript-console_contracts.md b/src/pages/docs/interacting-with-geth/javascript-console_contracts.md index 84d0ca6263..ce738641e7 100644 --- a/src/pages/docs/interacting-with-geth/javascript-console_contracts.md +++ b/src/pages/docs/interacting-with-geth/javascript-console_contracts.md @@ -3,7 +3,7 @@ title: JavaScript Console 2: Contracts description: Instructions for working with contracts in the Javascript console. --- -The [Introduction to the Javascript console](src/pages/docs/interacting-with-geth/javascript-console.md) page outlined how a Javascript console can be attached to Geth to provide a more user-friendly interface to Ethereum than interacting directly with the JSON-RPC API. This page will describe how to deploy contracts and interact with contracts using the attached console. This page will assume the Javascript console is attached to a running Geth instance using IPC. Clef should be used to manage accounts. +The [Introduction to the Javascript console](src/pages/docs/interacting-with-geth/javascript-console.md) page outlined how a Javascript console can be attached to Geth to provide a more user-friendly interface to Ethereum than interacting directly with the JSON-RPC API. This page will describe how to deploy contracts and interact with contracts using the attached console. This page will assume the Javascript console is attached to a running Geth instance using IPC. Clef should be used to manage accounts. ## Deploying a contract @@ -17,7 +17,7 @@ pragma solidity ^0.8.0; contract Storage{ uint256 value = 5; - + function set(uint256 number) public{ value = number; } @@ -48,33 +48,49 @@ The outputs look as follows: [{"inputs":[],"name":"retrieve","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"stateMutability":"view","type":"function"},{"inputs":[{"internalType":"uint256","name":"number","type":"uint256"}],"name":"store","outputs":[],"stateMutability":"nonpayable","type":"function"}] ``` -These are all the data required to deploy the contract using the Geth Javascript console. Open the Javascript console using `./geth attach geth.ipc`. +These are all the data required to deploy the contract using the Geth Javascript console. Open the Javascript console using `./geth attach geth.ipc`. Now, for convenice we can store the abi and bytecode in variables in the console: ```js -var abi = [{"inputs":[],"name":"retrieve","outputs":[{"internalType":"uint256","name":"","type":"uint256"}],"stateMutability":"view","type":"function"},{"inputs":[{"internalType":"uint256","name":"number","type":"uint256"}],"name":"store","outputs":[],"stateMutability":"nonpayable","type":"function"}] - -var bytecode = "608060405234801561001057600080fd5b50610150806100206000396000f3fe608060405234801561001057600080fd5b50600436106100365760003560e01c80632e64cec11461003b5780636057361d14610059575b600080fd5b610043610075565b60405161005091906100a1565b60405180910390f35b610073600480360381019061006e91906100ed565b61007e565b005b60008054905090565b8060008190555050565b6000819050919050565b61009b81610088565b82525050565b60006020820190506100b66000830184610092565b92915050565b600080fd5b6100ca81610088565b81146100d557600080fd5b50565b6000813590506100e7816100c1565b92915050565b600060208284031215610103576101026100bc565b5b6000610111848285016100d8565b9150509291505056fea264697066735822122031443f2fb748bdb27e539fdbeb0c6f575aec50508baaa7e4dbeb08577ef19b3764736f6c63430008110033" +var abi = [ + { + inputs: [], + name: 'retrieve', + outputs: [{ internalType: 'uint256', name: '', type: 'uint256' }], + stateMutability: 'view', + type: 'function' + }, + { + inputs: [{ internalType: 'uint256', name: 'number', type: 'uint256' }], + name: 'store', + outputs: [], + stateMutability: 'nonpayable', + type: 'function' + } +]; + +var bytecode = + '608060405234801561001057600080fd5b50610150806100206000396000f3fe608060405234801561001057600080fd5b50600436106100365760003560e01c80632e64cec11461003b5780636057361d14610059575b600080fd5b610043610075565b60405161005091906100a1565b60405180910390f35b610073600480360381019061006e91906100ed565b61007e565b005b60008054905090565b8060008190555050565b6000819050919050565b61009b81610088565b82525050565b60006020820190506100b66000830184610092565b92915050565b600080fd5b6100ca81610088565b81146100d557600080fd5b50565b6000813590506100e7816100c1565b92915050565b600060208284031215610103576101026100bc565b5b6000610111848285016100d8565b9150509291505056fea264697066735822122031443f2fb748bdb27e539fdbeb0c6f575aec50508baaa7e4dbeb08577ef19b3764736f6c63430008110033'; ``` The ABI can be used to create an instance of the contract: ```js -var contract = eth.contract(abi) +var contract = eth.contract(abi); ``` This contract instance can then be deployed to the blockchain. This is done using `eth.sendTransaction`, passing the contract bytecode in the `data` field. For convenience we can create a transaction JSON object first, then pass it to `eth.sendTransaction` later. Let's use the first account in `eth.accounts` as the sender. The amount of gas to include can be determined using `eth.estimateGas`: ```js -var gas = eth.estimateGas({data: bytecode}) +var gas = eth.estimateGas({ data: bytecode }); ``` Note that each command that touches accounts will require **approval in Clef** unless a custom rule has been implemented. The bytecode, gas and address of the sender can be bundled together into an object that will be passed to the contract's `new()` method which deploys the contract. ```js -var tx = {'from': eth.accounts[0], data: bytecode, gas: gas} -var deployed_contract = contract.new(tx) +var tx = { from: eth.accounts[0], data: bytecode, gas: gas }; +var deployed_contract = contract.new(tx); ``` The transaction hash and deployment address can now been viewed in the console by entering the variable name (in this case `deployed_contract`): @@ -105,14 +121,13 @@ The transaction hash and deployment address can now been viewed in the console b Passing the transaction hash to `eth.getTransaction()` returns the deployment transaction details including the contract bytecode in the `input` field. To interact with the contract, create an instance by passing the deployment address to `contract.at` then call the methods. ```js -var instance = contract.at("0x2d6505f8b1130a22a5998cd31788bf6c751247f") +var instance = contract.at('0x2d6505f8b1130a22a5998cd31788bf6c751247f'); // store() alters the state and therefore requires sendTransaction() -contract.set.sendTransaction(42, {from: eth.accounts[0], gas: 1000000}) +contract.set.sendTransaction(42, { from: eth.accounts[0], gas: 1000000 }); // retrieve does not alter state so it can be executed using call() -contract.retrieve().call() - ->> 2 +contract.retrieve().call() >> 2; ``` -## Summary +## Summary + This page demonstrated how to create, compile, deploy and interact with an Ethereum smart contract using Geth's Javascript console. 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 e10aa1279a..eb28325c21 100644 --- a/src/pages/docs/interacting-with-geth/rpc/ns-eth.md +++ b/src/pages/docs/interacting-with-geth/rpc/ns-eth.md @@ -3,8 +3,7 @@ title: eth Namespace description: Documentation for the JSON-RPC API "eth" 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. +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 @@ -65,6 +64,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/downloads.tsx b/src/pages/downloads.tsx index c612af2d6c..a335f0b569 100644 --- a/src/pages/downloads.tsx +++ b/src/pages/downloads.tsx @@ -1,8 +1,13 @@ -import { Code, Link, ListItem, Stack, Text, UnorderedList } from '@chakra-ui/react'; +import { Center, Code, Flex, 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 { + DownloadsHero, + DownloadsSection, + DownloadsTable, + SpecificVersionsSection +} from '../components/UI/downloads'; import { DataTable } from '../components/UI'; import { @@ -51,12 +56,7 @@ const DownloadsPage: NextPage = () => { } /> - + If you're looking for a specific release, operating system or architecture, @@ -92,10 +92,11 @@ const DownloadsPage: NextPage = () => { Signatures for details). - + - - + These are the current and previous stable releases of go-ethereum, updated automatically when a new version is tagged in our{' '} @@ -103,28 +104,48 @@ const DownloadsPage: NextPage = () => { GitHub repository. - - + } + sectionTitle='Stable releases' + > {/* TODO: swap test data for real data */} - - - - Show older releases - - - + + +
+ {/* TODO: swap testDownloadData with actual data */} + + Showing {amountStableReleases} latest releases of a total{' '} + {testDownloadData.length} releases + +
+ + + + + Show older releases + + + + - - + These are the develop snapshots of go-ethereum, updated automatically when a new commit is pushed into our{' '} @@ -132,33 +153,54 @@ const DownloadsPage: NextPage = () => { GitHub repository. - - + } + sectionTitle='Develop builds' + > {/* TODO: swap for real data */} - - - - Show older releases - - - + + +
+ {/* TODO: swap testDownloadData with actual data */} + + Showing {amountDevelopBuilds} latest releases of a total{' '} + {testDownloadData.length} releases + +
+ + + + + Show older releases + + + + - - + All the binaries available from this page are signed via our build server PGP keys: - - + } + sectionTitle='OpenPGP Signatures' + > {/* TODO: swap for real data */} @@ -173,37 +215,67 @@ const DownloadsPage: NextPage = () => { - - - - You can import the build server public keys by grabbing the individual keys directly - from the keyserver network: - + + + + + 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 - + + {/* 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: - + + + + 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 - + + {/* 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: - + + + + 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 - + + {/* TODO: These keys depends on the binary */} + gpg --verify geth-linux-amd64-1.5.0-d0c820ac.tar.gz.asc + + diff --git a/src/theme/components/Button.ts b/src/theme/components/Button.ts index 5d953f46c0..db07f8e61c 100644 --- a/src/theme/components/Button.ts +++ b/src/theme/components/Button.ts @@ -12,6 +12,19 @@ export const Button = { boxShadow: 'inset 0 0 0 2px #06fece !important' }, _active: { borderTop: '4px solid', borderColor: 'green.200', pt: '4px' } + }, + downloadsHeader: { + py: '8px', + px: '32px', + borderRadius: 0, + width: { base: '188px', md: 'auto' }, + bg: 'brand.light.primary', + _hover: { bg: 'brand.light.secondary' }, + _focus: { + bg: 'brand.light.primary', + boxShadow: 'inset 0 0 0 2px #06fece !important' + }, + _active: { borderTop: '4px solid', borderColor: 'green.200' } } } }; diff --git a/src/theme/foundations/textStyles.ts b/src/theme/foundations/textStyles.ts index df3252d467..954b49638f 100644 --- a/src/theme/foundations/textStyles.ts +++ b/src/theme/foundations/textStyles.ts @@ -67,7 +67,13 @@ export const textStyles = { 'downloads-button-label': { fontFamily: '"JetBrains Mono", monospace', color: 'yellow.50', - fontSize: 'xs', + fontSize: {base: 'md', lg: 'xl'}, + textTransform: 'uppercase' + }, + 'downloads-button-sublabel': { + fontFamily: '"JetBrains Mono", monospace', + color: 'yellow.50', + fontSize: {base: 'xs', lg: 'sm'}, textTransform: 'uppercase' }, 'download-tab-label': {