Corda：较大的序列化交易规模：当前的序列化设计是否可以替代？

Question

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

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

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

示例

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

使用BlobInspector对TRANSACTION_VALUE的二进制格式进行反序列化可以发现一个JSON文件只有2 KB，比二进制BLOB的11 KB小很多，但是如果使用其他模型存储，数据仍然会大量减少。 >

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

还请注意：Blob的大小远大于反序列化的JSON（至少5倍），这是违反直觉的。也许我在这里做错了...

Answer 1

尽管斑点看起来很大，但请注意其中还包含：

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

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