aa7f591587
Why make the change? As discussed previously, the way we will move across versions is to maintain completely separate codebases and eventually remove those that are not supported anymore. This has the drawback of some code duplication, but the advantage is that is more explicit what each version requires, and changes in one version will not impact the other, so we won't pile up backward compatible code. This is the same strategy used by `whisper` in go ethereum and is influenced by https://www.youtube.com/watch?v=oyLBGkS5ICk . All the code that is used for the networking protocol is now under `v0/`. Some of the common parts might still be refactored out. The main namespace `waku` deals with `host`->`waku` interactions (through RPC), while `v0` deals with `waku`->`remote-waku` interactions. In order to support `v1`, the namespace `v0` will be copied over, and changed to support `v1`. Once `v0` will be not used anymore, the whole namespace will be removed. This PR does not actually implement `v1`, I'd rather get things looked over to make sure the structure is what we would like before implementing the changes. What has changed? - Moved all code for the common parts under `waku/common/` namespace - Moved code used for bloomfilters in `waku/common/bloomfilter.go` - Removed all version specific code from `waku/common/const` (`ProtocolVersion`, status-codes etc) - Added interfaces for `WakuHost` and `Peer` under `waku/common/protocol.go` Things still to do Some tests in `waku/` are still testing by stubbing components of a particular version (`v0`). I started moving those tests to instead of stubbing using the actual component, which increases the testing surface. Some other tests that can't be easily ported should be likely moved under `v0` instead. Ideally no version specif code should be exported from a version namespace (for example the various codes, as those might change across versions). But this will be a work-in-progress. Some code that will be common in `v0`/`v1` could still be extract to avoid duplication, and duplicated only when implementations diverge across versions. |
||
|---|---|---|
| .. | ||
| bridge | ||
| core/types | ||
| crypto | ||
| keystore | ||
| types | ||
| Makefile | ||
| README.md | ||
README.md
Abstraction for Ethereum node implementation
This package is a collection of interfaces, data types, and functions to make status-go independent from the go-ethereum implementation.
status-go is a wrapper around an Ethereum node. This package was created to have a possibility of selecting the underlying Ethereum node implementation, namely go-ethereum or Nimbus. The underlying implementation is selected using Go build tags.
typesandcore/types-- provide interfaces of node services, common data types, and functions,bridge-- provide implementation of interfaces declared intypesusing go-ethereum or Nimbus ingethandnimbusdirectories respectively,crypto-- provide cryptographic utilities not depending on go-ethereum,keystore-- provide a keystore implementation not depending on go-ethereum.
Note: crypto and keystore are not finished by either depending on go-ethereum or not providing Nimbus implementation.
How to use it?
If you have a piece of code that depends on go-ethereum, check out this package to see if there is a similar implementation that does not depend on go-ethereum. For example, you want to decode a hex-string into a slice of bytes. You can do that using go-ethereum's FromHex() function or use equivalent from this package and avoid importing go-ethereum. Thanks to this, your code fragment might be built with Nimbus.