The Autobahn Network delivers a novel way to move other assets on the network that is used by Tixl, which offers speed and privacy. In contrast to existing solutions we do not rely on peer to peer payment channels, nor on centralized solutions to swap tokens.
The basic idea is to send the native tokens (we will use Bitcoin as the example for all assets in the following) to the address of a decentralized committee that stores the Bitcoins safely until they are withdrawn from the Autobahn Network.
This is achieved by giving a subset of all validators, called the committee (that makes sure every transaction is legitimate), key shares to a Bitcoin account.
With these key shares, the committee can sign Bitcoin transactions in a decentralized way, without single validators being able to move Bitcoin of the fund.
For every Bitcoin deposited into the Autobahn Network, an equivalent TBTC on the Autobahn Network is created, which will later be burned in the case where the Bitcoin is withdrawn.
The following figure shows how the Bitcoin Ledger is connected to the Autobahn Network via a "BTC / TBTC Gateway":
One of the central concerns for the second layer solution is to enable the transfer of other assets while maintaining decentralisation. This is trivial for the transactions in the network itself as it uses the existing mechanisms of the existing Tixl solution, which is achieving consensus with the Stellar Consensus Protocol.
However, the more challenging task is to guarantee decentralization for the transactions that bring assets to the Autobahn Network (Deposit), and those that bring them back to their native chain (Withdrawals).
The native asset can never leave the native chain as no entity in the Tixl Network has the authority to mint or burn native assets. Instead, the solution is to transfer the ownership of the native tokens to the Tixl Network on deposit and to transfer it back on withdrawal.
To achieve this in a decentralized way, the Autobahn Network uses a Multi-Party Threshold Signature Scheme (TSS).
A subset of the validator's nodes (the committee) will be chosen criteria like global network trust and decentralisation. Every member of the committee participates in the three algorithms of the TSS: Key generation, key re-sharing and signing.
From the global public key, the address, e.g. the bitcoin address, can be calculated, which is the pool address. When enough members of the committee work together they can produce a valid signature for the corresponding global private key, thus allowing the committee to spend the funds that have been transferred to the pool address.
Note, that no committee member reveals their key share or can produce signatures alone. The key re-sharing algorithm allows the committee to generate new key shares without changing the underlying global private key and even allows for new committee members to enter, and old ones to leave.
Threshold Signature Scheme (TSS)
Since our aim is to stay decentralized, no single validator should be able to spend Bitcoins from the shared pool where the Bitcoins are deposited. A procedure like a threshold signature scheme (TSS) is needed.
A (t,n) TSS is a group of n parties sharing a secret in such a way, that only ≥ t parties are able to reconstruct the secret respectively to produce a signature in a decentralized way, without revealing their shares. Additionally, there is a decentralized algorithm to create the secret shares, without any party knowing more than its share.
The Autobahn Network "BTC / TBTC Gateway" relies on the implementation of Binance written in Go, which has been security audited and offers all the features we require. The library offers three algorithms:
This algorithm lets n parties create keys with a threshold of t, which can be used for the other two algorithms.
This algorithm creates a signature and requires at least t parties to participate.
To make the storage of the secrets more secure, the secret shares can be regenerated with the underlying secret (and so the Bitcoin address) remaining the same. This is yet to be implemented in our prototype.
The transferring of assets to the Autobahn Network is quite simple: The user sends the amount they wish to deposit to the pool address and creates a Deposit Block, which contains a reference to the transaction of the native token, on the Autobahn Network.
To prevent any others from claiming that transaction, a claim proof must be provided. Currently two different claim proofs are implemented.
The first method to proof that the user can use the transaction for the deposit block is to sign the public key of the stealth chain the deposit block is going to be placed on with the asset private key, and then supply this signature to the block.
The second method is to send any amount to a second address, which is deterministically generated from the public key of the stealth chain.
In addition, the following criteria must be fulfilled by a deposit block in order to be accepted by the validators: The asset transaction must not have been used in any other deposit block before, the transaction must be confirmed (e.g. 6 times for bitcoin), the asset symbol of the deposit block must match the asset transaction, and the amount of the deposit block must match the amount that was transferred to the pool.
The deposit block mints the respective asset tokens on the Autobahn Network, thus when the deposit block is accepted by the validator network, the token in equal amount of the transaction to the pool now can be moved on the Autobahn Network, while the committee holds access to the native tokens in the pool.
To withdraw tokens of an asset from the Autobahn Network to receive native tokens, a withdrawal block must be created. The withdrawal block has an additional field where the address on the native chain the token should be transferred to, is stored and the amount is public.
When the address is validated, and the block itself is valid, the acceptance of the block results in a token burn of that asset.
The committee witnesses the externalisation of the withdrawal block and creates a transaction of the asset type, e.g. a native Bitcoin transaction, and executes the distributed signing algorithm.
When enough committee members participate in the signing, eventually a signature is produced which is used to complete the transaction.
The transaction is then sent to the native networks, e.g. Bitcoin Network, and the transaction reference is made public so that the user can retrieve it.
Note, that the transaction fee of the native asset is paid from the amount withdrawn. The balance of the pool cannot drop below zero, because only tokens that have been deposited can be withdrawn.