Best way to read witness values from public witness

[311923]

Hello - I'm looking for the best way to read the elements within a public witness.

For instance, in the case of the gnark playground 'hash of a secret' example: given a public witness (of type witness.Witness), is there any sample code to obtain the frontend.Variable Hash?

It looks like we need to define a schema and then use this to call witness.ToJSON or witness.FromJSON functions, but some aspects of this are not very clear, for example the role of tLeaf in creating a new Schema.

Any support would be much appreciated.

[ivokub]

Could you have a look at the example? Does this work?

There are essentially two options - binary or JSON serialization. Users should use binary serialization for efficiency and correctness. JSON serialization is only used for pretty-printing and is quite slow.

[phpstudyer]

Documentation is not detailed enough

[wraitii]

@ivokub I have a similar need, either "read" the public witness or make sure that it matches some known values. The fastest way to do this easily and generically seems to be to create a new Witness with said known values, serialise that and compare binary-serialised values. Is there a way to do equality comparisons directly on witnesses that might be faster ?

[ivokub]

I think this may be the fastest and safest way. The serialized witness is essentially []fr.Element, where fr.Element is[4]uint64 or [6]uint64 depending on the curve used, so this comparison is really fast.

Otherwise, the issue may become that before serialization the data types in witness assignment may be different (gnark allows anything which can be cast or converted to fr.Element e.g. strings, *big.Int, uintNN, intNN, to be witness elements and comparing them before serialization is difficult. In essence, serialization allows to have a canonical and comparable representation.

Is there a performance issue during serialization? Indeed currently we use a lot of reflection to flatten the witness from type implementing frontend.Circuit, but I haven't encountered it to be particularly slow. But if it is bottleneck in your case, maybe we can figure out something leaner.

[wraitii]

Thanks for the answer, indeed it matches what I figured.
My use case is reading some commonly-defined parts of a public witness (not necessarily the whole thing), so binary serialisation might be problematic as it is a full comparison, but I can probably work around that if I tweak my setup. It would be most intuitive to just be able to deserialize the specific variables I care about by e.g. name, but my understanding is that the witness doesn't store that metadata, so I'll have to essentially do that on my side, which is OK.

I haven't noted a performance issue, but I also haven't really checked/had requirements there, so that's something I'll keep an eye out for in the future.

[ivokub]

Yes, the witness goes directly into the circuit, where the additional metadata has now use as we care about the alignment only.

But, in order to make your comparison easier - the witness is actually fr.Vector ~ []fr.Element. You can do something a la

pubWit := wit.Public()
pubWitVector, ok := pubWit.(fr.Vector) // here fr is package a la "github.com/consensys/gnark-crypto/ecc/bn254/fr" depending which curve you use
if pubWitVector[2] != compareTo { // compareTo is the value you want to compare against, pubWitVector[2] is the second element in the witness
    panic("wrong witness")
}

for this to work, you need to have compareTo as fr.Element, but you can set it from string/bytes etc. See https://pkg.go.dev/github.com/consensys/gnark-crypto/ecc/bn254/fr#Element for assignment methods. Raw comparison should be good as fr.Element is defined as [4]uint64 or [6]uint64 which is comparable. Or you can use fr.Element.Equal(x) method (it is constant time).