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

Question

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

3

我觉得Corda（3.1）的当前版本将已签署的交易作为Java类SignedTransaction的序列化字节数组存储在BLOB中。（SignedTransaction是WireTransaction，即包含表示序列化交易的字节数组）。对于某些项目而言，这种方法可能会造成挑战，因为它看起来相对于内存和吞吐量而言是相当浪费的。

这是否是Corda序列化交易的标准方式？有哪些选项可以更改序列化以降低内存要求？

例如，在尝试简单的IOUState和简单交易的CordApp “IOU”示例时，单个交易将创建一个节点事务表中的单个条目，其中由select length(TRANSACTION_VALUE) from NODE_TRANSACTIONS报告的TRANSACTION_VALUE的大小为11千字节。看起来这11千字节由序列化的WireTransaction的9千字节和2千字节的签名组成。IOUState仅包含单个double（以及两个交易对手的信息）。

使用BlobInspector反序列化TRANSACTION_VALUE的二进制格式会显示一个仅为2 kByte的JSON文件 - 比二进制BLOB的11 kByte小得多，但仍然具有可通过不同的模型大幅减少的数据。

考虑到每秒170次交易（Corda引用的数字），简单的IOU示例将需要每个（参与的）节点每年50TB。

同时注意：BLOB的大小比反序列化JSON要大得多（至少为5倍），这是违反直觉的。也许我做错了什么......

- Christian Fries

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Joel · Accepted Answer

尽管 Blob看起来非常大，但请注意它还包括以下内容：

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

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