Once Snapps are up and running, how do people feel about some kind of verification process to check they are safe to use?
1 Like
Are there any examples you are referring to? I am not sure what you mean, but when I hear âverification of smart contractsâ the verification on Etherscan.io comes to my mind (see Uniswap Protocol: UNI token | 0x1f9840a85d5af5bf1d1762f925bdaddc4201f984)
I guess on a different level from Crypto you have regular type âAppsâ on the google play store or Apple App store that are verified to be safe to some extent. I know it goes against decentralisation, but looking at it from a user perspective it could bring a reassurance in the same way audited web wallets do.
snapps store verification keys on chain, so they are secured cryptographically. If someone try to use a botched software to interact with snapps, they wonât check out with the verification key and wonât succeed.
I think the idea behind that goes more into the direction of âhow can users verify that the snapp does what has been promisedâ, especially in reference to the Defi space where things like honeypots and co are sadly very common. But you could also there simply release the source code of a snapp and and compile it to the verification key yourself and then compare it with the on-chain verification key. Similar to what Etherscan.io does with the contract ABI
Yeah, thatâs sort of what I meant, I am thinking of a way that a ânonâ tech person would be able to trust the App because it had been tested in some way and found to be safe. From a user perspective compiling the source code of a snapp, then compiling it to the verification key and then comparing it with the on-chain verification key seems quite complicated and un user-friendly in comparison.
I would imagine these will be abstracted away from the average user, and snapps are like the backend but with cryptographic assurance of authenticity.
You would hope in theory that would be the case, I know people who have trouble changing the channel on the TV 
When you throw in personal data with crypto, trust (and ease of use) would play an important role in adoption.
2 Likes
I wonder if their is a way for a snapp developer to create a zk proof of the source code for the front-end code to run against the snapp smart contract? I also havenât totally gotten my head around all of this, so maybe it doesnât matter, since the proof being generated can only be generated running that smart contract, but I think it would add an extra source of security, knowing the front end UI is trusted.
1 Like
For your (smart contract) transaction to be valid and be accepted by the network it would have to be called by that exact smart contract that corresponds to the verification key on-chain. So actually, it is not possible to sneak in an additional function or parameter or whatever and have that executed. If the smart contract, on the frontend, has been tempered with, the transaction that will be broadcasted to the network by the user will simply be rejected. Does that clarify the execution of snapps?
However, you might want to add some feature that helps users who donât understand code to make sure they arenât executing something âshadyâ which does something completely different than advertised. That could be done by an auditing service - but that would be an off-chain user service independent from snapps
That first part makes sense and thatâs more or less what I thought. I was more thinking, is there a way to bypass an auditing service and just know that Iâm running a verified app using a proof. Even though the business logic of the smart contract canât be tampered with, there could still be ways for people to get tricked into doing something different. Like could you minify the entire front end app and have a proof for this minified versionâŚthen on the desktop you have an app that can point to the contract address and check that the frontend code you are running is associated to it.
I think there are two components to this:
- is the snapp contract logic safe?
- is the snapp contract Iâm interacting with the snapp contract I was expecting.
To address the first point you would you need to have external audits of the snapp contract. snarkJS and snapps are a new platform / framework and so it will take some time in the wild west for potential vulnerabilities to be exposed unfortunately. In regards to the second point I think this could be validated by the web based wallet. For example when I interact with a webpage and my extension pops up asking me to sign, I would want to see a hash of the snapp code such that I can compare to expected hash before singing.
I think this works as long as you are trying to attempting to interact with the same verification key. In case some one manages to serve a completely new contract (we have had some FE hacks in the wild already on other chains) , i feel this issue still persists.
I am a big proponent of systems like ENS , and would be interesting to see if we can create a naming service which wallets can use to show which contract you are interacting with as 99/100 users are not going to check contract details.
While i donât know regarding the possibility of snapps being upgraded , iâd like to understand does the current architecture support it and what does upgrading a snapp look like?
1 Like