Here are a couple of open research problems I've been silently collecting in the back of my head. In case they come across as incredibly niche, the missing context is that I'm working on Neptune Cash and these are relevant problems in that ecosystem.
- Proof Outsourcing (with Secrets)
Producing STARK proofs is relatively expensive. If you outsource their production you can cheaply verify that the result is correct. However, the outsourcee needs to know all of the inputs -- including secret ones. And so it is impossible to outsource the production of proofs about secrets without releasing those secrets.
FHE exists in theory and enables just that. The downside is that FHE incurs a humongous overhead on top of the already large overhead incurred by proving. So even when the base computation is something incredibly simple, like evaluating a hash function, the resulting FHE computation is unfathomably large.
On the other end of the spectrum lives MPC, where all participants are on equal footing and communicate interactively over the course of a protocol whose output is the result of the computation. The parties' secrets remain secret. The overhead of the MPC work over the proving work is much smaller, but the disqualifying feature is that the workload is equal for all participants. There is no delegation of work.
What's missing is a golden middle, where the outsourcer contributes to an interactive protocol to enable computation over secret data, but where the workload of the outsourcer is negligible compared to that of the outsourcee.
For a compelling application: ownership of coins in Neptune Cash are protected by lock scripts, and to spend a coin you need to prove that it halts gracefully for some secret input. Since the proof is zero-knowledge, and since the proof is tied to the transaction that spends the coin, the owner can safely broadcast the proof without risking a redirection of the funds by a malicious miner. Unfortunately, for low-end machines producing proofs is infeasible and they must outsource this task, which means that the outsourcee must be trusted.
- Lattice BIP-32
BIP-32 AKA HD Wallets is a scheme for parallel derivation of child secret keys from parent secret keys, and respectively child public keys from parent public keys, such that matching key pairs actually form a valid key pair. With this scheme, a merchant can generate a fresh address on untrusted and confiscatable hardware, such that the secret key capable of spending the received funds remains secured in cold storage vault.
The scheme relies on elliptic curve homomorphisms, which is why it is not secure in the presence of quantum attackers. Many cryptographic tricks using elliptic curve homomorphisms have been lifted to the lattice setting, which is (presumably) post-quantum secure. It requires special calibration of parameters though because lattice problems derive their hardness from the presence of noise and this noise has a tendency to grow in magnitude with each homomorphic operation. But even a BIP-32 tree of limited depth would be a great thing to have.
- Isogeny Addresses
Speaking of BIP-32 and post-quantum addresses, isogeny-based cryptography features a homomorphism that is the most similar to the one used by the various elliptic curve constructions, and yet it is (as far as we know) secure even in the presence of quantum attackers. Consequently, a BIP-32 construction involving isogeny-based crypto will support trees of unlimited depth.
There is another reason why isogeny-based addresses are desirable: these addresses are shorter than lattice-based addresses, meaning that more transactions can fit in blocks of limited and expensive space.
Note that in blockchains, we don't really care about signature schemes per se, at least for monetary soundness. What matters is that the same person (deriving identity from a secret key) that receives one coin assents to its expenditure. A commitment scheme, even one based on just hashing, suffices to achieve this property. A signature scheme does too, but it is overkill. The only reason why Neptune Cash bothers with public-key cryptography is for privacy.
- Recipient Fingerprinting
In the context of privacy-preserving blockchains, a major point of concern is the workload of recipients. Specifically, if third parties can't trace destinations of transfers (by design), how can recipients know they were the beneficiary of a transfer?
For instance, to send a Monero transaction you first derive a stealth address from the recipient's public keys, and then transfer the funds to that address. The only way the recipient can know that something destined for them came in, is by trying to unlock every transaction output in a large enough enveloping time window. If the trial unlock is unsuccessful, those funds are sent to someone else; if the trial unlock is successful, the wallet records the secret key and computes the new balance.
In Neptune Cash, payments to the default address type include recipient fingerprints. The recipient does not need to trial decrypt all published transaction outputs, they only need to scan for fingerprints that belong to them. This reduces their workload, but degrades privacy as multiple payments can now be linked as going the the same person. Recipients can, of course, generate a new address for each incoming payment, with a new fingerprint for each address, but this approach requires interaction with the recipient (contrary to Monero's stealth addresses).
There seems to be a missing sweet spot whereby the sender can derive a fingerprint from the recipient's address such that
- for external parties, fingerprints cannot be linked to addresses or to other fingerprints derived from the same address; and
- for the recipient, scanning a bunch of transactions for potential matches with the secret key material underlying their fingerprints can be done cheaply, or even outsourced.
- Stake-to-own-IP
How do you prevent a deanonymization service from flooding the network with cheap sybil nodes that do nothing but collect analytical data? Obviously, you make it expensive, for instance like so:
Peers require each other to produce proofs of ownership of UTXOs that carry funds in excess of a certain threshold, such that:
- the proof is linked to the IP address that the peer is visible on;
- peers can reuse the same proof for the same IP;
- if peers reuse the same UTXO for different IP addresses, then anyone knowledgeable of both proofs can claim the UTXO.
The end result is that in order to flood the network with $n$ sybil nodes, you need to stake $n$ UTXOs of a certain minimum value on $n$ IP addresses.
