Key Management Integration with Resource Machine Design

[taryune]

I am reaching out to initiate a technical discussion about integrating Mycel’s account transfer protocol with Anoma’s resource machine architecture. We believe there are interesting synergies to explore between our approaches to cross-chain asset transfers and Anoma’s resource-centric design.

We would greatly appreciate your insights and feedback on the architectural considerations and integration approaches outlined below. Our goal is to understand how we can best leverage the resource machine while maintaining the security and flexibility of both systems.

Background: Mycel Account Transfer Protocol

Mycel introduces an account transfer protocol that treats accounts as unified objects, enabling seamless cross-chain muti-assets transfers. Rather than relying on specific cryptographic standards or token bridges, Mycel allows entire accounts containing multiple assets to be transferred atomically across different blockchain ecosystems.

Key Features of Mycel

• Unified account object model
• Blockchain-agnostic transfers
• Multi-asset transfers
• No reliance on specific cryptographic standards
• Elimination of bridge dependencies

Initial Account Architecture

The first proposed architecture for account resources in Mycel includes:

Account Resource: An account resource is a special type of resource that represents a user’s account with key properties.

• Identity (owner)
• Asset holdings (tokens, NFTs, etc.)
• Intent specifications
• AccountId (identity in signer network)

Signer Network:
- Generates and stores signing keys for accounts
- Threshold Signature Scheme based signer network
- We use Internet Computer for PoC at this moment

Properties to Maintain During Account Transfers

1. Atomicity
   • All assets must transfer together or not at all
   • Key ownership must transition atomically with assets
   • No intermediate state where ownership is ambiguous
2. Authorization
   • Only authorized parties can initiate transfers
   • All parties must explicitly approve transfers
   • Authorizations must be cryptographically verifiable
3. Consistency
   • Asset ownership must match key ownership
   • State must remain consistent across resource machine and signer network
   • No possibility of duplicate key usage

Basic Flow

Account Creation & Asset Deposit

1. User requests account creation
2. Signer network generates signing keys
3. User deposit asset
4. Create account resource with:
   Owner identity
   Asset holdings
   Intent specifications
   Account identity

Intent Solving

1. User submits intent through account resource
2. Intent propagates to solver network
3. Solver identifies matching intents
4. Solver constructs balanced transaction:
   Consumes original account resources
   Creates new resources with swapped assets
5. Transaction executed if all parties approve

Transaction Signing

1. Signer network verify consumption authorized by owner
2. Generate signature for transaction

Challenge: Integration with Resource Machine

Building on Mycel’s account transfer model, we have a challenge that how to verify resource machine’s state on signer network. and we can analyze two potential approaches for that:

Option 1: Implementing Account Resource Machine on Signer Network

This approach would involve having the signer network directly implement the resource machine logic.

Advantages:

• Direct control over resource state and key management
• Simplified verification flow since state and keys are managed in one place
• Potentially lower latency for operations

Disadvantages:

• High implementation cost
• Creates tight coupling between resource machine and key management
• May limit interoperability with other signing networks

Option 2: Signer Network Verifies Resource Machine State Proofs

This approach keeps the resource machine and signer network separate, with the signer network verifying state proofs.

Advantages:

• Maintains separation of concerns
• Enables heterogeneous trust by allowing different signer networks
• More flexible and modular architecture

Disadvantages:

• Additional verification overhead
• More complex coordination between components

Key Discussion Points

1. Architectural Integration
   • Which approach better aligns with Anoma’s resource machine design principles?
   • What are the implications of each approach for scalability and interoperability?
2. State Proof Verification
   • What would be the optimal state proof system for this integration?
   • What types of state proofs would be most appropriate?
3. Resource Constraints
   • How should key ownership constraints be expressed in the resource machine?
   • What is the best way to represent account resources within the resource machine model?
4. Alternative approaches to account-resource management
   • if you came up with something better ideas

Welcome the opportunity for getting your feedback and a deeper technical discussion and look forward to exploring these ideas together.

Thank you for your time and consideration.

[maurice]

Hey @taryune, thank you so much for writing this up! We’ve had some initial discussions with colleagues this morning and we’d like to clarify a few things:

(1) From the text and graphic provided, it seems like you’re creating one resource per key / asset. Could you expand on why you would like to have multiple resources?

