Relationship between threshold BLS signature and mo:base/CertifiedData?

I understood that the execution layer signs the replicated state with threshold BLS signature. I want to call the canister(update call) from a browser and verify the return value with the subnet’s public key. Do I need to implement it using mo:base/CertifiedData like in the example?

  • If mo:base/CertifiedData is not used, will the state be signed with a threshold BLS signature?
  • If I don’t use mo:base/CertifiedData and call it with update call, is it might the return value be tampered with?

I found the following thread in 2021. However, I could not understand it exactly. Do you have any easy-to-understand documentation?

1 Like

Tutorial 1 - Deploy your first dapp in 5 minutes
The following is written.

This service worker comes from the ICP network and it is used to make sure the web app the user sees is the correct, untampered frontend.

Does the service worker “only” verify that it is the correct frontend? Does the service worker not verify the return value of the update call?

1 Like

Yes, it only verifies the frontend, but that is because it doesn’t need to do anything else. The service worker only cares about HTTP requests, which are sort-of equivalent with query calls to the function http_request. If you want to make an update call from your frontend, you will use e.g. the JS agent (which you get via the frontend content). The JS agent then checks that the update call is properly signed by the IC, so the service worker doesn’t have to do the same verification

1 Like

@Severin
Thanks for your reply.

The JS agent then checks that the update call is properly signed by the IC

Don’t I need to use mo:base/CertifiedData since JS agent checks it? Am I not understanding you well enough?

Anything from Motoko is only relevant if you write a canister/backend. What you were asking about is the agent/frontend side. If you want to write a canister then you have to think about certification, but not otherwise

I understood. Thank you very much.