-
Notifications
You must be signed in to change notification settings - Fork 46
Web Client: Data Stored Locally
1wallet web client stores partial proofs for completing transactions in the browser's IndexedDB. The proofs are considered "partial" because they can only be completed and used for authorizing transactions, if and only if the user provides the correct authenticator code(s) (6-digit or 12-digit OTPs). The proofs are made robust against brute-force using techniques described in Client Security. The proofs are the OTP Merkle Tree described in the Wiki[1]
[1]: not exactly - we will update the Wiki later to describe the improvements and revisions we made during the implementation).
These partial proofs are managed via a storage interface using localforage. Each wallet stores a key-value pair to the storage. The key corresponds to the root parameter of a wallet, which uniquely identifies the wallet and maps to a Google Authenticator entry. The values are the partial proofs, represented by an array of byte arrays (Uint8Array[]). Each array represents a layer in the OTP Merkle Tree, starting from the leaves at index 0 and followed by one layer above the leaves at index 1, and so on. Each proof is 32-byte long. For a wallet with lifespan of a year, about 64MB of proofs are stored, with the leaves occupying about 32MB.
When the wallet is upgraded, the address of the wallet "changes" (a new wallet is generated and the old wallet starts to forward everything to the new wallet), but its root parameter remains unchanged. As a result, the user could still use the same Google Authenticator entry to authorize transactions for the wallet, and we do not need to update anything in the storage for the partial proofs of the wallet. For
Every transaction in 1wallet requires completing a commit-reveal process. The partial proofs are loaded at the beginning of this process. See /code/lib/api/flow.js:L71. Note that even though the entire 64MB proofs are loaded, only a 32-byte chunk of the 32MB worth of leaves is used, followed by its ancestors (about 20). The position of the leaf used is based on the current time and/or operation type. This means we can store and access the proofs more efficiently and securely in the future. Right now, read and write to the proofs have negligible performance impact (<0.2 seconds on a 2014 iMac computer, based on /benchmark).
In addition to the partial proofs, 1wallet also stores the state of each wallet via Redux. See /code/client/src/store.js. The Redux store is also backed by localforage using IndexedDB, albeit under a separate index. See code/client/src/state/rootReducer.js. The layout of the state and the default values are shown in the reducer for wallets. See /code/client/src/state/modules/wallet/reducers.js. Note that the specific details for each key-value in the state.wallet object is not given in the default value, though the actions provide some guidance on what is generally expected. Please search and consult with usages of useSelector(state => state.wallet...) in the project for more information, as well as dispatch(walletActions.updateWallet(...)).
For example, the wallet creation component provides rich information about the meaning of each field in each wallet. See /code/client/src/pages/Create.jsx#L219.
The address input component provides rich information about the knownAddresses object. See /code/client/src/components/AddressInput.jsx#L162
All partial proofs and states can be regenerated using the Google Authenticator seed (represented as a QR code) and public information on the blockchain. Try it at https://1wallet.crazy.one/restore, and see /code/client/src/pages/Restore.jsx for more information.