Hlabs: Mutexo - an UTxO coordination layer

[GENERAL] Name and surname of main applicant

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

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

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

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

A centralized server and client implementation, that connects to a cardano-node and keeps track of utxos that are "about to be spent" (via a virtual mutex on a utxo: mutexo)

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

[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 (on external organizations). exsisting modules, still developed and maintained by HLabs, will be reused.

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

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

The project will be opens source under Apache-2.0 license

[SOLUTION] Please describe your proposed solution

UTxO contention is that thing that happens when 2 or more transactions want to use the same UTxO as input.

This scenario is particularly relevant when designing parallel dApps, where the contract has many utxos, and the user may choose any of them for their purpose.

two clients that are not aware of each other may end up choosing the same UTxO, and hence, only one will have their transaction accepted.

The solution proposed is to allow the clients to be aware of what is going on on the dApp in order to coordinate the utxos to use.

This can be done via a centralized server (most probably a dApp has one somewhere, even just to query data for the blockchain) and websockets.

The centralized server would keep track of a subset of the ledger state (only the utxos of the contract as an example) and send events to the clients that are looking to use those utxos.

When a client is building a transaction it will request to "lock" some utxos to the server, and if the utxo is not already locked, the server sends an "OK" response and emits an event for other clients, otherwise it just sends an "Error" response to the client that requested in the first place, so that an other utxo can be tried.

This solution does not prevent the utxos to be spent by someone that is not connected to the server, but it will handle most of the realistic scenarios.

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

The development of parallel dApps will allow developers to truly leverage the power of the eUTxO model, increasing the throughput and efficiency of the protocols developed on Cardano.

This will likely translate into a smother user experience, on top of improved performance of 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?

Michele Nuzzi has been part of the Cardano ecosystem at the beginning as a single stake pool operator and later as developer. In this time he wrote and still maintains numerous dependecy free typescript libraries that require a low level understanding of the Cardano protocol.

A non-exhaustive list list of some of the projects would be:

• plu-ts: a typescript framework for the creation of Cardano Smart contracts
• plutus-machine: typescript library for the evaluation of contracts off-chain
• cardano-ledger-ts: collection of classes and functions for Cardano specific data types and respective serialization and deserialization in CBOR format.
• ouroboros-miniprotocols-ts: library for low level interactions with the cardano-node based on the ouroboros mini protocols specification.

And more recently actively developing an alternative implementation of the cardano-node, thanks to previous catalyst funding.

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

Public repository setup,

Initial implementation based on the ouroboros mini-protocols;

comunications with the cardano-node, following the tip of the chain and mempool.

server implementation

keep a copy of a subset of ledger state in the server memory;

Update utxos based on the cardano-node events

client interface implementation (requests to lock utxos and responses)

client implementation

request infos on specific utxos.

request permission to "lock" utxos and handle possible responses.

receive updates on utxo being locked or spent.

demo and documentation on how to use the tool.

close out report and video.

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

1) Michele Nuzzi

• X.com (former Twitter)

Additionally, Hlabs is looking to expand the team to better handle the various ongoing projects.

New personnel working on this proposal in case of approval would meet the following requirements:

Senior Typescript developer, 5 years experience, deep understanding of computer science fundamentals and with solid understanding of the different Javascript runtimes and relative main APIs

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

Assuming 2 engineers working on the first usable prototype in the first 4 months and improving from there for the remaining 4 months for a production-ready component to use, for a wage of 5750 $/month

at the current rate of exchange of about 0.46 USD per 1 ADA

we have

2 x 5750 x 8 / 0.46 = 200000 ADA.

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

The UTxO contention is scaring developers by building parallel decentralized applications, truly leveraging the powerful eUTxO model.

an offchain coordination layer would represent a concrete solution for those developers, who would then start thinking more about how to parallelize the design of their contracts.