mirror of https://github.com/ethereum/go-ethereum
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
81 lines
2.9 KiB
81 lines
2.9 KiB
6 years ago
|
---
|
||
|
title: Swarm TODO
|
||
|
---
|
||
|
# Sprint plan
|
||
|
|
||
|
# scope
|
||
|
- forwarding only (no recursive lookup and no connecting to new nodes, only working with active peers)
|
||
|
|
||
|
## TODO
|
||
|
|
||
|
- integrate new p2p
|
||
|
- write unit tests for protocol and netstore (without protocol)
|
||
|
- rework protocol errors using errs after PR merged
|
||
|
- integrate new p2p or develop branch after p2p merge
|
||
|
- integrate cademlia into hive / peer pool with new p2p
|
||
|
- work out timeouts and timeout encoding
|
||
|
- cli tools
|
||
|
- url bar and proxy
|
||
|
|
||
|
## CLI
|
||
|
- hooking into DPA local API
|
||
|
- running as a daemon accepting request via socket?
|
||
|
|
||
|
### -
|
||
|
## Encryption
|
||
|
- encryption gateway to incentivise encryption of public content
|
||
|
- xor encryption with random chunks
|
||
|
- in-memory encryption keys
|
||
|
- originator encryption for private content
|
||
|
|
||
|
|
||
|
## APIs
|
||
|
- DAPP API - js integration (Fabian, Alex)
|
||
|
- mist dapp storage scheme, url->hash mapping (Fabian, Alex) [URL scheme](URL-Scheme)
|
||
|
|
||
|
# Discuss alternatives
|
||
|
|
||
|
I suggest we each pick 2/3 and read up on their project status, features, useability, objectives, etc
|
||
|
- Is it even worth it to reinvent/reimplement the wheel?
|
||
|
- what features do we want now and in future
|
||
|
- roadmap
|
||
|
|
||
|
# Brainstorming
|
||
|
|
||
|
- storage economy, incentivisation, examples:
|
||
|
-- content owner pays recurring ether fee for storage.
|
||
|
-- scheme to reward content owner each time content is accessed. i.e accessing content would requires fee. this would reward popular content. should be optional though.
|
||
|
- dht - chain interaction
|
||
|
- proof of custody https://docs.google.com/document/d/1F81ulKEZFPIGNEVRsx0H1gl2YRtf0mUMsX011BzSjnY/edit
|
||
|
- proof of resources http://systemdocs.maidsafe.net/content/system_components/proof_of_resources.html
|
||
|
- nonoutsourceable proofs of storage as mining criteria
|
||
|
- proof of storage capacity directly rewarded by contract
|
||
|
- streaming, hash chains
|
||
|
- routing and learning graph traversal
|
||
|
- minimising hops
|
||
|
- forwarding strategies, optimising dispersion of requests
|
||
|
- lifetime of requests, renewals (repeated retrieval requests), expiry, reposting (repeated storage request)
|
||
|
- redundancy - store same data in multiple nodes (e.g 4x)
|
||
|
- the more accessed a content is, the more available it should be, should increase performance for popular content.
|
||
|
|
||
|
# Simulations
|
||
|
|
||
|
- full table homogeneous nodes network size vs density vs table size expected row-sizes
|
||
|
- forwarding strategy vs latency vs traffic
|
||
|
- stable table, dropout rate vs routing optimisation by precalculating subtables for all peers. expected distance change (proximity delta) per hop
|
||
|
|
||
|
|
||
|
## Swarm
|
||
|
|
||
|
How far does the analogy go?
|
||
|
|
||
|
swarm of bees | a decentralised network of peers
|
||
|
-------|------------
|
||
|
living in a hive | form a distributed preimage archive
|
||
|
where they | where they
|
||
|
gather pollen | gather data chunks which they
|
||
|
to produce honey | transform into a longer data stream (document)
|
||
|
they consume and store | they serve and store
|
||
|
buzzing bzz | using bzz as their communications protocol
|
||
|
|