Features needed for bridges: Concurrent txs/out-of-order txs, a solution to sponsorship failure, fee bump sponsorship
65 views
Skip to first unread message
Leigh McCulloch
Jan 21, 2022, 8:35:34 PM1/21/22
to Stellar Developers
There are two features missing from Stellar that have been showing up lately while we've been looking at a decentralized blockchain bridge that relies on multi-sig and independently controlled validators could integrate with Stellar.
1. Concurrent txs / out-of-order txs / sequenceless txs
Today transactions must be submitted in order because sequence numbers for the source account of a transaction are the only property of a transaction prevent replay.
A transfer bridge sees events occur on a sending chain and generates signed transactions for a receiving chain. When Stellar is the receiving chain a bridge produces a series of transactions that must be submitted in order because the sequence number must be deterministic.
Submitting transactions cost fees and so the receiver or sender should be the ones that pay the fees, and the bridge shouldn't. Ideally the receiver can submit the transaction when they observe that it is available on the bridge. But because the transactions are sequential a receiver slow to submit their transaction would block subsequent transactions unless subsequent receivers decided to foot the bill to submit earlier transactions.
On chains with smart contracts and affordable data storage this problem can be alleviated by storing hashes or IDs on chain. Some bridges appear to do this as their method for preventing replay.
There have been some ideas shared in the past where a Stellar transaction could temporarily be recorded in the ledger to prevent its replay. One way this could work is to introduce a special value (e.g. -1) for the sequence number field of a transaction to indicate it has no sequence number. For a transaction to use this special value and be valid it would be required to be bound to a ledger range (e.g. ledgerBounds in CAP-21). When processed the network would create a ledger entry that lives on ledger until ledgerBounds.max is exceeded. If the transaction is resubmitted a second time while the ledger entry existed the transaction would fail.
Assuming that solutions that address this problem will need to create new ledger entries which must be sponsored, this highlights two more problems relating to sponsorship:
2. Unsatisfied sponsorship fails transactions
Today operations that create ledger entries are brittle to failure if the sponsor for the ledger entry isn't guaranteed to have a sufficient native balance to cover the reserve.
The bridge shouldn't have to pay for the sponsorship as much as it shouldn't need to pay for the fee.
The bridge can use the sponsorship operations to designate the receiver as the sponsor of any ledger entries created, however this would make the transaction vulnerable to failure by a bad actor. A receiver may not have a reserve available and a bad actor might pay the transaction fee to submit the transaction causing it to fail, consume the sequence number, and the receiver would be stuck missing their transfer.
This problem isn't unique to bridges. Any system that generates transactions for someone else and wishes to designate the sponsorship to another participant is burdened with finding some way to ensure the reserve will be available.
Assuming a solution is found to address this problem, there is one problem with sponsorship remaining:
3. Sponsorship must be hardcoded
Today, operations that create ledger entries can only elect the sponsor by hardcoding the sponsor into the transaction. This couples the sponsor at transaction creation time.
A bridge might be able to make an assumption that the sponsor could always be the receiver, but this might not be ideal, it might be that the sender wishes to cover the costs.
Today transactions can have a zero base fee and have their transaction fee paid by a fee account by wrapping the transaction inside a fee bump transaction. If it was possible to specify a sponsor in the same way it would allow the sender or receiver to choose how to sponsor the transaction.
These three problems seem troublesome to decentralized systems that want to leverage Stellar's multi-sig and delegate that another party take care of submitting the transaction at some later time.
There are some suggestions included above. Does anyone have feedback on the ideas suggested above? Or alternative solutions to these problems?
Cheers,
Leigh
1. Concurrent txs / out-of-order txs / sequenceless txs
Today transactions must be submitted in order because sequence numbers for the source account of a transaction are the only property of a transaction prevent replay.
A transfer bridge sees events occur on a sending chain and generates signed transactions for a receiving chain. When Stellar is the receiving chain a bridge produces a series of transactions that must be submitted in order because the sequence number must be deterministic.
Submitting transactions cost fees and so the receiver or sender should be the ones that pay the fees, and the bridge shouldn't. Ideally the receiver can submit the transaction when they observe that it is available on the bridge. But because the transactions are sequential a receiver slow to submit their transaction would block subsequent transactions unless subsequent receivers decided to foot the bill to submit earlier transactions.
On chains with smart contracts and affordable data storage this problem can be alleviated by storing hashes or IDs on chain. Some bridges appear to do this as their method for preventing replay.
There have been some ideas shared in the past where a Stellar transaction could temporarily be recorded in the ledger to prevent its replay. One way this could work is to introduce a special value (e.g. -1) for the sequence number field of a transaction to indicate it has no sequence number. For a transaction to use this special value and be valid it would be required to be bound to a ledger range (e.g. ledgerBounds in CAP-21). When processed the network would create a ledger entry that lives on ledger until ledgerBounds.max is exceeded. If the transaction is resubmitted a second time while the ledger entry existed the transaction would fail.
Assuming that solutions that address this problem will need to create new ledger entries which must be sponsored, this highlights two more problems relating to sponsorship:
2. Unsatisfied sponsorship fails transactions
Today operations that create ledger entries are brittle to failure if the sponsor for the ledger entry isn't guaranteed to have a sufficient native balance to cover the reserve.
The bridge shouldn't have to pay for the sponsorship as much as it shouldn't need to pay for the fee.
The bridge can use the sponsorship operations to designate the receiver as the sponsor of any ledger entries created, however this would make the transaction vulnerable to failure by a bad actor. A receiver may not have a reserve available and a bad actor might pay the transaction fee to submit the transaction causing it to fail, consume the sequence number, and the receiver would be stuck missing their transfer.
This problem isn't unique to bridges. Any system that generates transactions for someone else and wishes to designate the sponsorship to another participant is burdened with finding some way to ensure the reserve will be available.
Assuming a solution is found to address this problem, there is one problem with sponsorship remaining:
3. Sponsorship must be hardcoded
Today, operations that create ledger entries can only elect the sponsor by hardcoding the sponsor into the transaction. This couples the sponsor at transaction creation time.
A bridge might be able to make an assumption that the sponsor could always be the receiver, but this might not be ideal, it might be that the sender wishes to cover the costs.
Today transactions can have a zero base fee and have their transaction fee paid by a fee account by wrapping the transaction inside a fee bump transaction. If it was possible to specify a sponsor in the same way it would allow the sender or receiver to choose how to sponsor the transaction.
These three problems seem troublesome to decentralized systems that want to leverage Stellar's multi-sig and delegate that another party take care of submitting the transaction at some later time.
There are some suggestions included above. Does anyone have feedback on the ideas suggested above? Or alternative solutions to these problems?
Cheers,
Leigh
Reply all
Reply to author
Forward
0 new messages