Bump sha2 dependency to v0.0.3

[timohanke]

There has been a performance improvement for short messages which is relevant for Merkle tree applications. I would be interested in the effect on ic-certification. I am guessing around a 10% improvement in instructions used.

[nomeata]

Sure, can do. Is it API compatible, so I just have to change the version pins?

[timohanke]

Yes it is

On Thu, Sep 14, 2023 at 2:36 PM, Joachim Breitner @.***(mailto:On Thu, Sep 14, 2023 at 2:36 PM, Joachim Breitner < wrote:

Sure, can do. Is it API compatible, so I just have to change the version pins?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[nomeata]

Trying in #12, but it seems the latest dfx release (0.14.4) ships moc 0.9.3, while the latest vessel package set requires 0.10.0, according to https://dfinity.github.io/vessel-package-set/. All version confusing.

[timohanke]

sha2@0.0.3 requires moc >=0.9.8. Don't know how I can specify that in mops as a "dependency".

Since you also have a mops.toml in your repo, do you actually need vessel?

[nomeata]

Vessel is actually fine (it can fetch the necessary version of moc). But mops seems to rely on whatever moc is in path it seems (when I run mops publish, it tries to build stuff), and there I am using dfx. Maybe I should stop using dfx entirely, but it’s needed to run the demo canister, I guess?

Are people still using vessel or should I drop support for that?

[nomeata]

But in any case I think it makes sense to wait until the version of motoko shipped by sdk supports thew new sha2. (Unless people are no longer using the sdk?)

[timohanke]

People who use mops probably also use mocv to manage and select moc versions. Using mocv also overrides the moc version for dfx, so you are not bound to the one that ships with dfx. Using mocv and dfx in combination is actually very convenient.

You can stop supporting vessel because less people use it and the ones who do can (and probably are used to) manage their package set.

Sure, you can wait with merging the PR until dfx 0.15.x has been released which will include the necessary moc version.

[nomeata]

Ah, there is DFX_MOC_PATH now! Then maybe the simplest course of action (for me) is to get moc via nix directly from the moc repository.

[timohanke]

Yes, in CI scripts are usually download moc and set DFX_MOC_PATH.

[timohanke]

What do you use to benchmark the certification? Is that the demo canister?

[nomeata]

I don't think I do benchmark :-D

[timohanke]

I found the benchmark. It is here: https://dfinity.github.io/canister-profiling/crypto/#certified-map I will ask there for an update there.

[timohanke]

We can further speed up certification if you are willing to store your intermediate hashes as [Nat32] instead of Blob. I can expand the interface of sha2 to something like writeNat32(d : [Nat32) (instead of only having writeBlob(b : Blob) as now).

[nomeata]

Sure, PRs welcome

[timohanke]

There's an update on the benchmarking results here: https://github.com/dfinity/canister-profiling/pull/87 Certified map improves by 12.5%.

[nomeata]

Hmm, it seems mops is using dfx cache show to find moc and mo-doc, and insists on using mo-doc during mops publish.

This is the code:

        // detect mocv
        if (process.env.DFX_MOC_PATH && process.env.DFX_MOC_PATH.includes('mocv/versions')) {
                moDoc = process.env.DFX_MOC_PATH.replace(/\/moc$/, '/mo-doc');
        }
        else {
                moDoc = execSync('dfx cache show').toString().trim() + '/mo-doc';
        }

It seems there is no wasy way to tell mops to just use a specific binary. I’ll just wait for dfx to release with motoko 0.10.0 for now. Maybe I can find a nicer solution some other time.

[nomeata]

Ok, with dfx-0.15.0 it worked; guess the moc versions don't have to match up precisely:

~/dfinity/ic-certification $ mops publish
Publishing ic-certification@0.1.3 [::::::::::]
Published ic-certification@0.1.3
~/dfinity/ic-certification $ git tag v0.1.3