How do Contracts as a Service help Cardano?
We will offer a hosted Plutus service that allows users to run Contracts as a Service that leverage a shared off-chain infrastructure as a foundation for lightweight contract containers. Providing long running, resource intensive Alonzo Nodes and Chain Indexes for both mainnet and testnet as shared services to isolated lightweight containers means that users only need to spin up a Plutus Application Backend (and Wallet, as required) in their container to host off-chain code.
We propose:
- Sourcing of bare metal hosting services.
- Installation and configuration of a high performance and high availability LXD service.
- Creation of node-version / PAB-version matched containers with access to necessary dependencies and services to support CaaS.
- Design and development of a sparse user interface for users to create accounts, manage containers, and pay for services.
- Design and development of automated bridge between UI and CaaS host(s) for creation, management, and disposal of containers.
- Design and implementation of a scalable and secure network that will support containers that each require public exposure of several interfaces, as well as ssh/sftp access to access container.
- Performance testing with representative contract workloads to understand container density best practices.
- Security audit (third party TBD).
- (stretch goal) Allow container-to-container contract migration within a single tenancy so testnet contracts can be simply migrated to mainnet after testing.
- (stretch goal) Creation of a sparse JSON API that may be accessed with an API key that will offer the ability for tenants to remotely automate CaaS.
- We will deploy and maintain the infrastructure for the service.
- We will not charge for testnet contract containers.
- We will charge for mainnet contract containers as a base-plus metered service.
- We will charge for backup and recovery services as well as automation features.
- (future) Offer contract service monitoring for persistent contracts: ex. address monitoring, auction services, REST-like NFT generation.
- (future) Offer contract service scheduling for intermittent contracts: ex. structured payments, vesting, beacon-triggered events such as dead man switches.
- (future) Offer a “staking for services” option that allows users to direct staking rewards (from partner pools that implement the feature) to our operational fund to offset contract hosting fees.
- (future) We may operate a <u>cooperative</u> stake pool wherein only CaaS tenants may stake, and staking rewards are used to offset operational costs (and thus CaaS fees); if rewards exceed costs, tenants would receive a rebate in proportion to their stake. We <u>will not</u> operate a stake pool for profit.
How are we helping meet Fund 8 Goals for Ecosystem Foundations and Development of dApps and Integrations?
Developing with Plutus and Plutus Application Backend requires a setup and configuration process that (currently) will slow developer adoption of Cardano. Participants in the Plutus Pioneers Program Cohort 3 reported experiences and problems (via Discord, StackExchange, and weekly course Q&A) that ranged from many hours to days to start the course, and similar durations later in the course when a full node for either CLI-based or PAB-based transactions were required for coursework. Further, deployment as a dApp provider requires hosting the same resource intensive stack, which puts grassroots startup beyond the reach of many prospective developers.
Our service can be used as either a PAB Helper endpoint, or as a full node as described in the PAB documentation.
This service, as indicated in attached illustrations, will help bridge a technology gap until “light” PAB is available for in-browser and in-app use, and prior to that, until a remote wallet is able to (natively) balance transactions.
Until browser wallets can support transaction balancing natively, dApps must rely on hosted wallets and hosted PAB (or CLI) to complete transactions. Transactions may be manually balanced on the client side, but the process is complex and potentially error prone.
Since we may assume that most developers will not also be stake pool operators with ready access to fully synchronized nodes, we can further surmise that simple, low-cost contract hosting will be desirable for:
- those that wish to try the PAB without substantial commitment of time or resources;
- participants in coursework (such as the Plutus Pioneer Program) that are able to follow lectures and examples on a tablet or chromebook, but need a place to compile and test;
- anyone who wishes to have a specific and stable version of the PAB with long term support; and
- developers who wish to test migrations of contracts between versions of the PAB or versions of nodes.
How will this service be used by the community?
PAB documentation offers three use cases for PAB, and we have added a fourth for educational use.
- Hosted PAB with Wallet Backend – As indicated in documentation this configuration is officially supported but is not recommended for deployment, ostensibly due to wallet custody concerns. However, for cases where the wallet owner is the dApp provider that generates and sends (ADA or tokens), and/or receives transactions validated elsewhere, this is a valid use case.
- PAB Helper – Under development. This is the most likely transition pattern for dApps toward Light PAB. Nami demo.
- Light PAB – Not yet supported, but on roadmap. This will likely be the dominant dApp pattern once Light PAB is available.
- Hobby and Education
Please see attached diagrams for variations of those four use cases as adapted for a container / shared infrastructure implementation pattern we propose.
Assumptions:
- Our containers will be pre-loaded with Haskell, Cabal, plutus-apps, and nix-shell appropriate for version of Node and PAB supplied in container.
- nix-build / cabal build (as appropriate) will already have been executed for plutus-apps and nix-shell will execute PAB and Wallet without additional building required.
- Container will be accessed via SSH / SFTP, no GUI.
- http(s) interfaces for all services that users need exposed MAY be exposed publicly (via the UI), including wallet API and Swagger UI that are helpful for troubleshooting and testing.
- Node and Chain Index that run as services on the host will log to journal. As a result, tailing journalctl (-f) in a container console would yield sync status and transaction output normally found on stdout. We admit that isolating and directing specific user events to a container might be a trick. It’s an open item for problem solving during design and implementation. We may instead isolate and direct these messages to the UI.
What are areas of potential criticism for the proposal?
- Performance may be difficult to manage. Haskell builds are CPU intensive, so container density may make the cost model impractical in the long term since the testnet will be the most build/rebuild intensive and since it’s included in the “free tier” it does not generate any revenue.
- Pay per transaction (rather than metered usage) may be a preferred model for contracts so that all contract fees may be paid at execution, but it does not address the resource demands of long-running contracts with few transactions.