MarcAntoineLebourgeois
commented
1 month ago I would like to extend a bit the issue opened here by Andrey. We have a particular business case that could ease a lot the guardian implementation with Fireblocks signing service and facilitate the use of guardian based software by non tech users. We (Allcot) would like to use fireblocks as an external signing service between Straatos and MGS.
Business needs:
- We need two different configurations for the system account (straatos account) and our user accounts.
- We need a centralized account registered in FireBlocks that can manage multiple VaultID for each user
First option (Guardian does everything with our admin keys)
Allcot configures a system account, the same way we configure IPFS, MongDB, etc. via .env file (or WebUI/or manual configuration in case of MGS)
- Every time a new user is created, instead of creating an Hedera account, it creates a new Fireblocks vault
- for each vaultID, Guardian creates an HBAR account
- here the Hedera keys are generated
- each user should be assigned the new vaultID
- this implies that it needs to READ the account ID via Fireblocks API
- every operation signed by a Guardian user should be signed by the Hedera keys inside their assigned vaultID
- deletion of FB vaultIDs, accounts, etc should not be implemented by Guardian (yet)
- configuration of FB credentials should be possible via APIs and .env files
- we need a mock/testnet Fireblocks service for testing purposes
- Guardian should always use the fake FB service for Hedera Testnet and the real FB service for Mainnet
- This makes the vauldID a random number inside MongoDB
This is in case Guardian uses real FB for test:
- Guardian should consider the testnet is reset every 3 months (so accountIDs are not valid anymore and must be recreated)
- the best way to deal with this is to recycle the same userID and create a new the accountID under the same VaultID
- backup/fallback: ignore the old ValutID, create a new one, assign the new one to the old userID. This have a list of unused VaulID on Allcot’s Fireblocks user.
Second option
- pre configure Fireblocks ourselves
- then Guardian links information by requesting FB keys
Co created by Giuseppe and me
Problem description
Current support for Fireblocks in Guardian is limited to signing messages going into Hedera topics (see docs). This is too restrictive, many use-cases require keys used in other (if possible all) operations to be custodied in Fireblocks.
Requirements
Expand the set of Guardian operations in which Fireblocks API is used for signing transactions (using raw signing) remotely. See this repo for examples on how to implement this.
Definition of done
Acceptance criteria
To the extent possible, Guardian keys are in custody of Fireblocks with transactions signed remotely.