How to make `SmartContract.sender`'s correctness a part of the proof?

[hallow meadow]

There is a comment for .sender property of SmartContract class as below.
So my question is that how to do it a part of the proof.

Warning: The fact that this public key equals the current sender is not part of the proof. A malicious prover could use any other public key without affecting the validity of the proof.

[white barn]

Hey @hallow meadow, you can achieve this by taking the PrivateKeyof the user as an argument in your smart contract method, and then asserting the PrivateKey you got to equal to the sender. (Or else you do not even need the sender, you can just convert PrivateKey to a PublicKey and use it) This is possible in Mina since all the SmartContract inputs are private! Please let me know if this helps 🙂

[hallow meadow]

Thank you so much ❤️

I have another idea, instead of taking PrivateKey of the user (Auro wallet wouldn't allow it) as an argument, we can make the user sign sth and take it as an argument, then we can check if it is signed by SmartContract.sender.
So we will be sure that the user has the private key of the account to sign data.
Is this a valid approach?

[calm reef]

Hello, I see that you seem to have some doubts. What do you want to sign with Auro Wallet ?

[hallow meadow]

Thanks for kindness.
I'm very familiar with Auro wallet, I'll just make it sign a field with user's private key using window.mina.signFields method.

[white barn]

Yes, signature would also be a very nice approach. I just wanted to emphasize that you can even use PrivateKey with Mina smart contracts 😂 Be careful though to always sign a unique nullifier for each TX, so that if the signature is stolen, it cannot be used in other TXs. (even though this is very unlikely, as again the signature does not leave user's device and thus always stays private)

[calm reef]

Okay, if you have any ideas or suggestions, please feel free to submit them 😁

[humble flower]

Having a fetchAccount() function in the Auro API would be great.

The o1js library is big, and I do not load it on the main page, only on the pages that have to work with o1js. Still, showing the account balance or token balance on the main page would be great. You have this information in the Auro as you are showing it to the user, and it would be great to have a means to access it programmatically.

[calm reef]

Does fetchAccount() mean to return the information (such as balance and other status) of current account in daemon node ?
Could you please tell me why you want Auro Wallet to implement it?

Because it seems that the daemon's GQL interface can be used directly here? Because o1js also directly uses the GQL interface of daemon to query.

[humble flower]

Yes, in the ideal case, it should return the same information as o1js fetchAccount() return:
https://docs.minaprotocol.com/zkapps/o1js-reference/modules#fetchaccount

Yes, you are right. GraphQL can be used here, but getting it from window.mina will be much easier. Usually, zkApps don't work directly with GraphQL and use only o1js and window.mina, so now, to handle this case, writing additional zkApp code to access GraphQL queries is required that needs to handle different networks, query code, etc, leading to the potential bugs in the zkApps. It is not critical, but good to have feature.

[calm reef]

okay , in addition to fetchAccount(), no other information on the node api is needed ?

[humble flower]

I don't see that other information would be needed when o1js is not used, but other zkApps can have different use cases. fetchAccount() covers 99% of the needs, I think. Sometimes, there are requests to get block data, but they are very rare.
#zkapps-general message

[calm reef]

Hello, thank you for waiting. We will discuss this feature internally. We will communicate further if there are any updates.

[calm reef]

Hello, we plan to add support for zkApp request fetchAccount in the next version. This is the return of the current ordinary address and zk address ! @humble flower
Currently this method is only supported on the berkeley and testworld2 networks.

https://github.com/aurowallet/auro-wallet-browser-extension/blob/feature/fetchAccount/src/background/DappService.js#L151

Currently, the return result of the node is returned directly without any corresponding processing. Because currently Auro Wallet does not introduce o1js.

Do you have any suggestions or thoughts about this?

[wanton citrus]

I’m not sure but I think you can use Account.createSigned(this.sender)

So the sender need to sign the tx

[hallow meadow]

Yeah, thanks for this information. ❤️

[humble flower]

Thanks a lot! It is precisely what is needed, all the info including zkApp state, balance and verificationKey is present.

[wanton citrus]

Hello, have you an example with nullifier?

[calm reef]

OK, the next version of Auro Wallet will include this feature

[wise ore]

Currently, in my code, i am doing like this

const transaction = await Mina.transaction(
      PublicKey.fromBase58(sender),
      () => {
        state.zkapp!.submitSolution(
          Field(Number(puzzleRef)),
          PuzzleStruct.from(puzzle),
          PuzzleStruct.from(solution)
        );
      }
    );

so sender could be spoofed? instead, i should use PrivateKey or pass along user's signature?

am i understanding correct?

[wooden arch]

no @wise ore, the account you use as fee payer can't be spoofed - the tx in your example will only be valid with sender's signature on it.

the issue we were discussing here is the following:
when you use this.sender in your smart contract, it's value is basically a user-provided input. there's nothing proved about the connection of this.sender with the actual sender of the transaction.

[wise ore]

thank you, noted @wooden arch

[humble flower]

Hi @calm reef ! Do you plan to add the possibility of connecting to the mobile Auro wallet from the mobile web (iOS, Android)? Something similar to the MetaMask SDK, but to be able to use in mobile browsers like Safari.

o1js is working on mobile in my tests, but the possible functionality is limited without the wallet.

[calm reef]

Yes, we are considering auro mobile app to support zkapp. This is already in the plan.

[marsh sedge]

Isn't the fee-payer account always the sender?

[wooden arch]

Yes sure, if you use it normally.

But ultimately, from the point of view of the zero knowledge proof, this.sender looks like any other unconstrained variable. Like a method input.

So, if you go in and change the code of o1js, such that this.sender no longer contains the actual fee payer but whatever you want it to be, you will still be able to create a valid proof for that contract. That's because no constraints tie this.sender to anything else in the transaction.

(What we would want is this.sender to be part of the public input / committed to by the public input. But the way the protocol is currently structured, this is not the case. There's actually a protocol addition planned after the hardfork that would change that)

[marsh sedge]

But when you say that the fee payer can't be spoofed, does that mean the nodes are checking the fee payer's signature along with the proof?
And one can modify o1js to set this.sender arbitrarily.

[wooden arch]

Nodes are checking the fee payer's signature against the fee payer's address.

But nodes aren't checking the fee payer address against a proof in the transaction. They can't, because it's a zero knowledge proof, so it hides the value that was used for this.sender.

(Which would change if we exposed it as part of the proof's public input)

[marsh sedge]

I think it's clear now.
something like this is meaningless

this.sender.assertEquals(this.somePubkey.getAndRequireEquals())

[wooden arch]

Yeah cool you got it 😄

[marsh sedge]

we need to use this
AccountUpdate.create(this.sender).requireSignature();

then I can use asserts on this.sender