Author Topic: [Worker Proposal] JavaScript: Atomic Cross-Chain Swaps Framework  (Read 6348 times)

0 Members and 1 Guest are viewing this topic.

Offline benniehag

  • Newbie
  • *
  • Posts: 10
    • View Profile
ok.. i get the finger thing and the cyborg thing, but i have 4 fingers and a thumb just like every body ..well most people... right?

Offline matle85

  • Full Member
  • ***
  • Posts: 148
    • View Profile
I like the idea of easy movement between the chains. Id like to see confirmation it will be built for easy deployment on Bitshares based exchanges and that it will cover all Bitshares assets / ERC20 tokens.

It'd also be good to get the view from some of our CEXs about whether this would be useful / beneficial in their view (George, Ronny etc). It feels a bit odd funding a business sat on another chain I guess is also part of my hesitation...maybe that's a bit close minded though as it is a function that is all about being cross chain.

Kong's point (and Jonathan's by proxy) is a good one - what business will this add? My initial view is it would be a good addition bit I don't have much basis for that.

I don't know enough about the man hours required to comment on the estimated budget. We've been talking a lot about cross chain swaps the last few months...how much of an add on is this compared to what we will have?

Also, and this is sincerely meant as no criticism to the original posters as I'm not that clued up on ethereum projects, but have people used Everbloom? Is it good and is it popular? I couldn't see any data about it on Alexa or CMC.
« Last Edit: April 19, 2019, 10:57:42 pm by matle85 »

Offline Crypto Kong

  • Full Member
  • ***
  • Posts: 109
    • View Profile
Could you explain exactly how you will use this on your exchange and the estimated demand for the service provided etc. This way we can get an idea of initial usage, I'm all up for adding features to BitShares but a certain amount of research needs to be carried out so we aren't paying for features that will never be used. Thanks.

Offline AndrewEverbloom

  • Newbie
  • *
  • Posts: 3
    • View Profile
Thanks for the feedback so far from everyone. I can clarify a few things regarding goals and budget.

I should clarify that we are writing a front-end and library to make ACCS simpler for everyone to adopt. The front-end will be usable by your average crypto user to perform actual atomic swaps. Since it will be open source, it can be used as a reference implementation by anyone else to incorporate it into their own projects. The library/framework will provide the core building blocks. It will create and broadcast initial ACCS setup, monitor the blockchains for intermediary steps, and finalize the swaps, without requiring the implementer of any project on top to handle all of the details.

Regarding the budget, we are providing at-cost hourly rates ($75/hour instead of a more typical $125 for our engineers and those quoted in other worker proposals). This is because we believe this effort can benefit everyone. In terms of the amount of hours, we are only asking for a budget and don't expect the entire budget to be consumed. We can check in regularly with the community to see how we are progressing on hourly consumption and budget.

Offline AndrewEverbloom

  • Newbie
  • *
  • Posts: 3
    • View Profile
Quote
1. Create Wireframes for Demo Application (10%, 160 hours)

2. Architect the Demo Application (10%, 160 hours)

3. Implement Demo Application MVP on Testnet (40%, 640 hours)

4. Extract Framework from Demo Application (25%, 400 hours)

This seems kind of backwards to me. I'd expect that you architect a framework, maybe create wireframes in parallel, match both together (which is a good reality check for both frontend and backend), then implement demo application on top of framework. This approach would also cut down the cost significantly, IMO.

Excellent point and one that @fox and I discussed at length. We ultimately thought it would better to implement a working ACCS swap demo application or MVP (Minimum Viable Product) first to really work out all of the issues that are likely to crop up as we uncover edge cases. After having gone through this experience, we will be much better equipped to make a well designed framework. Thoughts?

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Quote
1. Create Wireframes for Demo Application (10%, 160 hours)

2. Architect the Demo Application (10%, 160 hours)

3. Implement Demo Application MVP on Testnet (40%, 640 hours)

4. Extract Framework from Demo Application (25%, 400 hours)

This seems kind of backwards to me. I'd expect that you architect a framework, maybe create wireframes in parallel, match both together (which is a good reality check for both frontend and backend), then implement demo application on top of framework. This approach would also cut down the cost significantly, IMO.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline clockwork

  • Committee member
  • Sr. Member
  • *
  • Posts: 376
    • View Profile
  • BitShares: clockwork
Although I like the concept, I can't get past the fact it seems excessively expensive to me.

I will not be supporting this at this cost.

