New Year, New Possibilities. Blue Sky suggestions welcome.

โš“ Neptune    ๐Ÿ“… 2024-01-14    ๐Ÿ‘ค danda    ๐Ÿ‘๏ธ 266      

danda

Warning

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

aszepieniec    2024-01-23 ๐Ÿ‘ ๐Ÿ‘Ž

  • plugin interface. Neptune was designed to support smart contract protocols via opt-in overlay protocols that do not affect users that do not opt in. To opt in, users should install third-party app software that runs on the same machine as neptune-core but communicates with it through a RPC interface.
3

aszepieniec    2024-01-24 ๐Ÿ‘ 1 ๐Ÿ‘Ž

  • block/tx explorer. An HTTP server that plugs into 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.
4

aszepieniec    2024-01-24 ๐Ÿ‘ ๐Ÿ‘Ž

  • authenticated peers. Give a presentation somewhere. Close the slide deck with a QR code that contains your nodeโ€™s address and public key hash. Or put the QR code on your business card. Folks who connect to this address+pubkey know that they are connected to the right network. Also, connections to this peer can be encrypted without fear of man-in-the-middle.
5

aszepieniec    2024-01-24 ๐Ÿ‘ 1 ๐Ÿ‘Ž

  • Tor. Consisting of two parts: (a) Tor (onion) addresses which work well with authenticated peers to ensure that new entrants are connecting to the right network. (b) Nodes should have the option of routing all of their peer-to-peer traffic over Tor.
6

aszepieniec    2024-01-27 ๐Ÿ‘ ๐Ÿ‘Ž

  • Block fingerprints. An often recurring task is finding out whether block A is a descendant of block B, or whether they live on different forks. There is an expensive but robust way to do this: walk back and compare predecessor. Here is a probabilistic way that is much cheaper and has small false positive rate and zero false negative rate. Every block is stored along with $k$ u64s called its fingerprint, which is reminiscent of a Bloom filter. Relative to its predecessor, every element in this array differs by either 0 or 1. The locations that are incremented depend on the blockโ€™s hash. In order to compare two blocks we subtract their filters as vectors. If the difference contains a negative number, then for certain B is not a descendant of A. If not, then it probably is. The exact probability depends on the length of this vector, $k$.
7

danda    2024-01-30 ๐Ÿ‘ 1 ๐Ÿ‘Ž [op]

i2p. Bitcoin and monero both support connecting via i2p now. Makes a nice alternative for Tor.

8

aszepieniec    2024-01-31 ๐Ÿ‘ ๐Ÿ‘Ž

  • minisketch. Minisketch is a set reconciliation protocol. Two peers each hold an a priori distinct set of data records, but they both want to know the union of their respective sets. How do they find out, using the least amount of bandwidth, which records they need to send and which the counterparty already has? Minisketch solves this problem. In a blockchain context, records could be blocks, or transactions, or even something else.
9

aszepieniec    2024-02-23 ๐Ÿ‘ ๐Ÿ‘Ž

  • 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):

    • a) it has a valid witness (including spending keys and mutator set membership proofs) (note that a (transaction, valid witness) pair cannot be broadcasted because that would undermine both soundness and privacy)
    • b) it has valid proofs for each subprogram (subprograms establish things like the owners consent to this transaction, there is no inflation, etc.)
    • c) it has a single valid proof that merges all of the above proofs into one
    • d) it has a single valid proof that the transaction originates from merging two valid transactions
    • e) it has a single valid proof that the transaction belongs to an integral mempool, i.e., one to which only valid transactions were added.
12