In response to popular demand, we had a brainstorming session at the office where we attempted to chart a roadmap for the project.
Disclaimers:
- This roadmap intends to capture important big picture future developments, not urgent ones. In particular, no priorities are implied.
- Prospective dates are intentionally omitted.
- This roadmap represents a snapshot of current way of thinking of the team members that were present (and not all were). The roadmap may be arbitrarily changed. No commitments are implied.
With those disclaimers made, this roadmap provides a better insight into what the project might have to offer in the future than the prior communication void did.
Mempool Redesign
This category captures a bunch of loosely related issues, starting with the erratic transaction confirmation pipeline and the proposal to fix it by refining the role of the Upgrader in the context of block production. However, Neptune Cash has unique demands and capabilities and no adequate mempool template exists to emulate. One task is to figure out and articulate what the mempool can and should do (in the specific context of Neptune Cash). Another issue is to enable support for multiple wallets because surely neptune-core cannot be made aware of all smart contracts and non-native tokens – and so, users that want to trade and engage with them must install an external plugin or so.
Authentication Structure Authentication
Authentication structure authentication refers to the nondeterministic algorithm for verifying the authenticity of a Merkle tree authentication structure. It is a key space-saving technique which was already affirmed to be an objective and anticipated as a future hard fork in the Hard Fork One announcement.
Triton-VM Optimizations
While we have certainly exhausted the low-hanging fruits, trove of higher-hanging fruits remain when it comes to prover optimizations. The following lists of optimizations is presented without context, more as a record for the developer(s) who are going to implement them than as an informative overview for outsiders. (Sorry.)
- Giacomo’s trick for verifying interpolants
- bitreverse Merkle tree leafs
- STIR
- DEEP Commitments
- continuations
- Plonkify AIR
- Double-DEEP
Transaction Chaining and Lock-Free UTXOs
Right now, you cannot spend outputs of transactions that have not been confirmed yet. While that’s inconvenient when you want to pay multiple people, it’s very annoying in the context of smart contracts because you only get one smart contract interaction per block. The solution is to change the Transaction data structure, or add a new one, whose inputs can refer not to items added to the mutator set but instead to outputs of some other transaction that was not confirmed yet. A new consensus program “Chain” will output a new transaction that combines the two links, and will perform cut-through on the outputs that are immediately spent. And while we are changing the Transaction data structure with facilitating smart contracts in mind, it makes sense to use the opportunity to enable lock-free UTXOs.
Applications and Smart Contracts
So far we have done a lot to build the foundations of the global financial backbone of the future, but the reason we are excited about that is because of all the applications you can build on top. Another list without context.
- Multisig
- Bridges + Cross-Chain Atomic Swaps
- Lightning
- Tokens
- Trading and Financial Instruments.
Succinctness
Succinctness is the feature of a blockchain whereby evaluating the fork choice rule and participating in block production can be done with negligible (as a function of the number of blocks) memory and time complexity. Concretely, we plan to achieve this feature with recursive block validation, which is a consensus rule that requires that every block contain a proof of its predecessor’s correctness.
After succinctness, archival nodes are not needed to enable new nodes to sync. They might be needed to serve users with historical block data so that they can update out-of-sync UTXO membership proofs, but they (the archival nodes) are allowed to charge a fee for this service. On the whole, the network can collectively forget historical data and this will not impact its continued operation.
Documentation
(Insert text here.)
v1.0.0
Right now neptune-core is on version v0.2.2. The leading 0 signals that things can break and no guarantees are given about compatibility across versions. It reinforces the disclaimer that it is experimental software running novel and untested cryptography.
At some point, hopefully, we will have garnered enough confidence in the security of the cryptography and the code that we can afford to drop not the disclaimer but its reinforcement through the version number.
More Developer Competitions / Bounties (?)
One of the objectives is to increase development parallelism. This is obviously difficult when developing the foundational basics because the knowledge required to contribute is the bottleneck. However, the foundations are slowly stabilizing and it is starting to get time to devote attention to ancillary projects – where the barrier to entry is a lot lower and whose parallel development does not interfere with itself. The GUI Wallet Competition is one step towards fostering external development efforts. If this dry run is well received there may be more competitions; otherwise a pivot is in order.