This means the submitted data has to be utf8 text (I think it's how the evm version works too).
suppliedValue is always '0' because I don't think there is a concept of sending more tokens in a data submission. I think probably that would require setting up an extra transaction, and then submitting an input with the tx info or something (because tracking all the transfers may not work well with the data index?).
There is no presync phase for these funnels.
The delay on the base funnel version is something that we don't have in the block funnel. I don't know if it's needed here, but in any case it's there (defaults to no delay and no confirmation depth).
A light client is used for access to the app's data, but the rpc is used to get the slots for the blocks (from the headers). This is used to compute timestamps without relying on the steady block production. (Also see https://github.com/availproject/avail-light/issues/574)
TODO
[x] Refactor to re-use the code of the parallel evm funnel? The functions are mostly already abstracted, it's just a matter of replacing some.
[x] Optimization? Only get headers for blocks with data (and latest one).
[x] Batcher support? I think that's for a different PR. For now inputs have to be directly submitted. We may have already part of the cryto since it's polkadot.
[x] There is a TODO in switchWallet, not sure what needs to be done there yet.
There are two funnels added here. The first one is an analog to the evm parallel funnel, and has to be configured as
avail-other
:The other one is an analog to the block funnel, and it has the same configuration, except that it has the key of
avail-main
.In both cases the data is added as part of the submittedData field. Example
Notes
This means the submitted data has to be utf8 text (I think it's how the evm version works too).
suppliedValue
is always '0' because I don't think there is a concept of sending more tokens in a data submission. I think probably that would require setting up an extra transaction, and then submitting an input with the tx info or something (because tracking all the transfers may not work well with the data index?).There is no presync phase for these funnels.
The delay on the base funnel version is something that we don't have in the block funnel. I don't know if it's needed here, but in any case it's there (defaults to no delay and no confirmation depth).
A light client is used for access to the app's data, but the rpc is used to get the slots for the blocks (from the headers). This is used to compute timestamps without relying on the steady block production. (Also see https://github.com/availproject/avail-light/issues/574)
TODO