MLabs - Embedano (Embedded Devices)

[IMPACT] Please describe your proposed solution.

Problem Space

At this point, Cardano has emerged as a secure, decentralized, and scalable root-of-trust for decentralized applications of all shapes and sizes. Therefore, it doesn’t come as a surprise that there’s a lot of demand from developers to run Cardano everywhere; for example, projects such as Adosia and Veritree already aggregate data to be published onchain by using embedded/IoT systems which are subject to resource constraints such as network bandwidth, and there are sure to be increasingly many such projects as the community continues to develop. We seek to address some of the challenges to using blockchain tech in these resource-constrained settings.

Consider a subset of the problem we seek to address: What is the best practice for an individual or an organization to custody their funds so that only authorized users can access them?

As an organization, the answer is kind of boring; existing tools, incl. high-resiliency object storage such as Amazon S3 and directory services such as Azure AD (especially with FIDO2 sign-on using a hardware security-key), are already sufficient to build out a secure and accessible digital organization. However, while this solution is preferable for large companies, it’s not as accessible for individuals and smaller organizations, especially without a lot of resources.

The best-practice on the blockchain, especially for individuals without much technical expertise, is to use a hardware wallet (HW). Two of the most popular HWs that support Cardano are from Ledger and Trezor, both of which have done a great job in making blockchain more accessible to the layman. For the purposes of this proposal, we’ll be taking a closer look at the solutions from Trezor, especially its flagship Model T (at time of writing); reason being, the solutions from Trezor are open-sourced down to the nuts-and-bolts, while Ledger (despite shipping a great product to an amazing community), does not open-source its firmware or hardware layout.

From a theoretical standpoint, a HW such as from Trezor is just an embedded system designed to store one’s private keys and use it to sign transactions in a secure setting. Trezor particularly does a great job in terms of hardware design, but we run into some limitations at the software-level:

• The firmware is written in C and Python, neither of which are ideal for our requirements; particularly, the former isn’t as safe and reliable as some of its more modern counterparts such as Rust and Zig, while the type system and performance characteristics of the latter aren’t ideal for high-assurance code in a resource-constrained setting; 
• To clarify, Trezor’s solutions are very secure nonetheless despite this fact, but only due to extensive audits and bug bounties; this is as opposed to high-assurance projects like the Ouroboros protocol-family and the Plutus language, which rely on formal verification at the program specification level.
• The Model T’s functionality is compliant with CIP-21, which defines a reduced feature set from cardano-wallet to be implemented by HWs (in other words, the Model T can’t do everything that cardano-wallet can do);
• While one can technically build their own Trezor, i.e., buy the underlying STM32 board from a third-party and load the firmware onto it themselves, they can’t so easily extend the firmware to another architecture or use the software as a library in the development of a different project, e.g., another HW.

The inspiration for this project originally came from the desire to build a HW designed from the ground up for and by the Cardano community, but the proposed scope of the project has since expanded. We seek to help developers overcome the hurdle of poorly-defined practices in this space, enabling them to use Cardano everywhere from the largest and most powerful datacenter nodes to the smallest and most resource-constrained systems possible.

Towards an Embedded Cardano SDK

While HWs are in fact an enticing use-case, storing private keys and signing transactions is possibly the least complex or impressive thing that one could accomplish on an embedded system. Reason being, the task does not require any Cardano-specific software, as seen in the Trezor implementation; all one really needs is support cryptographic primitives like the EdDSA signature scheme and the BLAKE family of hash functions. One might encounter some difficulty in fitting an entire transaction into the memory of the microcontroller, but that could possibly be solved by streaming the transaction to be signed in parts; in this way, the transaction size could be scaled up to some degree (perhaps even exceeding the limitations set forth by CIP-21!) Moreover, with only a slightly more-powerful embedded system, one could likely run the whole cardano-wallet as-is, e.g., over some stripped-down version of Linux!

Perhaps even more exciting is the prospect of validating transactions on an embedded system, e.g., using signature aggregation a’la Mithril. Galois, Inc. will be developing the first prototype of Mithril (in Rust and with planned formal proofs of correctness, nonetheless); however, it is not yet known whether the implementation will be suitable for use in the embedded/IoT space, among other resource-constrained settings. We envision a future where alternative resource-constrained implementations of core Cardano protocols exist and provide the same formally-verified security guarantees as do the originals.

