Ethereum Serial (IX): Installation and Customization of C++ Client (III)

run

Running eth without any arguments will sync your node to a public blockchain. It is also possible to create or sync to another blockchain (see Custom blockchains with eth).

Interacting with your node can be done with geth or the Ethereum console:

Using geth

Using the Ethereum Console

The Ethereum console is a node.js application that connects to a running eth/geth node and provides access to web3 objects.

Note: https://github.com/ethereum/ethereum-console

It can be installed using npm:

Notice:

 1
2

 > npm install -g ethereum-console
>ethconsole

Notice:

usage:

 1

 ethconsole [javascript file] [ipc socket]

Connect to the Ethereum node via ipc to remotely control it via the global variable web3 (web3.admin also appears) If no parameters are given, connect to the default ipc socket

Enter interactive mode.

parameter:

Connect to the given ipc socket (if it does not end in .ipc, use ipc://)

Executes the given JavaScript file, ending in .js, non-interactively.

The script needs to call process.exit() to terminate the console.

What is a module?

What is the main executable file?

1. eth command line Ethereum full node, controllable via RPC.

2. mix IDE, for contract and user interface development, testing and deployment to the blockchain

3. solc Solidity command line compiler.

4. lllc LLL command-line compiler.

Deprecated executable, will be retired soon

1. AlethZero An all-encompassing Qt-based graphical user interface for interacting with Ethereum (receives minimal support).

2. EthKey key management CLI.

What are the different modules?

• AlethZero - A Qt-based graphical user interface for interacting with Ethereum. Receives minimal support.

• libethereum - Modules related to the Ethereum web3 part, such as consensus engine, blockchain download, virtual machine.

– ethkey: independent key management

– ethminer: standalone ethash miner

– ethvm: standalone Ethereum virtual machine execution facility

– evmjit: Ethereum Virtual Machine Library Just-in-Time Compiler

– libethash: ethash mining proof-of-work algorithm implementation

– libethash-cl: ethash mining code for GPU mining (OpenCL)

– libethashseal: A generic wrapper around the proof-of-work sealing engine. Also includes the raw state of all ethash-based chains

– libethcore: a collection of core data structures and concepts

– libethereum: The main consensus engine (minus the Ethereum Virtual Machine). Includes state and blockchain classes

– libevm: Ethereum virtual machine implementation (interpreter).

– libevmasm: Ethereum virtual machine assembly tool, also includes optimizer

- libevmcore: A low-level data structure for the Ethereum virtual machine, opcodes, gas costs, etc.

– liblll: low-level LISP-like language compiler and assembler

- libnatspec: natspec script evaluator (confirmation information)

– libtestutils: Utilities for testing code

– lllc: LLL compiler command line interface

• libweb3core – Web3 core library, networking, encoding, decoding, basic data architecture.

– bench: tree-structured benchmarking

– libdevcore: data architecture, utilities, rlp, tree structures, in-memory databases

– libdevcrypto: cryptographic primitives, depends on libsecp256k1 and libcrypto++

– libp2p: core peer-to-peer networking implementation (except for specific subprotocols)

– rlp: standalone rlp encoder/decoder

• mix – decentralized application integrated development environment

• solidity – Solidity compiler

– docs: documentation, found at http://solidity.readthedocs.org/

– libsolidity: the actual implementation

– analysis: reference resolution, type checking… (enhanced AST annotation)

– ast: Abstract syntax tree and type system

– codegen: Generate assembly code from commented AST

– formal: formal verification

– interface: external interface for libsolidity users

– parsing: parser (creates uncommented AST)

- solc: command line compiler

• web3.js - JavaScript decentralized application framework library (connects to the backend via RPC/IPC)

• webthree – the actual client/node implementation ("eth")

– eth: command line client/node

– libjsconsole: JavaScript console to access the deprecated eth, to be replaced by nodejs app

– libjsengine: potential engine for libjsconsole, will be removed soon

– libweb3jsonrpc: json-rpc server-side endpoint, providing http and IPC (unix socket, windows pipe) connectors

– libwebthree: service connectors for Ethereum, swarm/ipfs and whisper

– libwhisper: whisper implementation

• webthree-helpers – Build system and some external dependencies

– cmake: build system cmake files, including instructions for interactive dependencies

– utils: external dependencies

# json_spirit: JSON parser for Boost's Spirit library

# libscrypt: scrypt implementation

# secp256k1: SECP 256k1 ECDSA signature algorithm implementation

Automatic setup of cpp-ethereum

At the time of writing this document, all cpp-ethereum automation is driven by a Jerkins instance hosted at http://52.28.164.97

The setup has a "nice alias" at http://ethbuilds.com, but it is owned by Bob Summerwill personally, not the Ethereum Foundation, and may end up pointing to something in the future.

It parallels the Ethereum download page examples for Go and Python builds.

The fact that we have two different automation systems is not ideal and is for historical reasons. It would make sense to consolidate all Ethereum Foundation projects into a single, ongoing automation setup, but it would be a lot of work. We are discussing it. It should be more approachable once the repo reorg is done for the C++ codebase.

The current Jenkins setup is missing the normalized continuous integration goal, which is its main weakness. There is no single URL you can visit to find out if the C++ build at HEAD is valid or broken. There is not even a URL you can visit per repository to find out if a private repository is valid or broken.

We also lost the webthree-umbrella automation as a whole to know if the set of repositories we were releasing was valid or broken.

We have automation for pull requests. They are built against development branches of the repositories they depend on. When testing changes which involve multiple repositories, there is a mechanism for specifying alternative branches for those dependencies. But it's broken.

This is a Jenkins project for PR automation. Whenever a new PR is created or the content of an existing PR branch is updated, they are automatically triggered through Github webhooks:

1. alethzero-prs – PR test by alethzero

2. libethereum-prs - PR tests for libethereum

3. libweb3core-prs – PR tests for libweb3core

4. mix-prs – PR testing for mix

5. solidity-prs – PR tests for solidity

6. webthree-helpers-prs – PR test for webthree-helpers

7. webthree-prs – PR test for webthree

Here are some other Jenkins projects we have:

1. ethbinaries-develop and ethbinaries-release – Projects that generate Windows and OS X binaries for the development release webthree-umbrella. The development project is run nightly, UTC. The release project is run manually.

2. ppa-build-develop and ppa-build-release - projects that package sources, build steps and binaries, the build steps are then pushed to Launchpad where they are built and if successful the binaries are pushed to the world. The develop project is run nightly, standard universal time. The release project is run manually.

3. solidity-emscripten - Solidity compiled for Emscripten. This is the build target, which calls the common targets listed below. The development project runs nightly, UTC.

4. update-umbrella - A utility project that can be run manually to update submodules in the webthree-umbrella project. Will be deprecated soon. It is run manually, and also nightly. The following projects are effectively "repositories" that build on the "user-facing" projects above.

5. ethbinaries-build – For use with ethbinaries-develop and ethbinaries-release.

6. project-build – used for all PR projects.

7. project-test – for all PR projects.

8. pullrequest_parser – used for all PR projects.

9. solidity-emscripten-publisher – for solidity-emscripten.

Bob has no idea what these Jenkins targets are. They may be obsolete.

1. code-coverage-run

We are making a conscious effort to move our automation scripts from Jenkins to Git to reduce the "voodoo factor" in our automation. It's still a work in progress, but there are a few key scripts we use for automation:

1. homebrew/prepare_receipt.sh – build for Homebrew

2. scripts/build_emscripten.sh – builds the Emscripten binary (for browser-solidity)

3. scripts/ethbinaries.sh – builds Windows and OS X binaries

4. scripts/ethbuild.sh – build code (all platforms)

5. scripts/ethtests.sh – runs tests (all platforms)

6. scripts/ppabuild.sh – builds bundles for PPAs

But we still have some orphaned scripts within Jenkins:

1. Creating Eth ZIP in Windows PowerShell – used to create win_eth.zip

2. github_issue_mover.py – Script for moving events from cpp-ethereum to webthree-umbrella libraries

Setting up a new Jenkins slave is a nightmare process. Here’s how to add an OS X slave. The process for other platforms will be different, but we won’t have to do that yet.

1. Install the appropriate operating software (Bob needs to log in with his Apple ID)

2. Install latest xcode from mac store

3. Install Homebrew

- Agree to the Xcode selection license

– brew update

– brew update

– Install first things first (http://www.ethdocs.org/en/latest/ethereum-clients/cpp-ethereum/building-from-source/osx.html)

– Install Ruby

—– See https://github.com/rbenv/rbenv#homebrew-on-mac-os-x

—– Brew install rbenv

—–rbenv init

—– Rbenv install 1.9.3-p551

—– Add eval “$(rbenv init –)” to ~/.bash_profile:

- Use Java web-start to connect to slaves (need to lower security settings)

– Cut-paste the PATH from the device into the configuration field for the node in Jenkins:

—– Example: /Users/administrator/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

Known Issues

1. Lack of standardized establishment

2. Lack of webthree-umbrella build

3. No automated Windows testing

4. Broken cross-repository PRs

5. Suspension Test

6. Incomplete test set

7. Did we run “ethereum/tests”?

8. Did we run “ethereum/rpc-tests”?

9. Windows box is running Windows 7 Home Edition. No RDC access.

10. Run Visual Studio 2013.

11. Should be running Windows 10 with VS2015, target is Windows 7

12. We don't have valid El Capitan binaries yet

13. No one doing Homebrew/PPA updates per loop

14. Never had a clean build?

In the next article, we will introduce "Ethereum Series (10): Introduction to Go, Java, Python, Ruby, and JS Clients"

Thanks to Azure and Bob from the Chaoxi team for participating in the translation and proofreading of "Ethereum Homestead Documentation".