Closed YaronWittenstein closed 2 years ago
I'm closing this issue due to the recent agreement that SVM will take charge of parsing the Envelope
.
In other words, the go-svm
and SVM C-API will require only a single tx
parameter instead of two separate Envelope
and Message
params.
@neysofu @neysofu
Currently, SVM has no idea about the original
Envelope
encoding.The way things are working is that
go-svm
encodes theEnvelope
into an in-memory buffer and passes it using the cGO API back to SVM.SVM knows how to decode that buffer, but nothing guarantees that the original encoding of the
Envelope
as sent over the network will match the one used to communicate later betweengo-svm
and SVM.In order the satisfy the requirement of being able to hash the whole original transaction - SVM needs to be able to reconstruct the original
Envelope
encoding. In order to simplify things, it's highly suggested thatgo-svm
will send theEnvelope
buffer using the original on-the-wire format and that SVM will know how to decode it later by itself.Once SVM holds the original binary
Envelope
and the original binaryMessage
(which is basically just passed as it's bygo-spacemesh
togo-svm
and then to SVM) - SVM could combine these two parts into one. In other words, SVM has the original data of the transaction.Another way to go about implementing this issue is to adjust the
go-svm
to SVM interface to simply send the whole transaction as a single buffer. Both implementations should end up with SVM having the whole original binary transaction.