Access Control on Secret Network — Viewing Keys vs Permits
Secret Network brings native privacy to smart contracts. With viewing keys and permits, users are given access control capabilities on their data, assets, and NFTs. What’s the difference between the two?
By enabling developers to build privacy-preserving applications and empowering users to take control of their data, Secret Network can offer what no public-by-default blockchain can: native access control.
Currently, there are two technical design implementations to achieve access control: viewing keys and query permits. We’ll look at these specifications more closely and how the two differ from each other.
Viewing keys: The problems they solve and create
Secret Network encrypts user data by default. When a user converts public assets such as ETH, BNB, and SCRT to their private equivalent (sETH, sBNB, sSCRT), metadata, such as balances, becomes hidden from all users on the network, including the user who owns these assets. Therefore, despite the added benefit to security, encryption creates a user experience issue.
How should our users interact with applications on the network if they cannot see the amount of tokens in their wallets?
Secret tokens (a.k.a. SNIP-compliant tokens) are built upon the existing standards of the Cosmos ecosystem. Therefore, the identity of a querier (someone requesting data) cannot be cryptographically authenticated. In other words, without a mechanism to verify a user’s identity, basic user information cannot be decrypted. To solve this problem, viewing keys were implemented as a part of the SNIP-20 specification.
By looking at the diagram above, we can see the typical use case of a viewing key.
- Alice cannot see her balance, so she creates a viewing key (password) for a particular SNIP token.
- The smart contract responsible for managing the SNIP token saves Alice and her password to the contract’s state.
- At another point in time, anyone, such as Bob, can request to see Alice’s balance. If Bob has been given permission to use Alice’s viewing key, he will be given her account balance from the smart contract successfully.
Viewing keys act as encrypted passwords. By allowing users to create and share these passwords with third-party applications, viewing keys highlight the quality of access control provided to users on Secret Network. Alice is the owner of her viewing keys, and without them, others cannot access her sensitive data.
Unfortunately, viewing keys contribute to significant friction in regard to the overall user experience on the network and create an avenue for technical issues to surface during times of high traffic. Crucial account data being hidden from users without viewing keys is a feature that is at best temporarily confusing to new users, and at worst, acts as a deterrent to network adoption. Because viewing keys are stored in a smart contract’s state, users must send a transaction and pay a small fee to cover the cost of gas in order to create these encrypted passwords. Therefore, when using viewing keys, there is a small upfront cost to new users who may simply want to view their account balance. In the case of bridging public assets, such as BNB (Binance Coin), this UX issue is amplified by the fact that new users are likely to have no SCRT for which they can cover the cost of gas. Without SCRT to pay for gas, a transaction can never be sent, a viewing key cannot be created, and the user cannot view their newly bridged, private sBNB balance.
Furthermore, in times of heavy traffic, the creation of many, sometimes unnecessary viewing keys in rapid succession has proven to strain the network. For example, the first private-by-default NFT collection on Secret Network, Anons, generated significant usage for the network. Users, fearful of missing the public mint, raced to the Anons website in order to secure their NFTs. The minting process for Anons guided users along a UX path which required users to create viewing keys prior to minting. Due to the nature of an NFT mint where time is sensitive and tokens are scarce, a hoard of users interacted with the Anons smart contract to create viewing keys, a flood of transactions was generated, which in turn led to the halting of the network and a delayed launch for the Anons project.
As the network is clogged with requests, nodes begin to fall out of sync, and transactions begin to fail. Users who receive failed requests are likely to respond by submitting more requests only to exacerbate the problem. Therefore, to solve these technical and UX challenges, a new method for querying private user data was implemented.
To summarize, the main challenges associated with viewing keys are:
- Viewing keys require new users to pay a one-time, upfront fee for basic account information such as balances, transaction histories, etc.
- In times of high traffic, the UI/UX built around viewing keys can lead to the creation of many unnecessary transactions which can decrease node performance, resulting in cascading problems for the network.
Query permits: The alternative querying method
Query permits were introduced in the SNIP-24 design specification. The documentation describes permits as a superior querying method when compared to viewing keys. By considering the previous example of Alice, a user who wants to check her private account balance, we can better understand how permits work and why they are a drastic improvement for users on Secret Network.
Query permits use a cryptographic technique known as public key encryption coupled with digital signatures. A permit is a formatted message. It outlines several arguments such as what tokens the permit applies to and what permissions the permit should allow, (e.g. should the permit allow the querier to view a user’s transaction history, balance, etc.). This message is signed by Alice using her account’s private key. When Alice submits a query, she sends her signed permit as an argument to a smart contract. Once received, the smart contract, using Alice’s public key, can validate her identity based on the signature she provided. If Alice’s identity is confirmed, the smart contract returns her data as requested.
Note that unlike viewing keys, the smart contract never mutates its state in order to save Alice’s identity. Therefore, there is no transaction associated with the usage of query permits, and there is no fee for requesting basic user information. This is a major UX improvement for end-users. Also, because there is no transaction associated with query permits, there is no risk of permits hindering network performance during times of high traffic.
Though permits significantly improve user experience, they come with a tradeoff. Query permits are more resource-hungry on nodes running the network. Because a user’s identity is never saved, a permit must always be validated with each query request. This process is more costly in terms of compute power when compared to viewing keys, which only require a basic check against data stored in a smart contract’s state. However, the overall improvement to user experience and network stability is well worth the added pressure placed on nodes to validate permits.
Designing for the user experience
Due to the newness of query permits, decentralized applications built on Secret Network have utilized them to varying degrees of success. If used improperly, permits can create more frictional UX than viewing keys, so it is vital that developers consider the impact query permits have on both UI & UX design. This section aims to provide a short set of recommendations for developers to follow when using query permits.
Query permits should be stored
Permits are ephemeral messages that must be passed to a smart contract each time a query is made. Forcing a user to regenerate a permit with each query is arguably a worse user experience than paying a one-time fee to create a viewing key. Therefore, after a permit is created, it should be saved to the browser, (e.g. in localStorage), so it can be reused later. If permits are saved, developers can provide a seamless experience for users by submitting future queries without the end-user noticing a request has been made at all.
Stored permits should be used forever or until they are revoked.
To reiterate, there is no need to recreate a permit once it has been generated. Providing users with a simple way to revoke permits should be integrated into an application’s user interface. Permits can be revoked by submitting a revoke message whose only parameter is the name of the permit to revoke.
Query permits can apply to multiple secret tokens
Rather than forcing a user to create a new permit for each secret token your application may use, it is best to allow multiple tokens to be used under the same permit. More tokens can be specified in the allowed_tokens array of the permit message. Developers should consider the domain of their application and allow multiple tokens accordingly.
By following these simple guidelines for query permits, developers can provide a definitively better user experience for their applications on Secret Network. For more details concerning permits and their implementation, take a look at the SNIP-24 documentation found on the Secret Foundation GitHub.
Conclusion
Secret Network is a layer-1 blockchain solution that combines the resiliency of privacy and the revolution of scalable smart contracts. Security solutions often come at the expense of user experience. The developers of Secret Network take an active stance in unburdening new users so that everyone may access private decentralized finance with ease. Viewing keys were the first implementation of access control for end-users, but they came with a cost, both to user experience and network stability. Query permits are an improvement to Secret Network’s privacy-preserving tokens. As developers build new applications and refactor existing tools according to this new standard, end-users will be able to explore the ecosystem as easily as they would on a public-by-default chain. By securing user data and providing users with simple access control tools such as viewing keys and permits, Secret Network takes one step further into a future where privacy is at the forefront of the Web3 movement.
