BLUE-280: Add Publisher for Transaction Digest to IPFS via Web3.Storage

[achal-singh]

Summary

• The Transaction DIgest Cron Server in the Archiver creates Transaction Digests every 10 cycles.
• This PR adds an ipfsPublisher (as a part of the Transaction DIgest Cron Server) to upload/publish the same Transaction Digest to the IPFS Network via the Web3.Storage provider.

Linear Task

Merging Notes

It'd be good to merge BLUE-283's PR into BLUE-280 PR first before merging BLUE-280 to dev.

Testing Notes

1. Before starting with the tests, make sure you register on the web3.storage portal with your email address and subscribe to their free-tier plan (that gives 5 GB of free storage).
2. Access your account on https://console.web3.storage and create a Space, set any name as per your preference. At the top of the screen you'll see a Root DID string (starts with did:key:...) of your Space.
3. Copy and paste the same email ID and Root DID of your space to the root_did and admin_email fields in the archiver-config.json file respectively and set the enableSavingToWeb3Storage flag to true.
4. Run npm run txDigestCronServer OR pm2 start --name txDigestCron npm -- run txDigestCronServer to launch the txDigestCronServer process.

[github-actions]

PR Reviewer Guide 🔍

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Key issues to review Error Handling The error handling in uploadDigestToIPFS function (line 55-60) might not provide sufficient information for debugging. Consider enhancing the error messages to include more specific details about the failure context. Logging Practice The use of console.log and console.error for logging throughout the ipfsPublisher.ts file is inconsistent with the use of mainLogger in other parts of the application. It is recommended to use mainLogger for uniformity and better control over logging levels and outputs. Possible Bug The condition in uploadDigestToIPFS function (line 29) seems to be incorrect. The function returns early if isUploadPossible() is false, which is the opposite of the expected behavior where it should proceed if the upload is possible.

[aniketdivekar]

we should not log email id. let's mask it using industry standard logic or remove it.

[achal-singh]

Yeah we can mask it for sure, although it can't be exploited, I consoled it initially just for testing purpose.

[aniketdivekar]

lets log cycle range also

[achal-singh]

I included the hash only to keep the log line short and the hash makes it easier to search in a DB (if someone wants to quickly look it up since its just 1 value).
I'll add in start and end cycles too.

To fix the log injection issue, we need to sanitize the rootDID value before logging it. Specifically, we should remove any newline characters from the rootDID to prevent log forgery. This can be done using String.prototype.replace to ensure no line endings are present in the user input.

To fix the log injection issue, we need to sanitize the adminEmail before logging it. Specifically, we should remove any newline characters from the adminEmail to prevent log injection attacks. This can be done using String.prototype.replace to remove newline characters.

To fix the log injection issue, we need to sanitize the rootDID value before logging it. Specifically, we should remove any newline characters from the rootDID to prevent log injection. This can be done using the String.prototype.replace method to replace newline characters with an empty string.