[bisq-network/proposals] Investigate alternative implementation for bisq (as basis for V2 / off-chain trading) (#125)

Fri Oct 4 07:59:47 UTC 2019

> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

# Suggestion

I would like to put forward the possibility of implementing Bisq v2 from scratch in a different language.

## Major Triggers

The following major issues triggered me to even consider this:
- A major feature of the [Bisq V2](https://github.com/bisq-network/proposals/issues/118) proposal is the [off-chain trade protocol](https://github.com/bisq-network/proposals/issues/32). It is very likely that off-chain trading will not be backwards compatible. Large parts of the code base will require re-implementing and there will be a hard-fork of the trade protocol. Of the code that doesn't require completely re-writting there will also have to be changes further reducing the amount of code that will be uneffected.
- The current state of the code base has a lot of technical debt. Lots of the code is hard to understand and could benefit from refactoring. But it is unlikely that this will occur because almost no one is able to review significant changes, especially to the most critical code. Due to the amount of internal coupling almost every change has the potential to effect something critical.
- The most important dependency of bisq (BitcoinJ) is unmaintained and untrustworthy. There is no alternative in the JVM ecosystem.

There are many other minor things that led me to consider this but they are dwarfed by the above mentioned major ones.

## Feasibility

Since a rewrite in a different language is a major undertaking that shouldn't be taken on lightly (even with the presence of the major triggers) much more information is required to analyse the trade-offs. For this purpose I have done a feasibility study to shed some light on the following questions:

- is an alternative implementation that is compatible with the live p2p network possible (ie. can java <-> rust processes communicate correctly via the protobuf based protocol)?
- are there any significant technical advantages that can be gained from taking this approach (eg. less overall complexity, less risky dependencies, better dev workflow etc.)?
- how high would the remaining effort be to achieve production rediness with an alternative implementation?
- does it make sense as a strategic approach to write V2 from scratch vs adapt the existing code?

You can find the code for the proof-of-concept of re-implementing bisq in rust here: https://github.com/bodymindarts/risq

## POC findings

As a result of the proof-of-concept I have come to the conclusion that there are indeed many potential benefits by re-implementing bisq in rust (as part of V2). Enough that it is worth putting forward this proposal for serious consideration.

- Backwards compatibility on the p2p layer is no problem (trade layer would be a hard fork anyway).
- Significant reduction of overall complexity and LOC (imo at least 50% less code) is realistic.
- better dev-workflow (ie. rust eco-system is much more dev-friendly. It is less verbose has faster build times and more powerful type system that reduces the potential for errors).
- api/cli-first implementation opens up potential for many extensions/integrations. Integrating an API into the current Bisq code base is a significant challenge. This should be a consideration from day 1.
- There is strong support for rust based implementations in the bitcoin eco system maintained by respectable devs with long track-records.
- (...)

## Next steps

With more information regarding feasibility available due to the proof-of-concept I believe an informed public discussion is now possible. Obviously how to move forward will depend a lot on the outcome of this discussion so the next steps I am laying out are not to be taken as recommendation. Rather a starting point for consideration.

To move forward with the (hypothetical) project Bisq V2 in rust (pending community discussions) the following steps would likely need to occur:
- consider wether the project could be a candidate for inclusion in the [incubator-space](https://github.com/bisq-network/proposals/issues/122)
- consider wether delivery would be stand-alone (a completely new app with download etc) or integrated into the current artifact.
- consider the boundries in terms of functionality for the new and legacy implementation. The most critical part of the existing code is the DAO. Perhaps the existing code could be stripped down to a kind of bisq-governance app (rather than risking an issue during re-implementation) in order to keep Bisq V2 focused on the off-chain trading (since that is the part that needs re-writting anyway).
- lots of other stuff that will hopefully emerge from the following discussion

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/125
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191004/d5f67eab/attachment-0001.html>