时间戳

首页 > 解决方案 > Corda：大型序列化事务大小：当前序列化设计是否有替代方案？

corda - Corda：大型序列化事务大小：当前序列化设计是否有替代方案？

问题描述

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

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

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

例子

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

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

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

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

标签： corda

解决方案

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

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

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

推荐阅读