Multichain Disk Consumption and Sizing

Question

Let's say each transaction that I have has 200 characters metadata. How many transactions and/or blocks before multichain can fill-up a 1TB-disk? Let's say that the whole 1TB-disk is allocated only for multichain.

Is it as simple as 1TB / (200 bytes + default transaction size)? Is there an average transaction size excluding the metadata?

Thanks.

Answer 1

There are several other things that take up disk space, so if you're talking about small pieces of data, they will not be the determining factor. If each transaction has one input and output (apart from the metadata), that's about 220 bytes. MultiChain will also use up disk space for rollback information, and to store the local transaction database for a node (which is separate from the blockchain). Sounds like in your case you should estimate around 1K of disk space per transaction. Bear in mind also that the current alpha writes a lot of logging information to help us debug problems, but that will be drastically reduced during the beta phase.

Comments

Thanks for your reply.

On logging, how is it managed? Are logs kept just for a certain amount of days?

---

For now the logs keep growing but there is an option -shrinkdebugfilesize for multichaind that shrinks the log file. We will be tidying all this up in time for the beta release.

---

Any idea about the overhead introduced by Stream feature?

---

Based on your previous answers regarding streams, it seems that the same concept can be applied in streams 2*(220+key size+value size). Please correct me if I am wrong.

I assume that multichain indexes the streams so that it could be retrieved in a timely manner. How then does multichain save the index? Does it consume additional disk space? If yes, by how much?

Thank you!

---

Yes, a stream item is just a special transaction output, so the same logic applies. There are a few extra bytes of padding for indicating this output, but nothing substantial: http://www.multichain.com/developers/data-streams/

If a node subscribes to a stream, it indexes it in various ways, using LevelDB as the storage engine. I can't yet give you exact measurements for this but you can try it and see for yourself.