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.
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 <u>plutus-scaffold</u> (also by MLabs) for the same and exact hardware requirements for different use-cases;
- Stretch goal: A HW prototype, relying on, e.g., a <u>Nordic nRF52840</u> development board, that uses the SDK. The prototype will likely rely on <u>cardano-hw-cli</u> 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 <u>Rust embedded hardware-abstraction layer (HAL)</u> and delivering any and all proofs-of-concept using <u>TockOS</u>.
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.
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?