Serpentine: A dApp Friendly Alternative To Hydra

[GENERAL] Name and surname of main applicant

Dominic Chambers

[GENERAL] Are you delivering this project as an individual or as an entity (whether formally incorporated or not)

Individual

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

7

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language.

No

[GENERAL] Summarize your solution to the problem (200-character limit including spaces)

• Demo Hydra alternative having client/server model which dApps need, not p2p model which Hydra has.
• Full implementation/testing of all on-chain code, plus "proof of concept" changes to Hydra Node.

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

No

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.”

No dependencies.

[GENERAL] Will your project’s output/s be fully open source?

Yes

[GENERAL] Please provide here more information on the open source status of your project outputs

The code for this project will be licensed for use by the general public under the GNU AGPLv3 license, and will be made available in a GitHub repo containing:

1. All of the on-chain and off-chain code I write.
2. Developer documentation explaining how to make use of the written code.
3. A thorough write up of my findings, plus suggested next steps, for a more general audience.

[SOLUTION] Please describe your proposed solution.

A "first principles" re-analysis of the problem, with an eye to simplify usage & maximise take-up within dApps:

• https://docs.google.com/document/d/1mzfyTYmnOmGbEXyUjmlx9QaXKNXAUeaJEwX3ymSR3DY/edit?usp=sharing

[IMPACT] Please define the positive impact your project will have on the wider Cardano community.

Imagine a world where the majority of Cardano dApps have best in class user-experience (UX) due to having near instant settlements, and industry leading transaction fees. Like Hydra will ultimately give us, but this time for all dApps.

[CAPABILITY & FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

I have a multi-decade track record delivering complex software projects. I have already performed significant amounts of research & experimentation to de-risk this proposal as much as possible, and get it to the level of maturity you now see if you read the attached document.

There will no doubt be some hiccups along the way, as the rubber meets the road, but to the extent that a more dApp friendly Hydra can exist, I'll build it.

[Project Milestones] What are the key milestones you need to achieve in order to complete your project successfully?

Firstly, please be aware that the point of the milestones will primarily be to tackle the identified risks for this project, which are:

1. The L1 smart contracts won't work for all possible scenarios, or may contain security vulnerabilities that could be taken advantage of.
2. It won’t be possible to dual sync L1 <--> L2 state without introducing security vulnerabilities.
3. The transaction size may be swamped by the size of the state update given a large number of users.
4. It may not be possible to run manual multi-sign transactions given a large number of validators.
5. It may not be possible to change the active set of L2 channel participants on the fly if the performance implications of validating multiple signatures is unrealistic given a large number of validators.
6. It's not possible to faux-run settlement solutions on hydra-node given that the transactions are ultimately invalid due to the tokens being locked under a script key.

Given the above:

• M1: Implement L1 smart contracts (minimal testing).
• Risks 1, 4 & 5.

• M2: Thoroughly test L1 smart contracts, including extensive security scenario based testing, so that we can demonstrate how all possible eventualities are correctly handled.
• Risks 1 & 2.

• M3: Update L1 smart contracts to support unlimited numbers of users and validators by allowing pointer-groups to be placed between the channel data and user and validator groups.
• Risk 3.

• M4: Fork hydra-node, and update it to produce Serpentine L1 state-updates alongside the Hydra L2 snapshots that it already produces, then show how the client can apply these state-updates to the Serpentine channel after putting the channel into a ForceTerminated state.
• This will rely on the pre-initialisation of both a Hydra channel and a Serpentine channel on L1, where both channels will have had the same users contribute the same amounts of Ada to them.

• M5: Update the forked hydra-node to dynamically apply state-update snapshots on L1 when it sees new deposit requests that need integrating into channel state.
• Risk 2.

• M6: Demonstrate that hydra-node could be made to run a dApp signed settlement solution involving funds locked by an arbitrary smart contract.
• Risk 6.
• M7: Document all code, release performance, security and usability findings, and share a plan on the expected next steps for phase two.

[RESOURCES] Who is in the project team and what are their roles?

1. Dominic Chambers: Full Stack Developer.

[BUDGET & COSTS] Please provide a cost breakdown of the proposed work and resources.

Break down is as follows, where developer time is costed at £40/hour:

• M1: Implement L1 smart contracts (minimal testing).
• 150 hours of development time.
• M2: Thoroughly test L1 smart contracts, including extensive security scenario based testing, so that we can demonstrate how all possible eventualities are correctly handled.
• 150 hours of development time.
• M3: Update L1 smart contracts to support unlimited numbers of users and validators by allowing pointer-groups to be placed between the channel data and user and validator groups.
• 75 hours of development time.
• M4: Fork hydra-node, and update it to produce Serpentine L1 state-updates alongside the Hydra L2 snapshots that it already produces, then show how the client can apply these state-updates to the Serpentine channel after putting the channel into a ForceTerminated state.
• 100 hours of development time.
• M5: Update the forked hydra-node to dynamically apply state-update snapshots on L1 when it sees new deposit requests that need integrating into channel state.
• 150 hours of development time.
• M6: Demonstrate that hydra-node could be made to run a dApp signed settlement solution involving funds locked by an arbitrary smart contract.
• 75 hours of development time.
• M7: Document all code, release performance, security and usability findings, and share a plan on the expected next steps for phase two.
• 50 hours of work time.

[VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

In Specific Terms:

This project has the potential to have huge impact to the Cardano community if it can be used to give Cardano apps best in class UX (not that they don't already set a high bar). Though a complex project, I have over 25 years of experience delivering challenging software projects, have an exceptional delivery track record doing so, and am costing my time significantly lower than I normally do.

In General Terms:

The average Staff engineer wage in London is £110K:

• https://www.glassdoor.co.uk/Salaries/london-staff-engineer-salary-SRCH_IL.0,6_IM1035_KO7,21.htm

100K of Ada equates to £30K at the current price, or 3 months and a week. This is a seven month project of 30 hours per week, and therefore represents a significant reduction in comparison to what I would normally bill at.

[IMPORTANT NOTE] The Applicant agrees to Fund Rules and also that data in the submission form and other data provided by the project team during the course of the project will be publicly available.

I Accept