DegenHive
- How to properly store the private key during ZkLogin? In a previous text with Sui guys, I was told it's not an issue if we store the private key on frontend. However we feel it's unsafe for users. We are considering storing it in an encrypted way in the backend and routing transactions through our server (with an auth pin for decryption). We want to discuss the proper way for doing this and explore attack vectors.
- Local storage is discouraged
- Recommendation:
- Create ZK proof when you’re trying to sign the transaction, not when the user logs in
- Store in session storage, so it’s erased when the user closes the browser
- Maintaining own salt tied to their sub field in JWT
- Emailing the user their salt on login
- If the user wants to login on another service, can you use the salt?
- Not presently, might be possible in the future but no clear path towards this
- Is a ZK wallet custodial?
- Is bound to the site
- Is not custodial in the sense that the app can control the user’s assets
- Backend should not see the things that are enough to sign a transaction:
- Recommend keeping the JWT used to generate ZK proof separate from the JWT used to do backend authentication
- Shouldn’t be pinging mainnet prover, should move over to Enoki
Navi Protocol
- Question about unit testing:
- want to perform an upgrade to the contract
- Want to simulate an upgrade in the unit tests
- Mysten has integration tests that do this
- but on a simulated network calling an actual upgrade in the CLI
- Is it possible to increment the time in localnet or testnet?
- not on testnet, maybe in localnet
- Want non-technical team members to be able to interact with a unit test environment
- Deposit, time increment, withdraw, in a unit test context, from a UI
- Mysten upgrade integration test: https://github.com/MystenLabs/sui/blob/3ebeac064d1cc4af4da3eb2f16269c7d185fb710/crates/sui/tests/cli_tests.rs#L1645-L1781