JoshOrndorff
commented
4 months ago Thanks for the post. I'll close it, and anyone can still reference your work in the future.
Closed NadigerAmit closed 4 months ago
JoshOrndorff
commented
4 months ago Thanks for the post. I'll close it, and anyone can still reference your work in the future.
Below is my study result of understanding the roles and responsibilities of each module owner to avoid overlaps or gaps in the integration process between Tuxedo Blockchain ,DApp and Talisman wallet.
Why integration between TalismanWallet and Dapp based on Tuxedo Blockchain is needed. Integrating Talisman with a DApp brings together the strengths of each component. Talisman specializes in secure key management and signing, while the DApp focuses on user interactions and transaction generation. This collaboration results in a more secure, user-friendly, and privacy-conscious experience for individuals using decentralized applications on a blockchain.
Let me list down the requirements below :
1. Integration Framework Requirements Communication Protocol: Need to define a standard communication protocol between the DApp and Talisman for transaction signing and user authentication.
Since there will be multiple inputs that need to be signed by different users, there needs to be more than one signature for 1 transaction in the talisman app.
Need to sign the whole transaction at once.
2. Transaction Workflow Requirements Unsigned Transaction Handling: Define a mechanism for the DApp to generate unsigned transactions and send them to Talisman for blind signing.
Blind Signing Process: Talisman performs blind signing for each input separately, ensuring privacy and security. Need to provide the individual signed inputs (individual redeemer to each input) to Dapp, so final Transactions can created and signed again if required and sent to the Tuxedo blockchain.
Signed Transaction Format: Need to define the format of signed transactions returned by Talisman, ensuring compatibility with the Tuxedo blockchain.
Transaction Submission: Need to establish a secure protocol for the DApp to submit signed transactions to the Tuxedo blockchain using the hardcoded RPC endpoint, since as of now metadata is not supported from Tuxedo blockchain.
3. Security Requirements Key Management: Talisman securely manages private keys and implements robust key storage mechanisms.
Transaction Validation: DApp needs to implement validation checks to verify the integrity of transactions before submission to the blockchain.
User Authentication: Secure user authentication needs to be done within Talisman, ensuring that only authorized users can sign transactions.
4. Flexibility and Future Enhancements Requirements
Modularity: Need to design the integration to be modular, allowing for updates or changes to the DApp or Talisman independently.
Metadata Support (Future): Need to consider future enhancements for metadata support in the Tuxedo blockchain.
Transaction Details Display (Future): Plan for potential enhancements to display transaction details in Talisman if such a feature is considered in the future.
Role &Responsibility between modules
1. Tuxedo Blockchain: Transaction Processing: Process incoming transactions based on the UTXO model, verifying individual signatures separately unlike account-based. UTXO Transactions consist of set of inputs, set of outputs, Constraint checkers, verifiers,etc
RPC Endpoint: Provide and maintain a reliable and secure RPC endpoint (e.g., "ws://127.0.0.1:9944") for communication with external components.
Future Enhancements: Need to consider and implement any future enhancements, such as metadata support, based on the evolving needs of the blockchain. i.e return the metadata for state_getMetadata() call.
2. DApp Blockchain Interaction: Connect directly to the Tuxedo blockchain using the provided RPC endpoint for data retrieval and transaction submission. Transaction Construction: Construct generic transactions for various purposes based on the UTXO model without requiring visibility into transaction details. User Interface: Develop and maintain a user-friendly interface for users to interact with the DApp, initiating transactions and managing assets. Security Measures: Validate transaction details before submission to ensure data integrity. Flexibility and Future Enhancements: Design the DApp with modularity, allowing for updates or changes independently of other components. Consider future enhancements, such as dynamic metadata support when introduced by the blockchain.
3. Talisman Wallet: Blind Signing: Receives unsigned transactions from the DApp. Signs the whole transaction without understanding the transaction details (blind signing). No need to sign the individual inputs, since signed inputs may be stolen and used for another purpose during the traversal between Wallet and Dapp or within the DApp. Since the inputs may belong to different public keys, sign the transaction from all the public keys one by one. This is a scenario similar to a talisman wallet is connected to different wallets of the same user having different public keys and he wants to use the coins from these different wallets.
Extra info on why individual input signing should be avoided: a. Prevents Signature Repurposing: Signing the entire transaction prevents attackers from reusing individual input signatures in different transactions. b. Content Integrity:Blind Signing the whole transaction ensures the integrity of the entire content, reducing the risk of tampering with individual inputs. c. Reduced Risk of Replay Attacks: Blind Signing the entire transaction mitigates the risk of replay attacks where a signed input is reused in a different context. d. Enhanced Privacy: Blind Signing enhances privacy by avoiding the exposure of specific input details to the signer.
4. Return the signed transaction to the DApp. Key Management: Securely manage private keys and implement mechanisms to prevent unauthorized access. User Authentication: Provide a secure user authentication process within the wallet. Signed Transaction Handling: Return signed transactions to the DApp after blind signing. Provide the redeemer after signing. Security Measures: Implement robust security measures for key storage and transaction signing. Support the Sr25519Signature scheme. Future Enhancements: Plan for potential enhancements, such as displaying transaction details or supporting new cryptographic methods, based on future developments. Support the Sr25519Signature scheme.
Sequence of events :
The user is already authenticated and logged into the Talisman Wallet.
The sequence diagram includes a generic acknowledgment from the Tuxedo Blockchain to the DApp regarding the success or failure of the transaction
The sequence diagram doesn't explicitly include error-handling scenarios, such as failed blind signing or transaction verification. Error-handling paths would need to be considered based on specific use cases and potential issues.
The transaction flow is simplified for illustration, and specific details about inputs, outputs, or transaction data are not provided.
DApp to Talisman: DApp constructs a generic transaction with details about multiple inputs and outputs. DApp sends the unsigned transaction to Talisman for blind signing.
Talisman Signs: Talisman, without understanding the transaction details, signs the whole transaction separately with different public keys of the owner. Talisman returns the signed transaction to the DApp.
DApp to Blockchain: DApp submits the signed transaction to the Tuxedo blockchain via the hardcoded RPC endpoint.(In future based on metadata returned by the state_getMetadata() RPC)
Blockchain Processing: Tuxedo blockchain processes the transaction based on its UTXO model. Verifies each signature separately for inputs.