Corda: Grande tamanho de transação serializada: existem alternativas ao design atual de serialização?

Parece-me que a versão atual do Corda (3.1) armazena uma transação (assinada) por meio de um BLOB como uma matriz de bytes serializada da classe JavaSignedTransaction. (OSignedTransaction é umWireTransaction, ou seja, contém uma matriz de bytes que representa a transação serializada).

Para alguns projetos, essa abordagem pode representar um desafio, pois parece um desperdício comparável com a memória e, portanto, com o rendimento.

É assim que o Corda serializa transações? Quais opções existem para alterar a serialização para reduzir os requisitos de memória?

Exemplo

Tentando oExemplo de "IOU" do CordApp tendo um simplesIOUState e uma transação simples, uma única transação cria uma única entrada na tabelaNODE_TRANSACTIONS onde o tamanho deTRANSACTION_VALUE Reportado porselect length(TRANSACTION_VALUE) from NODE_TRANSACTIONS é de 11 kilobytes. Parece que esses 11 kilobytes consistem em 9 kilobytes para o serializadoWireTransaction e 2 kilobytes para as assinaturas. O IOUState contém um único duplo (e informações sobre as duas contrapartes).

O uso do BlobInspector para desserializar o formato binário de TRANSACTION_VALUE revela um arquivo JSON de apenas 2 kBytes - muito menor que os 11 kBytes do BLOB binário, mas ainda com dados que podem ser reduzidos em massa se armazenados com um modelo diferente.

Considerando 170 transações por segundo (uma figura citada para Corda), o exemplo simples de IOU exigiria 50 terrabytes por ano (365 dias, 24 horas) em cada nó (participante).

Observe também: que o tamanho do blob é muito maior que o JSON desserializado (pelo menos, fator 5) é contra-intuitivo. Talvez eu tenha feito algo errado aqui ...

questionAnswers(1)

yourAnswerToTheQuestion