Last week by the numbers
neptune-core
twenty-first
neptune-explorer
triton-vm
Neptune Happenings
Hard Fork Proposed for POW Algo Change.
Pull Request #727 by @sword-smith fixes a deficiency in the memory-hard POW algorithm that disincentivizes guessers from switching to block proposals that should be more profitable for them.
Presently (in neptune-core 0.4.0) switching to another proposal requires performing the pre-processing step again which takes up valuable time. Many guessers choose not to switch, which disincentives composers from competing and keeps the guesser-fraction lower than it should otherwise be. Most importantly, it prevents new transactions from being merged into the block proposal after guessing has started. With this hardfork, more transactions can be added to the proposals as guessing is ongoing.
The PR makes switching essentially free, so guessers should be properly incentivized to jump on the most attractive block proposal, which also means the proposal that mines the most fee-paying transactions.
This change, while small, does affect consensus and thus would require a hard-fork, if agreed upon.
More information will be forthcoming once the PR goes through review process.
Neptune listed on CoinGecko and CoinPaprika
@sword-smith added a couple of RPC endpoints to explorer.neptune.cash that market aggregators need for providing blockchain information. For more technical details, see github.
With this technical support in place and the efforts of our outstanding Neptune Community, Neptune is now listed at:
coinpaprika
coingecko
https://www.coingecko.com/en/coins/neptune-cash
note: Be sure to look for Neptune Cash with symbol NPT. Some other listed projects have similar names.
Competing PRs raised for multi-lang RPC support in neptune-core
When it rains, it pours.
After years of having a single, rust-only RPC mechanism in neptune-core…
@danda and @KaffinPX have independently integrated RPC frameworks, taking different approaches. It will be up to reviewers to evaluate and choose a path forward. Both PRs are presently in a draft state, not considered ready for a final review.
Both solutions aim to address issue 62, which is one of the oldest open issues in neptune-core. The goal is to improve interoperability by making neptune-core RPC’s callable from other languages.
@danda’s solution utilizes a single set of RPC endpoint methods, where each method is automatically called by a thin wrapper for each of tarpc, json-rpc, and rest. All the wrappers are generated via macros. In this way, both old and new endpoints are supported by each RPC framework.
@KaffinPX’s solution adds json-rpc support to neptune-core and includes namespaces for different sets of methods such as node, chain, mempool, mining, etc. The PR presently includes two basic endpoints. It appears to be intended for future endpoints rather than extending interop for existing endpoints.
Parallel Block Download Progress
@aszepieniec worked on parallel block downloading and decided to implement a pseudo-random block generator to test concurrent processing of incoming blocks.
Summary of architecture:
- When sync mode is activated, it will spawn an event loop known as the sync loop which is a message-driven actor communicating with the main loop; the main loop relays messages to and from peer loops whenever necessary.
- The sync loop communicates with only one counterparty (the main loop) and does not share memory. This modular design benefits testing and conceivably the module could be factored out into its own crate (although there are lower-hanging fruits than more fine-grained crate separation if the objective is to improve compilation speed).
- As blocks come in, they are stored to disk into a temp directory. The temp directory has a deterministic name. If the directory already contains files then the sync will resume from there. (And so, you can power down your node mid-sync and not have to throw away all hard work.)
- Block can come in concurrently, out of order. When all blocks have been received, they are processed by the main loop in order as a result of which they are stored in the blocks database. At this point the temp directory is cleared and deleted.
- The state of the sync loop records which blocks have been received already (or even processed) and which blocks have not been received yet. Peers that have the new version of the software are given this snapshot and are allowed to respond with a random outstanding blocks (peer samples randomness). Since they are running the new software, they can respond with blocks from their own temp directory even as they themselves are syncing. Peers running the old version of the software are asked for given random blocks (sync loop samples randomness), and can only be used for synced if they themselves are fully synced.
Paving the Way for Faster Hashing
Prior to his leave of absence, @jfs started to integrate a vectorized version of the Tip5 hash function. This version makes use of AVX-512 features, leveraging Single Instruction Multiple Data (SIMD) instructions of modern CPUs. (It sounds fairly technical because it is.)
A community member pointed out that the implementation contains a bug somewhere, and @jfs has spent most of last week trying to figure out where. You can follow the feature on github.
Reminder: 0.5.0 Feature Wishlist
A wishlist has been created for the next version of neptune-core. The team is soliciting community feedback, so please add your desired features on github, or just comment in this thread.
Contributor Updates:
- conferencing at ASCrypto and LatinCrypt in Colombia
- parallel block download
- catch up with the last 3 months
- triage open PRs
- migrate stale PRs to latest
master - …
- reproduce bug & start debugging Tip5 AVX-512 discrepancy
- implemented and published multi-rpc crate
- raised draft PR integrating multi-rpc into neptune-core