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:
- contract calls
- payment transfer (optionally with annotations)
- 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.