A proposal for PST standard consensus and the future of tokens on Arweave
Originally posted here.
Arweaver-based multi-chain aggregation DEX Permaswap finally hit the Mainnet and is in the BETA phase. We believe this is an important infrastructure for the ecosystem, we hope that this will help capture value for projects’ assets on Arweave. There’s one little issue though, whilst we were all excited and ready to launch the first Arweave […]
Arweaver-based multi-chain aggregation DEX Permaswap finally hit the Mainnet and is in the BETA phase. We believe this is an important infrastructure for the ecosystem, we hope that this will help capture value for projects’ assets on Arweave.
There’s one little issue though, whilst we were all excited and ready to launch the first Arweave PST (profit share token) pair on permaswap we all of a sudden realized — there’s no unified standard for smartweave transactions which meant we had to suspend listing the first PST, sadly.
The problems we encountered
Because this was the first PST token pair to be created in DEX, we wanted to start with PST tokens that had no project background as well as having requests for listing that PST was: bAR. Now, after technical research, we realized there was a little issue.
bAR’s transaction can be made through two types of modes:
Arweave native tx. All PST transaction data sets are stored directly on Arweave;
Transaction via Warp gateway’s bundle item tx, which means PST transaction data is packaged with other stored data into a bundle transaction and then uploaded to Arweave.
This means the token’s transaction data is scattered across different places. This makes it challenging for Permaswap to obtain a complete ledger for PSTs.
What do the challenges consist of?
Before answering this important question, let’s start with “What is Smartweave ?”.
Smartweave is a smart contract on Arweave. Since Arweave is a storage public chain, it does not have on-chain computing capacity, so this smart contract has following principles:
The contract codes and related transaction data sets are stored on Arweave permanently, the results of the transaction are obtained from the on-chain data sets and computed off-chain.
As long as the contract code, the content of the transaction data set, and the order of execution are consistent, anyone or any organization can compute a consistent final state and use verifiability to reach a consensus.
PSTs are a Smartweave (Smart contract), the code for each PST and the data set of transactions are stored on Arweave for anyone to access as well as verify the ledger information at any time.
Previously, there was only one transaction data set model for PSTs — Arweave native transactions. The simple idea is to store PST transaction data directly on Arweave, which can be easily obtained from the chain in a variety of ways, ensuring that the data is decentralized and verifiable.
With the ecosystem continuously growing a new storage mode surfaced — a bundle TX named: ANS-104. To put it simply, a large number of data is bundled together and then stored onto Arweave through an intermediary. The mode is a great asset to Arweave as it greatly improves file efficiency, data uploads and reduces costs. Now, where there is good, there’s bad. Bad part of this new mode is that some PST transaction data sets are also packaged in bundles with other various pieces of data on this mode then uploaded onto the chain. Possible consequences of this new bundle mode:
The transaction data set of a specific PST in the bundle cannot be efficiently obtained through multiple ways. Taking everPay as an example, we can only synchronize Arweave native transactions through arsyncer, not bundle item tx transactions. If you use arsyncer, you need to download all bundles and filter the data within them, which is a very inefficient solution.
It is a more centralized way to obtain transaction data sets by relying on intermediaries;
There are risks of double-spending attack .
As a DEX, Permaswap needs to obtain complete PST transaction data sets, then from there get the overall ledger information about the particular PST through off-chain computing.
Let’s go back to the example of bAR. The bAR supports bundle item tx transactions and native tx transactions, Permaswap cannot obtain the transaction data set in the bundle other than the native tx transaction by using everPay’s arsyncer. Currently, the most efficient approach is to capture all of its transaction data sets entirely through Warp gateway. But because it supports two types of transactions, there is a risk of a double-spending attack, “An experiment on PST double-spend attack ” showed the potential risk.
So our challenges are:
Will the Warp gateway be used as the standard for Smartweave related transaction sets in whole community in the future?
Will there be other Bundle standards in the future besides ANS-104? As we know, there might be a way to bundle multiple bundle tx.
As an asset application, how does Permaswap choose?
In summary, all of the issues are due to the introduction of bundle transactions, this means theres no unified standard for how to include Smartweave related transactions.
There are several proposals as follows:
If a project requires more decentralized, less transfer efficiency and fees, use only Arweave native tx transfers, not bundle item tx transactions.
If a project requires more low fees and high efficiency, its PST would only use bundle item tx transactions from a specific intermediary. In this case, this particular intermediary is similar to the sequencer node of Layer2 on Ethereum’s or the coordinator node of everPay. The advantage is that the speed is fast and the status is determined in real time. The downside is that it’s relatively centralized.
DO NOT support both Arweave native tx and bundle item tx. This solution cannot achieve real-time performance, to avoid potential double-spending attack, they have to wait for the transaction data store on chain, and also loses decentralization, so it is not recommended.
DO NOT bundle multiple bundle tx which includes PST transaction data, this will increase the complexity, the client needs to download massive data to cross-verify the data, which greatly increases the difficulty of verification and brings unexpected security risks.
As the first DEX, Permaswap was expected to encounter various challenges, but we believe that with the efforts of the whole community, consensus can and WILL be reached. We are also eager to receive feedback from the ecosystem.
Arweavers! We need your consensus now.
Our links: everVision | everPay |Permaswap | Twitter | Github | Discord
Telegram / Discord / Twitter