How does an SDK for resource-constrained Cardano development help the community?

In Charles Hoskinson’s video "The Island, The Ocean, and the Pond", he eloquently explained that the other [Ethereum-style] blockchains are just the “pond” of competitors; Cardano could very well be competing in the “ocean”, i.e., with the likes of Microsoft, before long.

Consider a simple use-case: You want to sign into your account for some internet forum like Reddit, but you don’t want to be bothered to remember your username and password. Generally, platforms like Reddit integrate with single sign-on (SSO) providers like Google and Microsoft, especially in enterprise applications and highly-secure settings, which is how most people get around on the internet. In this case, the SSO provider is a sort of broker for your identity; really, all they’re doing is hosting a database on their side that tracks the authentication events (i.e., the events where you log in) in order to let authenticated users in while keeping unauthenticated ones out.

However, on Cardano, you get the ledger and the cryptography for free (along with everything IOG is rolling out on the Atala Prism side!) We envision a future where users could use their Cardano wallets to sign “authentication UTxOs” (onchain messages signifying request for authentication) in order to log into applications like Reddit instead of needing to go through a centralized SSO provider like Google or Microsoft. Moreover, if the protocol were able to run in a resource-constrained setting (all you really need to do is read the chainstate, which any Mithril node can do), we could use it for authentication in all kinds of settings; for example, one might be able to use their Cardano wallet to authenticate a login to a remote server via protocols like RDC (Windows) or SSH (Unix).

While seemingly only a small optimization, this would create the foundation for a decentralized marketplace for computational resources and trust. This way, it would be possible to decentralize informational wealth which was hitherto only available to powerful centralized actors in the space, i.e., the likes of Google and Microsoft.

[IMPACT] Please describe how your proposed solution will address the Challenge that you have submitted it in.

Our Proposal

We aim to start the development of the Cardano Embedded Rust SDK, an open-source platform for resource-constrained systems to interact with the Cardano blockchain. Our software system should provide developers on the embedded systems side with the tools to develop high-assurance and enterprise-ready software over a large breadth of hardware platforms.

This proposal is for the first phase of the development of the platform; we intend to pursue the development of later phases in due time. Our planned deliverables are as follows:

• A wallet SDK, compatible with the ARM Cortex-M series of processors, that is minimally compliant with CIP-21 and ideally equivalent to cardano-wallet;
• NOTE: This won’t be a functioning HW that is capable of replacing the likes of the Trezor Model T; rather, it will be a tool that can be used by developers to design their own HWs. In fact, we’re considering implementing alternative Cardano-specific firmware that can run on the Model T itself (in future phases of development, that is);
• A well-defined design pattern for resource-constrained applications that rely on the Cardano blockchain, incl. a scaffold in the image of plutus-scaffold (also by MLabs) for the same and exact hardware requirements for different use-cases;
• Stretch goal: A HW prototype, relying on, e.g., a Nordic nRF52840 development board, that uses the SDK. The prototype will likely rely on cardano-hw-cli by VacuumLabs and will NOT feature a screen to view exact transaction data as signed by the HW;
• We understand that the screen is part of the security model for production HWs such as from Ledger and Trezor, but we leave UI/UX requirements out of the scope of this proposal;
• Extensive documentation and blog posts detailing our findings regarding the best practices for high-assurance resource-constrained apps that interact with Cardano.

We plan to handle as much as possible, if not all, of the development in pure and safe Rust code. We will be targeting the Rust embedded hardware-abstraction layer (HAL) and delivering any and all proofs-of-concept using TockOS.

In future phases (not covered by this proposal), we aim to further improve the security of the platform through audit and formal verification (depending on tools available at MLabs and funding opportunities from the community); moreover, we seek to push the boundaries of what is possible on a low-power and resource-constrained device. We will also expand community knowledge in this area regarding the security guarantees possible on resource-constrained systems over protocols like NFC, bluetooth/BLE, and TCP/UDP over Ethernet.

