Currently we cannot have multiple smartcontractd daemon instances on the SAME contract, right?

I am researching how smartcontractd would work if I put it on the cloud to take advantage of autoscaling.

There can only be a single instance of smartcontractd handling a given smart contract right?
So no horizontal scaling on the cloud is possible with smartcontractd, right?
I thought you said somewhere that you ran some high TPS tests on smartcontractd showing it can process several thousand requests per second (or something like that).
How does smartcontractd do high TPS on a specific contract? In Serial Order, one at time, RPC style (but really fast)?

I am guessing the way to go (at the moment) is to have multiple different smart contracts up in the cloud but with only one processor instance for each contract type. That is to say, to divide the request load amongst different smart contracts rather than trying to scale up a single smart contract type.

Currently only one smart contract agent (daemon) can operate on one contract address at a time.

It can distribute a lot of the expensive functions including incoming transaction verification and outgoing transaction signing to many threads, but the actual processing of the request is synchronous since it involves modifying the state of the contract. It doesn’t currently have the ability to distribute that part, some of which is possible, just not implemented yet. When we were doing bench marking it could handle several thousand requests per second in a test environment on a PC. We have not yet been able to perform a live on chain test, but will continue to optimize and improve the software.

We have implemented distributed smart contract agents using threshold signatures for redundancy and security, but they do not provide scaling benefits yet.

Thanks for the very cool details. That gives me a good understanding for moving ahead.

The dream case in my opinion would be having a separate smart contract for each person of the population.