The problem Guardian-LINK solves

Problem-1

Lack of privacy-preserving Data Provenance
Standard TLS-based protocols securely communciate between a prover and a server. But what about involving a third party? (Verifier)
Associated risks with delegated access involve too much information been given out and control being in the hands of server, which means no data ownership.
This problem is addressed b Guardian-LINK using TLS notary, which uses multi-party computation allowing prover and notary to jointly manage a TLS connection, thereafter some portions of the data can be shown to verifer, redacting private components. Since, the notary was involved in MPC, data authenticity is guaranteed.

Problem-2

Ensuring privacy: One of the most pressing challenges in the blockchain space due to its transparent nature.
There is a need for confidential smart contracts
Associated risks of unencrypted transactions involve sensitive data exposure (token amounts, balance, etc.) and MEV extraction.
This problem is addressed by Guardian-LINK using FHE and Risc0-zkVM for verifiable computation. The zkVM generates a ZK proof for FHE operations execution inside it, so that it can be verified that all the computation was done correctly.

Concept Simplified

Each party has a key pair of public key and secret for FHE encryption and decryption. These keys are stored in an encrypted manner on lighthouse, and the user can retrieve their keys by signing an authorization message. For transactions, user specifies a plaintext amount which is encrypted under the public keys of both sender and receiver and then there encrypted balance is updated using FHE, allowing no need for decryption at all.

Challenges I ran into

Learning about RISC-0 ZKVM and implementing FHE in its environment was new to me, but everything worked out in the end!