Nescience: A User-Centric State-Separation Architecture - Moody | Status

Hi everyone, my name is Moodi and I'm a researcher as IFT. Maybe you are not familiar with IF. IF is the institute of free technology. Uh under its umbrella there are cool projects like status, logos, waku, codex, nomos. We are an incubator project within the research pident identity of the uh of IFA.

Our project is called Nessian. Um so yeah today I will dive into what is Nessian. Uh just to be uh clear about it, it's like state separation architecture. So combining private state and public state but also enabling selective privacy on the user side rather than deps. So to start with the problem that we are trying to solve.

So nowadays we have public blockchains that are transparent by design but they sacrifice privacy because they lack privacy. And then we have private blockchains that are private by design but they sacrifice functionality and integration. So the problem is we want to solve how we can preserve the privacy without losing the benefits of the public blockchain. Um so um without a hybrid approach actually users have a choice either to go fully public so they will get uh full functionalities but they will have no privacy and they can have private blockchains where they have privacy but it's limited. There are some workarounds about this like mixers or crosschain bridges, but these can be a little bit problematic and sometimes they break composibility.

So what we need is an architecture that can combine public and private transactions that can work together under the same platform. So what we are trying to do is to combine public state and private state together. So what is Nessence? Nessian we call it NSSA maybe the name is not the best but it's like Nessian state separation architecture uh and it enables um selective privacy I will go through selective privacy later uh the pronunciation is nessian so nessian actually means lack of knowledge uh so our idea is that instead of having privacy set and fixed by deps and developers we want to let developers and users to choose uh when transactions are private, when transactions are public and how. So the main idea is to have a double state architecture accounts based model and um UTXO based model uh that can be like bridging between transparency and shielded environments as needed by the users.

So what we'll have is a public state. It's an account-based ledger uh where we have accounts and u balances and a private state that is a UTXO based uh where it represent the ownership of data or sets. Um so yeah so what we are trying to enable here is let's say that Alice wants to send some transactions to Bob in a shielded or dshielded way. I will go through these definitions later but it will allow Alice to create a UTXO a new UTXO for Bob and send it privately. So um what we'll have is selective privacy within execution uh types.

So we will be having four execution types. Public execution, private execution, shielded and dshielded execution. So public execution is transparent execution. We only need a VM. Uh we write and read from the public state.

We have a private execution where we use a ZKVM um and it reads and write from the private state. Then we have shielded and the shielded execution. So shielded execution actually it reads from the public state and writes in the private state. Uh so we are spending publicly but who is receiving is receiving funds or assets or data uh privately and in dished executions we are writing from the private state uh we are reading from the private state and writing in the public state meaning that users can spend their funds privately but they can receive them publicly and here I want to give an example about shielded execution initial execution. So initial execution imagine Alice willing to um send some funds to Bob.

So what she will do is there will be a zk proof that need to show two things that Alice have this funds on her public account and that the new private node that Alice will uh build u is correctly formed. In the dished execution, Bob uh have a private note of this uh tokens that originally maybe received from Alice. Uh and now he needs to dish them. So what he need to do is he needs to move these tokens from his private account to his public account. Uh so the transaction will provide a proof that this token is valid uh and is worth this value.

uh and Bob is allowed to spend it actually. So it will be destroyed, nullified and then the tokens will be uh added to Bob's uh public state. So why selective privacy? Um so in our view selective privacy addresses real world needs. Um it shifts from being fully public or fully private.

It also somehow solved the problem of privacy leakage in accountsbased model where for example if you think about u a donating platform uh yeah the the donor is somehow maybe hiding his ID but in accountbased model we can still um leak some patterns. uh to solve this actually UTXO models break this linkab break this linkability. Uh so whenever users interact with a contract or send a transaction in essence u think about it as um having a privacy dial that you can set. So uh at the moment you craft a transaction you can choose if you want to have a public transaction, private transaction, shielded or the shielded execution. So you can think about it as when you send an email if you want to CC everyone so you go public or you want to send private email to some people.

