`ic_cdk::api::data_certificate()` is mis-designed

[vporton]

ic_cdk::api::data_certificate is made useless for high-load works, because, to the time a query (non-update) callback is called, the certified data set by the corresponding update call may have be already changed by another update call.

The usable workflow would be instead to deliver (save to a variable, sent out in ah HTTPS outcall, etc.) the data_certificate() return value directly in the update call that sets the data.

It would be acceptable to spread this update call to several blocks, if needed.

The real task

I tried to deliver the value of the certificate in an HTTPS outcall, to check at the sever's side, whether the request to the server is properly authorized.

[adamspofford-dfinity]

The certificate isn't meant to be about time accuracy any more granular than the duration the call takes. The purpose of the certificate is that the data was recorded during an update call and that the IC has signed a certificate attesting that this happened and a timestamp it was known valid at. One system tick separates it from the most recent possible update call affecting it; it is as momentarily accurate as the rest of the state tree.

It importantly doesn't tell you anything that an update call's return value can't tell you - that too was provided by the canister, during an update call, in a manner certified by the IC to be authentic, but optionally a few seconds and/or concurrent update calls in the past. It is only there to give you the guarantees of an update call with the speed of a query call if the query call is about data whose bookkeeping was recorded in advance. If you are trying to do something else with data, there may be a better solution to it than certified data.

Can you describe your use case in more detail?

[vporton]

I have some trouble understanding you.

Can you describe your use case in more detail?

I created a proxy that joins the 13 calls into just one upstream request.

My case is to check whether a certain map (B-tree) in the canister has a certain node. It is to check that the request that I do by my proxy server has been initiated by a certain canister, not a hacker, using the hash of the request in the tree.

Join Proxy project, however, partly failed, because I didn't succeed to validate II off-chain.

[adamspofford-dfinity]

I see. You want to gather an IC signature of a request immediately before making the request as proof to the recipient that the request is authentic. Why not use sign_with_ecdsa for this?

[vporton]

Why not use sign_with_ecdsa for this?

As far as I understand, sign_with_ecdsa requires open (for the nodes) private key. This isn't acceptable.