mirror of https://github.com/ethereum/go-ethereum
[DOCS] Link checker (#20086)
Adam Schmideg
5 years ago
committed by
Felix Lange
parent
8e49d1571d
commit
d0eea91981
@ -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,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 |
||||
 |
||||
|
||||
|
||||
@ -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. |
||||
@ -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) |
||||
Loading…
Reference in new issue