chore: update image paths
This commit is contained in:
Nicolás Quiroz
parent
b04df9d3c6
commit
e0464a7b26
@ -25,7 +25,7 @@ The libraries are updated synchronously with the Geth Github repository. The Go
|
||||
|
||||
Péter Szilágyi (@karalabe) gave a high level overview of the Go libraries in a talk at DevCon2 in Shanghai in 2016. The slides are still a useful resource ([available here](https://ethereum.karalabe.com/talks/2016-devcon.html)) and the talk itself can be viewed by clicking the image below (it is also archived on [IPFS](https://ipfs.io/ipfs/QmQRuKPKWWJAamrMqAp9rytX6Q4NvcXUKkhvu3kuREKqXR)).
|
||||
|
||||
[](https://www.youtube.com/watch?v=R0Ia1U9Gxjg)
|
||||
[](https://www.youtube.com/watch?v=R0Ia1U9Gxjg)
|
||||
|
||||
## Go packages
|
||||
|
||||
|
||||
@ -196,15 +196,15 @@ Solidity is a high-level language that makes code executable by the Ethereum vir
|
||||
|
||||
In a web browser, open <https://remix.ethereum.org>. This opens an online smart contract development environment. On the left-hand side of the screen there is a side-bar menu that toggles between several toolboxes that are displayed in a vertical panel. On the right hand side of the screen there is an editor and a terminal. This layout is similar to the default layout of many other IDEs such as [VSCode](https://code.visualstudio.com/). The contract defined in the previous section, `Storage.sol` is already available in the `Contracts` directory in Remix. It can be opened and reviewed in the editor.
|
||||
|
||||
|
||||
|
||||
|
||||
The Solidity logo is present as an icon in the Remix side-bar. Clicking this icon opens the Solidity compiler wizard. This can be used to compile `Storage.sol` ready. With `Solidity.sol` open in the editor window, simply click the `Compile 1_Storage.sol` button. A green tick will appear next to the Solidity icon to confirm that the contract has compiled successfully. This means the contract bytecode is available.
|
||||
|
||||
|
||||
|
||||
|
||||
Below the Solidity icon is a fourth icon that includes the Ethereum logo. Clicking this opens the Deploy menu. In this menu, Remix can be configured to connect to the local Geth node. In the drop-down menu labelled `ENVIRONMENT`, select `Injected Web3`. This will open an information pop-up with instructions for configuring Geth - these can be ignored as they were completed earlier in this tutorial. However, at the bottom of this pop-up is a box labelled `Web3 Provider Endpoint`. This should be set to Geth's 8545 port on `localhost` (`127.0.0.1:8545`). Click OK. The `ACCOUNT` field should automatically populate with the address of the account created earlier using the Geth Javascript console.
|
||||
|
||||
|
||||
|
||||
|
||||
To deploy `Storage.sol`, click `DEPLOY`.
|
||||
|
||||
@ -224,7 +224,7 @@ The contract is now deployed on a local testnet version of the Etheruem blockcha
|
||||
|
||||
After deploying the contract in Remix, the `Deployed Contracts` tab in the sidebar automatically populates with the public functions exposed by `Storage.sol`. To send a value to the contract storage, type a number in the field adjacent to the `store` button, then click the button.
|
||||
|
||||
|
||||
|
||||
|
||||
In the Geth terminal, the following logs confirm that the transaction was successful (the actual values will vary from the example below):
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ The execution client (Geth) is responsible for transaction handling, transaction
|
||||
|
||||
The relationship between the two Ethereum clients is shown in the schematic below. The two clients each connect to their own respective peer-to-peer (P2P) networks. This is because the execution clients gossip transactions over their P2P network enabling them to manage their local transaction pool. The consensus clients gossip blocks over their P2P network, enabling consensus and chain growth.
|
||||
|
||||
|
||||
|
||||
|
||||
For this two-client structure to work, consensus clients must be able to pass bundles of transactions to Geth to be executed. Executing the transactions locally is how the client validates that the transactions do not violate any Ethereum rules and that the proposed update to Ethereum’s state is correct. Likewise, when the node is selected to be a block producer the consensus client must be able to request bundles of transactions from Geth to include in the new block. This inter-client communication is handled by a local RPC connection using the [engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md).
|
||||
|
||||
|
||||
@ -22,7 +22,6 @@ There are future updates to Ethereum that will reduce the amount of disk space r
|
||||
|
||||
As well as storage capacity, Geth nodes rely on fast read and write operations. This means HDDs and cheaper HDDS struggle to sync the blockchain. There is a list of SSD models that can and cannot sync Geth in this [Github Gist](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038).
|
||||
|
||||
|
||||
## Bandwidth
|
||||
|
||||
It is important to have a stable and reliable internet connection, especially for running a validator because downtime can result in missed rewards or penalties. It is recommended to have at least 25Mbps download speed to run a node. Running a node also requires a lot of data to be uploaded and downloaded so it is better to use a ISP that does not have a capped data allowance.
|
||||
It is important to have a stable and reliable internet connection, especially for running a validator because downtime can result in missed rewards or penalties. It is recommended to have at least 25Mbps download speed to run a node. Running a node also requires a lot of data to be uploaded and downloaded so it is better to use a ISP that does not have a capped data allowance.
|
||||
|
||||
@ -112,35 +112,35 @@ sudo systemctl start grafana-server
|
||||
|
||||
When Grafana is up and running, it should be reachable at `localhost:3000`. A browser can be pointed to that URL to access a visualization dashboard. The browser will prompt for login credentials (user: `admin` and password: `admin`). When prompted, the default password should be changed and saved.
|
||||
|
||||
|
||||
|
||||
|
||||
The browser first redirects to the Grafana home page to set up the source data. Click on the configuration icon in the left bar and select "Data sources".
|
||||
|
||||
|
||||
|
||||
|
||||
There aren't any data sources yet, click on "Add data source" to define one.
|
||||
|
||||
|
||||
|
||||
|
||||
Select "InfluxDB" and proceed.
|
||||
|
||||
|
||||
|
||||
|
||||
Data source configuration is pretty straight forward if the tools run on the same machine as Geth. The InfluxDB address and details for accessing the database must be set. Refer to the image below.
|
||||
|
||||
|
||||
|
||||
|
||||
If everything is complete and InfluxDB is reachable, click on "Save and test" and wait for the confirmation to pop up.
|
||||
|
||||
|
||||
|
||||
|
||||
Grafana is now set up to read data from InfluxDB. Now a dashboard can be created to interpret and display it. Dashboards properties are encoded in JSON files which can be created by anybody and easily imported. On the left bar, click on "Create and Import".
|
||||
|
||||
|
||||
|
||||
|
||||
For a Geth monitoring dashboard, copy the ID of [this dashboard](https://grafana.com/grafana/dashboards/13877/) and paste it in the "Import page" in Grafana. After saving the dashboard, it should look like this:
|
||||
|
||||
|
||||
|
||||
|
||||
The dashboards can be customized further. Each panel can be edited, moved, removed or added. To learn more about how dashboards work, refer to [Grafana's documentation](https://grafana.com/docs/grafana/latest/dashboards/).
|
||||
|
||||
|
||||
@ -34,7 +34,7 @@ Ethstats has three components:
|
||||
|
||||
The summary dashboard for Ethereum Mainnet can be viewed at [ethstats.net](https://ethstats.net/).
|
||||
|
||||
|
||||
|
||||
|
||||
Note that the Ethstats dashboard is not a reliable source of information about the entire Ethereum
|
||||
network because submitting data to the Ethstats server is voluntary and has to be configured by
|
||||
|
||||
@ -72,7 +72,7 @@ The external API never handles any sensitive data directly, but it can be used t
|
||||
|
||||
The general flow for a basic transaction-signing operation using Clef and an Ethereum node such as Geth is as follows:
|
||||
|
||||
|
||||
|
||||
|
||||
In the case illustrated in the schematic above, Geth would be started with `--signer <addr>:<port>` and would relay requests to `eth.sendTransaction`. Text in `mono` font positioned along arrows shows the objects passed between each component.
|
||||
|
||||
@ -86,7 +86,7 @@ Clef is started on the command line using the `clef` command. Clef can be config
|
||||
clef --keystore /my/keystore --chainid 5
|
||||
```
|
||||
|
||||
On starting Clef, the following welcome messgae is displayed in the terminal:
|
||||
On starting Clef, the following welcome message is displayed in the terminal:
|
||||
|
||||
```terminal
|
||||
WARNING!
|
||||
|
||||
@ -23,7 +23,7 @@ This page will explain how rules are implemented in Clef and how best to manage
|
||||
|
||||
The ruleset engine acts as a gatekeeper to the command line interface - it auto-approves any requests that meet the conditions defined in a set of authenticated rule files. This prevents the user from having to manually approve or reject every request - instead they can define common patterns in a rule file and abstract that task away to the ruleset engine. The general architecture is as follows:
|
||||
|
||||
|
||||
|
||||
|
||||
When Clef receives a request, the ruleset engine evaluates a Javascript file for each method defined in the internal [UI API docs](/content/docs/tools/Clef/apis.md). For example the code snippet below is an example ruleset that calls the function `ApproveTx`. The call to `ApproveTx` is invoking the `ui_approveTx` [JSON_RPC API endpoint](/content/docs/tools/Clef/apis.md). Every time an RPC method is invoked the Javascript code is executed in a freshly instantiated virtual machine.
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ There are two ways that this can be achieved: integrated via Qubes or integrated
|
||||
|
||||
Qubes provides a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request to another qube. The OS then asks the user if the call is permitted.
|
||||
|
||||
|
||||
|
||||
|
||||
A policy-file can be created to allow such interaction. On the `target` domain, a service is invoked which can read the `stdin` from the `client` qube.
|
||||
|
||||
@ -43,7 +43,7 @@ This is how [Split GPG](https://www.qubes-os.org/doc/split-gpg/) is implemented.
|
||||
|
||||
##### Server
|
||||
|
||||
|
||||
|
||||
|
||||
On the `target` qubes, we need to define the RPC service.
|
||||
|
||||
@ -122,11 +122,11 @@ $ cat newaccnt.json| qrexec-client-vm debian-work qubes.Clefsign
|
||||
|
||||
A dialog should pop up first to allow the IPC call:
|
||||
|
||||
|
||||
|
||||
|
||||
Followed by a GTK-dialog to approve the operation:
|
||||
|
||||
|
||||
|
||||
|
||||
To test the full flow, start the client wrapper on the `client` qube:
|
||||
|
||||
@ -165,7 +165,7 @@ However, it comes with a couple of drawbacks:
|
||||
|
||||
The second way to set up Clef on a qubes system is to allow networking, and have Clef listen to a port which is accessible from other qubes.
|
||||
|
||||
|
||||
|
||||
|
||||
## USBArmory
|
||||
|
||||
|
||||
@ -204,7 +204,7 @@ For most users, manually confirming every transaction is the right way to use Cl
|
||||
For example, well defined rules such as:
|
||||
|
||||
- Auto-approve transactions with Uniswap v2, with value between 0.1 and 0.5 ETH per 24h period
|
||||
- Auto-approve transactions to address `0xD9C9Cd5f6779558b6e0eD4e6Acf6b1947E7fA1F3` as long as gas < 44k and gasPrice < 80Gwei can be encoded and intepreted by Clef's built-in ruleset engine.
|
||||
- Auto-approve transactions to address `0xD9C9Cd5f6779558b6e0eD4e6Acf6b1947E7fA1F3` as long as gas < 44k and gasPrice < 80Gwei can be encoded and interpreted by Clef's built-in ruleset engine.
|
||||
|
||||
### Rule files
|
||||
|
||||
@ -507,7 +507,7 @@ More examples, including a ruleset for a rate-limited window, are available on t
|
||||
|
||||
## Under the hood
|
||||
|
||||
The examples on this page have provided step-by-step instructions for verious operations using Clef. However, they have not provided much detail as to what is happening under the hood. This section will provide some more details about how Clef organizes itself locally.
|
||||
The examples on this page have provided step-by-step instructions for various operations using Clef. However, they have not provided much detail as to what is happening under the hood. This section will provide some more details about how Clef organizes itself locally.
|
||||
|
||||
Initializing Clef with a master password and providing an account password to `clef setpw` and attesting a ruleset creates the following files in the directory `~/.clef/` (this path is independent of the paths provided to `--keystore` and `--configdir` on startup):
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user