For example, we might address the open question of the possibility of running a HW and a cardano-node (or perhaps a mithril-node) on the same device, the former being unable to access (or be accessed from) the internet while the latter is given internet access only to connect to its relay peers. The Tock embedded platform enables communication between processes using well-defined data types over secure channels, while enforcing isolation of each process’ internal state (similarly to Linux), so it could be possible to run both components simultaneously, thus enabling a single low-power hardware device to sign and send transactions on its own.

The above and further open questions concerning the limitations of blockchain interaction on low-power embedded/IoT devices will be addressed in later phases of development.

[IMPACT] What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?

Our Proposal

We aim to start the development of Embedano, an open-source platform for resource-constrained systems to interact with the Cardano blockchain. Our software system should provide developers on the embedded systems side with the tools to develop high-assurance and enterprise-ready software over a large breadth of hardware platforms.

This proposal is for the first phase of the development of the platform; we intend to pursue the development of later phases in due time. Our planned deliverables are as follows:

• An alpha-phase cardano-wallet SDK for embedded and low-power devices;
• Stretch goal: A HW prototype, relying on, e.g., a Nordic nRF52840 development board, that uses the SDK. The prototype will likely rely on cardano-hw-cli by VacuumLabs and will NOT feature a screen to view exact transaction data as signed by the HW.
• We understand that the screen is part of the security model for production HWs such as from Ledger and Trezor, but we leave UI/UX requirements out of the scope of this proposal.
• NOTE: This won’t be a functioning HW that is capable of replacing the likes of the Trezor Model T; rather, it will be a tool which can be used by developers to design their own HWs. In fact, we’re considering implementing alternative Cardano-specific firmware that can run on the Model T itself (in future phases of development, that is).
• A well-defined design pattern for resource-constrained applications that rely on the Cardano blockchain, incl. a scaffold in the image of plutus-scaffold (also by MLabs) for the same and exact hardware requirements for different use-cases;
• Extensive documentation and blog posts detailing our findings regarding the best practices for high-assurance resource-constrained apps that interact with Cardano.

In future phases (not covered by this proposal), we aim to further improve the security of Embedano through audit and formal verification (depending on tools available at MLabs and funding opportunities from the community); moreover, we seek to push the boundaries of what is possible on a low-power and resource-constrained device. We’d also like to expand community knowledge in this area regarding the security guarantees possible on resource-constrained systems over protocols like NFC, bluetooth/BLE, and TCP/UDP over Ethernet.

The above and further open questions concerning the limitations of blockchain interaction on low-power embedded/IoT devices will be addressed in later phases of development.

Limitations and Future Areas for Development

The main unanswered questions are as follows:

• Will we be able to bring all the functionality from cardano-wallet over to the low-power side, as many systems can have constraints that make it difficult or impossible to fit a whole transaction (up to the max Tx-size) in volatile memory? If not, can we effectively stream a transaction and sign it in parts, i.e., can we exceed the capabilities of the Model T by using low-level non-blocking events and other performance optimizations?
• Can we expand our range of supported hardware devices? Is it only possible to run a wallet, or can we run a whole node on the device itself (e.g., using Mithril)?
• This will be critical for future development of the project.
• What are the best security practices in this space? Can we extend any formal specifications of correctness and complexity designed by IOG (or just write our own!) and deliver a provably-secure platform?

[FEASIBILITY] Please provide a detailed plan, including timeline and key milestones for delivering your proposal.

Intended Fund – Fund9: dApps, Products, and Integrations

Challenge Statement:  “What dApps, products and integrations can be implemented to bring impactful use cases to the Cardano ecosystem that help drive more adoption?”

1. Increasing the number of dapps and products available for the community to use that help to enrich the ecosystem with new use cases.
2. Increase the number of integrations that bring existing solutions together for a more seamless and connected experience between different products.
3. Increased quality of existing products & integrations through suggested improvements that is supported by customer feedback or increased usage by the community.

Milestones:

3 Months: Finish the initial exploratory phase of development and open-source a working scaffold for embedded apps that depend on Cardano; begin developing features for wallet SDK.

6 Months: Complete the development phase for the core features of the platform. At this point, it should be possible to build the code and sign a transaction on a hardware dev kit.

12 Months:  A fully-functional and flexible platform ready to be used by external developers for production embedded applications like HWs. At this point, the team will be addressing edge cases and generalizing what can be done on the embedded side (e.g., can we run the whole node on an embedded device instead of just the wallet?)

