Payment Channel Integration on Aeternity Lab (WIP)

Hi Guys,

So my brother @vishwas_hypermine he has been able to decipher through all the docs on State Channel (Kudos to AETERNITY core dev’s for the help) and create this simple to understand Developer tutorial.

The code will be open source on the github which anyone can see it . This is just a Demo version and it does not tell to be used in Production

Please have a look on the video


Hey @Vikram and @vishwas_hypermine great work! Now you can transfer value on the blockchain off-chain :smiley: I am really happy about your progress, looking forward for the repo in GitHub.



Very nice demo! Kudos

1 Like

Waoo thats sweet stuff. Keep up the great work!

1 Like

Good Job!!! I’m pending of the repo, regards!


This is dooooopeeeeeeeee!!! Massive kudos for you @Vikram and @vishwas_hypermine!! Congratulations! :heart_eyes:

1 Like


It all started with a Explainer Video you had posted on youtube.

We did this Ae - Laboratory inorder to understand it correctly as we are going to use it in our own project. Hypersign

For enterprise Identity systems its important that the project should scale.

So this will be bring massive difference on performance of any idenitity system built on top of blockchain (UPort, OrId etc)


Out of curiosity: what kind of numbers of channels per node are you imagining?

We have done some preparatory work on supporting more serious scalability tests, but so far, we haven’t really seen any users pushing the limits. Personally, I’ve created 1000 channels on one node running on my own laptop, with no visible problems.

This is not to say that there won’t be challenges, esp if channel setup requests, failures, reestablish etc. come in bursts. There always tends to be some breakage when you get into such territory.

We could also work on setting up more realistic throughput tests with large numbers of active channels. Again, it would help if we could get some tangible requirements from users.


@vishwas_hypermine Can you please give some input here.

Perhaps we can collectively figure out .

My 2 cent’s is If we are looking for a payment channel for API provider then, we need to look at what are the software Hypersign helps to integrate in an Enterprise .

A minimum of Active Directory/AWS IAM and Slack (Chat) . every enterprise will have .
Depending on number of employees in a Enterprise which is nearly 5k to 15k (Our target market).
we should make some assumption

@uwiger perhaps you can help us

Hi @uwiger we do not really have any tangible requirement. We are definitively looking for more channels, but for now our main metric would be “rate of transactions per channel” I am looking for high throughput per channel. The use case which we are considering is Pay per api call where a service provider provides a service (lets say a calculator service) and a consumer consumes it. Whenever a consumer consumes each api call, he has to pay. Now you can clearly see there is a need of high throughtput in this case. If I have to put some figure to start with then I would say atleast 1k transactions per sec on hardware of t2.medium with 8Gigs.

With my primary observation the number is very less close to 1-2tx per sec which we have to improve. (Again I am not confident in speaking this number for now.) Take a look at this demo.


If you are looking for throughput up towards 1k tx/s on a single channel, you will probably have to consider some sort of bulk payment approach, in order of increasing speed.

There are currently basically three different interaction models in the channel:

  1. contract calls
  2. payment transfer (optionally with annotations)
  3. generic messages

Contract calls are the slowest (we don’t actually have a comparative test case for them in the test suite), and generic messages are roughly 10x faster than payment transfers. The main difference lies in the signing: payments (and contract calls) must be mutually signed, whereas generic messages don’t.

Now, the way the test suite benchmark tests are set up, the signing clients run on the same machine as the two FSMs, so in terms of CPU cost, it’s not an entirely realistic setup. OTOH, when you spread them apart, you are likely to get more latency, which will affect single-channel throughput (since txs are serialized).

Given the amount of checking that goes on in order to cover all eventualities for contract calls, I don’t think it will be possible to increase throughput by two orders of magnitude. Right now, the best bet would be to employ a mix of all three interaction types.

  • Was not looking at contract call and was only working on the ‘Payment channel’ part and not on ‘state channel’ since I could not figure out if there is any requirement of smart contract in our use case.
  • The generic message does not makes sense because the whole purpose is of mutual agreement.
  • Now I am left with payment transfer, I guess batching seems to be reasonable option here.

Having said that I have couple of questions/ clarification/ doubts here:

As per my understanding in the minimal setup of channel use case, we have 3 entities:

  • Client 1- The initiator [A Websocket server]
  • Client 2- The responder [A Websocket server]
  • Aeternity blockchain node [A Websocket server ]
    When we setup the a channel, Client1 connect to Aeternity node and then waits for Client2 to connect with Aeternity (the accepts phase). Once Cilent2 connects, the channel is created and separate FSMIds are maintained on the Aeternity node. So at this point of time, they all three forms a network on web sockets some thing like this:

  • Now once the channel is setup, Client1 and Client2 can go ahead and do ping-pong to pay each other offline. My first question is, when they update the state offchian, does it happens peer-to-peer between client1 and client2 or Ae-node is also involved in this communication (may be for maintaining the state of rounds so that double spending could be prevented)?
  • The second question which I have is, when client1 connects with ae-node at the time of creation of channel, (as per my knowledge) the client2 has to get notified out side the protocol. Is it possible to send notification to client2 from Ae-node itself? like if there is any callback or event which can help here?

The clients both connect to some ae node (need not be the same one), and are paired with an FSM each. The FSMs then connect to each other via a noise-encrypted TCP connection.

Thus, the communication path for all messages is
Client <-> [WebSocket] <-> FSM <-> [noise] <-> FSM -> [WebSocket] <-> Client

The ae node(s) will then be involved in all exchanges - even generic messages. A particular point of this is that all messages travel along the same path, preserving message ordering.

You could establish a credit buffer through mutual consent (contract call or upd_transfer), and then have a message volley using generic messages, where the credit is consumed. Messages could refer to the offchain state hash stipulating the agreement. This would be a slight dilution of trust, but for applications that e.g. want to handle pay-per-content, where the content serving is of a higher frequency than what’s possible with mutually-signed transactions, it might be an acceptable compromise.


Contract calls are the slowest (we don’t actually have a comparative test case for them in the test suite) …

Now, we do (at least in an open PR). Calling one of the simplest contracts imaginable (a counter), the contract call bench test is ca 40% slower than the upd_transfer bench. On my humble laptop, this means that the test setup can do ca 50 tps on up_transfer (10 concurrent channels), and 36 tps for contract calls.

A thing to keep in mind is that the test runs everything on the same machine. This will tend to underestimate communication overhead but also includes the client-side cost for signing the transactions. They should give a rough idea of the order-of-magnitude performance, though.

(The humble laptop in question is a Huawei Matebook X Pro with 16 GB RAM, and a ton of browser windows open in the background.)



@uwiger I am planning to perform some tests starting from upd_transfer using some better performance tool , may be Jmeter from my use case. You remember, I had coded the throttle tool to automate the api calls? I am not confident on that tool so I am pplanning to use some better test tool to test the performance.

What would be your suggestion in this case and what all metrics should keep in mind while performing the tests. My plan is to test on t2.medium machine.

Also, once I am done with upd_transfer perf test, I will switch to generic message and test the performance.

It could be interesting to chart the effect of different communication setups. Also, we’ve seen that communication costs within an Amazon region are much lower than when going across regions. So …

  • Both FSMs on the same ae node
  • FSMs on different ae nodes, within the same region
  • nodes in different regions
  • Client and FSM on same host / in same region / different regions

This might give some hint regarding how best to set up a network for state channels. Is it better to go for proximity in the WebSocket interface or the noise interface?

1 Like