Native and Bundle mixed sequencing optimisation solution

Originally posted here.
By: everVision

Overview

Previously, we published an article titled “We need a PST consensus! “, which discussed two issues. One is Smartweave transaction data sets collected consensus. The second problem is the verifiability of data in bundles. Today, we’d like to make some suggestions that can be evolved in the future. Sequencer and validator Before we begin, we […]

The Post

Previously, we published an article titled “We need a PST consensus! “, which discussed two issues. One is Smartweave transaction data sets collected consensus. The second problem is the verifiability of data in bundles. Today, we’d like to make some suggestions that can be evolved in the future.

Sequencer and validator

Before we begin, we need to understand two critical roles in the system – the Sequencer and the Validator.

Sequencer is responsible for receiving user transaction data, sorting and uploading them to Layer1 in the order they are received. Most sequencers are run by system creators and are widely used in Layer2 Rollup because of their simplicity and efficiency. In the Arweave ecosystem, it is used in Bundle TX for some platforms, typically Warp Contract, the Smartweave contract platform, and everPay, the real-time financial payment protocol (named Coordinator instead of Sequencer in the everPay system).

Validator is the institution or individual who verifies the transaction data, which makes up for the defects of the sequencer’s relative centralisation from the perspective of verifiability. It can be a data explorer, wallet, etc.

Native & Bundle mixed sequencing

In the previous article, we mentioned that most of Smartweave in the Arweave ecosystem, such as PST tokens, support both Arweave Native TX and Bundle item TX. This method requires an intermediary using a sequencer, which we refer to here as Native & Bundle mixed sequencing.

Simply put, the sequencer acts as a middleman responsible for collecting the complete transaction data set. It receives users’ transaction data, collects PST-related transaction data from the Arweave main chain, arranges them according to specific rules, and bundles them before uploading them to Arweave for permanent storage.

The advantage of this approach is that it allows for both real-time transaction confirmation and lower on-chain costs, while still giving users a more decentralised native transaction option. But the problems are just as obvious, mainly as follows:

The sequencer censors user’s transactions, such as not recording the transactions of certain users;

The sequencer breaks down, causing the entire system to fail to run correctly.

After a lot of discussions, we decided that through optimisation, this mixed sequencing could avoid the above problems.

Of course, we can better solve the problem through the way of multiple sequencers, but this solution requires additional coin issuance, which will be introduced in a subsequent article.

Optimisation of mixed sequencing

Allow users to send transactions in two ways. A. Send Native transactions on Arweave. B. The transaction will be directly sent to the sequencer, which will sort and pack and store on Arweave forever, and the transaction can be confirmed in real-time;

The sequencer will confirm the native transactions and collect them in the transaction data set of the sequencer server after several blocks (assuming the period is C1) are confirmed, sort them to form a new transaction data set, and then Bundle them to the main Arweave chain.

Arweave transactions that have not been included in the sequencer will be automatically included in the validator’s transaction data set after a longer block confirmation (assuming a period of C2).

The above rules need to be coded to the sequencer node and validator nodes.

Case study

Assuming C1 is 15 blocks, C2 is 150 blocks, and Arweave is on 1000 block height,

The transaction TX1 sent by Bob via Arweave Native TX is packaged into Arweave Block 1000;

Bob also sends TX2 , Alice and Sam send TX3 and TX4 to the sequencer server.

(where TX1 and TX2 are in conflict, for example, both transfer all balances in Bob’s account)

1. When the sequencer runs normally

TX2 , TX3 , and TX4 are confirmed in real-time and uploaded to Arweave Block 1002 via the Bundle.

After passing 15 blocks of C1, that is, block height 1016, the sequencer collected TX1 and Bundled it to upload Arweave.

At this point, all four transactions have been uploaded.

Any third party that wants to verify a transaction can access the transaction data set from the Arweave chain,

The order is TX2 , TX3 , TX4 , TX1

Since TX1 conflicts with TX2 , the TX1 transaction is considered invalid during calculation and will be ignored.

2. The sequencer is down

If at the block height 1000, the sequencer server breaks down and cannot bundle TX2 , TX3 , and TX4 onto the chain.

After a longer period of 150 blocks of C2, at 1151 block height, TX1 is automatically included in the transaction data set by another third-party validator.

Any third party that wants to verify a transaction can now retrieve the transaction data TX1 from the Arweave chain.

Users can continue to send Arweave Native transactions even when the sequencer is down, and the system can still run normally.

When the sequencer server resumes after the block height of 1151, the sequencer state at this time is the new state after receiving TX1 .

3. If the Sequencer censors transactions

If the sequencer censors transactions when the block height is 1000, it does not record the transaction TX2 sent by Bob, but only bundles TX3 and TX4 to Arweave.

After passing 15 blocks of C1, block height 1016, the sequencer also does not record theTX1 sent by Bob.

However, at block height 1151, other third-party validators will automatically collect TX1 .

Any third party that wants to verify a transaction can access the transaction data set from the Arweave chain,

The order is TX3 , TX4 , TX1

Therefore, if sequencer deliberately does not include Bob’s TX2 transaction, Bob can still complete the transfer through native transaction TX1 , which is included in the transaction data set by the validators.

Arbitrum similar solution

The optimisation solution was inspired by Ethereum Layer2 project Arbitrum.

All transactions on Arbitrum (including cross-chain transactions between L1 and L2, and original transactions on L2) will be included in L1 SequencerInbox contract. The content of this contract determines the specific transaction and the order. The transaction included in this contract is executed from beginning to end to get the current status on the L2 chain.

SequencerInbox only allows writing to Sequencer nodes, but Delayed inbox contracts can be written to transactions by regular users and third-party nodes. Transactions in the Delayed inbox are periodically collected in the Sequencer to the SequencerInbox; When Sequencer does evil or breaks down, it can be forced into SequencerInbox by the Force Inclusion mechanism after some time (24 hours at present), to make the system run normally.

Join our

Telegram / Discord / Twitter