Um so yeah uh this is this is how we see things. This is how we want to shift this choice to be from the user uh choosing uh whenever to be transparent or private rather than the DAP or the developers that dictate the level of privacy of user transaction. So here I will just show you an example about how the architecture is made. So for public executions we don't have a ZK VM. So we have the user that will have his public state public input they will go through the sequencer they will be rerun and the public state will be updated whenever there is a transaction.

Same for private execution but as you can see we have a ZKVM we have the user that is uh uh compiling his private data into a proof. There is the ZKVM that will verify this proof and the private state will be updated later. Shielded executions actually as I said we are going from public to private. So you need to think about sending some tokens publicly. So let's say that you need to send 50 tokens.

What you will do is that you will submit to the VM the request of spending 50 tokens. It will be verified that you have these tokens and your balance will decrease. At the same time, the user will be sending private calls to the ZKVM saying okay I want to send they are proof but within the proofs you will have like I want to send 10 tokens to user A, 10 tokens to user B, 10 tokens to user C etc. And no one will see this. So everyone on the chain will see that I spent 50 tokens because my public balance will be decreased but no one will know how I spent them and to whom I send them.

And the dished execution actually we are going from private to public. So what the user will do is whenever they decide to dish uh some tokens and update the public state they will be doing this. So they will feed the ZKVM with the private uh inputs and what will happen is that there will be some controls. We will see later a more clear example and what we will see is that the receiver uh account balance will increase but when we check the transaction we won't be able to link where these funds come from. So this is an example of a shielded execution.

So Alice wants to send assets to Bob privately. So she will initiate initiate a public transaction which is a shielded uh transfer. So the shielded transfer will lock Alice's assets publicly and it will create a private exo for Bob. So on the public phase Alex transaction Alice transaction will run on the public VM. it will deduct its asset from the public uh account and the output will be directed into a shielded pool on the private output.

Actually, Alice will be building a new UTXO for Bob and it will include generating a random commitment and assigning the ownership of this UTXO or not to Bob. So there is a ZKVM that will be uh made and this will show two things. it will show that the public transaction output value is equal to the UTXO value. So we will be able to say okay Alice wants to spend publicly 50 tokens. There is a proof on private proof that she will be um spending this tokens.

So the ZKVM will only check this value. So we will check that what Alice want to spend is equal to the note that she created and it will tie the ctxo commitment to the transaction. So the sequencer actually what will do he will execute the public part and decrease Alice's uh balance and it will verify the zk proof and update the state. So the public state will be updated through the public transaction and the private UTXO commitment will be add to the tree of the UTXO. So like this we have combined private and public execution within the same transaction.

So what we are doing now now we are trying to work on um hybrid smart contracts. So we want um to build a logic under the same smart contract where public functions and private functions are uh touched either like public state or private state within the same logic. So a contract can have a public method that triggers um some private uh functions or what we want is to be able to call from a private function a public function like dshielded and shielded executions. We also want to enforce that certain state variables can be only updated by private transactions or public functions. So uh think about it like this.

You want to deploy a smart contract in Nessions. Uh so you'll have two facets uh a public facing part and a private logic part. Uh for example the contract might say uh for public executions uh maybe uh just do this state updates and for private executions uh we want the logic to happen on UTXO. Uh so the developer instead of writing uh a smart contract for each execution uh the developer would be able to write uh a unified smart contract where it can touch both uh public and private states. Uh the logic will understand whenever there is a public transaction for example it will only touch the public output it would only touch the public uh state.

If there are some private functions then the user will uh generate some proofs. They will be run through the ZKVM under uh kernel circuits. Then this kernel circuit. So each private transaction or each private function will be seen as uh a kernel circuit. Then the circuits will be uh aggregated and the user will be able to send the proof along with the transaction.

