Signing Storage Transactions
Arcana Network storage protocol is the backbone of all dApp user data privacy and access control. It is implemented using smart contracts that require the signing of blockchain transactions for each operation that requires accessing data or uploading it to the Arcana Store. The storage protocol uses standard EIP-712 signature scheme that consists of a secp256k1 signing algorithm and keccak256 hashing algorithm.
To use the Arcana Network storage protocol for user data privacy and access control, the dApp must integrate with the Arcana Storage SDK.
Arcana Storage SDK requires the standard Ethereum provider to sign blockchain transactions for storage operations. This requirement for an Ethereum provider can be met in one of the following ways:
Setup and use one of the supported third-party wallet providers:
- Any other wallet that supports Ethereum Provider API standard.
If you are using a third-party wallet, then you cannot manage user experience for signing Arcana blockchain transactions, unlike with the embedded Web3 Arcana wallet offered by the Auth SDK.
For every dApp user action that triggers a blockchain transaction, the wallet displays a user request to review and approve the transaction. The dApp developer can use the
alwaysVisible wallet visibility setting during Auth SDK instantiation to manage whether the wallet will always show up on the dApp or if it will only show up when a blockchain transaction is triggered. Other third-party wallets do not allow this level of control whereby dApp developers can manage user experience for signing blockchain transactions.
In the latest release of the Arcana Network storage protocol, there is more transparency for the dApp user as they can actually see various items that make up the message and then make an informed decision to approve or reject the blockchain transaction.
The information displayed to the dApp user in the message contains the following items.
- Transaction metadata
Meta Transaction Request
The details in each type of sign transaction message may vary depending on the storage transaction type.
Here is a generic structure of a message displayed to the dApp user seeking approval/rejection of storage operation:
- Message Info:
Transaction: Information about the transaction
- Method: The name of the storage operation. For e.g., upload, delete, etc.
DID: The file identifier on which the operation is being performed
File Size: Size in bytes
File Name: Hash of the file name
Storage Node: The address of the storage where the file is depositednote
After user approval, the file is deposited on a storage node with the specified address. Then it is encrypted using a symmetric key and split into multiple parts and stored on distributed storage in the specified storage region. The symmetric key used to encrypt the file is also split and stored in multiple storage locations.
Ephemeral Address: This is a temporary address that is generated and used to sign blockchain transactions for storing multiple parts of the symmetric key used to encrypt the data filenote
An Ephemeral key is generated and used to simplify the user experience. Otherwise, the user will have to sign multiple times to upload each of the different parts of the symmetric key.
- Meta-transaction Request:
- Version: Forwarder Contract Version
- ChainID: Arcana Network Blockchain ID
- Forwarder Address: The forwarder refers to a contract in the Arcana Network storage protocol that verifies the standard EIP-712 typed signatures before forwarding the request to the Arcana contract for processing
See Sign Transaction Messages to see details of specific messages displayed by the wallet in response to different data access operations issued by the dApp via the Storage SDK.