Contracts as a Service

[IMPACT]

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:

1. Sourcing of bare metal hosting services.
2. Installation and configuration of a high performance and high availability LXD service. 
3. Creation of node-version / PAB-version matched containers with access to necessary dependencies and services to support CaaS.
4. Design and development of a sparse user interface for users to create accounts, manage containers, and pay for services. 
5. Design and development of automated bridge between UI and CaaS host(s) for creation, management, and disposal of containers.
6. 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.
7. Performance testing with representative contract workloads to understand container density best practices.
8. Security audit (third party TBD).
9. (stretch goal) Allow container-to-container contract migration within a single tenancy so testnet contracts can be simply migrated to mainnet after testing.
10. (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.  
11. We will deploy and maintain the infrastructure for the service.
12. We will not charge for testnet contract containers.
13. We will charge for mainnet contract containers as a base-plus metered service.
14. We will charge for backup and recovery services as well as automation features.
15. (future) Offer contract service monitoring for persistent contracts: ex. address monitoring, auction services, REST-like NFT generation.
16. (future) Offer contract service scheduling for intermittent contracts: ex. structured payments, vesting, beacon-triggered events such as dead man switches.
17. (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.
18. (future) We may operate a cooperative 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 will not 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.

1. 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. 
2. PAB Helper – Under development. This is the most likely transition pattern for dApps toward Light PAB. Nami demo.
3. Light PAB – Not yet supported, but on roadmap. This will likely be the dominant dApp pattern once Light PAB is available. 
4. 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.

[FEASIBILITY]

Milestones for Evaluation of Progress

Primary goal: CaaS in place for Vasil hard fork (July?), though planned timing for the fork seems difficult to verify.

Following successful award: Four, Four-Week Iterations, Plus Planning Week and Cleanup Week (18-week total duration)

Week 1: Iteration Zero: Stories & Estimation, Golden Story, Half Day Iteration Planning Meeting (IPM #1)

Week 2: Kickoff

Week 4: Iteration 1 Midpoint Check

Week 6: IPM #2

Week 7: Anticipated Container Beta

Week 8: Iteration 2 Midpoint Check

Week 10: IPM #3

Week 12: Iteration 3 Midpoint Check

Week 13: Anticipated UI Beta

Week 14: Re-estimate Remaining Stories, Half Day Iteration Planning Meeting (IPM #4)

Week 16: Iteration 4 Midpoint Check

Week 17: Project Closeout Preparation

Week 18: Release

Budget:

$21,120 Front End / API Developer: 192 Hours @ $110

$21,750 PAB / Haskell Developer: 145 Hours @ $150

$21,960 Sysadmin: 180 Hours @ $122

$20,800 First Nine Months Shared Bare Metal Hosting

$2,000 Security Audit

$9,700 Allowance for Unforeseen within Range of Estimate Accuracy +/- 10%

Requested Funds in USD:

$97,330

David Jacobsen has more than twenty years of experience in engineering, software development, consulting, and traditional IT management. He’s experienced with international teams and products after having lived and worked in The Netherlands and having led multi-national development projects for a major US energy supplier. David recently completed the Plutus Pioneer Program and is excited about pairing new understanding and experiences with Cardano and PAB with traditional development skills. He holds a BS in Engineering from the Colorado School of Mines.

https://www.linkedin.com/in/jacobsendavid/

https://github.com/nullvalues

Brice Sinkule has more than five years of experience in front end development with Reactjs and React Native using Redux state management. In his current role as a lead front end developer, he contributes across all mobile and web projects which involve building a platform that supports video content management, content delivery, scheduling, and user enrollment.

https://www.linkedin.com/in/brice-sinkule/

https://github.com/bsinkule

Hal Arnold is a seasoned Software Professional, Mentor and Executive Leader that is skilled at building, guiding and nurturing high performance agile teams [xp, scrum/kanban] specializing in high performance functional programming focused on quality code. He is an experienced pair programmer and pair programming team lead with a long history in TDD/BDD. Hal recently completed the Plutus Pioneer Program and is excited to help remove some of the complexity of getting started with Plutus for other pioneering minded developers.

https://www.linkedin.com/in/hal-arnold-a9380/

[AUDITABILITY]

Progress can be measured with three distinct and visible way points for technical auditability:

1. SSH access to manually created containers is operational and a contract can be run using shared node and chain index infrastructure. This can be demonstrated and directly tested.
2. The UI is operational and can read the status of a manually created and linked container on a host. This can be demonstrated and directly tested.
3. The UI is able to initiate container creation on a host and can affect the status of a container. This can be demonstrated and directly tested.

Performance and usability audits will require a more qualitative approach (and likely) iterative approach.

A technical success would include an end-to-end test of features, starting with UI creation of a new user and container, connection to the container to deploy a contract, and successful execution of the contract on the testnet.

An operational success would include successful execution of mainnet contracts by a number of distinct tenants that produce expected outcomes with acceptable performance.

A community success would include adoption by Plutus Pioneer Program as an integrated part of coursework.

A back-slapping success would include adoption also by Marlowe users, or by bespoke contract execution providers that currently rely on dedicated hosting at a higher cost. Container modification may be necessary, but nothing in the hosting strategy precludes non-plutus implementations. It is simply crafted for Plutus / Haskell first as it is part of core Cardano strategy.

This is a new proposal.