This post was published 41 days ago. The infomation described in this article may have changed.
I’m making this thread for anyone to throw out ideas for Neptune. Basically, anything we would like to see exist or occur: software/features, architecture, community building, economy, mining, game-theory, etc.
This is BlueSky Thinking, so for purposes of this brainstorming exercise, it is the idea that matters. Artificial constraints such as deadlines, budgets, mvp, and spent-cost efforts do not exist. Practicality and present feasability are only minor obstacles. :-)
My own personal wishlist for Neptune software/architecture, in no particular order, are:
Seperate wallet from server. So a single neptune-core instance could serve multiple neptune-wallet-rpc servers. Monero does this, and it makes for a clean architecture and smaller code/attack surface for the core server and wallet. Also more suitable for use by exchanges, block explorers, etc that do not need wallet functionality.
multi-wallet support. Some of my fav bitcoin wallets support multiple wallets and make it easy to create new wallets. Either with a new seed for each, or sharing same seed, but with a different bip32/44 path identifier. monero-wallet-rpc supports shared seed wallets with the new_account API, so again that’s a possible model.
strong ASIC resistance, in the form of randomX POW algo. again, from Monero. Or possibly equivalent dynamic programs running in triton-vm would be even cooler (tritonX?). This should also help prevent 51% attacks by existing ASIC or GPU capacity, something common to lower market-cap coins.
SDK. let’s make neptune-core into a proper library/crate, with neptune-core executable just an app/user with very little code. (darkfi does this).
jsonrpc interface. (already discussed)
EVM compatibility layer. There’s a lot of EVM contracts out there and GUI apps built around them. (Infrastructure) It seems some layer1 chains don’t seem to gain traction until they provide EVM compatibility, and most do provide it.
bip39 mnemonic support.
light mode support in neptune-core. (already planned, i think?)
immutable/frozen consensus layer. already discussed in another thread.
mine tiny amounts on any device. eg mobile phone. So anyone can mine/participate. even though they might receive eg fractional satoshi equiv rewards. Ideally if my hash contribution is 1/100 billionth of the worldwide hashpower, then I should receive 1/100 billionth of each block reward that I mine on. The key is that the tiny rewards be regular to keep people participating. Also, the long tail is key for decentralization and ossification.
integrate p2pool by default. or something similar for decentralized mining pool/shares. This should weaken centralized pools and their capacity for 51% and potentially huge influence re eg soft-forks.
consensus: require proof that miner (hasher) is validating. make it impossible (or too slow) to mine a block without full, local blockchain. In bitcoin miners choose centralized pools because it is easy and they don’t have to setup a full node. But they are not validating and double-checking eachother. They are only hashing. This greatly harms decentralization. Take away this option, and they will be happier to use something like p2pool. edit: yes this is in conflict with tiny amounts on any device, but that probably won’t happen anyway, heh. edit again: if a neptune light-mode miner can fully validate given only the current tip block + new block, then it seems this will not be a problem the way it is on bitcoin, so we just need to ensure they are actually doing that, and not able to delegate validation to pool.
So what do you think of the ideas on my wishlist? And what are your ideas?
note: Several of these ideas are from exposure to the monero ecosystem. I don’t wish to turn neptune into monero by any means, but I do think they’ve had some nice, comparatively little-known architectural improvements over the btc ecosystem, for example.🏷️ bluesky, architecture, asic, evm, bip39, lightmode
neptune-core but communicates with it through a RPC interface.
neptune-core and displays information like block height, block digest, # addition records, # removal records, variable network parameters such as difficulty, node address (?). On top of that it allows the user to lookup blocks and transactions.
space-efficient mempools. Add a consensus rule allowing mempool operators to throw away all transaction validity proofs in exchange for one mempool validity proof. Specifically, add rule (e) to the following list of criteria for transaction validity. A transaction is valid if (any criterion suffices):