Account Storage and Efficiency
Q: How is account data persisted on nodes efficiently when programs output or modify accounts?
A: Right now, accounts are stored in a hashmap that maps addresses to accounts. Programs don’t actually create new accounts; they just modify the ones that already exist. The public state is basically a dictionary of addresses to accounts. When a program runs, it fetches entries from that dictionary, executes, and then writes the updates back. The important detail is that the hashmap doesn’t hold every account. It only stores non-default accounts — the ones that have been claimed or touched by some program. If a transaction tries to use an account that hasn’t been claimed yet, that account isn’t in the hashmap at all but is treated as if it has default values. This way, data doesn’t get duplicated and storage stays efficient.
Q: What are the unique selling points of Nescience, and why is it being built?
A: One of the biggest selling points of Nescience is that it’s privacy-first by design. A lot of other systems added privacy as an afterthought, which makes the solutions less efficient. Nescience, on the other hand, bakes privacy in from the beginning, so it’s part of the foundation.
Another angle is developer experience. Not every DApp developer is an expert in zero-knowledge proofs or in handling the tricky mix of public and private variables. Nescience is set up in a way that makes it easier for developers to work with privacy features without needing deep cryptography knowledge.
On top of that, there’s selective privacy:
- Public transactions stay cheap and efficient, so you don’t lose anything if you don’t need privacy.
- dApp developers can pick and choose which transactions should be private.
The idea is that good user interfaces will make this even easier over time, so regular users won’t have to think about the details — they’ll just use apps seamlessly. Altogether, the focus on privacy, efficiency, and usability is what makes Nescience stand out.