Closed jeanmon closed 2 days ago
I think we shouldn't separately pass the calldata on the TS side. You might want to prepend it to the VK like we do with the other public inputs:
That might be wrong, or a hack, but then it's probably still better to solve them all in a final way in a separate PR (once it's agreed how we are going to pass things, and what we are going to pass).
@fcarreiro I was trying this as a first attempt but then realized that it is actually more complex for the time being to pursue this route. We have already in the code some separate calldata, returndata structures. Furthermore, the current serialization mechanism in Proof and HonkProof class do not support to pass variable-length (vector) data structure. I could hack it for the callata but as soon as we want to add returndata it will not work. Not sure how easy it is to change this because we are inheriting from some BB classes. Bottom line, if as you said we are not sure how we want to pass calldata, I would rather take the easier path.
I think we shouldn't separately pass the calldata on the TS side. You might want to prepend it to the VK like we do with the other public inputs:
That might be wrong, or a hack, but then it's probably still better to solve them all in a final way in a separate PR (once it's agreed how we are going to pass things, and what we are going to pass).
@fcarreiro I was trying this as a first attempt but then realized that it is actually more complex for the time being to pursue this route. We have already in the code some separate calldata, returndata structures. Furthermore, the current serialization mechanism in Proof and HonkProof class do not support to pass variable-length (vector) data structure. I could hack it for the callata but as soon as we want to add returndata it will not work. Not sure how easy it is to change this because we are inheriting from some BB classes. Bottom line, if as you said we are not sure how we want to pass calldata, I would rather take the easier path.
The path in this PR might seem easier but it adds a second way of doing things, and it breaks abstractions so I'm rather against it.
It also is not easier. HonkProof is just a vectorprove
std::vector<FF> calldata;
HonkProof proof;
auto raw_proof = prover.construct_proof();
proof.insert(proof.end(), raw_proof.begin(), raw_proof.end());
proof.push_back(calldata.size());
proof.insert(proof.end(), calldata.begin(), calldata.end());
return std::make_tuple(*verifier.key, proof);
and like this in verify
std::vector<FF> public_inputs_vec;
std::vector<FF> calldata;
std::vector<FF> raw_proof;
// This can be made nicer using BB's serialize::read, probably.
const auto public_inputs_offset = proof.begin();
const auto public_inputs_size = PUBLIC_CIRCUIT_PUBLIC_INPUTS_LENGTH;
const auto calldata_size_offset = public_inputs_offset + public_inputs_size;
const auto calldata_offset = calldata_size_offset + 1;
const auto raw_proof_offset = calldata_offset + static_cast<size_t>(proof.at(calldata_size_offset));
std::copy(public_inputs_offset, public_inputs_offset + public_inputs_size, std::back_inserter(public_inputs_vec));
std::copy(calldata_offset, calldata_offset + calldata_size, std::back_inserter(calldata));
std::copy(raw_proof_offset, proof.end(), std::back_inserter(raw_proof));
Metrics with a significant change:
First preliminary work for issue #7211. Added a new public calldata column and passes calldata file to the avm verifier.