Warp Sequencer is a module that is responsible for submitting users' transactions into Arweave (via Bundlr Network). During the process, the transactions are indexed in Warp Gateway. This makes them instantly available for further processing (e.g. state evaluation) - unlike in traditional processing, where user has to wait several minutes for transaction mining and confirmation.
Additionally, the Warp Sequencer does not require users to have any cryptocurrencies (AR, ETH, etc.) on their wallets.
The idea behind Warp Sequencer is to increase the Developer and User Experience. Normally, when an interaction with a contract is being sent to Arweave, one has to wait some time:
- for the transaction mining (~2 minutes)
- for the proper transaction confirmation (assuming at least 10 blocks - ~20 minutes).
This in total gives ~20-25 minutes, which:
- Breaks the DX, e.g. in case developer wants to quickly test the contract's functions on mainnet
- Breaks the UX, e.g. - each user of a given dApp/protocol must wait really long to see the effect of an interaction with a contract. This makes the applications effectively unusable - especially for users coming from the web2.
Additionally, any interaction with contract requires some amount of ARs in the wallet - which might further increase the entry barrier, both for developers and given protocol/dApp users.
NOTE Waiting for a proper confirmation
is especially important (though often overlooked) in case of a smart contract interactions.
Imagine a cache, that is evaluating the contracts state for all the interactions returned at any given time by the default Arweave (arweave.net) gateway.
If the cache does not wait for the proper transactions' confirmation, it may happen that it will store a contract state evaluated from the transactions from a forked blocks (or - even worse - from transactions that were not included in any block).
Advantages of using Warp Sequencer for interactions posting
- Interaction is near-instantly available - as soon as proper response from Bundlr network is received.
- Posting interactions with contract does not require any ARs - the deployment via Bundlr network is either
fully subsidized by the Arweave (for transactions <= 100KiB) or by the Warp (for transactions > 100KiB).
The max transaction size is currently 2MiB.
Most of the contracts' interactions have the "default" 4B size.
- Even though the Bundlr transactions are created and signed by the Warp's wallet, it is still possible to identify
the original data item owner/signer.
NOTE This is especially important in case of smart contracts - as contracts' business logic very often is dependent on who (i.e. what wallet address) is interacting with the contract.
- The option to use VRF in contracts that require verifiable randomness.
- Even if the Warp infra will go down, all the contract interactions can be still retrieved directly from Arweave, using a simple GQL query.
How it works
Instead of posting the interaction transactions directly to Arweave mainnet, Warp SDK creates a data item with interaction input and tags which is then signed with user's wallet. Data item is then sent to Warp Sequencer (
/gateway/v2/sequencer/register endpoint) (this is the default behaviour of Warp's SDK
forMainnet instance is being used).
The Warp Sequencer then:
1. Generates a sort key
A sort key is generated from:
- current mainnet network height
- current sequence value
- original transaction id
- current mainnet block hash
In the original SmartWeave protocol specification, a sort key is defined
[ block_height,sha256(transactionId + blockHash) ], where:
block_height- current network height, l-padded with
0to 12 chars, e.g. for block height
1015556, the result is
sha256(transactionId + blockHash)- a
sha256hash of the concatenated buffers of the transaction id and block hash, e.g. for txId
UR_35HORbjjZ_NnUqinkZuWkcNB1-gBST3Rezt5JrDsand block hash
ixWCxRN36DjVUxQRa68xIeoZLfvLDTtX78e0ae8RAAJjOPpDBuVKVaEKYOpq7bLS, the result is
The complete sort key for the above values would
The generated sort keys are then used by the SmartWeave protocol to lexicographically sort the transactions.
The Warp Sequencer extends this default mechanism by the current sequence value.
The formula for the sort key is extended to:
[ block_height,sequence_value,sha256(transactionId + blockHash) ]
This sequence value can be obtained from the Sequencer's node timestamp, database or other sources.
In its current implementation - a Sequencer node timestamp value is being used.
This in effect gives a fair transactions ordering - the transactions will have the sequence assigned in order in which they are processed by the Sequencer.
Assuming transaction id
1015560 and current Sequencer value
1663069424541, the generated sort key would
NOTE All the transactions sent to Arweave directly, have the sequence value assigned to
This effectively means that if transactions to a given contract are sent both directly to Arweave mainnet and Warp
if two transactions happen to be at the same block height, the "direct" Arweave transactions take precedence.
This also means that the sequencing algorithm is fully backwards compatible with the original SmartWeave protocol.
2. Generates tags for the Bundlr transaction
|Tag Name||Tag Value|
|The original owner/signar of the contract transaction|
|The sequence value used by the Sequencer for this transaction|
|The generated sort key for this transaction|
|The sort key of the previous transaction|
|The original transaction id|
|The block height used for generating the sort key|
|The block hash used for generating the sort key|
|The timestamp of the block that was used for generating the sort key|
|...all the tags of the original transaction|
Sequencer-Last-Sort-Key tells what is the sort key of the 'previous' transaction in the sequencer and
can be used to verify whether all transactions have been properly loaded (i.e. if one
decides to load them directly from L1 nodes) and none is missing.
Additional set of tags are added in case user requests generating a random value using VRF (Verifiable Random Function):
|Tag Name||Tag Value|
|The original hash generated by the VRF (using |
|The original proof generated by the VRF|
|A BigInt value evaluated from the hash generated by the VRF|
|The public key used by the VRF|
Verifiable randomness can be used by contracts that require using random values - e.g. gaming contracts, nft/loot
generating contracts, etc.
vrf-pubkey, the client can always verify the generated random value.
3. Wrap original data item in a bundle and uploads the bundle to Bundlr
Apart from all the tags from point 2, some additional tags are added to the wrapping bundle:
|Tag Name||Tag Value|
In order to send original data item to Bundlr, we use the concept of nested bundles and set an interaction data item inside a bundle. If you're not faimiliar with this concept, here is a quick summary:
Bundling allows to write multiple data items into one top level transaction. A data item differs from a regular transaction by not allowing to transfer AR tokens and passing reward but it has most of the transaction's properties - such as owner, data, tags, owner and id.
In a nutshell, the nested bundles concept means that a data item of a bundle can also be a bundle containg other data items. According to ANS-104 standard it can lead to theoretically unbounded levels of nesting.
You can read the specification for nested bundles standard in ANS-104.
Obviously the data-item is signed by the Sequencer's wallet - and as such can be easily verified.
The Sequencer wallet address is
NOTE The original data item is not modified in any way - this is to preserve the original signature!
After receiving proper response and receipt from Bundlr, the Warp gateway indexes the contract interaction internally - to make it instantly available.
4. Finally, the Warp gateway returns the response from the Bundlr to the client.
Interaction data item retrieval (generated by the Warp Sequencer) via Arweave gateway
Use the GQL endpoint, with the original data item id passed in the
Contract tag. Note that all the
interactions will be part of a bundle (i.e. will have the
edges.node.bundledIn.id value set).
Interaction retrieval via Warp gateway
/gateway/interactions/:id endpoint allows to retrieve the interaction info based on its original id.
- Blind/trustless sequencing - https://github.com/warp-contracts/gateway/issues/48
- Sequencer decentralization - https://github.com/warp-contracts/gateway/issues/93