Sending transactions from Cosmos network to Arweave

[szynwelski]

The basic task of the sequencer is to produce blocks containing transactions in a given order. Once the order is established, the transactions should go to Arweave using Bundlr.

The purpose of this issue is to describe and implement the functionality of data transfer from the sequencer to Arweave. The subject of the format and validation of sent data is described in #12.

The simplest solution

The simplest solution is to create a dedicated application that listens for Cosmos blocks and sends them to the Bundlr. Such an application has little room for manipulation, but it would still be a central element in our solution and can only be considered as an intermediate step.

Ultimately, we would like the Cosmos network to send blocks to Bundlr. This can be achieved with the following procedure.

Relayer selection and verification

• The node that is responsible for sending blocks to Bundlr at a given moment is called a relayer.
• Exactly one node is a relayer at a time.
• The selection of the relayer from the set of active validators is done in the same way as the selection of the proposer. The difference is that the proposer is chosen for each round, and the relayer is chosen after the previous relayer has correctly or incorrectly performed its duty.
• The node that has been selected as a relayer has a certain number of blocks (e.g. 10 blocks) to send the selected number of blocks to Bundlr.
• For every block sent, the relayer is rewarded and thus encouraged to send as many blocks as possible. An important requirement is that the relayer can only send a block for which all lower height blocks have been sent.
• After sending blocks in the form of Bundled Data to Bundlr, the relayer sends a transaction to the Cosmos network with receipt signed by Bundlr. Together with the receipt, the relayer must provide his signature for the nested bundle sent to Bundlr. Then, such receipt is validated by the network and if it is correct, the relayer receives a reward proportional to the number of blocks sent. The next relayer is also selected.
• To validate a receipt signed by Bundlr, the network must maintain a list of public keys of Bundlr nodes. There must be a mechanism for updating public keys confirmed by 2/3 votes of validators. Note: according to the authors, the functionality of signing receipt by Bundlr is to be maintained after the decentralization of their nodes.
• If the relayer within a given number of blocks (e.g. 10 blocks) fails to submit a valid receipt, it is slashed and another relayer is selected.
• In case it's not possible to send blocks (due to a malfunction or lack of availability of the Bundlr), the relayer sends a transaction to the Cosmos network with information about the issue with the Bundlr. In this case, the relayer is not punished for now and his successor is chosen. In this way, a series of transactions can be created with information about problems with Bundlr. At some point this series will end (i.e. Bundlr is working properly again). If such a series was created by relayers who have less than 1/3 of the votes, they are slashed exactly as if they had not done their duty.

Parameters to be decided

1. The number of blocks within which the relayer can send data to Bundlr (e.g. 10 blocks).
2. The reward the relayer receives for sending each block.
3. Relayer penalty for not sending blocks.
4. Should the relayer only be able to send one bundle (potentially multiple blocks) on its turn? Or should the relayer decide when his turn ends (but not longer than the maximum turn length, e.g. 10 blocks)?

Possible attacks from malicious or malfunctioning nodes

Sending transactions but not sending receipt

Anyone who listens to Cosmos blocks (not only validators) can send all or part of the transactions to Bundlr. This will make the relayer's work more difficult because the relayer may get a duplication error when trying to send a given block to Bundlr. Therefore, it should be possible for the relayer to send the entire block to Bundlr, and if that fails, individual transactions and block metadata should be sent separately.

To handle this situation, we need to ask Bundlr to add the functionality of informing which DataItems in the bundle are duplicates and signing such a response (so that the relayer can prove that it cannot upload the transaction, because someone has already uploaded it).

Note: The format of the blocks sent by the relayer is described below and the format of the block metadata is described in #12.

Not sending blocks to Bundlr

A malicious node that is selected as a relayer may simply not send blocks to Bundlr. Then the number of blocks waiting to be sent will increase, which means more work for the next relayer. In addition, a certain group of malicious nodes can be selected for subsequent relayers, and then the delay in sending can increase to a larger number.

However, this behavior will cost malicious relayers the loss of tokens. On the other hand, honest relayers should be able to catch up and get a bigger reward for sending more blocks.

TODO: check empirically how much an honest relayer is able to send data within a fixed number of blocks (e.g. within 10 blocks).

Sending incorrect information about a problem with Bundlr

A malicious node may report a problem with Bundlr even though it is working properly. It can thus delay sending blocks while trying to avoid slashing. But to avoid being punished, Bundlr issue must be confirmed by more relayers that together hold at least 1/3 of the votes. This is not possible without confirming Bundlr issues by an honest node (in Comet BFT it is assumed that there are less than 1/3 of dishonest nodes).

Problem with Bundlr

Sending blocks can fail not only because of malicious nodes, but because of actual problems with Bundlr. In this case, information about a problem with Bundlr will appear in subsequent blocks and the number of blocks waiting to be sent will increase. Once problem with Bundlr is resolved, the relayers will need to send more blocks to catch up.

Tests are needed to ensure that any delay can be compensated for in this way.

It's important to ensure that the rest of the Warp SmartContracts functionality work properly in the event of a Bundlr issue

Sending invalid block metadata

Some application can send fake Cosmos block metadata to Bundlr. The topic is related to the validation of sent data and is described in #12.

If the relayer sent invalid data, its receipt will not be accepted by the network and it will be slashed.
If incorrect data is sent by another Cosmos node (not a relayer), it may be punished. To this end, we can add a mechanism that allows you to send proof to the network in the form of receipt from Bundlr that a given node, which is not a relayer, sent metadata to it.
If invalid data was sent by a node that is not a Cosmos validator, such metadata will be ignored (see #12).

Format of blocks sent to Bundlr

Since any application listening to Cosmos blocks (or a validator from its mempool) can fetch and send transactions to Bundlr, we cannot require individual transactions to be wrapped in a fixed structure. Therefore, the format of data sent from Cosmos to Bundlr should assume that Arweave transactions can be sent as separate DataItems. These DataItems can be included in a bundle in which the relayer also sends Cosmos block metadata (metadata details described in #12) or sent in separate bundles. So the format could be as follows:

1. bundle with DataItem with block metadata + DataItems with transactions,
2. bundle with DataItem with block metadata,
3. bundle with a DataItem with a single Arweave transaction.

When creating a Cosmos transaction confirming the sending of data, the relayer should put in it:

• a receipt signed by Bundlr after receiving a bundle of type 1,
• or a list of receipts signed by Bundlr for bundles of type 2 and 3 (for all transactions in the block) confirming their acceptance or information that such a bundle has already been accepted.

Alternatively, if Bundlr added functionality to inform which DataItems are duplicates, the relayer could retry the bundle, skipping duplicate DataItems.

Pros and cons

➕ Decentralization of relayer functionality
➕ The sequencer and other elements of Warp SmartContracts works even in the case of problems with Bundlr
➖ Definitely more complex than the simplest solution

Alternative approach

Sending transactions to Bundlr first. The sequencer would then receive the transactions along with the receipt signed by Bundlr and would only sequence those transactions.

➕ There is no problem with duplication of DataItems.
➕ /➖ It still requires a relayer mechanism, which will be a bit simpler as it will only send Cosmos block metadata.
➖ In case of problems with Bundlr, all Warp SmartContracts functionality does not work.

[janekolszak]

Relayer, in its centralized version for the initial deployment stage, will be implemented here: warp-contracts/syncer/issues/47