Corda：较大的序列化事务大小：当前的序列化设计是否可以替代？

本文介绍了Corda：较大的序列化事务大小：当前的序列化设计是否可以替代？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

在我看来，当前版本的Corda（3.1）通过BLOB存储（签名的）交易作为Java类 SignedTransaction 的序列化字节数组。 。 （ SignedTransaction 是 WireTransaction ，即包含表示序列化事务的字节数组。）

对于某些项目，这种方法可能会带来挑战，因为它在内存和吞吐量上都显得相当浪费。

这是标准方法吗？ Corda会序列化交易吗？有哪些选项可以更改序列化以减少内存需求？

示例

尝试使用具有简单 IOUState 和简单事务的 CordApp IOU示例，单个事务在表 NODE_TRANSACTIONS ，其中选择长度（TRANSACTION_VALUE）从NODE_TRANSACTIONS 报告的 TRANSACTION_VALUE 的大小为11 KB。看来，这11 KB包括序列化的 WireTransaction 的9 KB和签名的2 KB。 IOUState包含单个双精度（以及两个对应的信息）。比二进制BLOB的11 kByte还要大，但如果使用其他模型存储，数据仍然会大量减少。

考虑到每秒170个事务（该数字引用为Corda），简单的IOU示例每年在每个（参与）节点中需要50 terrabytes（365天，24小时）。

另请注意： blob比反序列化的JSON大得多（至少5倍）是违反直觉的。也许我在这里做错了事...

解决方案

尽管blob看起来非常大，但请注意它还包含：

• 要序列化的事物的模式/描述，允许在没有原始类定义的情况下重构对象（例如，用于GUI或数据需要在未来很多年进行检查）
• 转换标头以允许反序列化各种状态的状态

但是，优化是可能的，我们将寻求在Corda的未来版本中实现它们。例如，一种选择是在知道对手方已经拥有架构的情况下将其分割。

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...

解决方案

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.