[Disclaimer: This is a dual proposal to "Erdstall". "Perun" and "Erdstall" are two different scaling solutions developed by the PolyCrypt team. As we have limited resources, we would prioritize one project over the other depending on the interest from the community.]
Perun protocol: The Perun channel protocol is an instance of a state channel protocol that results from a series of renowned research papers (EUROCRYPT, CCS, S&P). The protocol allows a fixed group of participants to open a channel between each other such that the deposited funds can then be transferred within the group with a local consensus at zero cost and nearly zero latency using off-chain transactions. The Perun protocol guarantees the security of the funds at all times. If a dispute arises (for example, one party goes offline) the protocol provides a way for honest participants to receive a payout according to the most recently agreed off-chain state.
Custom transaction logic: The Perun protocol also allows for imposing arbitrary logic on a channel so that transactions can be made even without full off-chain consensus. For example, this allows for realizing atomic off-chain swaps with complex transaction logic.
Cross-chain transactions: Due to the local consensus mechanism, the Perun protocol can be extended to supporting cross-chain channels, where the deposited assets may lie on different blockchain networks (e.g., ETH and ADA). Implementing this functionality is work in progress but we eventually plan to bring it to all supported blockchain backends.
Implementation: The Go-Perun library implements the Perun protocol in an abstract sense so that it can be used with arbitrary blockchain backends given an implementation of the corresponding backend module. We currently offer backends for Ethereum, Cosmos, and Polkadot.
Roadmap overview: In order to bring Perun channels to Cardano, several steps are necessary.
- We need to evaluate how we can integrate our Perun channel protocol and implementation with the interfaces provided by Cardano. For that we require the following:
- We need to understand how our account-based protocol translates to the eUTXO model.
- We need to be able to encode arbitrary information in the off-chain client and then decode that information in the smart contract logic.
- We need to be able to generate signatures in the off-chain client for arbitrary states, pack these signatures in the transaction data, and then verify these signatures in the smart contract on-chain.
- We implement the on-chain smart contract that handles the logic for opening, closing, and disputing a channel on-chain.
- We implement the off-chain client connector that enables the go-perun library to send transactions to the Cardano network.
Remarks on roadmap and scope: The following should be taken into account.
- Focus on simple payment functionality first: In order to keep the complexity low at the start, we plan to focus on simple payment channel functionality first, meaning we will leave the implementation of state channels with custom transaction logic to a later point in time.
- Steep learning curve expected: We are used to working in the account-based model and with imperative smart contract programming languages. Therefore, we expect a steep learning curve at the start.
Update (March 9, 2022):
- Synergies with Hydra team: We have discussed possible synergies with the Hydra team and plan to look into that further while the project is running. Potentially we can build on Hydra as a whole or reuse existing components of Hydra. We were also made aware that we might have underestimated the required effort and therefore adjusted our timeline and budget accordingly.
If the project is successful, there will be a state-channel-based scaling solution available for Cardano. State channels are particularly viable for use cases that require low latency transactions as, for example, in gaming or micropayment solutions.
Moreover, Perun channels will potentially enable cross-chain transactions in the future.
Challenge 1: Steep learning curve. We anticipate a steep learning curve and technological challenges on the way to bringing Perun channels to Cardano. So far we are used to working in the account-based model and with imperative programming languages.
Mitigation. We aim to mitigate the challenge of a steep learning curve by putting in a corresponding buffer in our project plan estimation. Furthermore, we will focus on the most simple version of Perun channels on Cardano first before aiming at implementing the full Perun feature set.
Challenge 2: Availability of Go client. Our library is written in Go and we typically rely on the availability of a Go client to send transactions to the blockchain and monitor the blockchain for corresponding events. However, such a client does not seem to be available for Cardano so far.
Mitigation. We aim for an implementation of our protocol first in a Cardano-native way using the respective native programming languages. We then may look into building an adapter between Go and the Cardano native environment.
Challenge 3: Availability of external libraries. Our smart contract logic must support some form of serialization that is also available to our off-chain client in Go. Furthermore, the smart contract must be able to verify signatures, meaning we require the availability of a signature verification function within a smart contract.
Mitigation. We will investigate the availability of libraries and ways to serialize information and verify signatures in a smart contract in the first phase of our project. In principle, we know that smart contracts on Cardano are powerful enough to provide the required functionality. However, if none of it is readily available, this may in fact put the whole project at risk.