e parece que la versión actual de Corda (3.1) almacena una transacción (firmada) a través de un BLOB como una matriz de bytes serializada de la clase JavaSignedTransaction. (LosSignedTransaction es unWireTransaction, es decir, contiene una matriz de bytes que representa la transacción serializada).

ara algunos proyectos, este enfoque puede plantear un desafío, ya que parece un desperdicio comparable en términos de memoria y, por lo tanto, de rendimient

¿Es esta la forma estándar en que Corda serializará las transacciones? ¿Qué opciones existen para cambiar la serialización para reducir los requisitos de memoria?

Ejempl

Probar elCordApp "IOU" Ejemplo tener un @ simp IOUState y una transacción simple, una sola transacción crea una sola entrada en la tablaNODE_TRANSACTIONS donde el tamaño deTRANSACTION_VALUE reportado porselect length(TRANSACTION_VALUE) from NODE_TRANSACTIONS es de 11 kilobytes. Parece que estos 11 kilobytes consisten en 9 kilobytes para el @ serializaWireTransaction y 2 kilobytes para las firmas. El IOUState contiene un solo doble (e información sobre las dos contrapartes).

Utilizando BlobInspector para deserializar el formato binario de TRANSACTION_VALUE revela un archivo JSON de solo 2 kBytes, mucho más pequeño que los 11 kBytes del BLOB binario, pero aún tiene datos que podrían reducirse enormemente si se almacenan con un modelo diferente.

Considerando 170 transacciones por segundo (una cifra citada para Corda), el ejemplo de IOU simple requeriría 50 terrabytes por año (365 días, 24 horas) en cada nodo (participante).

Nota también: que el tamaño del blob es mucho mayor que el JSON deserializado (al menos el factor 5) es contradictorio. Tal vez hice algo mal aquí ...