chore: update image paths

pull/26459/head^2
Nicolás Quiroz 2 years ago
parent 24f8b3d6fa
commit c1759fdcf6
  1. 2
      src/pages/docs/developers/dapp-developer/native.md
  2. 8
      src/pages/docs/developers/geth-developer/dev-mode.md
  3. 2
      src/pages/docs/fundamentals/node-architecture.md
  4. 16
      src/pages/docs/monitoring/dashboards.md
  5. 2
      src/pages/docs/monitoring/ethstats.md
  6. 2
      src/pages/docs/tools/clef/Introduction.md
  7. 2
      src/pages/docs/tools/clef/rules.md
  8. 10
      src/pages/docs/tools/clef/setup.md

@ -25,7 +25,7 @@ The libraries are updated synchronously with the Geth Github repository. The Go
Péter Szilágyi (@karalabe) gave a high level overview of the Go libraries in a talk at DevCon2 in Shanghai in 2016. The slides are still a useful resource ([available here](https://ethereum.karalabe.com/talks/2016-devcon.html)) and the talk itself can be viewed by clicking the image below (it is also archived on [IPFS](https://ipfs.io/ipfs/QmQRuKPKWWJAamrMqAp9rytX6Q4NvcXUKkhvu3kuREKqXR)). Péter Szilágyi (@karalabe) gave a high level overview of the Go libraries in a talk at DevCon2 in Shanghai in 2016. The slides are still a useful resource ([available here](https://ethereum.karalabe.com/talks/2016-devcon.html)) and the talk itself can be viewed by clicking the image below (it is also archived on [IPFS](https://ipfs.io/ipfs/QmQRuKPKWWJAamrMqAp9rytX6Q4NvcXUKkhvu3kuREKqXR)).
[![Peter's Devcon2 talk](/assets/devcon2_labelled.webp)](https://www.youtube.com/watch?v=R0Ia1U9Gxjg) [![Peter's Devcon2 talk](/images/devcon2_labelled.webp)](https://www.youtube.com/watch?v=R0Ia1U9Gxjg)
## Go packages ## 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. 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.
![Remix](/assets/remix.png) ![Remix](/images/remix.png)
The Solidity logo is present as an icon in the Remix side-bar. Clicking this icon opens the Solidity compiler wizard. This can be used to compile `Storage.sol` ready. With `Solidity.sol` open in the editor window, simply click the `Compile 1_Storage.sol` button. A green tick will appear next to the Solidity icon to confirm that the contract has compiled successfully. This means the contract bytecode is available. The Solidity logo is present as an icon in the Remix side-bar. Clicking this icon opens the Solidity compiler wizard. This can be used to compile `Storage.sol` ready. With `Solidity.sol` open in the editor window, simply click the `Compile 1_Storage.sol` button. A green tick will appear next to the Solidity icon to confirm that the contract has compiled successfully. This means the contract bytecode is available.
![Remix-compiler](assets/remix-compiler.png) ![Remix-compiler](/images/remix-compiler.png)
Below the Solidity icon is a fourth icon that includes the Ethereum logo. Clicking this opens the Deploy menu. In this menu, Remix can be configured to connect to the local Geth node. In the drop-down menu labelled `ENVIRONMENT`, select `Injected Web3`. This will open an information pop-up with instructions for configuring Geth - these can be ignored as they were completed earlier in this tutorial. However, at the bottom of this pop-up is a box labelled `Web3 Provider Endpoint`. This should be set to Geth's 8545 port on `localhost` (`127.0.0.1:8545`). Click OK. The `ACCOUNT` field should automatically populate with the address of the account created earlier using the Geth Javascript console. Below the Solidity icon is a fourth icon that includes the Ethereum logo. Clicking this opens the Deploy menu. In this menu, Remix can be configured to connect to the local Geth node. In the drop-down menu labelled `ENVIRONMENT`, select `Injected Web3`. This will open an information pop-up with instructions for configuring Geth - these can be ignored as they were completed earlier in this tutorial. However, at the bottom of this pop-up is a box labelled `Web3 Provider Endpoint`. This should be set to Geth's 8545 port on `localhost` (`127.0.0.1:8545`). Click OK. The `ACCOUNT` field should automatically populate with the address of the account created earlier using the Geth Javascript console.
![Remix-deploy](assets/remix-deploy.png) ![Remix-deploy](/images/remix-deploy.png)
To deploy `Storage.sol`, click `DEPLOY`. 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. After deploying the contract in Remix, the `Deployed Contracts` tab in the sidebar automatically populates with the public functions exposed by `Storage.sol`. To send a value to the contract storage, type a number in the field adjacent to the `store` button, then click the button.
![Remix-func](/assets/remix-func.png) ![Remix-func](/images/remix-func.png)
In the Geth terminal, the following logs confirm that the transaction was successful (the actual values will vary from the example below): 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. The relationship between the two Ethereum clients is shown in the schematic below. The two clients each connect to their own respective peer-to-peer (P2P) networks. This is because the execution clients gossip transactions over their P2P network enabling them to manage their local transaction pool. The consensus clients gossip blocks over their P2P network, enabling consensus and chain growth.
![node-architecture](/assets/node_architecture.png) ![node-architecture](/images/node_architecture.png)
For this two-client structure to work, consensus clients must be able to pass bundles of transactions to Geth to be executed. Executing the transactions locally is how the client validates that the transactions do not violate any Ethereum rules and that the proposed update to Ethereum’s state is correct. Likewise, when the node is selected to be a block producer the consensus client must be able to request bundles of transactions from Geth to include in the new block. This inter-client communication is handled by a local RPC connection using the [engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md). 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).

@ -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. 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.
![](/assets/grafana1.png) ![](/images/grafana1.png)
The browser first redirects to the Grafana home page to set up the source data. Click on the configuration icon in the left bar and select "Data sources". 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".
![](/assets/grafana2.png) ![](/images/grafana2.png)
There aren't any data sources yet, click on "Add data source" to define one. There aren't any data sources yet, click on "Add data source" to define one.
![](/assets/grafana3.png) ![](/images/grafana3.png)
Select "InfluxDB" and proceed. Select "InfluxDB" and proceed.
![](/assets/grafana4.png) ![](/images/grafana4.png)
Data source configuration is pretty straight forward if the tools run on the same machine as Geth. The InfluxDB address and details for accessing the database must be set. Refer to the image below. 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.
![](/assets/grafana5.png) ![](/images/grafana5.png)
If everything is complete and InfluxDB is reachable, click on "Save and test" and wait for the confirmation to pop up. If everything is complete and InfluxDB is reachable, click on "Save and test" and wait for the confirmation to pop up.
![](/assets/grafana6.png) ![](/images/grafana6.png)
Grafana is now set up to read data from InfluxDB. Now a dashboard can be created to interpret and display it. Dashboards properties are encoded in JSON files which can be created by anybody and easily imported. On the left bar, click on "Create and Import". 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".
![](/assets/grafana7.png) ![](/images/grafana7.png)
For a Geth monitoring dashboard, copy the ID of [this dashboard](https://grafana.com/grafana/dashboards/13877/) and paste it in the "Import page" in Grafana. After saving the dashboard, it should look like this: 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:
![](/assets/grafana8.png) ![](/images/grafana8.png)
The dashboards can be customized further. Each panel can be edited, moved, removed or added. To learn more about how dashboards work, refer to [Grafana's documentation](https://grafana.com/docs/grafana/latest/dashboards/). 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/). The summary dashboard for Ethereum Mainnet can be viewed at [ethstats.net](https://ethstats.net/).
![Ethstats](assets/ethstats-mainnet.png) ![Ethstats](/images/ethstats-mainnet.png)
Note that the Ethstats dashboard is not a reliable source of information about the entire Ethereum 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 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: The general flow for a basic transaction-signing operation using Clef and an Ethereum node such as Geth is as follows:
![Clef signing logic](/assets/clef_sign_flow.png) ![Clef signing logic](/images/clef_sign_flow.png)
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. 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.

@ -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: The ruleset engine acts as a gatekeeper to the command line interface - it auto-approves any requests that meet the conditions defined in a set of authenticated rule files. This prevents the user from having to manually approve or reject every request - instead they can define common patterns in a rule file and abstract that task away to the ruleset engine. The general architecture is as follows:
![Clef ruleset logic](/static/images/clef_ruleset.png) ![Clef ruleset logic](/images/images/clef_ruleset.png)
When Clef receives a request, the ruleset engine evaluates a Javascript file for each method defined in the internal [UI API docs](/content/docs/tools/Clef/apis.md). For example the code snippet below is an example ruleset that calls the function `ApproveTx`. The call to `ApproveTx` is invoking the `ui_approveTx` [JSON_RPC API endpoint](/content/docs/tools/Clef/apis.md). Every time an RPC method is invoked the Javascript code is executed in a freshly instantiated virtual machine. 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. Qubes provides a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request to another qube. The OS then asks the user if the call is permitted.
![Example](assets/qrexec-example.png) ![Example](/images/qrexec-example.png)
A policy-file can be created to allow such interaction. On the `target` domain, a service is invoked which can read the `stdin` from the `client` qube. 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 ##### Server
![Clef via qrexec](/assets/clef_qubes_qrexec.png) ![Clef via qrexec](/images/clef_qubes_qrexec.png)
On the `target` qubes, we need to define the RPC service. 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: A dialog should pop up first to allow the IPC call:
![one](qubes_newaccount-1.png) ![one](/images/qubes_newaccount-1.png)
Followed by a GTK-dialog to approve the operation: Followed by a GTK-dialog to approve the operation:
![two](qubes_newaccount-2.png) ![two](/images/qubes_newaccount-2.png)
To test the full flow, start the client wrapper on the `client` qube: 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. The second way to set up Clef on a qubes system is to allow networking, and have Clef listen to a port which is accessible from other qubes.
![Clef via http](clef_qubes_http.png) ![Clef via http](/images/clef_qubes_http.png)
## USBArmory ## USBArmory

Loading…
Cancel
Save