Meta-Transaction Layout

🌌 Research Experimental
1

Meta-Transaction Layout

Introduction

Cryptocurrencies are only one use case of Distributed Ledger Technology (DLT). The vision of IOTA goes beyond that and solves the core problem instead of specific use cases. IOTA should be considered as a generic protocol; a protocol that enables decentralized communication in an unreliable medium. A protocol that is same powerful and valuable as other low level protocols, e.g. TCP/IP.

By using an application agnostic transaction format, we can use the network for any application imaginable.

The aim of the Meta-Transaction (meta-tx) Layout is to provide an application agnostic format, by separating vital characteristics from optional.

A meta-tx consists of the following vital fields:

  • trunk

  • branch

  • shard_id

  • timestamp

  • tx_type

  • payload

  • nonce

tx_type indicates how the payload is structured. This field could be any number or sequence.

The meta-transaction layout allows the network to have different types of transactions at the same time. Therefore, the payload of a certain transaction could contain custom field x,y whereas another payload only contains custom field z. It should be noted, not every node will/must understand all transactions. Applications parse only the transactions that are relevant to them.

Further advantages:

  • A transaction of an application will only contain fields that are relevant to it. It is more clean, saves space and has positive impact on TPS.
  • This layout allows us to make updates on the protocol, without breaking the network. Nodes will be able to forward transactions, even if they don’t understand them, to neighbors who could understand them. It gives us backward compatibility.
  • The meta-tx layout should help standardize the protocol.

Could this have an impact on consensus?

Yes. We still want to find consensus, even if there are different types of transactions. Instead of voting on double-spends (which is use case specific), we vote on a more abstract layer, e.g. the timestamp of a transaction (vital field). The result will be a totally ordered Tangle, independent of the use case. Applications then make use of this ordering.

Reference: Meta-Transaction Layout - Google Dokument

2

I whole heartedly support this idea. We need consensus on some sort of timestamps anyways, so the consensus issues.

The only question is not if we should implement metatransactions, but when we should implement them. Indeed, the goal of coordicide should be to turnoff the coordinator. In the future, we will have to implement a new protocol anyways (to include shardin and quibic… ). The question then is then should meta transactions be part of this future protocol or coordicide?

To be honest, I am not sure what the answer should be to that question.

1 Like
3

I think we should implement at least some parts of the concept within Coordicide. GoShimmer, as far as I remember, already does this. What I mean by “some parts” is that voting could still happen on a more specific layer, e.g. voting on double spends, instead of voting on the abstract layer (e.g. logical clocks). Still, we gain some advantages of the meta-tx layout (e.g. since txs are smaller, an impact on TPS can be expected). However, if we have consensus on the timestamping layer ready within Coordicide, I see no reason not to implement the entire meta-tx concept directly.