MiniSwap 2.0: Scaling MiniSwap at Layer 2

MiniSwap 2.0 is an entirely new generation of interoperable decentralised exchange service, with breakthroughs on the scalability and trans-fee-efficiency. MiniSwap 2.0 achieves the interoperability by extending the MiniSwap Global protocol.

To provide better scalability guarantee and reduce the transaction fees on Ethereum, MiniSwap 2.0 relies on a new layer 2 protocol, called concurrent and non-interactive succinct verification of aggregated states (CNiSVAS). CNiSVAS is layer 2 protocol leveraging non-interactive proof of carrying data (PCD) [1–4] with high concurrency. CNiSVAS also aims at reducing or even eliminating the high gas consumption of swapping operations, and achieves it by validating all transactions offline and only committing an verifiable aggregated Mini-Checksum on the main chain.

MiniSwap 2.0 deploys a layer 2 contract for all asset pairs that are available on the MiniSwap. The layer 2 protocol consists of four phases, namely channel establishment, fast swapping, checkpointing, and channel closure. Users join the layer 2 network through the channel establishment. Users can join the layer 2 network with a set of different assets. After joining the layer 2 network, a user is able to enjoy the off-chain fast swapping by communicating with Swappingbot. The Swappingbot manages all off-chain transactions. The Swappingbot is maintained in a decentralised manner (e.g. through a threshold signature scheme or a Byzantine agreement protocol).

To enjoy layer 2 swap, users run a fair exchange protocol with the Swappingbot, to swap assets with atomicity. The exchange rate is determined by a price oracle. Users obtain a proof from the Swappingbot to confirm an off-chain transaction. The proof is a membership proof stating that a transaction is recorded in batch of state updates that is represented by a digest. The batch of state updates, i.e., accumulated off-chain swaps, will be aggregated and confirmed on the chain periodically. This is called a checkpointing. Users can close the channel at anytime. The balance of the user will be updated in the next checkpointing.

Channel Establishment

To establish a channel, users first create an account with a tuple of asset and value pairs. Then, users trigger MiniSwap 2.0 channel establishment contract to deposit the assets to the Swappingbot account, as specified in the tuple. The Swappingbot has one account for each asset available on MiniSwap.

Fast swapping

Users send a request to the Swappingbot to swap Token X by using y amount of Token Y. The Swappingbot provides the price for this swapping, with a validity time period. There is a local clock to timeout this price. The price is provided by a price oracle. For example, this can be done by using a local aggregation of different external oracle services, or by using an external aggregated oracle such as Chainlink. If the user accepts the price, then the user creates a transaction T X to transfer y amount of Token Y to the Swappingbot address, with a condition that transaction T X′ is valid, where T X′ transfers x amount of Token X from the Swappingbot to the user according to the given price. This conditional transaction, which is considered an atomic fair exchange protocol, is sent to the Swappingbot within the timeout period.

The Swappingbot verifies the received transaction. If it is a valid transaction, then it creates a proof, to confirm the received transaction. Users can make further transactions based on the off-chain confirmed transactions. The proof generated by the Swappingbot is a non-interactive succinct proof to verify aggregated states. A simple and intuitive (but not succinct) construction can be done as a Merkle tree.

· The Swappingbot creates a Merkle tree of size N, where all leaves are labelled by “0”.

· The hash value of received validated off-chain transactions will replace “0” in the chronological order.

· A membership proof will be given to the user together with (root, index), where the root is the hash value of the tree, and the index is a pair of numbers indicating the number of checkpointings on chain, and the location of the transaction in the tree.

While this presents the basic idea, this is not a succinct proof as the proof is of size O(logN). A more proper construction is by using Proof of Carrying Data (PCD) [1], which can be implemented by using Succinct Non-interactive ARguments of Knowledge (SNARKs) [2–4], which can be constructed without any trusted oracles [5].

PCD is a cryptographic mechanism ensuring that a given property is maintained at every step of a distributed computation among mutually-untrusting parties. Prescribed properties are specified as a compliance predicate. Each state in the system comes with a proof, which attests that all historical states, including the current one, comply with the predicate. Hence, the aggregated states in the CNiSVAS protocol can be efficiently verified in constant time regardless of the number N of transitions.

Checkpointing

There are two conditions to trigger on-chain checkpointing. First, an on-chain checkpointing occurs when the Swappingbot has accumulated N off-chain transactions, where N is a predefined large number. Second, an on-chain checkpointing occurs when there are less than N off-chain transactions, but it is already N′ blocks since the last confirmation, where N′ is a predefined system parameter to guarantee liveness. Swappingbot will first aggregate and match all swaps as one multi-input multi-output transaction to make the swap, and confirm the rest non-matchable transactions via MiniSwap 2.0.

Channel Closure

To close an account, the user sends a close request to the Swappingbot, which will confirm and send a proof similar to a normal transaction. This closing transaction essentially transfers all the remaining fund back to the user from the Swappingbot. This will be confirmed upon the according checkpointing transaction.

Accountability of Swappingbot

The Swappingbot is implemented as a decentralised service through a threshold signature scheme. As the transaction from asset X to asset Y is only validated if the pairing transaction from Y to X is valid, so users will not at risk of losing their money.

References

1. Chiesa, A., Tromer, E.: Proof-carrying data and hearsay arguments from signature cards. In: Yao, A.C. (ed.) Innovations in Computer Science — ICS 2010, Tsinghua University, Beijing, China, January 5–7, 2010. Proceedings. pp. 310–331. Tsinghua University Press (2010)

2. Bitansky, N., Canetti, R., Chiesa, A., Tromer, E.: Recursive composition and bootstrapping for SNARKS and proof-carrying data. In: Boneh, D., Roughgarden, T., Feigenbaum, J. (eds.) Symposium on Theory of Computing Conference, STOC’13, Palo Alto, CA, USA, June 1–4, 2013. pp. 111–120. ACM (2013)

3. Ben-Sasson, E., Chiesa, A., Tromer, E., Virza, M.: Scalable zero knowledge via cycles of elliptic curves. In: Garay, J.A., Gennaro, R. (eds.) Advances in Cryptology — CRYPTO 2014–34th Annual Cryptology Conference, Santa Barbara, CA, USA, August 17–21, 2014, Proceedings, Part II. Lecture Notes in Computer Science, vol. 8617, pp. 276–294. Springer (2014)

4. Chiesa, A., Ojha, D., Spooner, N.: Fractal: Post-quantum and transparent recursive proofs from holography. In: Canteaut, A., Ishai, Y. (eds.) Advances in Cryptology — EUROCRYPT 2020–39th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Zagreb, Croatia, May 10–14, 2020, Proceedings, Part I. Lecture Notes in Computer Science, vol. 12105, pp. 769–793. Springer (2020)

5. Chong, S., Tromer, E., Vaughan, J.A.: Enforcing language semantics using proof-of-carrying data. IACR Cryptol. ePrint Arch. 2013, 513 (2013)