11

A transaction in IOTA consists of 2673 trytes. The biggest part is the signatureMessageFragment (more infos here) which has a size of 2187 trytes.

It is used to store the signature of value transactions and it can be used for custom data of 0 value transactions.

If a transaction's signatureMessageFragment has leading 9s, they don't have to be transmitted or stored because the Curl hash function will produce the same result with any amount of leading 9s.

Value Transaction

If you want to send IOTAs to another person, you have to create a Bundle that consists of 4 or more transactions.

  1. recipient output
  2. input + first half of signature
  3. second half of signature
  4. remainder output

With variable size signatureMessageFragments, we could put the entire signature into 1 transaction. That would save some header data (2673-2187=486 trytes) and even more for multisignature transactions.

This would reduce the Tangle size significantly, wouldn't it?

Data Transaction

If you want to send a small amount of data (up to 2187 trytes), you can put it at the end of signatureMessageFragment without using up additional space/network because you can ignore the leading 9s.

But if you want to send a big amount of data (e.g. 16 Kilotrytes (16000 trytes)), you have to make 8 transactions instead of 1. That's a lot of unnecessary header data.

2673-2187=486 trytes
486*8=3888 trytes

3.9 Kt header for 16Kt instead of 486 Kt header for 16Kt

With variable size signatureMessageFragments, we could send small amounts of data and big amounts of data in less space.
This would decrease the Tangle size significantly, wouldn't it?

PoW

Of course you'd have to adjust the amount of PoW to the size.
e.g. default POW for up to 2187 Trytes of data, higher difficulty for additional data.
But it would be possible, wouldn't it?


Even if the Tangle size won't be decreased by a lot because most transaction data would be <= 2188.
It would save at least 486 trytes per value tx, right?

So:

What are the disadvantages of variable size transactions?

  • 1
    Leading 9s don't need to be transmitted nor stored, with Curl hash function that doesn't change the transaction hash. Take that into account in your math. – Come-from-Beyond Dec 13 '17 at 9:11
  • The 9s in the signatureMessageFragment? So if the message/signature is HELLO9CFB999999... only HELLO9CFB has to be stored? – Zauz Dec 13 '17 at 16:12
  • The field value should be 999...99HELLO9CFB, in this case only HELLO9CFB needs to be transmitted/stored. – Come-from-Beyond Dec 13 '17 at 19:49
10
+50

There is no a perfect solution, the both variants (fixed-size and variable-size transactions) have their own pros and cons. These are some pros of fixed-size transactions which make them the best choice for the IoT:

  • Smaller codebase for transaction processing (if implemented in software)
  • Fewer logic gates for transaction processing (if implemented in hardware)
  • Higher security (because of a lower chance for buffer overflow type bugs to happen)
  • Reduced resource consumption (because of absence of issues like heap fragmentation)
  • Better load balancing (because transaction processing is more predictable)
  • Atomic transmission over a physical medium (because packet size can be equal to transaction size + service data)

The list can be continued, it's just what has come to my head now. One could compare fixed-size transactions to fixed-size instructions used in some CPUs. In the Internet-of-Things there more cases where a fixed size is better than the variable size.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.