Integrating `transaction` into `chainhead`

[josepot]

Close #77

In my previous comment, I voiced concerns about the transaction group of functions. My belief is that integrating the transaction group into chainhead would simplify things, and this PR represents that effort.

To clarify, my main objective is twofold:

1. Submit a transaction using a followSubscription token.
2. On detecting a new block, verify if the submitted transaction is within it and identify its index.

I don't care that much about the particular mechanisms that we use for communicating the other intermediary states (validation status and broadcast).

Additionally, the use of followSubscription for transaction submission negates the need for events like dropped, error, or determining if the transaction is in the best/final block. If a transaction is identified in a block, the only requisite is to track those blocks until they're considered best/finalized.

cc: @tomaka

[tomaka]

Some nodes might not support sending out transactions.

[josepot]

Some nodes might not support sending out transactions.

wouldn't those be the same nodes that wouldn't support chainhead? I'm genuinely asking 🙏 . Asked differently: why would a node which is able to support chainhead, not be able to support broadcasting transactions? 🤔

[gavofyork]

I suppose a one-way protocol, like broadcasting blocks over the radio, would mean you could follow the chain head but not be able to submit transactions.

Is that what you're thinking of here, @tomaka ?

[josepot]

I suppose a one-way protocol, like broadcasting blocks over the radio, would mean you could follow the chain head but not be able to submit transactions.

Is that what you're thinking of here, @tomaka ?

If that's the case, then wouldn't it make sense for the transaction group of functions to be a super-set of the chainhead group? My reasoning is based on the current implementation where the transaction group can only be utilized if the chainhead group is present. The potential for them to become out of sync poses evident challenges.

[josepot]

From what I've gathered, we essentially have two viable options:

1) Make the transaction group of functions be a superset of the chainhead functionalities, similar to the approach in this PR.

2) Confine the transaction group's responsibilities to solely broadcasting transactions. This would leave tasks like validation, locating the transaction within a block, etc., to the client. For the record: I would be happy with this option, too.

However, what seems counterintuitive is the current implicit coupling between chainhead and transaction, especially when we can't assure they'll be synchronized. If we're advocating for the chainhead functionalities to be distinct from the transaction ones, the reverse should also be valid.

[gavofyork]

I suppose that a node which is able to accept a transaction (and, we would presume, forward it on to other nodes capable of getting it in a built block if not build a block with it itself) must track the chain head: either they do so because they're building blocks, or to avoid gossiping invalid transactions to other nodes who would surely boot them if they consistently gossiped invalid/expired transactions (or indeed other data) to them.

With that in mind, transaction RPCs should indeed imply the availability of chain head tracking RPCs.

[tomaka]

or to avoid gossiping invalid transactions to other nodes

On the other hand, the JSON-RPC client might be able to attest that the transaction is valid because it has validated the transaction on its side. In practice this will be the case most often than not, because the JSON-RPC client probably wants to calculate the fees of the transaction before submitting it.

In the case of a publicly-available JSON-RPC server, the server needs to be careful about clients submitting invalid transactions, but in the case where the JSON-RPC client and server and working closely together, there's normally no need for the server to re-validate the transaction once again.

If the JSON-RPC server doesn't have to validate the transaction, it could create nice optimizations, for example in the case of a light client the server might not even have to download the runtime of the chain anymore, provided the JSON-RPC client is sure that its transactions are valid.

Overall, as I've mentioned on Element, this feels like a complex problem to me, and I haven't fully wrapped my head around it.

[josepot]

In retrospective, this PR was premature. As @tomaka pointed out on element, we should first have a proper discussion about this topic. I opened #79 as an attempt to have a structured discussion around this.