Goals for payments on backend side

Althea L1 Development
1

Hey guys,

I’m sorry for putting it in this section but I believe its the right place. I’d like to start a discussion about our goals for payments on the backend side and get everyone on the same page from backend to frontend. I believe it is a good time to discuss it as Clarity can make payments already, and guac (and its rita integration) wasn’t touched in a while.

I’m also missing some context as I’m relatively new to the team. For last couple of days I was consumed by implementing clarity so I apologise if I forgot about some facts.

I’ll also make separate topic with proposal for agenda for next dev meeting to brainstorm things we don’t know yet.

Current status

  • Clarity 0.1.1 is released and is compliant with official ETH test suite for Transactions (all ~198 tests are passing), it was also verified on Ropsten testnet, and on ganache (at the time of writing I have another PR that does automatic payments verification on ganache testnet). This means that we can make ETH transactions on the backend even on MIPS and big endian systems.
  • We have contract developed and it could be integrated for DAO payments (@Sebohe correct me if I’m wrong). This process could be done manually as well before integrating it into the stack. We have a piece of code on Rita that already checks the membership.
  • Frontend is ready to do this.
  • Debt tracking works well and we should be able to at least allow simple payments between clients
  • DAO calls are done already on Rita side to verify if an address is in the list or not.

Use cases

I can think of one important use case right now for Guac that is not yet finished:

  • Alice wants to pay Bob for the traffic she used.

Goals

Payments

To my knowledge this is currently missing and we need to implement it as a new feature.

  • Alice wants to pay Bob for the traffic she used
  • Amount of Wei is calculated that has to be transferred from Alice to Bob given the parameters of the mesh.
  • Alice clicks a button “Pay debts” (This can be triggered manually, button seems safe choice at the beginning)
  • A transaction is broadcasted to the network (Frontend could display a message “Do you really want to transfer XXX ETH to Bob?”)
  • After few moments Alice and Bob balance is updated with a message that the payment went through
  • Debt keeper resets the counter.

The last part is very important - we need a way to know that the transaction is confirmed. I can imagine querying the network with TX hash and checking amount of confirmations.
On the other hand we want to use ETH payment channels which I believe is important distinction.

Guac

I’d keep Guac’s purpose to focus only on being a “Payment Controller” i.e. expose an API to make transactions with an ability to know if a transaction is confirmed, or not. I believe it was the original goal.

I believe that even though guac contains a lot of logic for payment channels and non trivial amount of tests it still contains gaps in functionality we really need to get payments going. For example: how do we know if the transaction was successful?

2

So there’s some nuance there, we have DAO code but bandwidth payments require the channel contract which is dependent on getting it from the Connext people @Jehan where is that right now?

Good for the very first iteration but we need to automate quickly. That being said if we’re on the testnet do we care if we send bs?

Validating transactions on payment channels is a little easier, you should keep track of the channel state and then the channel partner hands you a signed state update to store. If you fire off a timer and check that the state update you sent is now the latest and signed by your peer then you should be good to check if things succeeded.

3

This can be implemented by making debtkeeper not sending guac any make payment requests until it has recieved a special SendPayment message or soemthing

Guac’s original goal was to basically expose an api of “pay someone”, but instead of using eth transactions it would use payment channels.

Right now we have a state machine which contains special states for pending transactions (which resolve immediately right now). In the future, we would hook it up such that these transitions only happen when a transaction is confirmed

4

@michal We should definitely talk about this. Payments are not done by broadcasting transactions to the network. The only time transactions are broadcast are when opening a channel. Payments will happen automatically every few seconds and only go between Alice and Bob until it is time to close the channel.

5

@michal you can start by reading this: Althea L1

and

https://medium.com/connext/state-channels-for-babies-c39a8001d9af

I didn’t invent payment channels, many groups are working on them and there are many variations.

6

Thanks, that explains at least one part of payments.

I should at least try to set up that contract and get myself familiarised with it before discussing it on Monday.

7

BTW while searching for the contract source code I realised its 404 now and the guy behind it tries to sell a service based on it

https://github.com/ConnextProject/ethcalate-bidirectional-erc20 404 (I believe its the original repo)

The service which I believe is based on the contract code http://ethcalate.network.

Is anyone by a chance in possession of that source code?

Edit: And can we fork it?

8
9

After 24th Sept meeting a lot of things become clearer.

Contract

  • We’ll contact the authors regarding the license and confirm if we can continue to use the forked version. Otherwise we can implement our own payment channels contract.
  • We need to make it actually compile. https://github.com/althea-mesh/simple-bidirectional-erc20-channel/issues/2 (Interestingly the code is ~5months old and it already fails to build)
  • There is no immediate action to deploy the contract on a testnet, we should do our best to write tests for the contract within the contracts repo, or locally with ganache.
  • Deployment of the contract would be a requirement while integrating guac and rita.
  • For testing guac we don’t need to run the contract as well - we should be able to mock out contract calls for testing guac. https://github.com/althea-mesh/guac_rs/issues/12
  • As for guac configuration side we should be able to somehow update the contract address after the initial deployment, but this is something we have time to figure out.

Guac

  • It will be kept as “payment library”
  • It should support payment channels smart contract together with handling its states
  • While opening channels we dont want to do anything automatically for the users, eventually a configured amount of ETH can be deposited.
  • We should be able to detect case when we run out of funds https://github.com/althea-mesh/guac_rs/issues/13
  • Additional API for the user to be able to withdraw funds from his hot wallet on the router (for example when user wants to withdraw funds he earned). https://github.com/althea-mesh/guac_rs/issues/14

Bounty hunter

Bounty hunter is a 3rd party to help deal with malicious parties. BT will be designed to receive signed updates for channel updates, and keep track of their states.

Plans

Dev plans for following days regarding payments:

10

I know I’ve asked you this before but I don’t remember the answer, why not just use Ethabi and would using it shave any time off versus writing our own implementation.