mirror of
https://github.com/ethereum/go-ethereum.git
synced 2026-08-20 10:52:25 +00:00
Merge branch 'gh-pages' into feature/dev-mode
This commit is contained in:
Felix Lange
GitHub
commit
de8d321f74
41 changed files with 299 additions and 700 deletions
18
.travis.yml
Normal file
18
.travis.yml
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
language: ruby
|
||||
rvm:
|
||||
- 2.5.3
|
||||
|
||||
before_script:
|
||||
- gem install html-proofer
|
||||
|
||||
# Assume bundler is being used, therefore
|
||||
# the `install` step will run `bundle install` by default.
|
||||
script:
|
||||
- bundle exec jekyll build
|
||||
- bundle exec htmlproofer ./_site --assume-extension --allow-hash-href
|
||||
|
||||
env:
|
||||
global:
|
||||
- NOKOGIRI_USE_SYSTEM_LIBRARIES=true # speeds up installation of html-proofer
|
||||
|
||||
cache: bundler # caching bundler gem packages will speed up build
|
||||
1
Gemfile
1
Gemfile
|
|
@ -30,4 +30,5 @@ gem "wdm", "~> 0.1.0" if Gem.win_platform?
|
|||
|
||||
group :development, :test do
|
||||
gem "pry"
|
||||
gem "html-proofer"
|
||||
end
|
||||
38
_config.yml
38
_config.yml
|
|
@ -15,52 +15,66 @@ defaults:
|
|||
- scope:
|
||||
path: "*"
|
||||
values:
|
||||
root: "."
|
||||
root: "../.."
|
||||
- scope:
|
||||
path: "*/*"
|
||||
values:
|
||||
root: ".."
|
||||
root: "../.."
|
||||
|
||||
default_root: ".."
|
||||
default_root: "../.."
|
||||
|
||||
collections_dir: docs
|
||||
collections:
|
||||
getting-started:
|
||||
output: true
|
||||
caption: Getting started
|
||||
sidebar_index: 1
|
||||
frontpage: _getting-started/index.md
|
||||
install-and-build:
|
||||
output: true
|
||||
permalink: docs/:collection/:slug
|
||||
caption: Install and build
|
||||
sidebar_index: 1
|
||||
sidebar_index: 2
|
||||
frontpage: _install-and-build/Installing-Geth.md
|
||||
interface:
|
||||
output: true
|
||||
permalink: docs/:collection/:slug
|
||||
caption: Interacting with Geth
|
||||
sidebar_index: 2
|
||||
sidebar_index: 3
|
||||
support:
|
||||
output: true
|
||||
permalink: docs/:collection/:slug
|
||||
caption: Issues and support
|
||||
sidebar_index: 3
|
||||
sidebar_index: 4
|
||||
developers:
|
||||
output: true
|
||||
permalink: docs/:collection/:slug
|
||||
caption: Developer docs
|
||||
sidebar_index: 4
|
||||
sidebar_index: 5
|
||||
clef:
|
||||
output: true
|
||||
permalink: docs/:collection/:slug
|
||||
caption: Clef
|
||||
sidebar_index: 5
|
||||
sidebar_index: 6
|
||||
frontpage: _clef/Overview.md
|
||||
whisper:
|
||||
output: true
|
||||
permalink: docs/:collection/:slug
|
||||
caption: Whisper
|
||||
sidebar_index: 6
|
||||
sidebar_index: 7
|
||||
frontpage: _whisper/Whisper-Overview.md
|
||||
rpc:
|
||||
output: true
|
||||
permalink: docs/:collection/:slug
|
||||
caption: JSON RPC APIs
|
||||
sidebar_index: 7
|
||||
sidebar_index: 8
|
||||
doc:
|
||||
output: true
|
||||
permalink: docs/:collection/:slug
|
||||
caption: Other
|
||||
sidebar_index: 8
|
||||
sidebar_index: 9
|
||||
legacy:
|
||||
output: true
|
||||
permalink: docs/:collection/:slug
|
||||
caption: Legacy content
|
||||
sidebar_index: 9
|
||||
sidebar_index: 10
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
Install: /install-and-build/Installing-Geth
|
||||
Install: /docs/install-and-build/installing-geth
|
||||
Downloads: /downloads
|
||||
Documentation: /docs
|
||||
|
|
|
|||
|
|
@ -26,12 +26,12 @@ common-js:
|
|||
<span class="icon-bar"></span>
|
||||
<span class="icon-bar"></span>
|
||||
</button>
|
||||
<a class="navbar-brand" href="{% include link.html url='' %}/">Go Ethereum</a>
|
||||
<a class="navbar-brand" href="{% include link.html url='' %}">Go Ethereum</a>
|
||||
</div>
|
||||
<div id="navbar" class="navbar-collapse collapse">
|
||||
<ul class="nav navbar-nav">
|
||||
{% for link in site.data.navbar %}
|
||||
{% capture target %}{% include link.html url=link.last %}{% endcapture %}
|
||||
{% capture target %}{% include link.html url=link.last %}{% endcapture %}
|
||||
<li><a href="{{target |strip }}">{{ link.first }}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
|
|
@ -41,7 +41,12 @@ common-js:
|
|||
{{ content }}
|
||||
<hr/>
|
||||
<footer class="container">
|
||||
<p>© 2013-2019. The go-ethereum Authors.</p>
|
||||
{%- capture gh_link -%}
|
||||
https://github.com/ethereum/go-ethereum/blob/gh-pages/
|
||||
{%- if page.collection -%}{{ site.collections_dir }}/{%- endif -%}
|
||||
{{- page.path -}}
|
||||
{%- endcapture -%}
|
||||
<p>© 2013–2019. The go-ethereum Authors. <a href="{{ gh_link }}">Edit this page.</a></p>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
|
|
|||
|
|
@ -1,303 +0,0 @@
|
|||
---
|
||||
title: Clef overview
|
||||
---
|
||||
|
||||
|
||||
_A reasonably secure wallet_
|
||||
|
||||
Goal: Accommodate arbitrary high requirements for security (through _isolation_ and _separation_), while still providing _usability_.
|
||||
|
||||
Clef can be used to sign transactions and data and is meant as a replacement for geth's account management.
|
||||
This allows DApps not to depend on geth's account management. When a DApp wants to sign data it can send the data to
|
||||
the signer, the signer will then provide the user with context and asks the user for permission to sign the data. If
|
||||
the users grants the signing request the signer will send the signature back to the DApp.
|
||||
|
||||
This setup allows a DApp to connect to a remote Ethereum node and send transactions that are locally signed. This can
|
||||
help in situations when a DApp is connected to a remote node because a local Ethereum node is not available, not
|
||||
synchronised with the chain or a particular Ethereum node that has no built-in (or limited) account management.
|
||||
|
||||
Clef can run as a daemon on the same machine, or off a usb-stick like [usb armory](https://inversepath.com/usbarmory),
|
||||
or a separate VM in a [QubesOS](https://www.qubes-os.org/) type os setup.
|
||||
|
||||
|
||||
## More info
|
||||
|
||||
Check out
|
||||
|
||||
* the [tutorial](Tutorial) for some concrete examples on how the signer works.
|
||||
* the [setup docs](Setup) for some information on how to configure it to work on QubesOS or USBArmory.
|
||||
* more info about [rules](Rules)
|
||||
* the [data types](datatypes) for detailed information on the json types used in the communication between
|
||||
clef and an external UI
|
||||
|
||||
## Security model
|
||||
|
||||
The security model of the signer is as follows:
|
||||
|
||||
* One critical binary is responsible for all cryptographic ops.
|
||||
* The signer has a well-defined 'external' API - **UNTRUSTED**.
|
||||
* The signer also has bidirectional APIs with whoever invoked it, via stdin/stdout -- considered **TRUSTED**.
|
||||
* `clef` exposes API for the UI to consume,
|
||||
* `ui` exposes API for `clef` to consume
|
||||
|
||||
|
||||
The basic premise being,
|
||||
|
||||
* A small(ish) binary without dependencies,
|
||||
* that is deployed on a trusted (secure) machine,
|
||||
* which serves untrusted requests,
|
||||
* in a hostile (network) environment
|
||||
|
||||
|
||||
The general flow for signing a transaction using e.g. geth is as follows:
|
||||
|
||||
|
||||
|
||||
|
||||
Clef relies on __sign-what-you-see__. To provide as much context as possible,
|
||||
|
||||
- It parses calldata against 4byte database of method signatures.
|
||||
- It alerts the user about the origin of the request (ip, `user-agent`,`transport`, `Origin`)
|
||||
|
||||
|
||||
# Setup scenarios
|
||||
|
||||
One setup scenario is to use virtualization, e.g. within QubesOS, where to
|
||||
Clef is deployed on a non-networked machine (`ethvault` below)
|
||||
|
||||
|
||||
|
||||
|
||||
Another option is to deploy Clef on a separate physical device, e.g. USB Armory,
|
||||
and access the CLI-UI via SSH on the interface provided by the USB ethernet
|
||||
adapter, and expose HTTP interface via tunneling.
|
||||
|
||||
|
||||
|
||||
|
||||
## Multi-user setup
|
||||
|
||||
Clef can also be used in a situation where several people need to make transactions,
|
||||
and some other person (finance) does approval.
|
||||
|
||||
|
||||
## Architecture
|
||||
|
||||
Clef is divided into two parts
|
||||
|
||||
- Clef
|
||||
- UI
|
||||
|
||||
Clef has a CLI natively, but a more refined UI can start `clef` in _standard-input-output-IO mode_.
|
||||
|
||||
---
|
||||
|
||||
Clef _native_ CLI user interface example:
|
||||
```
|
||||
--------- Transaction request-------------
|
||||
to: 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192
|
||||
from: 0x8A8eAFb1cf62BfBeb1741769DAE1a9dd47996192 [chksum ok]
|
||||
value: 1 wei
|
||||
gas: 0x1 (1)
|
||||
gasprice: 1 wei
|
||||
nonce: 0x1 (1)
|
||||
|
||||
Request context:
|
||||
127.0.0.1:59870 -> HTTP/1.1 -> localhost:8550
|
||||
|
||||
Additional HTTP header data, provided by the external caller:
|
||||
User-Agent: Go-http-client/1.1
|
||||
Origin:
|
||||
-------------------------------------------
|
||||
Approve? [y/N]:
|
||||
> y
|
||||
Enter password to approve:
|
||||
```
|
||||
|
||||
`clef` will invoke API-methods on the UI whenever an action is required.
|
||||
|
||||
- `ui_ApproveTx`
|
||||
- `ui_ApproveListing`
|
||||
- ...
|
||||
|
||||
This is called the `internal api`, or `ui-api`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Rules
|
||||
|
||||
Historically, a user who wanted an easy way to sign transactions repeatedly, would
|
||||
use some variant of `personal.unlock`. That is a very insecure way of managing
|
||||
accounts, and is not present in Clef. Clef instead implements Rules, which can
|
||||
be customized to provide the same type of ease of use, but with much higher
|
||||
security-guarantees.
|
||||
|
||||
Examples of rules:
|
||||
|
||||
* "I want to allow transactions with contract `CasinoDapp`, with up to `0.05 ether` in value to maximum `1 ether` per 24h period"
|
||||
* "I want to allow transaction to contract `EthAlarmClock` with `data`=`0xdeadbeef`, if `value=0`, `gas < 44k` and `gasPrice < 40Gwei`"
|
||||
|
||||
Clef comes with a Javascript VM which can evaluate a ruleset file. The ruleset
|
||||
file has access to the same interface that an external UI would have.
|
||||
|
||||
#### Example 1: Allow listing
|
||||
|
||||
```javascript
|
||||
function ApproveListing(){
|
||||
return "Approve"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### Example 2: Allow destination
|
||||
|
||||
```javascript
|
||||
function ApproveTx(r){
|
||||
var ok = "0x0000000000000000000000000000000000001337";
|
||||
var nope = "0x000000000000000000000000000000000000dead";
|
||||
if(r.transaction.from.toLowerCase()== ok){
|
||||
return "Approve"
|
||||
}
|
||||
if(r.transaction.from.toLowerCase()==nope){
|
||||
return "Reject"
|
||||
}
|
||||
// Otherwise goes to manual processing
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### Example 3: a rate-limited window
|
||||
|
||||
|
||||
```javascript
|
||||
function big(str){
|
||||
if(str.slice(0,2) == "0x"){ return new BigNumber(str.slice(2),16)}
|
||||
return new BigNumber(str)
|
||||
}
|
||||
|
||||
// Time window: 1 week
|
||||
var window = 1000* 3600*24*7;
|
||||
// Limit : 1 ether
|
||||
var limit = new BigNumber("1e18");
|
||||
|
||||
function isLimitOk(transaction){
|
||||
var value = big(transaction.value)
|
||||
// Start of our window function
|
||||
var windowstart = new Date().getTime() - window;
|
||||
|
||||
var txs = [];
|
||||
var stored = storage.Get('txs');
|
||||
|
||||
if(stored != ""){
|
||||
txs = JSON.parse(stored)
|
||||
}
|
||||
// First, remove all that have passed out of the time-window
|
||||
var newtxs = txs.filter(function(tx){return tx.tstamp > windowstart});
|
||||
console.log(txs, newtxs.length);
|
||||
// Secondly, aggregate the current sum
|
||||
sum = new BigNumber(0)
|
||||
sum = newtxs.reduce(function(agg, tx){ return big(tx.value).plus(agg)}, sum);
|
||||
// Would we exceed weekly limit ?
|
||||
return sum.plus(value).lt(limit)
|
||||
|
||||
}
|
||||
function ApproveTx(r){
|
||||
if (isLimitOk(r.transaction)){
|
||||
return "Approve"
|
||||
}
|
||||
return "Nope"
|
||||
}
|
||||
|
||||
/**
|
||||
* OnApprovedTx(str) is called when a transaction has been approved and signed.
|
||||
*/
|
||||
function OnApprovedTx(resp){
|
||||
var value = big(resp.tx.value)
|
||||
var txs = []
|
||||
// Load stored transactions
|
||||
var stored = storage.Get('txs');
|
||||
if(stored != ""){
|
||||
txs = JSON.parse(stored)
|
||||
}
|
||||
// Add this to the storage
|
||||
txs.push({tstamp: new Date().getTime(), value: value});
|
||||
storage.Put("txs", JSON.stringify(txs));
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### A note about passwords...
|
||||
|
||||
In normal mode, passwords are supplied via UI.
|
||||
In order to use rules, keystore passwords must be stored in `clef`. Clef uses an encrypted container to store
|
||||
|
||||
- Keystore passwords
|
||||
- SHA256 hash of ruleset file
|
||||
- Key/value pairs accessible to the Javascript ruleset implementation
|
||||
- This, in turn, enables the ruleset files to save data and thus implement
|
||||
things like the rate-limited window.
|
||||
|
||||
---
|
||||
## External UIs
|
||||
|
||||
The `clef` daemon can be wrapped by an external process, which can then take
|
||||
the part of a UI.
|
||||
|
||||
|
||||
QT UI on Ubuntu
|
||||
|
||||
|
||||
GTK UI on Qubes
|
||||
|
||||
|
||||
|
||||
### Rules for UI apis
|
||||
|
||||
A UI should conform to the following rules.
|
||||
|
||||
* A UI MUST NOT load any external resources that were not embedded/part of the UI package.
|
||||
* For example, not load icons, stylesheets from the internet
|
||||
* Not load files from the filesystem, unless they reside in the same local directory (e.g. config files)
|
||||
* A Graphical UI MUST show the blocky-identicon for ethereum addresses.
|
||||
* A UI MUST warn display approproate warning if the destination-account is formatted with invalid checksum.
|
||||
* A UI MUST NOT open any ports or services
|
||||
* The signer opens the public port
|
||||
* A UI SHOULD verify the permissions on the signer binary, and refuse to execute or warn if permissions allow non-user write.
|
||||
* A UI SHOULD inform the user about the `SHA256` or `MD5` hash of the binary being executed
|
||||
* A UI SHOULD NOT maintain a secondary storage of data, e.g. list of accounts
|
||||
* The signer provides accounts
|
||||
* A UI SHOULD, to the best extent possible, use static linking / bundling, so that required libraries are bundled
|
||||
along with the UI.
|
||||
|
||||
|
||||
### UI Implementations
|
||||
|
||||
There are a couple of implementation for a UI. We'll try to keep this list up to date. Currently, none of these are finished.
|
||||
|
||||
| Name | Repo | UI type| No external resources| Blocky support| Verifies permissions | Hash information | No secondary storage | Statically linked| Can modify parameters|
|
||||
| ---- | ---- | -------| ---- | ---- | ---- |---- | ---- | ---- | ---- |
|
||||
| QtSigner| https://github.com/holiman/qtsigner/| Python3/QT-based| :+1:| :+1:| :+1:| :+1:| :+1:| :x: | :+1: (partially)|
|
||||
| GtkSigner| https://github.com/holiman/gtksigner| Python3/GTK-based| :+1:| :x:| :x:| :+1:| :+1:| :x: | :x: |
|
||||
| Frame | https://github.com/floating/frame/commits/go-signer| Electron-based| :x:| :x:| :x:| :x:| ?| :x: | :x: |
|
||||
| Clef UI| https://github.com/ethereum/clef-ui| Golang/QT-based| :+1:| :+1:| :x:| :+1:| :+1:| :x: | :+1: (approve tx only)|
|
||||
|
||||
|
||||
## Geth integration
|
||||
|
||||
The `--signer` CLI option for `geth` means that `geth` can use `clef` as a
|
||||
backend signer.
|
||||
|
||||
Although some things, like `personal.unlock` disappears, `clef` has otherwise
|
||||
a corresponding (or exceeding) feature set:
|
||||
|
||||
* Full set of options for hardware interaction (derivation etc) via UI
|
||||
* EIP 191/712 - signing typed data
|
||||
|
||||
Clef can even sign Clique headers in a private network
|
||||
|
||||
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ There are two ways that this can be achieved: integrated via Qubes or integrated
|
|||
Qubes provdes 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.
|
||||
|
|
@ -49,11 +49,11 @@ 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.
|
||||
|
||||
[qubes.Clefsign](qubes/qubes.Clefsign):
|
||||
[qubes.Clefsign](qubes.Clefsign):
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
|
@ -97,7 +97,7 @@ with minimal requirements.
|
|||
On the `client` qube, we need to create a listener which will receive the request from the Dapp, and proxy it.
|
||||
|
||||
|
||||
[qubes-client.py](qubes/client/qubes-client.py):
|
||||
[qubes-client.py](qubes-client.py):
|
||||
|
||||
```python
|
||||
|
||||
|
|
@ -140,11 +140,11 @@ $ cat newaccnt.json| qrexec-client-vm debian-work qubes.Clefsign
|
|||
|
||||
This should pop up first a dialog to allow the IPC call:
|
||||
|
||||
|
||||
|
||||
|
||||
Followed by a GTK-dialog to approve the operation
|
||||
|
||||
|
||||
|
||||
|
||||
To test the full flow, we use the client wrapper. Start it on the `client` qube:
|
||||
```
|
||||
|
|
@ -182,7 +182,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
|
||||
form other qubes.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -280,7 +280,7 @@ Response
|
|||
### account_signTypedData
|
||||
|
||||
#### Sign data
|
||||
Signs a chunk of structured data conformant to [EIP712]([EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md)) and returns the calculated signature.
|
||||
Signs a chunk of structured data conformant to [EIP712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md) and returns the calculated signature.
|
||||
|
||||
#### Arguments
|
||||
- account [address]: account to sign with
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Go.*
|
|||
## Token contract
|
||||
|
||||
To avoid falling into the fallacy of useless academic examples, we're going to take the
|
||||
official [Token contract](https://ethereum.org/token) as the base for introducing the Go
|
||||
official Token contract as the base for introducing the Go
|
||||
native bindings. If you're unfamiliar with the contract, skimming the linked page should
|
||||
probably be enough, the details aren't relevant for now. *In short the contract implements
|
||||
a custom token that can be deployed on top of Ethereum.* To make sure this tutorial doesn't
|
||||
|
|
@ -83,7 +83,7 @@ of the contract itself, and need to specify a `backend` through which to access
|
|||
The binding generator provides out of the box an RPC backend through which you can attach
|
||||
to an existing Ethereum node via IPC, HTTP or WebSockets.
|
||||
|
||||
We'll use the foundation's [Unicorn](https://ethereum.org/donate) token contract deployed
|
||||
We'll use the foundation's Unicorn token contract deployed
|
||||
on the testnet to demonstrate calling contract methods. It is deployed at the address
|
||||
`0x21e6fc92f93c8a1bb41e2be64b4e1f88a54d3576`.
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ To get you hands dirty, here's a code snippet that will
|
|||
* Display some initial infos about your node
|
||||
* Subscribe to new blocks and display them live as they arrive
|
||||
|
||||
<img src="http://i.imgur.com/LyTCCqg.png" width="512px" />
|
||||
<img src="http://i.imgur.com/LyTCCqg.png" width="512px" alt="Android in-process node"/>
|
||||
|
||||
```java
|
||||
import org.ethereum.geth.*;
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Peer-to-peer
|
||||
---
|
||||
The peer to peer package ([go-ethereum/p2p](https://github.com/ethereum/go-ethereum/tree/develop/p2p)) allows you to rapidly and easily add peer to peer networking to any type of application. The p2p package is set up in a modular structure and extending the p2p with your own additional sub protocols is easy and straight forward.
|
||||
The peer to peer package ([go-ethereum/p2p](https://github.com/ethereum/go-ethereum/tree/master/p2p)) allows you to rapidly and easily add peer to peer networking to any type of application. The p2p package is set up in a modular structure and extending the p2p with your own additional sub protocols is easy and straight forward.
|
||||
|
||||
Starting the p2p service only requires you setup a `p2p.Server{}` with a few settings:
|
||||
|
||||
|
|
|
|||
|
|
@ -144,7 +144,7 @@ the following into `<datadir>/geth/static-nodes.json`:
|
|||
]
|
||||
```
|
||||
|
||||
You can also add static nodes at runtime via the js console using [`admin.addPeer()`](../interface/JavaScript-Console#addpeer):
|
||||
You can also add static nodes at runtime via the js console using [`admin.addPeer()`](../interface/management-apis#admin_addpeer):
|
||||
|
||||
```js
|
||||
admin.addPeer("enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303")
|
||||
|
|
|
|||
|
|
@ -14,8 +14,8 @@ Specifications of all ethereum technologies, languages, protocols, etc.
|
|||
### Specs
|
||||
|
||||
- [JavaScript API](https://github.com/ethereum/wiki/wiki/JavaScript-API#a)
|
||||
- [Generic JSON RPC](https://github.com/ethereum/wiki/JSON-RPC)
|
||||
- [JSRE admin API](../interface/JavaScript-Console#console-api)
|
||||
- [Generic JSON RPC](https://github.com/ethereum/wiki/wiki/JSON-RPC)
|
||||
- [JSRE admin API](../interface/javascript-console)
|
||||
- [RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
- [ÐΞVp2p Wire Protocol](https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol)
|
||||
- [Web3 Secret Storage](https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition)
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Ethereum on Android
|
|||
---
|
||||
Building Geth for Android is a non trivial task, as it requires cross compiling external C dependencies ([GNU Arithmetic Library](https://gmplib.org/)); internal C dependencies ([ethash](https://github.com/ethereum/ethash)); as well as the entire CGO enabled Go code-base to Android. This is further complicated by the Position Independent Executables (PIE) security feature introduced since Android 4.1 Jelly Bean, requiring different compiler and linker options based on the target Android platform version.
|
||||
|
||||
To cope with all the build issues, the [`xgo`](https://github.com/karalabe/xgo) CGO enabled Go cross compiler is used, which assembles an entire multi-platform cross compiler suite into a single mega docker container. Details about using `xgo` can be found in the project's [README](https://github.com/karalabe/xgo/blob/master/README.md), with Ethereum specifics on the go-ethereum cross compilation [wiki page](Cross-compiling-Ethereum).
|
||||
To cope with all the build issues, the [`xgo`](https://github.com/karalabe/xgo) CGO enabled Go cross compiler is used, which assembles an entire multi-platform cross compiler suite into a single mega docker container. Details about using `xgo` can be found in the project's [README](https://github.com/karalabe/xgo/blob/master/README.md), with Ethereum specifics on the [go-ethereum cross compilation](../developers/cross-compiling-ethereum).
|
||||
|
||||
TL;DR
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Both types of accounts have an ether balance.
|
|||
|
||||
Transactions can be fired from from both types of accounts, though contracts only fire transactions in response to other transactions that they have received. Therefore, all action on ethereum block chain is set in motion by transactions fired from externally controlled accounts.
|
||||
|
||||
The simplest transactions are ether transfer transactions. But before we go into that you should read up on [accounts](../how-to/Managing-your-accounts) and perhaps on [mining](../how-to/Mining).
|
||||
The simplest transactions are ether transfer transactions. But before we go into that you should read up on [accounts](../interface/managing-your-accounts) and perhaps on [mining](../legacy/mining).
|
||||
|
||||
## Ether transfer
|
||||
|
||||
|
|
@ -34,10 +34,10 @@ Contracts can receive transfers just like externally controlled accounts, but th
|
|||
blockchain 上で有効となる contract は Ethereum 特別仕様の バイナリの形式で、EVM byte コード と呼ばれます。
|
||||
しかしながら、典型的には、contract は [solidity](https://github.com/ethereum/wiki/wiki/Solidity-Tutorial) のような高級言語で記述され、blockchain 上に upload するために、この byte コードへコンパイルされます。
|
||||
|
||||
flontier リリースでは、geth は Christian R. と Lefteris K が手がけた、コマンドライン [solidity コンパイラ](https://github.com/ethereum/cpp-ethereum/tree/develop/solc) である `solc` をシステムコールで呼び出すことを通して、solidity コンパイルをサポートしています。
|
||||
flontier リリースでは、geth は Christian R. と Lefteris K が手がけた、コマンドライン [solidity コンパイラ](https://solidity.readthedocs.io/en/latest/installing-solidity.html) である `solc` をシステムコールで呼び出すことを通して、solidity コンパイルをサポートしています。
|
||||
以下もお試しください。
|
||||
* [Solidity realtime compiler](https://chriseth.github.io/cpp-ethereum/) (by Christian R)
|
||||
* [Cosmo](http://meteor-dapp-cosmo.meteor.com)
|
||||
* [Cosmo](https://github.com/cosmo-project/meteor-dapp-cosmo)
|
||||
* [Mix]()
|
||||
* [AlethZero]()
|
||||
|
||||
|
|
@ -118,7 +118,7 @@ You are ready to compile solidity code in the `geth` JS console using [`eth.comp
|
|||
}
|
||||
```
|
||||
|
||||
The compiler is also available via [RPC](https://github.com/ethereum/wiki/JSON-RPC) and therefore via [web3.js](https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethcompilesolidity) to any in-browser Ðapp connecting to `geth` via RPC.
|
||||
The compiler is also available via [RPC](https://github.com/ethereum/wiki/wiki/JSON-RPC) and therefore via [web3.js](https://github.com/ethereum/wiki/wiki/JavaScript-API#web3ethcompilesolidity) to any in-browser Ðapp connecting to `geth` via RPC.
|
||||
|
||||
The following example shows how you interface `geth` via JSON-RPC to use the compiler.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Setting up monitoring on local cluster
|
||||
---
|
||||
This page describes how to set up a monitoring site, [like this one](http://eth-netstats.herokuapp.com/), for your private network. It builds upon [this wiki article](Setting-up-private-network-or-local-cluster) and assumes you've created a local cluster using [this script (gethcluster.sh)](https://github.com/ethersphere/eth-utils).
|
||||
This page describes how to set up a monitoring site for your private network. It builds upon [this page](setting-up-private-network-or-local-cluster) and assumes you've created a local cluster using [this script (gethcluster.sh)](https://github.com/ethersphere/eth-utils).
|
||||
|
||||
The monitoring system consists of two components:
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: Setting up private network or local cluster
|
|||
This page describes how to set up a local cluster of nodes, advise how to make it private, and how to hook up your nodes on the eth-netstat network monitoring app.
|
||||
A fully controlled ethereum network is useful as a backend for network integration testing (core developers working on issues related to networking/blockchain synching/message propagation, etc or DAPP developers testing multi-block and multi-user scenarios).
|
||||
|
||||
We assume you are able to build `geth` following the [build instructions](../install-and-build/Building-Ethereum)
|
||||
We assume you are able to build `geth` following the [build instructions](../install-and-build/build-from-source)
|
||||
|
||||
## Setting up multiple nodes
|
||||
|
||||
|
|
@ -115,5 +115,5 @@ I0216 10:01:40.094089 p2p/discover/udp.go:227] Listening, enode://890b6b5367ef60
|
|||
|
||||
[This page](https://github.com/ethereum/wiki/wiki/Network-Status) describes how to use the [The Ethereum (centralised) network status monitor (known sometimes as "eth-netstats")](http://stats.ethdev.com) to monitor your nodes.
|
||||
|
||||
[This page](Setting-up-monitoring-on-local-cluster) or [this README](https://github.com/ethersphere/eth-utils)
|
||||
[This page](../doc/setting-up-monitoring-on-local-cluster) or [this README](https://github.com/ethersphere/eth-utils)
|
||||
describes how you set up your own monitoring service for a (private or public) local cluster.
|
||||
127
docs/_getting-started/index.md
Normal file
127
docs/_getting-started/index.md
Normal file
|
|
@ -0,0 +1,127 @@
|
|||
---
|
||||
title: Getting Started with Geth
|
||||
permalink: getting-started
|
||||
---
|
||||
|
||||
## Installing
|
||||
|
||||
You can install the Go implementation of Ethereum in a variety of ways. These include installing it via your favorite package manager; downloading a standalone pre-built binary; running as a docker container; or building it yourself. This section highlights the common options, but you can find others in the left hand menu, or in the [install and build](/install-and-build/Installing-Geth) section.
|
||||
|
||||
### Install on macOS via Homebrew
|
||||
|
||||
You can install go-ethereum on macOS using [our Homebrew tap](https://github.com/ethereum/homebrew-ethereum). If you don't have Homebrew, [install it first](http://brew.sh/).
|
||||
|
||||
Then run the following commands to add the tap and install geth:
|
||||
|
||||
```shell
|
||||
brew tap ethereum/ethereum
|
||||
brew install ethereum
|
||||
```
|
||||
|
||||
_[Read this guide](/install-and-build/Installing-Geth#install-on-macos-via-homebrew) further Homebrew options._
|
||||
|
||||
### Install on Ubuntu via PPAs
|
||||
|
||||
You can install go-ethereum on Ubuntu-based distributions using the built-in launchpad PPAs (Personal Package Archives). We provide a single PPA repository with both our stable and our development releases for Ubuntu versions `trusty`, `xenial`, `zesty` and `artful`.
|
||||
|
||||
Install dependencies first:
|
||||
|
||||
```shell
|
||||
sudo apt-get install software-properties-common
|
||||
```
|
||||
|
||||
To enable our launchpad repository run:
|
||||
|
||||
```shell
|
||||
sudo add-apt-repository -y ppa:ethereum/ethereum
|
||||
```
|
||||
|
||||
After that you can install the stable version of go-ethereum:
|
||||
|
||||
```shell
|
||||
sudo apt-get update
|
||||
sudo apt-get install ethereum
|
||||
```
|
||||
|
||||
_[Read this guide](/install-and-build/Installing-Geth#install-on-ubuntu-via-ppas) for further Ubuntu options._
|
||||
|
||||
### Install on Windows
|
||||
|
||||
_Although we were shipping Chocolatey packages for a time after the Frontier release, the constant manual approval process led to us stopping distribution. We will try to negotiate trusted package status for go-ethereum so the Chocolatey option is available again._
|
||||
|
||||
Until then grab a Windows installer from our [downloads](https://geth.ethereum.org/downloads) page.
|
||||
|
||||
### Download standalone binary
|
||||
|
||||
We distribute all our stable releases and development builds as standalone binaries. These are useful for scenarios where you'd like to: a) install a specific version of our code (e.g., for reproducible environments); b) install on machines without internet access (e.g., air gapped computers); or c) do not like automatic updates and would rather manually install software.
|
||||
|
||||
We create the following standalone binaries:
|
||||
|
||||
- 32bit, 64bit, ARMv5, ARMv6, ARMv7 and ARM64 archives (`.tar.gz`) on Linux
|
||||
- 64bit archives (`.tar.gz`) on macOS
|
||||
- 32bit and 64bit archives (`.zip`) and installers (`.exe`) on Windows
|
||||
|
||||
For all binaries we provide two options, one containing only Geth, and another containing Geth along with all the developer tools from our repository (`abigen`, `bootnode`, `disasm`, `evm`, `rlpdump`). Read our [`README`](https://github.com/ethereum/go-ethereum#executables) for more information about these executables.
|
||||
|
||||
To download these binaries, head to the [Go Ethereum Downloads](https://geth.ethereum.org/downloads) page.
|
||||
|
||||
### Run inside docker container
|
||||
|
||||
We maintain a Docker image with recent snapshot builds from our `develop` branch on DockerHub. In addition to the container based on Ubuntu (158 MB), there is a smaller image using Alpine Linux (35 MB). To use the alpine [tag](https://hub.docker.com/r/ethereum/client-go/tags), replace `ethereum/client-go` with `ethereum/client-go:alpine` in the examples below.
|
||||
|
||||
To pull the image and start a node, run these commands:
|
||||
|
||||
```shell
|
||||
docker pull ethereum/client-go
|
||||
docker run -it -p 30303:30303 ethereum/client-go
|
||||
```
|
||||
|
||||
_[Read this guide](/install-and-build/Installing-Geth#run-inside-docker-container) for further Docker options._
|
||||
|
||||
## Starting a node
|
||||
|
||||
### Create an account
|
||||
|
||||
Before starting Geth you first need to create an account that represents a key pair. Use the following command to create a new account and set a password for that account:
|
||||
|
||||
```shell
|
||||
geth account new
|
||||
```
|
||||
|
||||
_[Read this guide](/interface/Managing-your-accounts) for more details on importing existing Ethereum accounts and other uses of the `account` command._
|
||||
|
||||
### Sync modes
|
||||
|
||||
Running Geth starts an Ethereum node that can join any existing network, or create a new one. You can start Geth in one of three different sync modes using the `--syncmode "{mode}"` argument that determines what sort of node it is in the network.
|
||||
|
||||
These are:
|
||||
|
||||
- **Full**: Downloads all blocks (including headers, transactions and receipts) and generates the state of the blockchain incrementally by executing every block.
|
||||
- **Fast** (Default): Downloads all blocks (including headers, transactions and receipts), verifies all headers, and downloads the state and verifies it against the headers.
|
||||
- **Light**: Downloads all block headers, block data, and verifies some randomly.
|
||||
|
||||
For example:
|
||||
|
||||
```shell
|
||||
geth --syncmode "light"
|
||||
```
|
||||
|
||||
### Connect to node
|
||||
|
||||
Once you have an account and Geth is running, you can interact with it by opening another terminal and using the following command to open a JavaScript console:
|
||||
|
||||
```shell
|
||||
geth attach
|
||||
```
|
||||
|
||||
In the console you can issue any of the Geth commands, for example, to list all the accounts on the node, use:
|
||||
|
||||
```shell
|
||||
eth.accounts
|
||||
```
|
||||
|
||||
You can also enter the console directly when you start the node with the `console` command:
|
||||
|
||||
```shell
|
||||
geth --syncmode "light" console
|
||||
```
|
||||
|
|
@ -23,9 +23,9 @@ The default data directory locations are platform specific:
|
|||
|
||||
Accounts are stored in the `keystore` subdirectory. The contents of this directories should be transportable between nodes, platforms, implementations (C++, Go, Python).
|
||||
|
||||
To configure the location of the data directory, the `--datadir` parameter can be specified. See [CLI Options](../interface/Command-Line-Options) for more details.
|
||||
To configure the location of the data directory, the `--datadir` parameter can be specified. See [CLI Options](../interface/command-line-options) for more details.
|
||||
|
||||
_**Note:** The [Ethash DAG](../how-to/Mining#ethash-dag) is stored at `~/.ethash` (Mac/Linux) or `%APPDATA%\Ethash` (Windows) so that it can be reused by all clients. You can store this in a different location by using a symbolic link._
|
||||
_**note:** the [ethash dag](../legacy/mining) is stored at `~/.ethash` (Mac/Linux) or `%APPDATA%\Ethash` (Windows) so that it can be reused by all clients. You can store this in a different location by using a symbolic link._
|
||||
|
||||
## Upgrades
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: Build from source
|
||||
---
|
||||
<!-- TODO: Maybe move? -->
|
||||
|
||||
## Build from source
|
||||
|
||||
Go Ethereum (as its name implies) is written in [Go](https://golang.org), and as such to build from source code you need to have at least Go 1.7 installed (preferably the latest version, currently at 1.9.2). This guide does not go into details on how to install Go itself, for that please read the [Go installation instructions](https://golang.org/doc/install).
|
||||
|
||||
Assuming you have Go installed, you can download our project via:
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Developers' guide
|
||||
---
|
||||
**NOTE: These instructions are for people who want to contribute Go source code changes.
|
||||
If you just want to run ethereum, use the normal [Installation Instructions](Installing-Geth)**
|
||||
If you just want to run ethereum, use the normal [Installation Instructions](installing-geth)**
|
||||
|
||||
This document is the entry point for developers of the Go implementation of Ethereum. Developers here refer to the hands-on: who are interested in build, develop, debug, submit a bug report or pull request or contribute code to go-ethereum.
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ go-ethereum exectuables can be built individually. To build just geth, use:
|
|||
go install -v ./cmd/geth
|
||||
```
|
||||
|
||||
Read about cross compilation of go-ethereum [here](../doc/Cross-compiling-Ethereum).
|
||||
read about cross compilation of go-ethereum [here](../developers/cross-compiling-ethereum).
|
||||
|
||||
### Git flow
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ for more see [go test flags](http://golang.org/cmd/go/#hdr-Description_of_testin
|
|||
### Metrics and monitoring
|
||||
|
||||
`geth` can do node behaviour monitoring, aggregation and show performance metric charts.
|
||||
Read about [metrics and monitoring](../doc/Metrics-and-Monitoring)
|
||||
read about [metrics and monitoring](../doc/metrics-and-monitoring)
|
||||
|
||||
### Getting Stack Traces
|
||||
|
||||
|
|
@ -126,7 +126,7 @@ PRs need to be based on and opened against the `master` branch (unless by explic
|
|||
agreement, you contribute to a complex feature branch).
|
||||
|
||||
Your PR will be reviewed according to the [Code Review
|
||||
Guidelines](../doc/Code-Review-Guidelines).
|
||||
guidelines](../developers/code-review-guidelines).
|
||||
|
||||
We encourage a PR early approach, meaning you create the PR the earliest even without the
|
||||
fix/feature. This will let core devs and other volunteers know you picked up an issue.
|
||||
|
|
@ -134,8 +134,8 @@ These early PRs should indicate 'in progress' status.
|
|||
|
||||
## Dev Tutorials (mostly outdated)
|
||||
|
||||
* [Private networks, local clusters and monitoring](../doc/Setting-up-private-network-or-local-cluster)
|
||||
* [private networks, local clusters and monitoring](../doc/setting-up-private-network-or-local-cluster)
|
||||
|
||||
* [P2P 101](../doc/Peer-to-Peer): a tutorial about setting up and creating a p2p server and p2p sub protocol.
|
||||
* [p2p 101](../developers/peer-to-peer): a tutorial about setting up and creating a p2p server and p2p sub protocol.
|
||||
|
||||
* [How to Whisper](../doc/How-to-Whisper): an introduction to whisper.
|
||||
* [how to whisper](../whisper/whisper-overview): an introduction to whisper.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: JavaScript console
|
|||
---
|
||||
Ethereum implements a **javascript runtime environment** (JSRE) that can be used in either interactive (console) or non-interactive (script) mode.
|
||||
|
||||
Ethereum's Javascript console exposes the full [web3 JavaScript Dapp API](https://github.com/ethereum/wiki/wiki/JavaScript-API) and the [admin API](JavaScript-Console#javascript-console-api).
|
||||
Ethereum's Javascript console exposes the full [web3 JavaScript Dapp API](https://github.com/ethereum/wiki/wiki/JavaScript-API) and the admin API.
|
||||
|
||||
## Interactive use: the JSRE REPL Console
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ The attach node accepts an endpoint in case the geth node is running with a non
|
|||
$ geth attach http://191.168.1.1:8545
|
||||
$ geth attach ws://191.168.1.1:8546
|
||||
|
||||
Note that by default the geth node doesn't start the http and weboscket service and not all functionality is provided over these interfaces due to security reasons. These defaults can be overridden when the `--rpcapi` and `--wsapi` arguments when the geth node is started, or with [admin.startRPC](Management-APIs#admin_startrpc) and [admin.startWS](Management-APIs#admin_startws).
|
||||
Note that by default the geth node doesn't start the http and weboscket service and not all functionality is provided over these interfaces due to security reasons. These defaults can be overridden when the `--rpcapi` and `--wsapi` arguments when the geth node is started, or with [admin.startRPC](management-apis#admin_startrpc) and [admin.startWS](management-apis#admin_startws).
|
||||
|
||||
If you need log information, start with:
|
||||
|
||||
|
|
@ -72,6 +72,6 @@ In addition to the full functionality of JS (as per ECMA5), the ethereum JSRE is
|
|||
|
||||
# Management APIs
|
||||
|
||||
Beside the official [DApp API](https://github.com/ethereum/wiki/JSON-RPC) interface the go ethereum node has support for additional management API's. These API's are offered using [JSON-RPC](http://www.jsonrpc.org/specification) and follow the same conventions as used in the DApp API. The go ethereum package comes with a console client which has support for all additional API's.
|
||||
Beside the official [DApp API](https://github.com/ethereum/wiki/wiki/JSON-RPC) interface the go ethereum node has support for additional management API's. These API's are offered using [JSON-RPC](http://www.jsonrpc.org/specification) and follow the same conventions as used in the DApp API. The go ethereum package comes with a console client which has support for all additional API's.
|
||||
|
||||
[The management API has its own wiki page](Management-APIs).
|
||||
[The management API has its own page](management-apis).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Management APIs
|
||||
---
|
||||
Beside the official [DApp APIs](https://github.com/ethereum/wiki/JSON-RPC) interface go-ethereum
|
||||
Beside the official [DApp APIs](https://github.com/ethereum/wiki/wiki/JSON-RPC) interface go-ethereum
|
||||
has support for additional management APIs. Similar to the DApp APIs, these are also provided using
|
||||
[JSON-RPC](http://www.jsonrpc.org/specification) and follow exactly the same conventions. Geth comes
|
||||
with a console client which has support for all additional APIs described here.
|
||||
|
|
@ -58,7 +58,7 @@ These additional APIs follow the same conventions as the official DApp APIs. Web
|
|||
[extended](https://github.com/ethereum/web3.js/pull/229) and used to consume these additional APIs.
|
||||
|
||||
The different functions are split into multiple smaller logically grouped APIs. Examples are given
|
||||
for the [JavaScript console](JavaScript-Console) but
|
||||
for the [JavaScript console](javascript-console) but
|
||||
can easily be converted to an RPC request.
|
||||
|
||||
**2 examples:**
|
||||
|
|
@ -90,32 +90,33 @@ extra management API namespaces:
|
|||
|
||||
| [admin](#admin) | [debug](#debug) | [miner](#miner) | [personal](#personal) | [txpool](#txpool) |
|
||||
| :--------------------------- | :----------------------------------------------- | :---------------------------------- | :--------------------------------------- | :------------------------- |
|
||||
| [addPeer](#admin_addpeer) | [backtraceAt](#debug_backtraceAt) | [setExtra](#miner_setextra) | [ecRecover](#personal_ecrecover) | [content](#txpool_content) |
|
||||
| [datadir](#datadir) | [blockProfile](#debug_blockProfile) | [setGasPrice](#miner_setgasprice) | [importRawKey](#personal_importrawkey) | [inspect](#txpool_inspect) |
|
||||
| [nodeInfo](#admin_nodeinfo) | [cpuProfile](#debug_cpuProfile) | [start](#miner_start) | [listAccounts](#personal_listaccounts) | [status](#txpool_status) |
|
||||
| [addPeer](#admin_addpeer) | [backtraceAt](#debug_backtraceat) | [setExtra](#miner_setextra) | [ecRecover](#personal_ecrecover) | [content](#txpool_content) |
|
||||
| [datadir](#admin_datadir) | [blockProfile](#debug_blockprofile) | [setGasPrice](#miner_setgasprice) | [importRawKey](#personal_importrawkey) | [inspect](#txpool_inspect) |
|
||||
| [nodeInfo](#admin_nodeinfo) | [cpuProfile](#debug_cpuprofile) | [start](#miner_start) | [listAccounts](#personal_listaccounts) | [status](#txpool_status) |
|
||||
| [peers](#admin_peers) | [dumpBlock](#debug_dumpblock) | [stop](#miner_stop) | [lockAccount](#personal_lockaccount) | |
|
||||
| [setSolc](#admin_setcolc) | [gcStats](#debug_gcStats) | [getHashrate](#miner_gethashrate) | [newAccount](#personal_newaccount) | |
|
||||
| [setSolc](#admin_setsolc) | [gcStats](#debug_gcstats) | [getHashrate](#miner_gethashrate) | [newAccount](#personal_newaccount) | |
|
||||
| [startRPC](#admin_startrpc) | [getBlockRlp](#debug_getblockrlp) | [setEtherbase](#miner_setetherbase) | [unlockAccount](#personal_unlockaccount) | |
|
||||
| [startWS](#admin_startws) | [goTrace](#debug_goTrace) | | [sendTransaction](#personal_sendtransaction) | |
|
||||
| [stopRPC](#admin_stoprpc) | [memStats](#debug_memStats) | | [sign](#personal_sign) | |
|
||||
| [startWS](#admin_startws) | [goTrace](#debug_gotrace) | | [sendTransaction](#personal_sendtransaction) | |
|
||||
| [stopRPC](#admin_stoprpc) | [memStats](#debug_memstats) | | [sign](#personal_sign) | |
|
||||
| [stopWS](#admin_stopws) | [seedHash](#debug_seedhash)[sign](#personal_sign)| | | |
|
||||
| | [setBlockProfileRate](#debug_setBlockProfileRate) | | | |
|
||||
| | [setBlockProfileRate](#debug_setblockprofilerate) | | | |
|
||||
| | [setHead](#debug_sethead) | | | |
|
||||
| | [stacks](#debug_stacks) | | | |
|
||||
| | [startCPUProfile](#debug_startCPUProfile) | | | |
|
||||
| | [startGoTrace](#debug_startGoTrace) | | | |
|
||||
| | [stopCPUProfile](#debug_stopCPUProfile) | | | |
|
||||
| | [stopGoTrace](#debug_stopGoTrace) | | | |
|
||||
| | [startCPUProfile](#debug_startcpuprofile) | | | |
|
||||
| | [startGoTrace](#debug_startgotrace) | | | |
|
||||
| | [stopCPUProfile](#debug_stopcpuprofile) | | | |
|
||||
| | [stopGoTrace](#debug_stopgotrace) | | | |
|
||||
| | [traceBlock](#debug_traceblock) | | | |
|
||||
| | [traceBlockByNumber](#debug_blockbynumber) | | | |
|
||||
| | [traceBlockByHash](#debug_blockbyhash) | | | |
|
||||
| | [traceBlockByNumber](#debug_traceblockbynumber) | | | |
|
||||
| | [traceBlockByHash](#debug_traceblockbyhash) | | | |
|
||||
| | [traceBlockFromFile](#debug_traceblockfromfile) | | | |
|
||||
| | [traceTransaction](#debug_tracetransaction) | | | |
|
||||
| | [verbosity](#debug_verbosity) | | | |
|
||||
| | [vmodule](#debug_vmodule) | | | |
|
||||
| | [writeBlockProfile](#debug_writeBlockProfile) | | | |
|
||||
| | [writeMemProfile](#debug_writeMemProfile) | | | |
|
||||
| | [standardTraceBlockToFile](#debug_standardTraceBlockToFile)| | | |
|
||||
| | [writeBlockProfile](#debug_writeblockprofile) | | | |
|
||||
| | [writeMemProfile](#debug_writememprofile) | | | |
|
||||
| | [standardTraceBlockToFile](#debug_standardtraceblocktofile)| | | |
|
||||
|
||||
|
||||
## Admin
|
||||
|
||||
|
|
@ -628,7 +629,7 @@ References:
|
|||
|
||||
### debug_traceBlockByNumber
|
||||
|
||||
Similar to [debug_traceBlock](#debug_traceBlock), `traceBlockByNumber` accepts a block number and will replay the
|
||||
Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByNumber` accepts a block number and will replay the
|
||||
block that is already present in the database.
|
||||
|
||||
| Client | Method invocation |
|
||||
|
|
@ -642,7 +643,7 @@ References:
|
|||
|
||||
### debug_traceBlockByHash
|
||||
|
||||
Similar to [debug_traceBlock](#debug_traceBlock), `traceBlockByHash` accepts a block hash and will replay the
|
||||
Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByHash` accepts a block hash and will replay the
|
||||
block that is already present in the database.
|
||||
|
||||
| Client | Method invocation |
|
||||
|
|
@ -656,7 +657,7 @@ References:
|
|||
|
||||
### debug_traceBlockFromFile
|
||||
|
||||
Similar to [debug_traceBlock](#debug_traceBlock), `traceBlockFromFile` accepts a file containing the RLP of the block.
|
||||
Similar to [debug_traceBlock](#debug_traceblock), `traceBlockFromFile` accepts a file containing the RLP of the block.
|
||||
|
||||
| Client | Method invocation |
|
||||
|:-------:|----------------------------------------------------------------------------------|
|
||||
|
|
@ -926,6 +927,15 @@ flag.
|
|||
The `miner` API allows you to remote control the node's mining operation and set various
|
||||
mining specific settings.
|
||||
|
||||
### miner_getHashrate
|
||||
|
||||
Get your hashrate in H/s (Hash operations per second).
|
||||
|
||||
| Client | Method invocation |
|
||||
|:-------:|-------------------------------------------------------------|
|
||||
| Console | `miner.getHashrate()` |
|
||||
| RPC | `{"method": "miner_getHashrate", "params": []}` |
|
||||
|
||||
### miner_setExtra
|
||||
|
||||
Sets the extra data a miner can include when miner blocks. This is capped at
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ or import). Without it you are not able to unlock your account.
|
|||
Note that exporting your key in unencrypted format is NOT supported.
|
||||
|
||||
Keys are stored under `<DATADIR>/keystore`. Make sure you backup your keys regularly! See
|
||||
[DATADIR backup & restore](../doc/Backup--restore)
|
||||
[DATADIR backup & restore](../install-and-build/backup-restore)
|
||||
for more information. If a custom datadir and keystore option are given the keystore
|
||||
option takes preference over the datadir option.
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ OPTIONS:
|
|||
--keystore Directory for the keystore (default = inside the datadir)
|
||||
```
|
||||
|
||||
Accounts can also be managed via the [Javascript Console](../interface/JavaScript-Console)
|
||||
Accounts can also be managed via the [Javascript Console](../interface/javascript-console)
|
||||
|
||||
## Examples
|
||||
### Interactive use
|
||||
|
|
@ -335,7 +335,7 @@ That can then be executed with:
|
|||
|
||||
Since this function will disappear after restarting geth, it can be helpful to store
|
||||
commonly used functions to be recalled later. The
|
||||
[loadScript](../interface/JavaScript-Console#loadscript)
|
||||
[loadScript](../interface/javascript-console)
|
||||
function makes this very easy.
|
||||
|
||||
First, save the `checkAllBalances()` function definition to a file on your computer. For
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ If you have the SolC Solidity Compiler installed, you need now reformat by remo
|
|||
|
||||
#### Linking your compiler in Geth
|
||||
|
||||
Now [go back to the console](../doc/geth) and type this command to install solC, replacing _path/to/solc_ to the path that you got on the last command you did:
|
||||
Now [go back to the console](../interface/javascript-console) and type this command to install solC, replacing _path/to/solc_ to the path that you got on the last command you did:
|
||||
|
||||
admin.setSolc("path/to/solc")
|
||||
|
||||
|
|
|
|||
|
|
@ -4,11 +4,11 @@ title: Creating your own Ethereum apps using Eth go
|
|||
|
||||
**This page is heavily outdated**
|
||||
|
||||
The modular nature of Go and the Ethereum Go implementation, [eth-go](https://github.com/ethereum/eth-go), make it very easy to build your own Ethereum native applications.
|
||||
The modular nature of Go and the Ethereum Go implementation make it very easy to build your own Ethereum native applications.
|
||||
|
||||
This post will cover the minimal steps required to build an native Ethereum application.
|
||||
|
||||
Ethereum comes with a global config found in the [ethutil](https://github.com/ethereum/eth-go/tree/master/ethutil) package. The global config requires you to set a base path to store it's files (database, settings, etc).
|
||||
Ethereum comes with a global config found in the ethutil package. The global config requires you to set a base path to store it's files (database, settings, etc).
|
||||
|
||||
```go
|
||||
func main() {
|
||||
|
|
@ -19,7 +19,7 @@ func main() {
|
|||
|
||||
ReadConfig takes four arguments. The data folder to use, a log flag, a globalConf instance and an id string to identify your app to other nodes in the network.
|
||||
|
||||
Once you've configured the global config you can set up and create your Ethereum node. The Ethereum Object, or Node, will handle all trafic from and to the Ethereum network as well as handle all incoming block and transactions. A new node can be created through the `new` method found in [eth-go](https://github.com/ethereum/eth-go).
|
||||
Once you've configured the global config you can set up and create your Ethereum node. The Ethereum Object, or Node, will handle all trafic from and to the Ethereum network as well as handle all incoming block and transactions. A new node can be created through the `new` method found in eth-go.
|
||||
|
||||
```go
|
||||
func main() {
|
||||
|
|
|
|||
|
|
@ -9,17 +9,17 @@ title: Mining
|
|||
|
||||
At Frontier, the first release of Ethereum, you'll just need a) a GPU and b) an Ethereum client, Geth. CPU mining will be possible but too inefficient to hold any value.
|
||||
|
||||
At the moment, Geth only includes a CPU miner, and the team is testing a [GPU miner branch](https://github.com/ethereum/go-ethereum/tree/gpu_miner), but this won't be part of Frontier.
|
||||
At the moment, Geth only includes a CPU miner, and the team is testing a GPU miner branch, but this won't be part of Frontier.
|
||||
|
||||
The C++ implementation of Ethereum also offers a GPU miner, both as part of Eth (its CLI), AlethZero (its GUI) and EthMiner (the standalone miner).
|
||||
|
||||
_**NOTE:** Ensure your blockchain is fully synchronised with the main chain before starting to mine, otherwise you will not be mining on the main chain._
|
||||
|
||||
When you start up your ethereum node with `geth` it is not mining by default. To start it in mining mode, you use the `--mine` [command line option](../interface/Command-Line-Options). The `-minerthreads` parameter can be used to set the number parallel mining threads (defaulting to the total number of processor cores).
|
||||
When you start up your ethereum node with `geth` it is not mining by default. To start it in mining mode, you use the `--mine` [command line option](../interface/command-line-options). The `-minerthreads` parameter can be used to set the number parallel mining threads (defaulting to the total number of processor cores).
|
||||
|
||||
`geth --mine --minerthreads=4`
|
||||
|
||||
You can also start and stop CPU mining at runtime using the [console](../interface/JavaScript-Console#adminminerstart). `miner.start` takes an optional parameter for the number of miner threads.
|
||||
You can also start and stop CPU mining at runtime using the [console](../interface/javascript-console). `miner.start` takes an optional parameter for the number of miner threads.
|
||||
|
||||
```
|
||||
> miner.start(8)
|
||||
|
|
@ -30,7 +30,7 @@ true
|
|||
|
||||
Note that mining for real ether only makes sense if you are in sync with the network (since you mine on top of the consensus block). Therefore the eth blockchain downloader/synchroniser will delay mining until syncing is complete, and after that mining automatically starts unless you cancel your intention with `miner.stop()`.
|
||||
|
||||
In order to earn ether you must have your **etherbase** (or **coinbase**) address set. This etherbase defaults to your [primary account](Managing-your-accounts). If you don't have an etherbase address, then `geth --mine` will not start up.
|
||||
In order to earn ether you must have your **etherbase** (or **coinbase**) address set. This etherbase defaults to your [primary account](../interface/managing-your-accounts). If you don't have an etherbase address, then `geth --mine` will not start up.
|
||||
|
||||
You can set your etherbase on the command line:
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ miner.setEtherbase(eth.accounts[2])
|
|||
|
||||
Note that your etherbase does not need to be an address of a local account, just an existing one.
|
||||
|
||||
There is an option [to add extra Data](../interface/JavaScript-Console#adminminersetextra) (32 bytes only) to your mined blocks. By convention this is interpreted as a unicode string, so you can set your short vanity tag.
|
||||
There is an option [to add extra Data](../interface/javascript-console) (32 bytes only) to your mined blocks. By convention this is interpreted as a unicode string, so you can set your short vanity tag.
|
||||
|
||||
```
|
||||
miner.setExtra("ΞTHΞЯSPHΞЯΞ")
|
||||
|
|
@ -66,7 +66,7 @@ Header:
|
|||
|
||||
See also [this proposal](https://github.com/ethereum/wiki/wiki/Extra-Data)
|
||||
|
||||
You can check your hashrate with [miner.hashrate](../interface/JavaScript-Console#adminminerhashrate), the result is in H/s (Hash operations per second).
|
||||
You can check your hashrate with [miner.hashrate](../interface/javascript-console), the result is in H/s (Hash operations per second).
|
||||
|
||||
```
|
||||
> miner.hashrate
|
||||
|
|
@ -139,14 +139,13 @@ The GPU miner is implemented in OpenCL, so AMD GPUs will be 'faster' than same-c
|
|||
ASICs and FPGAs are relatively inefficient and therefore discouraged.
|
||||
|
||||
To get openCL for your chipset and platform, try:
|
||||
* [AMD SDK openCL](http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk)
|
||||
* [AMD SDK openCL](http://developer.amd.com/tools-and-sdks)
|
||||
* [NVIDIA CUDA openCL](https://developer.nvidia.com/cuda-downloads)
|
||||
|
||||
## On Ubuntu
|
||||
### AMD
|
||||
|
||||
* http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing
|
||||
* http://developer.amd.com/tools-and-sdks/graphics-development/display-library-adl-sdk/
|
||||
* http://developer.amd.com/tools-and-sdks
|
||||
|
||||
download: `ADL_SDK8.zip ` and `AMD-APP-SDK-v2.9-1.599.381-GA-linux64.sh`
|
||||
|
||||
|
|
@ -189,7 +188,7 @@ You check your cooling status:
|
|||
|
||||
## Mining Software
|
||||
|
||||
The official Frontier release of `geth` only supports a CPU miner natively. We are working on a [GPU miner](https://github.com/ethereum/go-ethereum/tree/gpuminer), but it may not be available for the Frontier release. Geth however can be used in conjunction with `ethminer`, using the standalone miner as workers and `geth` as scheduler communicating via [JSON-RPC](https://github.com/ethereum/wiki/JSON-RPC).
|
||||
The official Frontier release of `geth` only supports a CPU miner natively. We are working on a GPU miner, but it may not be available for the Frontier release. Geth however can be used in conjunction with `ethminer`, using the standalone miner as workers and `geth` as scheduler communicating via [JSON-RPC](https://github.com/ethereum/wiki/wiki/JSON-RPC).
|
||||
|
||||
The [C++ implementation of Ethereum](https://github.com/ethereum/cpp-ethereum/) (not officially released) however has a GPU miner. It can be used from `eth`, `AlethZero` (GUI) and `ethMiner` (the standalone miner).
|
||||
|
||||
|
|
@ -235,7 +234,7 @@ ethminer -G // -G for GPU, -M for benchmark
|
|||
tail -f geth.log
|
||||
```
|
||||
|
||||
`ethminer` communicates with geth on port 8545 (the default RPC port in geth). You can change this by giving the [`--rpcport` option](https://github.com/ethereum/go-ethereum/Command-Line-Options) to `geth`.
|
||||
`ethminer` communicates with geth on port 8545 (the default RPC port in geth). You can change this by giving the [`--rpcport` option](../interface/command-line-options) to `geth`.
|
||||
Ethminer will find get on any port. Note that you need to set the CORS header with `--rpccorsdomain localhost`. You can also set port on `ethminer` with `-F http://127.0.0.1:3301`. Setting the ports is necessary if you want several instances mining on the same computer, although this is somewhat pointless. If you are testing on a private cluster, we recommend you use CPU mining instead.
|
||||
|
||||
Also note that you do **not** need to give `geth` the `--mine` option or start the miner in the console unless you want to do CPU mining on TOP of GPU mining.
|
||||
|
|
@ -292,5 +291,5 @@ eth -m on -G -a <coinbase> -i -v 8 //
|
|||
* https://github.com/ethereum/wiki/wiki/Ethash
|
||||
* [Benchmarking results for GPU mining](https://forum.ethereum.org/discussion/2134/gpu-mining-is-out-come-and-let-us-know-of-your-bench-scores)
|
||||
* [historic moment](https://twitter.com/gavofyork/status/586623875577937922)
|
||||
* [live mining statistic](https://etherapps.info/stats/mining)
|
||||
* [live mining statistic](https://ethstats.net/)
|
||||
* [netstat ethereum network monitor](https://stats.ethdev.com)
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ title: Swarm TODO
|
|||
|
||||
## APIs
|
||||
- DAPP API - js integration (Fabian, Alex)
|
||||
- mist dapp storage scheme, url->hash mapping (Fabian, Alex) [URL scheme](URL-Scheme)
|
||||
- mist dapp storage scheme, url->hash mapping (Fabian, Alex) [URL scheme](../doc/url-scheme)
|
||||
|
||||
# Discuss alternatives
|
||||
|
||||
|
|
|
|||
|
|
@ -10,15 +10,15 @@ title: Swarm - distributed preimage archive
|
|||
- http://www.amazon.co.uk/Swarmwise-Tactical-Manual-Changing-World/dp/1463533152/
|
||||
|
||||
## Docs & specs
|
||||
- [Swarm TODO](Swarm---TODO)
|
||||
- [Swarm TODO](./swarm-todo)
|
||||
- Dani & Viktor on public wiki: https://github.com/ethereum/wiki/wiki/Distributed-Preimage-Archive
|
||||
- Dani on swarm hash: https://github.com/ethereum/wiki/wiki/Swarm-Hash
|
||||
- Dani on incentive system: https://github.com/ethersphere/swarm/blob/master/doc/incentives.md
|
||||
- [The swarm smart contract](Swarm-Contract)
|
||||
- The swarm smart contract
|
||||
- gav on url-hint https://github.com/ethereum/wiki/wiki/URL-Hint-Protocol
|
||||
- Gav on public wiki: https://github.com/ethereum/cpp-ethereum/wiki/Swarm
|
||||
- network (DEVp2p)
|
||||
- [Peer-to-Peer](Peer-to-Peer)
|
||||
- [Peer-to-Peer](../developers/peer-to-peer)
|
||||
- on kademlia: https://github.com/ethereum/wiki/wiki/Cademlia-Peer-Selection
|
||||
|
||||
## Talks
|
||||
|
|
|
|||
|
|
@ -1,166 +0,0 @@
|
|||
---
|
||||
title: Swarm channels, namereg-resolution draft
|
||||
---
|
||||
# Channels and streams
|
||||
|
||||
a *swarm chain* is an ordered list of content that are linked as a forkless chain.
|
||||
.
|
||||
This is simply modeled as linked manifests.
|
||||
|
||||
a *channel* is a sequence of manifests (_S_) and a relative path _P_ with a starting manifest _M_ and a streamsize _n_ (can be infinite). A channel is well-formed or regular if in every manifest in the stream _P_ resolves to a consistent mime type _T_ . For instance , if _T_ is `application/bzz-manifest+json`, we say the channel is a _manifest channel_, if the mime-type is `mpeg`, its a video channel.
|
||||
|
||||
A *primary channel* is a channel that actually respect chronological order of creation.
|
||||
|
||||
A *live channel* is a primary channel that keeps updating (adding episodes to the end of the chain) can have a (semi)-persistent mime-type for path _P_
|
||||
|
||||
A *blockstream channel* is a primary channel provable linked in time via hashes.
|
||||
|
||||
A *signed channel* is a primary channel provably linked by signatures (sequence position index signed by the publisher)
|
||||
|
||||
*Trackers* are a manifest channel which tracks updates to a primary channel and provides forward linking .
|
||||
|
||||
## Example channels:
|
||||
|
||||
- name histories, e.g updates of a domain, temporal snapshots of content
|
||||
- blockchain: blockchain is a special case of blockstream
|
||||
- git graph, versioning
|
||||
- modeling a source of information: provable communication with hash chain, not allowed to fork, numbered.
|
||||
|
||||
#### content trackers
|
||||
|
||||
reverse index of a stream
|
||||
- contains `next` links to following state
|
||||
- published after next state
|
||||
- publish provable quality metrics:
|
||||
- age: starting date of tracker vs date of orig content
|
||||
- neg exp forgetting(track date vs primary date of next episode) ~ alertness, puncuality (tracker
|
||||
- git version control
|
||||
|
||||
every named host defines a timeline,
|
||||
- create a manifest stream tracking a site
|
||||
|
||||
## Ways to link manifests
|
||||
|
||||
#### examples
|
||||
|
||||
``` json
|
||||
{ "entries":
|
||||
[
|
||||
{
|
||||
"host": "fefe.eth",
|
||||
"number": 9067,
|
||||
"previous": "ffca34987",
|
||||
"next": "aefbc4569ab",
|
||||
"this": "90daefaaabbc",
|
||||
}
|
||||
],
|
||||
"auth": "3628aeefbc7689523aebc2489",
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
# Name resolution
|
||||
|
||||
The host part in a bzz webaddress should be resolved with our version of DNS, ie. using both `NameReg` (name registration contract on ethereum) and a simple mutable storage in swarm.
|
||||
|
||||
## signed version store
|
||||
The point of channels (Swarm---Channels
|
||||
) is to have a total order over a set of manifests.
|
||||
|
||||
The typical usecase is that it should be enough to know the name of a site or document to always see the latest version of a software or get the current episode of your favourite series or the consensus state of a blockchain. It should also be possible to deterministically derive the key to future content...
|
||||
|
||||
One possibility is to modify the NameReg entry in the blockchain to point to a swarm hash. Recording each change on the blockchain results in an implicit live channel linking. This scheme is simple inasmuch as it puts authentication completely on the chain. However, it is expensive and not viable given the number of publishers and typical rate of update.
|
||||
|
||||
Alternatively, swarm provides the protocol for associating a channel and a position with a swarm hash. The versioning can be authenticated since a message containing host name, sequence position index and swarm hash is signed by the public key registered in ethereum NameReg for the host.
|
||||
|
||||
Publishers, fans or paid bookkeepers track updates of a channel and wrap accumulated messages into a tracker manifest.
|
||||
Most probably publishers would broadcast updates of a channel manifest in the first place.
|
||||
|
||||
This special key-value store can be implemented as a mutable store: the value with a higher index will simply override the previous one.
|
||||
|
||||
There can be various standards to derive lookup key deterministically
|
||||
the simplest one is `HASH(host:version)` for a specific version and `HASH(host)` for the latest version.
|
||||
The content has the following structure:
|
||||
|
||||
```
|
||||
sign[<host>, <version>, <timestamp>, <hash>]
|
||||
```
|
||||
|
||||
Retrieve request for a signed version is the same as a request for a hash.
|
||||
|
||||
[RetrieveMsg, HASH(host:version), id, timeout, MUTABLE]
|
||||
[RetrieveMsg, HASH(host:0), id, timeout, MUTABLE]
|
||||
|
||||
Store request for a signed version is the same as for a hash:
|
||||
|
||||
[StoreMsg, key, id, MUTABLE, Sign[host, version, time.Unix(), hash]]
|
||||
|
||||
## Format
|
||||
It is up to debate how we distinguish names to be resolved.
|
||||
|
||||
An early idea was to use a top level domain, such as `.eth` (<source> == `<host>.eth`)
|
||||
this might limit the possibilities
|
||||
|
||||
Another idea was to have it as or part of the protocol: `eth://my-website.home` or `eth+bzz://my-website.home`. This are semantically incorrect, however.
|
||||
|
||||
Third, put an _eth_ inside the host somehow.
|
||||
|
||||
Ad-hoc constructs like `bzz://eth:my-website.home` will be rejected by host pattern matchers.
|
||||
|
||||
Abusing subdomains `bzz://eth.my-website.home` would cause ambiguity and potential collision.
|
||||
Abusing auth `user:pass@my-website.home` would disable basic auth.
|
||||
|
||||
A suggestion that most aligns with the *signed versioning* and very simple is that we look up everything that is not a 32 byte hash format for a public key. The version of the site is looked up using the port part of the host. A specific version is given after the `:`.
|
||||
|
||||
The generic pattern then:
|
||||
|
||||
```
|
||||
(<version_chain>.)<host>(:<number>)(/<path>)
|
||||
```
|
||||
|
||||
### example 0
|
||||
```
|
||||
bzz://breaking.bad.tv/s4/e2/video
|
||||
```
|
||||
- _breaking.bad.tv_ is looked up in NameReg to yield public key _P_
|
||||
- _breaking.bad.tv_ is looked up in the immutable store to yield a message `[_breaking.bad.tv_,0,3,aebf45fbf6ae6aaaafedcbcb467]`
|
||||
- `aebf45fbf6ae6aaaafedcbcb467` is looked up in swarm to yield the manifest
|
||||
- manifest entry for path `/s4/e2/video` results in the actual document's root key
|
||||
|
||||
### example 1
|
||||
```
|
||||
bzz://breaking.bad.tv/video
|
||||
```
|
||||
resolves the following way:
|
||||
- _breaking.bad.tv_ is looked up in NameReg to yield public key _P_
|
||||
- _breaking.bad.tv_ is looked up in the immutable store to yield - by `H(cookie)` - a message `[_breaking.bad.tv_,s5:e12,3,aebf45fbf6ae6aaaafedcbcb467]` signed by `P`
|
||||
- `aebf45fbf6ae6aaaafedcbcb467` is looked up in swarm to yield the manifest
|
||||
- manifest entry for path `video` results in the actual document's root key
|
||||
|
||||
### example 2
|
||||
```
|
||||
bzz://current.breaking.bad.tv:s4:e10/video
|
||||
```
|
||||
- _breaking.bad.tv_ is looked up in NameReg to yield public key _P_
|
||||
- current.breaking.bad.tv:s4:e10 is looked up in the immutable store to yield a message `[current.breaking.bad.tv,s4:e10,3,45fbf6ae6aaaafedcbcb467ccc]`
|
||||
- `45fbf6ae6aaaafedcbcb467ccc` is looked up in swarm to yield the manifest
|
||||
- manifest entry for path `video` results in the actual document's root key
|
||||
|
||||
### example 3
|
||||
```
|
||||
bzz://breaking.bad.tv/playlist
|
||||
```
|
||||
- same as ex 2...
|
||||
- manifest entry for path `playlist` results in a playlist manifest
|
||||
|
||||
|
||||
### example 4
|
||||
```
|
||||
bzz://stable.ethereum.org:8.1/download/go/mac-os
|
||||
```
|
||||
- _stable.ethereum.org_ is looked up in NameReg to yield public key _P_
|
||||
- stable.ethereum.org:s4:e10 is looked up in the immutable store to yield a message `[stable.ethereum.org,s4:e10,3,45fbf6ae6aaaafedcbcb467ccc]`
|
||||
- `45fbf6ae6aaaafedcbcb467ccc` is looked up in swarm to yield the manifest
|
||||
- manifest entry for path `video` results in the actual document's root key
|
||||
|
||||
Generalised content streaming, subscriptions.
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
---
|
||||
title: Swarm contract
|
||||
---
|
||||
This one contract regulates the incentive structure of Swarm.
|
||||
|
||||
The corresponding solidity code can be browsed [here](https://github.com/ethersphere/go-ethereum/blob/bzz/bzz/bzzcontract/swarm.sol).
|
||||
|
||||
# Methods
|
||||
|
||||
## Sign up as a node
|
||||
|
||||
Pay a deposit in Ether and register public key. Comes with an accessor for checking that a node is signed up.
|
||||
|
||||
## Demand penalty for loss of chunk
|
||||
|
||||
Present a signed receipt by a signed up node and a deposit covering the upload of a chunk. After a given deadline, the signer node's deposit is taken and the presenting node's deposit refunded, unless the chunk is presented. Comes with an accessor for checking that a given chunk has been reported lost, so that holders of receipts by other swarm nodes can punish them as well for losing the chunk, which, in turn, incentivizes whoever holds the chunk to present it.
|
||||
|
||||
## Present chunk to avoid penalty
|
||||
|
||||
No penalty is paid for lost chunks, if chunk is presented within the deadline. The cost of uploading the chunk is compensated exactly from the demand's deposit, with the remainder refunded. Comes with an accessor for checking that a given node is liable for penalty, so the node is notified to present the chunk in a timely fashion.
|
||||
|
||||
# Price considerations
|
||||
|
||||
For the price of accepting a chunk for storing, see [Incentives](https://github.com/ethersphere/swarm/blob/master/doc/incentives.md)
|
||||
|
||||
This price should be proportional to the sign-up deposit of the swarm node.
|
||||
|
||||
The deposit for compensating the swarm node for uploading the chunk into the block chain should be substantially higher (e.g. a small integer multiple) of the corresponding upload measured with the gas price used to upload the demand to prevent DoS attacks.
|
||||
|
||||
# Termination
|
||||
|
||||
Users of Swarm should be able to count on the loss of deposit as a disincentive, so it should not be refunded before the term of Swarm membership expires. If penalites were paid out as compensation to holders of receipts of lost chunks, it would provide an avenue of early exit for a Swarm member by "losing" chunks deposited by colluding users. Since users of Swarm are interested in their information being reliably stored, their primary incentive for keeping the receipts is to keep the Swarm motivated, not the potential compensation.
|
||||
|
||||
# Receipt circulation
|
||||
|
||||
End-users of Swarm keeping important information in it are obviously interested in keeping as many receipts of it as possible available for "litigation". The storage space required for storing a receipt is a sizable fraction of that used for storing the information itself, so end users can reduce their storage requirement further by storing the receipts in Swarm as well. Doing this recursively would result in end users only having to store a single receipt, yet being
|
||||
able to penalize quite a few Swarm nodes, in case only a small part of their stored information
|
||||
is lost.
|
||||
|
||||
Swarm nodes that use the rest of Swarm as a backup may want to propagate the receipts in the opposite direction of storage requests, so that the cost of storing receipts is eventually paid by the end user either in the form of allocated storage space or as a direct payment to Swarm.
|
||||
|
|
@ -18,26 +18,26 @@ By installing and running `geth`, you can take part in the ethereum frontier liv
|
|||
Supported Platforms are Linux, Mac Os and Windows.
|
||||
|
||||
We support two types of installation: binary or scripted install for users.
|
||||
See [Install instructions](../install-and-build/Building-Ethereum) for binary and scripted installs.
|
||||
See [Install instructions](../install-and-build/build-from-source) for binary and scripted installs.
|
||||
|
||||
Developers and community enthusiast are advised to read the [Developers' Guide](../install-and-build/Developers-Guide), which contains detailed instructions for manual build from source (on any platform) as well as detailed tips on testing, monitoring, contributing, debugging and submitting pull requests on github.
|
||||
Developers and community enthusiast are advised to read the [Developers' Guide](../install-and-build/developers-guide), which contains detailed instructions for manual build from source (on any platform) as well as detailed tips on testing, monitoring, contributing, debugging and submitting pull requests on github.
|
||||
|
||||
## Interfaces
|
||||
|
||||
* Javascript Console: `geth` can be launched with an interactive console, that provides a javascript runtime environment exposing a javascript API to interact with your node. [Javascript Console API](../interface/JavaScript-Console) includes the `web3` javascript Ðapp API as well as an additional admin API.
|
||||
* JSON-RPC server: `geth` can be launched with a json-rpc server that exposes the [JSON-RPC API](https://github.com/ethereum/wiki/JSON-RPC)
|
||||
* [Command line options](../interface/Command-Line-Options) documents command line parameters as well as subcommands.
|
||||
* Javascript Console: `geth` can be launched with an interactive console, that provides a javascript runtime environment exposing a javascript API to interact with your node. [Javascript Console API](../interface/javascript-console) includes the `web3` javascript Ðapp API as well as an additional admin API.
|
||||
* JSON-RPC server: `geth` can be launched with a server that exposes the [JSON-RPC API](https://github.com/ethereum/wiki/wiki/JSON-RPC)
|
||||
* [Command line options](../interface/command-line-options) documents command line parameters as well as subcommands.
|
||||
|
||||
## Basic Use Case Documentation
|
||||
|
||||
* [Managing accounts](../how-to/Managing-your-accounts)
|
||||
* [Mining](../how-to/Mining)
|
||||
* [Managing accounts](../interface/managing-your-accounts)
|
||||
* [Mining](../legacy/mining)
|
||||
|
||||
**Note** buying and selling ether through exchanges is not discussed here.
|
||||
|
||||
## License
|
||||
|
||||
The Ethereum Core Protocol licensed under the [GNU Lesser General Public License](https://www.gnu.org/licenses/lgpl.html). All frontend client software (under [cmd](https://github.com/ethereum/go-ethereum/tree/develop/cmd)) is licensed under the [GNU General Public License](https://www.gnu.org/copyleft/gpl.html).
|
||||
The Ethereum Core Protocol licensed under the [GNU Lesser General Public License](https://www.gnu.org/licenses/lgpl.html). All frontend client software (under [cmd](https://github.com/ethereum/go-ethereum/tree/master/cmd)) is licensed under the [GNU General Public License](https://www.gnu.org/copyleft/gpl.html).
|
||||
|
||||
## Reporting
|
||||
|
||||
|
|
@ -85,8 +85,6 @@ IRC Freenode channels:
|
|||
* `#dappdevs`: Dapp developers channel
|
||||
* `#ethdev`: buildserver etc
|
||||
|
||||
[IRC Logs by ZeroGox](https://zerogox.com/bot/log)
|
||||
|
||||
### Gitter
|
||||
|
||||
* [go-ethereum Gitter](https://gitter.im/ethereum/go-ethereum)
|
||||
|
|
@ -96,11 +94,7 @@ IRC Freenode channels:
|
|||
|
||||
### Forum
|
||||
|
||||
- [Forum](https://forum.ethereum.org/categories/go-implementation)
|
||||
|
||||
### The ZeroGox Bot
|
||||
|
||||
[ZeroGox Bot](https://zerogox.com/bot)
|
||||
- [Forum](https://forum.ethereum.org/categories/geth)
|
||||
|
||||
### Dapp developers' mailing list
|
||||
|
||||
|
|
|
|||
|
|
@ -1,60 +0,0 @@
|
|||
---
|
||||
title: Swarm POC series
|
||||
---
|
||||
now project features and POC milestones are managed under
|
||||
https://github.com/ethereum/go-ethereum/projects/6
|
||||
|
||||
## POC 0.1: plan bee
|
||||
|
||||
* [x] underground dev testnet launched on BZZ day (3.22 is l33t for BZZ)
|
||||
* [x] create ansible and docker for node deployment
|
||||
* [x] a few public gateways
|
||||
|
||||
## POC 0.2 sworm
|
||||
|
||||
* [x] rebase on geth 1.5 edge
|
||||
* [x] small toynet deployed, see [network monitor](http://146.185.130.117/)
|
||||
* [x] support for separate url schemes for dns enabled, immutable and raw manifest - feature [#2279](https://github.com/ethereum/go-ethereum/issues/2279)
|
||||
* [x] Ethereum name service integration
|
||||
* [x] scripted network tests, cluster control framework
|
||||
* [x] algorithmic improvements on chunker split/join
|
||||
* [x] algorithmic improvements on upload/download
|
||||
* [x] algorithmic improvements in kademlia and hive peers manager
|
||||
* [x] calibrating kademlia connectivity parameters to toynet scale
|
||||
* [x] orange paper series released hosted on [swarm toynet](http://swarm-gateways.net/bzz:/swarm#the-thsphr-orange-papers)
|
||||
* [x] minimalistic [swarm homepage](http://swarm-gateways.net/bzz:/swarm)
|
||||
* [x] adapt to felix's rpc-client-as-eth-backend scheme to run swarm as a separate daemon
|
||||
* [x] merge into main repo develop branch
|
||||
|
||||
## POC 0.3
|
||||
|
||||
Priorities are not finalised, this is just a tentative plan.
|
||||
The following features are prioritised for POC 3 (subject to change)
|
||||
|
||||
* [ ] docker on azure: complete test cluster deployment and remote node control framework
|
||||
* [ ] comprehensive suite of typical network scenarios
|
||||
* [ ] syncer rewrite - syncdb refactor to storage
|
||||
* [ ] mist integration
|
||||
* [ ] storage monitoring and parameter setting API for Mist swarm dashboard
|
||||
* [ ] bzz protocol should implement info for reporting - feature [#2042](https://github.com/ethereum/go-ethereum/issues/2042)
|
||||
* [x] improved peer propagation [#2044](https://github.com/ethereum/go-ethereum/issues/2044)
|
||||
* [x] abstract network simulation framework
|
||||
* [x] protocol stack abstraction, pluggable subprotocol components - (swap, hive/protocol, syncer, peers) for pss
|
||||
* [ ] new p2p API integration - feature [#2060](https://github.com/ethereum/go-ethereum/issues/2060)
|
||||
* [ ] pss - unicast
|
||||
* [ ] swap rewrite
|
||||
* [ ] obfuscation for plausible deniability
|
||||
|
||||
## POC 0.4
|
||||
|
||||
* [ ] enhanced network monitoring, structured logging and stats aggregation
|
||||
* [ ] unicast/multicast messaging over swarm - pss
|
||||
* [ ] swear and swindle http://swarm-gateways.net/bzz:/swarm/ethersphere/orange-papers/1/sw%5E3.pdf
|
||||
* [ ] smash/crash proof of custody http://swarm-gateways.net/bzz:/swarm/ethersphere/orange-papers/2/smash.pdf
|
||||
* [ ] swarm DB support phase 0 - compact manifest trie and proof requests
|
||||
* [ ] [SWarm On-demand Retrieval Daemon](https://gist.github.com/zelig/aa6eb43615e12d834d9f) - feature [#2049](https://github.com/ethereum/go-ethereum/issues/2049) = sword. ethereum state, contract storage, receipts, blocks on swarm
|
||||
* [x] ~implement (a reviewed version of) [EIP-26](https://github.com/ethereum/EIPs/issues/26)~ obsoleted by ENS and the vickrey auction
|
||||
* [ ] swarm namereg/natspec rewrite - enhancement [#2048](https://github.com/ethereum/go-ethereum/issues/2048)
|
||||
* [x] ~solidity [contractInfo standard](https://github.com/ethereum/solidity/pull/645) and contract source verification support~ https://www.reddit.com/r/ethereum/comments/5d5lyd/first_contract_to_contain_swarm_hash_to_its/
|
||||
|
||||
## POC 0.5
|
||||
|
|
@ -1 +0,0 @@
|
|||
See [Swarm Roadmap](https://github.com/orgs/ethersphere/projects/5)
|
||||
|
|
@ -1 +0,0 @@
|
|||
See [Swarm Roadmap](https://github.com/orgs/ethersphere/projects/5)
|
||||
|
|
@ -10,7 +10,7 @@ title: FAQ
|
|||
|
||||
**Q.** I would like to run multiple geth instances but got the error "Fatal: blockchain db err: resource temporarily unavailable".
|
||||
|
||||
**A.** Geth uses a datadir to store the blockchain, accounts and some additional information. This directory cannot be shared between running instances. If you would like to run multiple instances follow [these](../doc/Setting-up-private-network-or-local-cluster) instructions.
|
||||
**A.** Geth uses a datadir to store the blockchain, accounts and some additional information. This directory cannot be shared between running instances. If you would like to run multiple instances follow [these](../doc/setting-up-private-network-or-local-cluster) instructions.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: How to Whisper
|
|||
---
|
||||
Whisper is a pure identity-based messaging system. Whisper provides a low-level (non-application-specific) but easily-accessible API without being based upon or prejudiced by the low-level hardware attributes and characteristics, particularly the notion of singular endpoints.
|
||||
|
||||
This tutorial assumes you've read [p2p 101](Peer-to-Peer). If you haven't read it I suggest you read it. This tutorial will guide you to setting up a full p2p server with whisper capabilities.
|
||||
This tutorial assumes you've read [p2p 101](../developers/peer-to-peer). If you haven't read it I suggest you read it. This tutorial will guide you to setting up a full p2p server with whisper capabilities.
|
||||
|
||||
Let's quickly cover some of whisper's basic functionality and discuss it in greater detail later.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,13 +9,13 @@ This is the documentation for the official Ethereum golang implementation. For g
|
|||
|
||||
Main entry points:
|
||||
|
||||
* [Installation Instructions](../install-and-build/Building-Ethereum)
|
||||
* [Management APIs](../interface/Management-APIs)
|
||||
* [Managing Accounts](../interface/Managing-your-accounts)
|
||||
* [Command Line Options](../interface/Command-Line-Options)
|
||||
* [JavaScript Console](../interface/JavaScript-Console)
|
||||
* [Private Network](../doc/Private-network)
|
||||
* [Developers' Guide](../install-and-build/Developers-Guide)
|
||||
* [Whisper v6](../doc/Whisper)
|
||||
* [Installation Instructions](./install-and-build/installing-geth)
|
||||
* [Management APIs](./interface/management-apis)
|
||||
* [Managing Accounts](./interface/managing-your-accounts)
|
||||
* [Command Line Options](./interface/command-line-options)
|
||||
* [JavaScript Console](./interface/javascript-console)
|
||||
* [Private Network](./doc/private-network)
|
||||
* [Developers' Guide](./install-and-build/developers-guide)
|
||||
* [Whisper v6](./whisper/whisper-overview)
|
||||
|
||||
Sidebar lists all pages.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
layout: default
|
||||
root: ./
|
||||
css:
|
||||
- /static/styles/custom/home.css
|
||||
---
|
||||
|
|
@ -14,7 +15,7 @@ css:
|
|||
</div>
|
||||
|
||||
<div class="container mascot-mobile">
|
||||
<img src="./static/images/mascot.png" height="200px" />
|
||||
<img src="./static/images/mascot.png" alt="Geth mascot" height="200px" />
|
||||
</div>
|
||||
|
||||
<div class="container marketing">
|
||||
|
|
@ -22,10 +23,10 @@ css:
|
|||
<div class="col-md-7">
|
||||
<h2 class="featurette-heading">What is Ethereum?</h2>
|
||||
<p class="lead">Ethereum is a decentralized platform that runs smart contracts, applications that run exactly as programmed without possibility of downtime, censorship, fraud or third party interference.</p>
|
||||
<p class="lead">See <a href="https://ethereum.org" target="_blank">our website</a> or <a href="http://ethdocs.org/en/latest/introduction/what-is-ethereum.html" target="_blank">read the docs</a> for more infos!</p>
|
||||
<p class="lead">See <a href="https://ethereum.org" target="_blank">our website</a> or <a href="https://www.ethereum.org/beginners/" target="_blank">read the docs</a> for more infos!</p>
|
||||
</div>
|
||||
<div class="col-md-5 hide-on-small-screen">
|
||||
<img class="featurette-image center-block" src="./static/images/ethereum.png" height="300px">
|
||||
<img class="featurette-image center-block" src="./static/images/ethereum.png" alt="Ethereum logo" height="300px">
|
||||
</div>
|
||||
</div>
|
||||
<hr/>
|
||||
|
|
@ -36,7 +37,7 @@ css:
|
|||
<p class="lead">See <a href="https://github.com/ethereum/go-ethereum" target="_blank">our repository</a> and <a href="./downloads">downloads section</a> for the code!</p>
|
||||
</div>
|
||||
<div class="col-md-5 col-md-pull-7 hide-on-small-screen">
|
||||
<img class="featurette-image center-block" src="./static/images/mascot.png" height="300px">
|
||||
<img class="featurette-image center-block" src="./static/images/mascot.png" alt="Geth mascot" height="300px">
|
||||
</div>
|
||||
</div>
|
||||
<hr/>
|
||||
|
|
|
|||
|
|
@ -3,4 +3,4 @@ title: Install
|
|||
root: ..
|
||||
permalink: /install/
|
||||
---
|
||||
See [Installing Geth](../doc/Installing-Geth).
|
||||
See [Installing Geth](../docs/install-and-build/installing-geth).
|
||||
Loading…
Reference in a new issue