Merge pull request #1 from Swader/develop

Basic changes, testing workflow

.gitignore

@@ -6,3 +6,52 @@ db.json
 .deploy*/
 package-lock.json
 public/
+
+# Composer
+/vendor
+composer.phar
+
+# IntelliJ - PhpStorm and PyCharm
+*.ipr
+*.iws
+
+# Eclipse
+/.project
+/.settings
+/.classpath
+
+# Logs
+logs
+error.log
+access.log
+
+# Netbeans
+nbproject
+.nbproject
+.nbproject/*
+nbproject/*
+nbproject/private/
+/nbbuild/
+/nbdist/
+nbactions.xml
+nb-configuration.xml
+
+# Thumbnails
+._*
+# Files that might appear on external disk
+.Spotlight-V100
+.Trashes
+
+# SublimeText project files
+/*.sublime-project
+*.sublime-workspace
+
+# Dart
+packages
+packages/*
+
+# Vagrant
+.vagrant
+.vagrant/*
+
+.env

source/_data/sidebar.yml

@@ -3,8 +3,8 @@ docs:
     introduction: index.html
     milestones: milestones.html
     design: design.html
-    ideas_for_implementation: ideas_for_implementation.html
     resources: resources.html
     team: team.html
+    faq: faq.html
     contributor_guide: contributor_guide.html
     

source/docs/faq.md

@@ -0,0 +1,19 @@
+---
+id: faq
+title: Frequently Asked Questions
+---
+
+In talking to people both familiar and complete strangers to Ethereum clients, these questions were asked more than once.
+
+
+### Q: When do you expect to have it production-ready?
+
+Not for a while. Sharding is a long ways off, and until then we'll be focusing on getting Ethereum v1 tests to pass in our full node mode. The full node will be ready in 2019, but the super-light implementation might take longer.
+
+### Q: How is a super-light node different from just calling Infura through Web3js?
+
+A Web3js or any similar JavaScript package for communicating with the blockchain is basically a more advanced XMLHttpRequest / Fetch wrapper. What we mean by this is that these packages retrieve information from another node and trust it implicitly. They ask "has this transaction been confirmed?" and get a response that's either "yes" or "that transaction is unknown". With light nodes, they ask "give me the data to check if this transaction has been confirmed" and then check on their own. This is a trust-minimized setup which combines the best of both worlds - very little storage and processing power required while allowing for cryptographic verification of the full node's claims.
+
+### Q: What's the plan for mobile? You speak of deploying to mobile devices, but Nimbus only compiles to C, C++ and JavaScript and iOS and Android don't support C natively. Will you be compiling to JS and deploying with a web wrapper? That doesn't sound performant!
+
+Native compiles with Nim work for both Android and iOS, just like geth written in go works. It's all NDK/C API. We'll soon have published specific instructions on how to compile it for all manner of devices.

source/docs/ideas_for_implementation.md

@@ -1,14 +0,0 @@
----
-id: ideas_for_implementation
-title: Ideas for Implementation
----
-
-1.  Create [devp2p](https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol) and an abstraction to allow for [libp2p](https://github.com/Agorise/c-libp2p), [Node Discovery](https://github.com/ethereum/wiki/wiki/Node-discovery-protocol), [RLP encoding](https://github.com/ethereum/wiki/wiki/RLP), [Modified Patricia Merkle Tree](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/), [bigint's](https://github.com/def-/nim-bigints), [keccak256](https://github.com/ethereum/eth-hash), and [secp256k1](https://en.bitcoin.it/wiki/Secp256k1).
-1.  Create an abstraction that would allow sub-protocols: ETH, [SHH](https://gist.github.com/gluk256/9812e59ed0481050350a11308ada4096), [PSS](https://gist.github.com/zelig/d52dab6a4509125f842bbd0dce1e9440), [Swarm](https://github.com/ethersphere/swarm), [LES](https://github.com/ethereum/wiki/wiki/Light-client-protocol), [Stateless Clients](https://nordicapis.com/defining-stateful-vs-stateless-web-services/), Sharding, [Plasma](https://plasma.io/), [State Channels](https://blog.stephantual.com/what-are-state-channels-32a81f7accab). For now, we can ignore all but LES and Sharding.
-1.  DB: Most implementations of Ethereum use [LevelDB](https://github.com/google/leveldb). Parity has a DB abstraction and uses [HashDB](https://github.com/NPS-DEEP/hashdb/wiki) and [RocksDB](https://rocksdb.org/docs/getting-started.html).
-1.  RocksDB is an interesting choice, because it solves the issues that have troubled leveldb. Rocksdb also has a [light version](https://github.com/facebook/rocksdb/blob/master/ROCKSDB_LITE.md) for mobile usage; it's in C++, which would be an issue only if we go for pure C.
-1.  [EVM](https://github.com/pirapira/awesome-ethereum-virtual-machine): basic VM, [eWASM](https://github.com/ewasm/design) ([Hera](https://github.com/ewasm/hera) is also in C++)
-1.  IPC/RPC abstraction, [external API methods](https://github.com/ethereum/wiki/wiki/JSON-RPC) that can be consumed by application bindings: react-native module, IPC, RPC HTTP server, or web sockets
-1.  Encryption library is a little unclear. [Libgcrypt](https://www.gnupg.org/software/libgcrypt/index.html) has everything we need but might be problematic from the standpoint of LGPL licensing. If we have an abstraction for Libgcrypt, we could use it now and swap it out later for something more permissive.
-1.  Alternatively, we could roll out our own library. However, implementing our own encryption would not be a great idea, and our version would have to be audited and tested. Suggestions are welcome.
-1.  Monitor [ethereum/py-evm](https://github.com/ethereum/py-evm/tree/sharding). Connect with Chang-Wu Chen, Hsiao-Wei Wang, and anyone else working on sharding.