Native and Bundle mixed sequencing optimisation solution
Originally posted here.
Previously, we published an article in the community 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. More community members are beginning to realise the seriousness of these problems, as they form an obstacle to […]
Previously, we published an article in the community 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. More community members are beginning to realise the seriousness of these problems, as they form an obstacle to the growth of the value of Arweave’s ecosystem assets.
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 it to Layer1 in the order it is 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. Along with those is 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.
Currently, the Smartweave project platform in the Arweave ecosystem uses a single point sequencer to upload data, so there are relatively centralised defects, mainly as follows:
The sequencer does malicious behavior not to record the transactions of certain users;
The sequencer breaks down, causing the entire system to fail to run correctly.
This is why we did not recommend using mixed sequencing in the previous article. However, after a lot of discussion, we decided that through optimisation, this mixed sequencing could avoid the above problems.
Of course, we can better solve the problem through the decentralised 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 the 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 at this time 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 longer block confirmed (assuming a period of C2).
The above rules need to be coded to the sequencer node and validator nodes.
In the current Arweave ecosystem, Warp’s sequencer only includes points 1 and 2, but not 3. Adding a third clause will significantly improve the robustness of its system.
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)
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 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 in 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.
At the end
The mixed sequencing solves the integrity of Smartweave transaction data sets such as PST, but it does not solve the decentralised verification problem, which for DEX such as Permaswap is a huge security risk. We will elaborate on this in a subsequent article.
Our links: Permaswap | Whitepaper | Twitter | Discord
Telegram / Discord / Twitter