[FEASIBILITY] Please provide a detailed budget breakdown.

Funding:

Engineering hours: 1200

Total: $96,000

Engineering Hours Breakdown:

Exploratory analysis of embedded toolchains and potential hardware and RTOS platforms to be supported 60

Design, architecture, specification, initialization/scaffolding 120

Implementation and superficial testing of core features 240

Extensive testing and possible implementation of edge features 120

Docs and training materials 60

Subtotal 600

Change budget 600

Total time 1200

The reason for the large change budget requested is the uncertainty regarding the extent to which we can bring Cardano to resource-constrained hardware systems. At MLabs, our core competency is software-level R&D in the blockchain space; consequently, our undertakings are often on the ambitious side and thus end up requiring a large change budget in order to have a no-surprises engineering phase.

[FEASIBILITY] Please provide details of the people who will work on the project.

MLabs: MLabs has quickly become one of the premier development firms in the Cardano Ecosystem. We are an IOG Plutus Partner and work regularly with IOG to develop the Cardano blockchain and ecosystem. Our team is composed of talented developers who have helped build community projects such as:

• Liqwid
• SundaeSwap
• Ardana
• PlayerMint
• Seabug
• Many others

Through our work with early-stage projects, we have one of the largest groups of Haskell/Plutus developers in the community.

Website: https://mlabs.city/

Core Team

Formal Methods Engineering and Systems Programming

Hari Amoor:

Hari is a software engineer at MLabs, mainly specializing in formal methods, i.e., type theory, proof-automation, etc., which is a core competency of MLabs; thus, he is familiar with languages such as Agda and Idris, along with Haskell. Moreover, he is also proficient in systems programming, mainly with Rust but also in C++ and Zig.

Hari has made many contributions to various smart contract systems and tooling on Cardano while at MLabs, while spending his spare time fulfilling his pursuits as a “crypto degen."

GitHub: https://github.com/hariamoor-mlabs

Delivery Manager

George Flerovsky:

George manages a portfolio of projects at MLabs including decentralized exchanges, governance, auctions, yield optimization, and on-chain analytics. He completed his Master of Arts degree in Economics in 2017 and has five years of professional experience in data science and engineering. Prior to joining MLabs, George was involved with designing the streaming merge algorithm for concurrency in the Cardax decentralized exchange.

George has developed in and loved Haskell since 2015, and has been involved with Cardano since 2018. He has carefully studied the Cardano research papers and specifications, developing a deep knowledge of the Cardano consensus protocol, smart contract framework, and network stack. He participated in the first cohort of the Plutus Pioneers Program in the summer of 2021, and actively contributed to the Alonzo Blue, White, and Purple testnets.

GitHub: https://github.com/GeorgeFlerovsky

[FEASIBILITY] If you are funded, will you return to Catalyst in a later round for further funding? Please explain why / why not.

As mentioned, this proposal is for the first phase of the development of the platform; we intend to pursue the development of later phases in due time. As such, we likely intend to apply again for Catalyst funding in the future.

[FEASIBILITY] Are you or any member of your team working on any other proposals in this Fund9?

[FEASIBILITY] Are you or your team working on any other proposals from previous Funds?

[AUDITABILITY] Please describe what you will measure to track your project's progress, and how will you measure these?

KPIs (Key Performance Indicators)

Developer productivity:

- Commits to our open-source GitHub repo

Quality and usefulness:

- Documentation and ease of use

- Blog posts on exploration and design choices

- Testing and benchmark suite

Developer interest:

- Github repos that use our platform

- Social media visibility

We plan to implement our code with inline documentation; the API should be accessible through this interface via a static site-generator like Haddock or RustDoc.

We’ll also write Medium articles talking about the development experience and lessons learned.

[AUDITABILITY] What does success for this project look like?

Success for this project involves the completed development of the mentioned deliverables, positive reception by the Cardano development community, Cardano effectively available in resource-constrained contexts, general interest in furthering the project, and several builders incorporating the library into their projects.

[AUDITABILITY] Please provide information on whether this proposal is a continuation of a previously funded project in Catalyst or an entirely new one.

This is a new proposal.