New Feature: "Broadcasts"

🌌 Research Coordicide
1

In this post I want to propose a new “feature” for the IOTA protocol - broadcast messages.

What is a “broadcast message”?

A broadcast message is a transaction that reaches all nodes through gossip but that is “allowed to be forgotten”. It will count into a nodes rate limit, but it will not be picked up by the tip selection and therefore not become part of the tangle.

How do we mark a transaction as being a broadcast message?

A transaction is marked as a broadcast message by having its branch and trunk point at the genesis.

Transactions that try to “attach” to a broadcast message are considered to be invalid (unless there are no other transactions available - i.e. time of the first value transaction).

Note: Broadcast messages that contain value transfers are ignore by the ledger state.

What are the use cases of broadcast messages?

Since broadcast messages do not become part of consensus, they can “skip” a lot of the “heavy processing steps” of a normal transaction. They can essentially be gossiped further on arrival. They are therefore the “fastest” way of communication in the tangle and allow “near real time” communication (maybe the equivalent of UDP).

Nodes that are so small, that they can not even afford to maintain a part of the dag in memory can still use the existing IOTA network and infrastructure to communicate with each other by sending broadcast messages (i.e. sensors sending data to an aggregator).

Note: They would have to be “recharged” with mana remotely by somebody pledging mana to their node id so they can continue to send messages of course).

Data that is not supposed to “stay” in the tangle forever (i.e. for privacy reasons) can still be sent to all network participants who can then react to it if they are online.

Conclusion

Transactions that have both of their “references” point towards the genesis are already considered to be “lazy tips” and will therefore not be picked up by the tip selection. They therefore already more or less “have the named features” naturally. So why don’t we just declare them a “feature” instead of “an attack vector”? :stuck_out_tongue:

1 Like
2

Interesting. Currently nodes in the qubic assembly are assumed to exchange UDP packages, so they must know IP addresses of all peers. The broadcasting over gossip could replace that, provided the messages are properly masked and understandable only for recipients. Or even one step further, the broadcasted transactions could contain some kind of “tangle address” of the recipient and gossip extended with some routing. It all has overhead, of course

3

This is a very nice feature and particularly something I am interested in to implement an AR application that displays information from sensors connected to the Tangle. I have one question and one concern:

  1. Question: When is this feature going to be available, at least for testing? This is an excellent feature, specially if the speeds are close to UDP. Currently, we are working on an ephemeral cache of sorts that captures data of interest for our AR devices. Since we are doing it on a local tangle, this is a good working solution. However, this broadcast feature is very interesting and could be a more permanent solution for other applications that require real-time data from IoT devices participating in the general tangle.

  2. Concern: Broadcast provenance trustability.
    My main concern is how the broadcast messages are tested or guaranteed to be from a secure provenance. Can I assume that only trusted tangle participants (e.g., IoT sensors) that have known provenance, which has already contributed somehow to the tangle, can broadcast messages? Because if at least the provenance of the broadcast has not been somehow certified, then the broadcast data is not trustable. Am I wrong? Or am I missing something here?

4

Were just discussing ideas here, there are not current plans to implement this feature at this time.