So now I will just show a table on what are the differences between what we are doing and what is being done. Uh we are not claiming that we are better. What we are claiming is that we are shifting uh the privacy uh towards the user. So we are building something that is userdriven rather than depth driven. Uh we are allowing four execution types uh public, private, shielded and dshielded.

Uh we are working on smart contracts that can be fully hybrid. Uh regarding uh public transactions, we don't use ZK so there is no cost for that. Uh instance can be deployable uh as an L1 as well. We use Rust, we use risk zero ZKVM. So all the architecture itself is modular pieces components can change under certain rules.

Uh but yeah it's fully it's fully modular and fully flexible. So um now the idea is that whatever we are doing we are building public goods. We care about users. We don't care a lot about monetizing or making profit. And this is where um the idea comes from.

Um so I will just give some use cases where nessence can be uh used. So often those uh struggle with balancing between uh transparency and the voter privacy. So today if we have onchain voting everyone can see how each address voted and this can lead sometimes to some pressures or bribes. So uh with nessence we can build a DAO where proposals are published. So maybe it's like public uh or the decision is public or what we are voting for is public but the votes are casted uh privately and each vote can be seen as a UTX or not.

Uh so voters can submit their uh votes as uh private executions. Uh so no one can see how they voted. What we will see is that the result is revealed and we can also submit a proof that these votes were casted correctly. This is like it preserves the voter anonymity and still ensure that the outcome is valid and it's transparent and it's also uh encourage uh more honest voting as there will be no fear of retaliation or no fear of pressure. uh everything is seen as a secret bullet uh ballet uh all executed on a public blockchain.

Another um another example can be uh private defy um uh AMMs where every swap is visible. Everyone can see who traded which amount and when. So this transparency actually sometimes lead to issues like front running as bots can see a large trade and try to jump ahead and can reveal maybe sometimes the strategy of uh big traders. If we use uh AMMs on top of Nessions, a user can perform uh these swaps in private uh and the contract um the AMM contract can just like accept this shielded or private swaps uh where the proof is provided that every trade is obeying the the rules. So like this we can reduce the MV uh because observers cannot pinpoint actually individual traits uh and sometimes actually uh we could take a loan privately.

So uh instead of uh showing what we are doing or like uh showing our financial um uh situation we can take uh we can accept loans to be done privately between users and just uh show the total uh price change or the total amount. U this is one of the last things that we care about. So sometimes when I'm talking to people they say oh this is another uh tornado cache. Actually it is not uh even though I have nothing against tornado cache but people are afraid about compliance. So um one advantage of nience is uh users can choose when to be transparent.

Uh imagine a business that want to pay uh their salaries. So they want to use the blockchain for accountability but uh they want to hide they want to have some confidentiality for example hiding uh from supplies suppliers or salaries they don't want to show everyone uh salary. So what they will do they can do all the everyday transaction uh privately and they can use um uh a viewing key. This viewing key actually allows uh auditors to check all the transactions that have been made. Uh the only difference is that it's not being made all public.

It's just giving the user the ability to choose when they want things to be public. So uh look at it as uh an opaque glass that is frosted when you are on private mode. Whenever you want to go public transparent, you can show it. Otherwise, you can stay private, but you can choose who can see whatever there is in the uh in the glass. So, this is how we see selective privacy.

It's selective disclosure and it gives user also privacy preserving compliance. Thank you. Any questions? Yes. Yeah.

So I have like half a dozen question.

I will I will keep it short. Um maybe just before one first thing is um it's a bit counterintuitive but you know sometimes in terms of UIX constraining users is actually the good thing to do and I'm thinking for instance if we think of the darknet market okay they forced transition of the user from Bitcoin to Monero simply because trusting the user to do proper mixing on the Bitcoin blockchain proved to be unrealistic. most were not doing proper mixing and essentially they were putting in danger the whole system by their lack of privacy. So they kind of decided okay we're gonna force you into a private by default coin coin and now we know that uh privacy is preserved in our little system. So I I guess my question is like it's a bit similar to the Zcash problem essentially where if you have public and private coing on the same network and especially with state change transactions like those shielding and unshielding how do you not weaken your anonymity set by the existence of those public uh transaction?

