问题
It appears to me as if the current version of Corda (3.1) stores a (signed) transaction via a BLOB as a serialized byte-array of the Java class SignedTransaction. (The SignedTransaction is a WireTransaction, i.e. contains a byte array representing the serialized transaction).
For some projects this approach might pose a challenge as it seems comparably wasteful w.r.t to memory and hence throughput.
Is this the standard way Corda will serialize transactions? What options exist to change the serialization to reduce memory requirements?
Example
Trying the CordApp “IOU” Example having a simple IOUState and a simple transaction, a single transaction creates a single entry in table NODE_TRANSACTIONS where the size of TRANSACTION_VALUE reported by select length(TRANSACTION_VALUE) from NODE_TRANSACTIONS is 11 kilobytes. It appears as if these 11 kilobytes consist of 9 kilobyte for the serialized WireTransaction and 2 kilobytes for the signatures. The IOUState contains a single double (and info on the two counterparts).
Using BlobInspector to deserialize the binary format of TRANSACTION_VALUE reveals a JSON file of only 2 kBytes - much smaller than the 11 kBytes of the binary BLOB, but still having data which could be massively reduced if stored with a different model.
Considering 170 transaction per seconds (a figure quoted for Corda), the simple IOU example would require 50 terrabytes per Year (365 days, 24 hours) in each (participating) node.
Note also: That the size of the blob is much larger than the deserialized JSON (at least factor 5) is counterintuitive. Maybe I did something wrong here...
回答1:
Although the blob appears to be very large, note that it also contains:
- The schema/description of the thing being serialised, allowing the object to be reconstructed without the original class definitions (e.g. for use in GUIs or if data needs to be inspected many years into the future)
- Transformation headers to allow various versions of state to be deserialised
However, optimisations are possible and we will look to implement them in future releases of Corda. For example, one option is to slice off the schema if you know that your counterparty already has it.
来源：https://stackoverflow.com/questions/51709928/corda-large-serialized-transaction-size-are-there-alternatives-to-current-seri