hash_varlen mutates the sponge state in a way that ought to be exposed such that a rust-shadowing function of this snippet can be written in e.g. tasm-lang.
This realization came about as I was writing the recursive verifier in tasm-lang and saw that after calling hash_varlen the rust-shadowed sponge state and Triton VM's sponge state were out-of-sync.
On a further note, I realized that our current implementation of hash_varlen resets the sponge state by calling the VM instruction sponge_init which means that fiat-shamir cannot be perfomed by the verifier after a call to hash_varlen. For the way the prover/verifier works that's not a problem though, as we are done getting fiat-shamir values when the 1st call to hash_varlen happens.
hash_varlenmutates the sponge state in a way that ought to be exposed such that a rust-shadowing function of this snippet can be written in e.g.tasm-lang.This realization came about as I was writing the recursive verifier in
tasm-langand saw that after callinghash_varlenthe rust-shadowed sponge state and Triton VM's sponge state were out-of-sync.On a further note, I realized that our current implementation of
hash_varlenresets the sponge state by calling the VM instructionsponge_initwhich means that fiat-shamir cannot be perfomed by the verifier after a call tohash_varlen. For the way the prover/verifier works that's not a problem though, as we are done getting fiat-shamir values when the 1st call tohash_varlenhappens.