Corda:大型序列化交易大小:是否有当前序列化设计的替代方案？

Question

在我看来，当前版本的 Corda (3.1) 似乎通过 BLOB 将(签名的)交易存储为 Java 类 SignedTransaction 的序列化字节数组。 (SignedTransaction 是一个 WireTransaction，即包含一个表示序列化交易的字节数组)。

对于某些项目，这种方法可能会带来挑战，因为它似乎相对浪费内存和吞吐量。

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

示例

尝试使用 CordApp“IOU”示例，它有一个简单的 IOUState 和一个简单的事务，单个事务在表 NODE_TRANSACTIONS 中创建一个条目其中 select length(TRANSACTION_VALUE) from NODE_TRANSACTIONS 报告的 TRANSACTION_VALUE 的大小为 11 KB。看起来这 11 KB 似乎包含序列化 WireTransaction 的 9 KB 和签名的 2 KB。 IOUState 包含一个 double(以及两个副本的信息)。

使用 BlobInspector 反序列化 TRANSACTION_VALUE 的二进制格式显示一个只有 2 kBytes 的 JSON 文件——比二进制 BLOB 的 11 kBytes 小得多，但仍然有数据，如果使用不同的模型存储，这些数据可能会大大减少。

考虑到每秒 170 笔交易(引用 Corda 的数字)，简单的 IOU 示例将需要每个(参与)节点每年(365 天，24 小时)50 TB。

另请注意:blob 的大小远大于反序列化的 JSON(至少因子 5)是违反直觉的。也许我在这里做错了什么......

Answer 1

虽然这个 blob 看起来非常大，但请注意它还包含:

• 被序列化的事物的模式/描述，允许在没有原始类定义的情况下重建对象(例如用于 GUI 或如果数据需要在未来多年检查)
• 转换 header 以允许反序列化各种版本的状态

然而，优化是可能的，我们将在未来的 Corda 版本中实现它们。例如，如果您知道您的交易对手已经拥有模式，一种选择是将其切掉。