Production Readiness of the PAB and Chain Index

I asked our CTO at Loxe the other day if he’d be willing to make a short statement on the cause of his frustration and the cause of not having fully operational on mainnet.

What came out was an article that he shared on LinkedIn.

Here’s their summary:

At Loxe Inc., we’d been waiting for the release of the PAB and the capacity to make Plutus scripts interactive and automated for some time. When the release occurred that made interactions on-chain, with real wallets, feasible, we were overjoyed. We were primarily interested in getting our scripts functioning outside the traces and testing wallets we were using.

However, we have found that creating production-ready systems with the PAB and Chain index are no small feat. Especially ones running on mainnet. We attempted to run a modularized/containerized system on kubernetes, see details below, but found the result very unstable because of the node socket communication. We found keeping the PAB container alive was impossible as it routinely ran out of memory, resynced its database, and intermittently stopped responding (see mitigating PAB memory issues with cron) .

The Chain index sync is a gargantuan task. We had been waiting for weeks for the system to sync completely with mainnet on a 6-core CPU with 32GB of RAM in the cloud. If you know something about costs, this is not a cheap instance (see cost mitigation below). The mainnet sync finally completed with an on-disk size of 215GB, much larger than the ~21GB for testnet. Be prepared.
Emurgo’s libraries are not ready to interact well with the PAB. Plutus does not interpret UTXO information formed through emurgo serialization of scripts parameterized by only data.
See article for details.

The full article goes into more detail and has links to our docker containers.
On the other hand, we developed quite quickly and launched ahead of schedule in February. But the functionality was much simpler and we worked around the non-existent PAB at that time.

This is obviously not just a Plutus topic, but more general an issue for setting up and maintaining infrastructure. The lack of tooling or faulty tooling has been an issue and it often appears that some of these “official” tooling providers are never using their own software. Otherwise they must clearly realize that their stuff is broken.

What’s been your experience? How do you navigate the frustration of wanting to create world-changing software on Cardano but you feel that the support is not all there?

And before I get a “if you don’t like it, then leave” comment (which tends to happen on twitter), I’m not blaming Emurgo, IO, or the Cardano Foundation. The failure to deliver our services on time is entirely my fault as the CEO of my company - I’m simply asking for advice here.



dear @manonthemat I appreciate reading about your experience & thanks for sharing your difficulties. I’m not involved doing an integration like that myself but I meant to look up & share these reports I read recently of companies who decided not to wait for a more efficient PAB and worked around the need for it altogether:

… we run contracts through the Command Line Interface (CLI) by signing the Cardano wallet [sic]. It is easier than using the hosted PAB with lots of problems that need to be solved. When the PABs can deploy on a remote server without a wallet, we will be able to talk about the efficient DeFi market on Cardano.

… Our main goal is to replace the currently bloated PAB setup with a leaner one of cardano-index and cardano-tx-builder.

1 Like

Thanks for sharing.