Limit of on-ledger computation

Is there guidance (from DA product) on appropriate limits for on ledger Daml computations? I’m thinking about almost completely pure computation? For example, the input is the payload of the template, payload of the choice and no create, no exercise or other Update calls.

My general thoughts on the matter is that one should reserve on ledger computation for things that require authorized oversight, and I tend to use the common NP class description. So for example, one can use the ledger to verify a SAT solution but not to find it, or one can use it to verify that a traveling plan is within a budget limit, but not to find a suitable solution.

That’s not a bad way of thinking about it. The value of smart contract code is that it’s verified by all involved parties. There are cases like the one you mentioned where construction of a solution and verification of that solution have vastly different complexities, in which case I’d only put the verification in the smart contract.

But there are also cases where the two are one and the same - eg standard option pricing. If you wanted to create a contract that acts as an options vending machine, it would make perfect sense to put the pricing calculation on ledger. The pricing calculation is an integral part of the rules of the contract.

The above considerations are about what calculations are worth having on the ledger. The other consideration is what impact calculations on the ledger has on system performance. The smart contract code is executed on every node that observes the exercise node where that code sits. Those calculations will compete directly with all the other transaction processing. Ie if you have a calculation that takes 100ms, and you run 16 CPU participants, you can put a ceiling of 160 ledger events/s. You can compensate with more CPUs, but scaling this to high performance is going to be much harder than running the computations off-ledger.

bernhard:

But there are also cases where the two are one and the same - eg standard option pricing. If you wanted to create a contract that acts as an options vending machine, it would make perfect sense to put the pricing calculation on ledger. The pricing calculation is an integral part of the rules of the contract.

This is a good case to dig deeper on. If there’s a standard formula like Black Scholes and the input is vol, strike, expiration and interest rate then a price is straight forward. But when you introduce volatility smiles and solving for arbitrage free pricing, every bank “on-the-street” does it differently; I don’t think that you want that on the ledger. A request-response pattern seems more appropriate to me.

I completely agree. For a normal bid/ask market, you don’t put your pricing algorithms into the smart contracts. They are your decision making engine. Decisions happen off-ledger.