Disclaimer: Multi-chain HTLC support is also planned for Beet so we have done a fair amount of research about a wizard-style implementation. Hence I have a rough idea of the work required.

Offline freedom168

  • Newbie
  • *
  • Posts: 2
    • View Profile
I don't think the WP is necessary.
1. HTLC support is implemented by the own bitshares-ui team. There is no need to open a new proposal separately.
2. Even a single proposal should not exceed 400 hours of work.
3. Even if you do not consider the above two points, this framework should support more chains, such as BTC. As a framework, you should also support more development languages. Such as c++, java and so on.


Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
+5%
What I like most here is that it closes the gab between BitShares and Ethereum (potentially other chains).

For those that don't know, HTLC can be used for interledger.org and this worker proposal proposes to build a 2 party scenario for Ethereum!

Offline AndrewEverbloom

  • Newbie
  • *
  • Posts: 3
    • View Profile

Hello BitShares Community,

My name is Andrew, and I am one of the cofounders of Everbloom. On behalf of the team at Everbloom, I would like to submit a proposal for an Atomic Cross-Chain Swap (ACCS) Framework and Front-end in collaboration with the BitShares community.

Everbloom brings experience from the Ethereum ecosystem. We built an Ethereum-based decentralized exchange (overview of the Everbloom Exchange on Youtube). With this experience, we can deploy an HTLC smart contract on the Ethereum blockchain and ensure successful integration between BitShares and Ethereum.

Proposal

The entire proposal can be found at Atomic Cross-Chain Swaps Framework. I have included a smaller version of the full proposal in the remainder of this post. We are seeking questions and feedback before we submit the proposal for voting.

Background

With BSIP44, Hashed Time-Locked Contracts (HTLC) will become available on the BitShares Blockchain. An HTLC is a conditional transfer where an encumbrance must be remedied to complete successfully. The BitShares Hashed Time-Locked Contract implementation permits a designated party “recipient” to receive funds by disclosing the pre-image of a hash (think: a password to claim a deposit) prior to an expiration timeout. It also permits the initiating party “sender” to receive their deposited funds back if the timeout is reached, in a refund situation.

This allows two parties to exchange tokens on independent platforms trustlessly and securely and thus enables Atomic Cross-Chain Swaps (ACCS).

This worker proposal intends to develop a JavaScript framework on top of Bitshares HTLCs to enable ACCS with Ethereum ERC-20 compatible tokens and allow easy integration into existing front-ends (such as the reference bitshares-ui). We will also create a demo application and documentation to demonstrate the framework in action.

We are convinced that the proposed framework for ACCS can reshape the entire exchange landscape once it is easy to use for customers. Given that we operate Everbloom, an exchange based on top of Ethereum, we have the expertise to completely deliver on this proposal in collaboration with the BitShares contributors.

As we believe in the spirit of Open Source, and because we want a tight integration into bitshares-ui, we chose to engage the BitShares community to support the development of an open source library for ACCS. If this proposal is accepted by the community, we see a win-win scenario, where we can make use of the framework to increase our customer base and BitShares benefits from a tight integration into Ethereum and Everbloom.

Deliverables

The goal of this worker proposal is to develop an open source framework for ACCS that is capable of integrating with multiple blockchains and initially provides adapters for ACCS operations across at least two blockchains (BitShares and Ethereum). The framework should be architected with usability and security in mind and the architecture should allow adding other blockchains to it with little effort.

The final delivery will constitute:

  • Javascript Framework: The Javascript framework will integrate with the BitShares and the Ethereum Blockchain to allow ACCS. The goals of this library is to simplify and mostly automate ACCS and allow easy integration into existing applications and libraries. It will create and broadcast initial ACCS setup, monitor the blockchains for intermediary steps and finalize the swaps accordingly.
  • Unit & Integration Tests: Unit tests are used to ensure that individual parts of the software behave as specified. Integration tests will ensure that these parts work together properly.
  • Specifications and Documentation: The specifications will give a concise picture about the system architecture while documentation will provide implementation details.
  • Front-end and Demo Application to facilitate ACCS: A separate front-end application is implemented that connects corresponding testnets and allows ACCS across them. The purpose of the front-end, on the one hand, is that it shows to the end-user how it works while not risking any funds. On the other hand, it presents integration details to developers that seek to integrate the library with their own platform.

Atomic Cross Chain Swap Workflow