(2) Could you share further information on the signer network? Is there any documentation that we could read? It seems like in order to make informed recommendations on the challenges you’re facing, we’d need to have a better understanding of the signer network.

cc/ @Michael

[taryune]

Hey @maurice @Michael,
Thanks for your feedback!

(1) From the text and graphic provided, it seems like you’re creating one resource per key / asset. Could you expand on why you would like to have multiple resources?

Focusing on key management may have introduced unnecessary complexity.
Instead of managing multiple resources for keys and assets, one could have a single resource representing swap orders.
In this case, one resource would manage key pairs for the signer network.

(2) Could you share further information on the signer network? Is there any documentation that we could read? It seems like in order to make informed recommendations on the challenges you’re facing, we’d need to have a better understanding of the signer network.

We are currently using this signer network provided by Internet Computer:
Specs:

Threshold ECDSA | Internet Computer

Example implementation:

examples/rust/threshold-ecdsa at master · dfinity/examples

In the future we would like to support multiple signer networks.

[Michael]

Hi @taryune and thank you for your post. There seem to be different architectural options, indeed.

I would like to defer the architectural questions to @isheff, who is working on controllers (but has also worked on our identity architecture in the past). For practical and feasibility question on the various approaches, @mariari, our engineering team lead, should be able to provide you some answers. I will also bring this topic up as part of our org-wide, quarterly in-person meeting this week.

Here is my view on your questions, but take this with a grain of salt.

The underlying architectural question seems to be where you want the Mycel state to live.
From your post, there seem to be two types of state

1. Private keys generated and managed by your TEE-based signer network
2. Public keys/accounts corresponding to the private keys and being associated with various assets deposited by users.

Option 1: Implementing Account Resource Machine on Signer Network

This approach would involve having the signer network directly implement the resource machine logic.

In this case, the resources constiuting the Mycel state would live in your own network.
Implementing the RM yourself shouldn’t be necessary (and would be a lot of work). Instead, it seems to me that you can

1. run your signer network as an Anoma chain where the nodes, in addition to running the consensus, provide key generation and exchange as a service (see 1, 2).
2. or, if you want to keep things separate, run the Anoma node as a sidecar to your signer network protocol.

In both cases, the Mycel state would live on a specialized chain that you run. To interoperate with other chains (where the asset deposits happen), the signer nodes would also need to be block producers on other networks.

Option 2: Signer Network Verifies Resource Machine State Proofs

This approach keeps the resource machine and signer network separate, with the signer network verifying state proofs.

I want to make sure that I understand this approach correctly. Where do you want the Mycel state to live in this case?

An option is to store the state on an existing network, given that an Anoma protocol adapter has been deployed there. The protocol adapter contract maintains a commitment tree and nullifier set (e.g., in a smart contract) on this network and verifies and executes RM transactions.

Your signer network would need to compute all necessary RM proofs locally and call the protocol adapter to verify and settle account creation and account swap intents.
To interoperate with other chains, cross-chain resource transfers would be needed. However, I am unsure how to guarantee the atomicity property here, and I would like to defer this again to @isheff as well as @cwgoes.

The application logic (the account resource definition & logic and transaction functions to create and swap/settle account transfers) that you’ll need to write depends on the chosen architecture. I can provide the best help here once the architectural questions are resolved.

[taryune]

@Michael Thank you for your thoughtful response!

Regarding Option 1 (Implementing Account Resource Machine on Signer Network):
I’m very interested in your suggestion about running the signer network as a service on an Anoma chain. This approach seems promising as it would leverage Anoma’s existing infrastructure while allowing our specialized key management services to operate within that framework. I need some time to explore this approach further, particularly how the consensus participants could also serve as TSS nodes for key generation and management.

Regarding Option 2 (Signer Network Verifies Resource Machine State Proofs):
To clarify where the Mycel state would live in this approach - we’re currently using Internet Computer Protocol (ICP) to store the Mycel state, which includes the key management system and account mappings. In this model, the signer network on ICP would verify state proofs from the Anoma resource machine before authorizing operations.

Thank you for bringing this up at your quarterly meeting. I look forward to continuing this discussion and exploring the best architectural approach for integrating Mycel with Anoma.