Gajumaru State Channels

State Channels on Gajumaru are an evolution of Aeternity State Channels. They are 1-to-1 messaging sessions anchored on-chain, supporting the following types of interaction:

Co-signed coin transfers
Deposit and withdraw coins
Loading and calling Smart Contracts
Sending plain messages

A channel, once set up, can basically be kept open forever. The participants can disconnect and later reconnect and resume the session. The channel state can be checkpointed to the chain, and eventually, when the channel is closed, the coin balances in the channel are distributed accordingly to the corresponding on-chain accounts. As each state change is co-signed, transactions on a channel are settled immediately. The on-chain protocol provides clear dispute logic for cases where the parties do not agree on the closing state. Each endpoint can monitor the chain in real-time, and detect if the opposing party tries to close the channel subversively. Third-party monitor support is also supported.

Performance

Each Gajumaru node has the capacity to act as a State Channel proxy, providing a simple JSON-RPC interface for clients. One node can service at least a thousand concurrent channels. As channels only touch the chain very rarely (when opened, closed, and if checkpointing the state), the number of state channels that can be open simultaneously basically scales linearly with the number of nodes deployed.

On one state channel session, you can roughly execute:

40 contract calls per second
500+ coin transfers per second
3000+ plain messages per second

(or a mix of the above). These are estimates based on a rudimentary benchmark suite, running on an M4 Macbook, and can be updated on request. It's important to note that these interactions come with an ordering guarantee, i.e. they are all performed sequentially. Multiple concurrent channels allow for much higher throughput when transactions can be serviced in parallel.

An intuition for the number "500+ coin transfers per second" would be that given that the test measured round-trip time for both parties of a coin transfer (2 ms), one might estimate the processing overhead of serving one side of a State Channel payment to be less than 1 ms.

For real-world business cases, one would also need to consider network transfer delays, manual signing delays, business logic overhead, etc., but the raw processing cost is an important metric when considering how much a solution can scale.

Running a small scaling benchmark, similar to the single-channel benchmark above, using 50 concurrent channels:

1,900 contract calls per second (47.5x)
3,500 coin transfers per second (6.5x)
30,400 plain messages per second (11.5x)

We have not yet spent much time optimizing this, but were able to push the benchmark to 10k concurrent channels, and the total throughput numbers remained stable. This indicates that the system is mostly free from internal bottlenecks that would degrade performance as more channels are added. However, the 10 performance cores were saturated already with 50 channels putting the pedal to the metal, so further scaling was not possible on that particular hardware. Adding more nodes, the total throughput will scale linearly, i.e. if one node can deliver a certain throughput, N nodes will deliver N times as much, at least during the time when channels do not post transactions to the chain (the whole point of State Channels is to do this as seldom as possible).

The State Channel implementation is capable of running in server mode, where the application listens on a given port and services any request that comes in. A State Channel Market demo exists, where a market provider services merchants and customers, facilitating customer-to-merchant payments atomically across channels, for a low service fee, and at a round-trip cost of ca 15 ms + network transfer delays and, as mentioned above, with immediate settlement.

In the context of Gajumaru, such a State Channel Market could allow for immediate transfer of funds between Associate Chains. In this scenario, the Market provider uses the on-chain mechanism for balancing collateral in bulk between chains.

On-chain performance

Opening a channel involves an on-chain transaction. On Aeternity, the rule of thumb was to wait for a requisite number of keyblock confirmations before funds allocated to the channel became usable. We have since implemented support for deferring funding confirmation, in order to make the channel immediately usable as soon as the opening transaction is seen on-chain. With Gajumaru's witnessing-based finality, the time to full confidence in a channel is even shorter. But since a channel can be suspended and resumed without on-chain activity, a channel often has to be set up only once, would be usable within seconds, and activated on-demand within fractions of a second.

Transaction fees

There is no mandatory fee for transactions within a State Channel, although fees could certainly be defined for a given service. The extremely low processing overhead of State Channel interactions allows for minimal to no fees.

In the case of cross-AC State Channel Markets, service fees might be higher to reflect the regulatory compliance costs of intermediating transfers between markets, as well as the market value of facilitating near-instant cross-market transactions.

Execution models

Peer-to-peer

The fundamental model for State Channels is peer-to-peer: User A and user B agree to set up a channel by posting an ChannelCreateTx transaction on-chain. In this channel, they can send each other coins, load and execute contracts, deposit to and withdraw from the channel, and snapshot current state to the chain. The channel is finally closed using (ideally) a ChannelCloseMutualTx, indicating that both agree on the final state. This model can offer the following benefits:

Aggregation, if the transaction volume is greater than 2
Instant finality, as all transactions are co-signed
In-band messaging enriches the interaction model beyond signed transactions
Privacy: transactions inside a channel are not visible - only the closing state is.

Client-to-Server

For scenarios like Scooter Rental, Casino, Coffee Shop Card, you can set up a server listening on some port, and servicing client state channels. The establishment provides business logic on the server side, and the State Channel framework provides support for spawning multiple acceptors on a single port, very similarly to how e.g. a web server works. Clients can disconnect and reconnect to the same channel at any time. Each session is private and encrypted.

Planned extensions

Work is underway to provide native multi-currency support on Associate Chains. This will also be reflected in State Channels, such that they will support efficient transfers of different currencies.

Use cases

Instant payment along the lines of Swish (Scandinavia) or Venmo are clear use cases. Larger events, transportation, etc.
A generalized version of 'loyalty cards', like e.g. coffee shop cards.
Open tab at bars and restaurants. Customers can pay as they order by scanning a QR code. The owner is protected from walkouts, as they can unilaterally close the tab and get paid. Smart Contracts can offer mutual protection, with pre-pay locked into the contract until the food/beer is served.
Micro-paywalls, e.g. paying for the next page of text.
Pay-as-you-go AI bot interaction.
Pay-as-you-go media streaming. The in-band plain message support can be used to prompt users when it's nearing time to top up.
"Follow-the-money" social media content promotion, where State Channels can be used to widgetize a monetary tip rather than just a 'like' (which costs nothing, and therefore is easily gamed.)

For practical widgetization, we have added support for adding a proxy keypair for automatic signing. This could be used e.g. such that the user application pre-approves a certain number of transactions below a certain threshold, which can all be automatically signed before a manual signature is requested to approve the next batch. This is fully under the user's control, and risk is also limited further through the amount of money the user decides to deposit into the channel.

Implementation status

End-to-end demonstrations of practical State Channel use cases, including State Channel Markets, are planned during the Spring or early Summer after Mainnet Launch. Partly dependent on funding. Basic support for Gajumaru's State Channel design was in place already in 2019, as exemplified by CoinFabrik building a merchant demo system. The demo inspired several performance and robustness improvements of the code base.