Okay. Um so uh good question actually what we care most about is um so we are not holding any data any private data in the architecture. So users are uh generating their proofs uh on the user side. Uh what we care about is just making sure that these proofs are valid and these proofs as I said in the in the example before uh whatever value they have they match the public uh value that have been requested originally by the user. So once we have this and we have this check then everything should be okay.

Whenever we see that for example the user is trying to send 50 tokens but they don't have this 50 tokens or the proof itself doesn't reflect this 50 tokens then the sequencer will reject this and it not it's not going to be uh processed. What we also encourage is with selective privacy and we highlight this selective privacy is that users can start using nessions but by being fully transparent and while they learn about privacy because privacy is not just hiding. We are not talking about hiding money or tokens or it's about literally understanding what uh data should be kept private and how to use this privacy when to like disclosure like when to disclose this private information. So this is why we say that it has different type of um of things to do. uh what we care is the control of uh of private and public data and of course if you want to do something that is somehow malicious you are not going to use nessence you will go fully private and use uh some roll-ups or some mixers or monero or stuff like that so we don't put a lot of assumptions on the users uh because we want to drive the user to understand the privacy needs and why they need to use this architecture in order to achieve uh their goal.

I don't know if I answered your question.

I'm not sure. So essentially, you're telling me that if I'm looking for very strong absolutely resilient privacy,

sorry,

if I need some serious privacy where I'm thinking I need to protect myself against a state funded act or or this kind of threat, this is not for nation.

Yeah. Yeah. I I I mean what I'm saying is that if you want to do malicious things, you are not going to use this because controls are made in a way that whenever there is suspicious uh transactions, they will be rejected. Also you you are obliged to have this viewing key that you will need to show and audit and maybe for some checks that these transactions actually are not like are valid and are not like somehow breaking the system.

Thank you.

One more question.

Hi, thank you for presentation. I have actually two questions. So one question is you you mentioned this AMM with kind of private and public where the price change is public and the details of swap are not

but if the price changes can I deduct what are the changes in the reserves. So basically I know what was the swap. I mean you can you can know what happened like you can know that there was a change but you won't be able to link it to this address or to this person to this user.

Okay. Uh and the other one u the users have to keep the proofs right uh to

sorry

users generate the proofs and they are they are required to keep them safe. Yeah right. So if user loses their proofs they basically lose the money that was locked. Right. Um I'm not sure about this if the user lose the proofs actually the users are proving that they have uh consumed some notes or they have built some notes uh and what is happening is that on the public state these funds are locked.

So even if they lose this uh proof and they don't submit it there is nothing that will be done. So the the funds will be

they cannot be unlocked. They cannot be unlocked. Right.

Sorry.

They cannot be unlocked. Only the the only unlock is when you make this private transfer later. And to make this private transfer later, I need this uh proof to show that I'm spending the money that was locked.

Yes.

And if I lose this proof,

it means that I lost this money that was locked. Right.

Kind kind of like if I lose my private key. If you lose your Yes, sure.

Okay. Same situation.

Yes, sure.

Okay. Thank you.

Sorry, we had to

just you ask short one.

Okay.

How this functionality relates to the other products in the full portfolio like Codex or Nomos?

Actually, uh for Codex, we don't have any um any link to it yet. But for Nomos, you know, Nomos is working on uh zones. So, Nessence can be a sovereign zone where uh you know, they they generate the proofs and then they will regenerate, rerun our proofs and make us bridge with other nodes for now until it's clear how the native zone in Nomos will be built and I think that we might be able also to be a native zone with Nomos. Thank you.

Thank you.