Open problems
Crypto.
Horizontally-scalable databases.
A horizontally-scalable database is a database where adding one node increases the capacity linearly. We know how to do this since Google’s Bigtable, and since then we’ve achieved better efficiency through colocating disparate data stores e.g. in Colossus. The question is - if/when we will apply this to crypto?
There are two parts to implementing this:
- Computation. We need to compute the database index efficiently. We can use ZK S[TN]ARK’s to efficiently verify the correct computation of an index. And we can use recursive proofs in order to scale this - wherein each node produces a proof of their work, and these N proofs for N nodes are aggregated into 1 proof for 1 blockchain, to award fees for work done. The challenge remains in doing this efficiently.
- Open ideas. Specialised structures (vector commitments) for database indexes. Recursive proof aggregation (fast STARK proofs, big size -> slow proofs, small size a la groth16).
- Storage. We need to store/share the data persistently. Unlike Google, there is no file system abstraction (GFS). At best, we have Arweave and Filecoin.
There are multiple axes to target:
- Strongly-consistent databases. SQL databases.
- Loosely-consistent databases. Like those used by Twitter, Facebook, Discord.
There are multiple places this is needed:
- WalletConnect recently shut down their v1 API, to many apps breaking. If their backend was decentralized, this would not have happened.
- Reddit, Discord, Github - many examples of censorship here and lack of community control.
Crypto on mobile.
The dream is tokenising anything on the go and being able to speculate with ease (speculation is good, contrary to what the word imparts).
Crypto on mobile requires an entire post to explain, because there are problems at every layer of the stack - onboarding, accounts, different blockchains, etc.
I’ve summarised them here - https://mirror.xyz/nakamofo.eth/nPamnC8dTK0bIPNg3nNAu4bWZts-EysfgaeNWbOiV6c.
Decentralized frontends.
Crypto is useless if the frontend goes down. What use is having a capture-resistant global institution if the user interface is susceptible to failure? This is the big problem I worked on when building Dappnet. There are still many issues to solve here, that I’m still thinking about.
Usable API’s for private on-chain games.
How can we have private information in on-chain games, ie. the fog-of-war problem? See this post for more background.
Privacy and indexers.
How do we securely lookup a private account when indexers can log our requests?
Problem of Zcash.
TODO fill in with Zcash + Penumbra probabilistic delegated detection capability.
TODO fill in with MPC + homomorphic encryption + wei dai’s
ZK updates lead to race conditions.
How do we do concurrent updates to state in ZK without race conditions?
Adjacent areas: CRDT’s, ZK S[NT]ARK’s