As of v1.2.0, in order to execute a voucher, one has to provide the voucher fields (destination and payload) and a proof structure. This proof structure contains an OutputValidityProof field and a proof context blob.
With #42, the specific outputs fields would be abstracted away, and the user would provide the output blob instead, to be decoded by the contract itself.
With #48, the proof context blob is no longer necessary, and we, instead, use an InputRange structure to index claims for a given application.
As a result, the signature of executeVoucher would go from...
In the server manager gRPC interface, however, these two fields are stored separately. The node doesn't really care about their contents specifically, and would like to look at them as opaque.
✔️ Solution
After discussing with the machine and node teams, we agreed to add an InputRange field to the OutputValidityProof structure. This would also be reflected on the gRPC interfaces used by the server manager, for example.
As a result, we can remove the Proof structure from the code base, and use OutputValidityProof instead.
struct OutputValidityProof {
InputRange inputRange;
// the other fields...
}
function executeOutput(bytes calldata output, OutputValidityProof calldata proof) external;
📚 Context
As of v1.2.0, in order to execute a voucher, one has to provide the voucher fields (destination and payload) and a proof structure. This proof structure contains an
OutputValidityProof
field and a proof context blob.With #42, the specific outputs fields would be abstracted away, and the user would provide the output blob instead, to be decoded by the contract itself.
With #48, the proof context blob is no longer necessary, and we, instead, use an
InputRange
structure to index claims for a given application.As a result, the signature of
executeVoucher
would go from...... to...
In the server manager gRPC interface, however, these two fields are stored separately. The node doesn't really care about their contents specifically, and would like to look at them as opaque.
✔️ Solution
After discussing with the machine and node teams, we agreed to add an
InputRange
field to theOutputValidityProof
structure. This would also be reflected on the gRPC interfaces used by the server manager, for example.As a result, we can remove the
Proof
structure from the code base, and useOutputValidityProof
instead.