From 3c9b0e96f16e0ae45b33c675f88688388d25d156 Mon Sep 17 00:00:00 2001 From: Bruno Skvorc Date: Wed, 10 Oct 2018 06:21:44 +0200 Subject: [PATCH] Basic changes, testing workflow --- .gitignore | 49 +++++++++++++++++++++++++ source/_data/sidebar.yml | 2 +- source/docs/faq.md | 19 ++++++++++ source/docs/ideas_for_implementation.md | 14 ------- 4 files changed, 69 insertions(+), 15 deletions(-) create mode 100644 source/docs/faq.md delete mode 100644 source/docs/ideas_for_implementation.md diff --git a/.gitignore b/.gitignore index 6891517..6684837 100644 --- a/.gitignore +++ b/.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 \ No newline at end of file diff --git a/source/_data/sidebar.yml b/source/_data/sidebar.yml index 9d4b4e6..64e2a29 100644 --- a/source/_data/sidebar.yml +++ b/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 \ No newline at end of file diff --git a/source/docs/faq.md b/source/docs/faq.md new file mode 100644 index 0000000..bdd8ec1 --- /dev/null +++ b/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. \ No newline at end of file diff --git a/source/docs/ideas_for_implementation.md b/source/docs/ideas_for_implementation.md deleted file mode 100644 index 38080ac..0000000 --- a/source/docs/ideas_for_implementation.md +++ /dev/null @@ -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.