For further clarity, let's outline the workflow of a successful atomic swap. The Front-end will implement this workflow.

Alice and Bob want to swap two assets on different blockchains. Alice has BTS, Bob has ETH, but they both want what the other has. A successful process looks as follows:

  • Setup Phase: before creating any HTLCs, Alice and Bob needs to first agree on parameters.
    • How many BTS and ETH they intend to swap; their exchange rate.
    • How long should the time-lock on the HTLC be active?
    • Alice’s receiving account on Ethereum.
    • Bob’s receiving account on BitShares.
    • Who will generate the secret (the “Pre-Image”) and the hash of the secret (the “Hash”). For the sake of this example, Alice will chose the Pre-Image and be the Hash creator.

  • Creation Phase: having agreed on the parameters, Alice and Bob create the HTLCs.
    • Alice creates an HTLC on Bitshares with the receiver as Bob. BTS is locked into the BitShares HTLC. She shares the location of the BitShares HTLC with Bob. By doing so, she implicitly shares the Hash with Bob.
    • Bob waits for the HTLC to confirm on the BitShares blockchain and validates all parameters, including but not limited to, that he is the receiver, that the amount is appropriate, and the HTLC hash-lock matches the agreed upon Hash.
    • Bob creates an HTLC on Ethereum with the receiver as Alice. ETH is locked in the Ethereum HTLC.
    • Alice waits for the HTLC to confirm on the Ethereum blockchain and validates that she is the receiver and the HTLC hash-lock matches the agreed upon Hash.

  • Redemption Phase: with the HTLCs created on both blockchains, Alice and Bob can now proceed to redeeming their new coins.
    • Alice redeems the ETH on Ethereum by redeeming the HTLC by submitting the Pre-Image in a transaction. In doing so, she exposes the Pre-Image.
    • Bob waits for Alice to expose the Pre-Image, and then Bob redeems the HTLC on BitShares using the same Pre-Image.

  • Complete: Everyone is now done.

The following diagram illustrates the ACCS Workflow:


Milestones

These milestones serve as information to the BTS voters that evaluate this worker proposal. The milestones are used by the escrow to judge proper delivery. Any and all development will be done in public repositories.

The milestones are given in order of completion with an estimated hours of work involved for each milestone.

  • Create Wireframes for Front-end Application (10%, 160 hours)
    • Wireframes should illustrate the Front-end Application Workflow as described in a section above.

  • Architect the Front-end Application (10%, 160 hours)
    • Define the structure of the Front-end Application beyond the UI. The architecture should provide for communication across clients to facilitate the sharing of ACCS information necessary to perform a complete swap.

  • Implement Front-end Application MVP on Testnet (40%, 640 hours)
    • Given the Wireframes and Architecture, implement a complete Front-end Application.

  • Extract Framework from Front-end Application (25%, 400 hours)
    • Implement Framework in Javascript
    • Integration for the BitShares Blockchain
    • Integration for the Ethereum Blockchain
    • Unit Tests Proper documentation of the entire flow and the interface (15%, 240 hours)

  • Documentation (15%, 240 hours)
    • Proper documentation of the entire flow and the interface.

Timeline

The total estimated hours of effort is 1600 hours. Everbloom intends to put two developers working 40 hours per week onto the project. This results in a five month completion time as shown in the following math:

1600 hours / 2 devs / 40 hours per week / 4 weeks per month = 5 months

Requested Funding

1600 hours * $75 per developer hour = (up to) $120,000 USD

About Everbloom

Everbloom is a venture-backed, decentralized cryptocurrency exchange that has raised $2M in capital to build an enterprise-grade trading marketplace for institutional investors. The Everbloom Exchange supports the trading of digital assets built on top of the Ethereum blockchain. The company is headquartered in Boston, MA, USA. Everbloom was recently covered by CoinDesk.

We also had the good fortune of being included on the DEX panel at Bitfest 2018, the BitShares community conference. Here is a picture of the DEX panel at Bitfest.

ACCS are an important technology for the continued adoption of cryptocurrencies and blockchains. We believe a collaboration with BitShares is a great way to elevate ACCS beyond simple command-line demos and toward easy-to-use user interfaces and reference implementations.

Questions or Comments?

Please let us know if you have any questions or comments on this proposal. The Everbloom team will be here to respond.

Thanks for reading, and we hope to work with the community to bring cross-chain swaps to BitShares!


« Last Edit: March 01, 2019, 12:10:02 am by AndrewEverbloom »