User-defined objects #1068
Replies: 5 comments 20 replies
-
|
Thank you for such a detailed write up! I really like the idea of adding more customizability/programmability to assets, and have been trying to think in this direction as well. There are a few things, however, that are not yet clear to me in the proposal. One such thing is who/how keeps track of the "bookkeeping data" about created objects. By bookkeeping data I mean things like the total number of issued coins for a fungible asset, or all issued non-fungible assets. Currently, we have a dedicated storage slot in the faucet accounts to keep track of this data - but how would this be handled in the model where any account can create objects of different types? Somewhat related to the above: in the current model, the assets are "static". That is, once issued they don't really change (an exception to this is the amount part of the fungible asset). One reason for this is that the original issuer needs to make sure they don't create "duplicate" assets. But if an asset can be modified after it is issued, this may become complicated. Another way to think about this is that we need to make sure that an asset's "vault key" remains stable throughout its lifetime while some other attributes of an asset are allowed to change. Also, it seems to me that we need to route most interactions with the objects through the vault. That is, instead of calling procedures on an object directly, we'd call a procedure on an object that is stored in a vault. This way, we can ensure that an object can be modified only via its "native" procedures. So, for example, instead of first removing an asset from the vault and then adding it to a note (via two separate procedures), we'd have to provide kernel procedures like: With this setup it would be possible to define assets generically. For example, the asset definition itself would know how to insert an asset into the vault and so, for example, for fungible assets Another question is what should be the capabilities of the native asset procedures. For example, it would be great to have the ability to define an asset that can only be transferred to accounts which meet certain criteria (e.g., the owner of the account is 18 years old or older). For this, native asset procedures should be able to call methods on the account itself (maybe via FPI?). |
Beta Was this translation helpful? Give feedback.
-
|
Great questions, thanks!
My thinking was that the bookkeping data of objects is not generic but specific to the type of object. A coin's bookkeping data is the total supply, its decimals or its symbol. A non-fungible asset's bookkeping data might be the total number of issued assets, though some issuers might not care about it. A nameservice's bookkeping data would perhaps be a name -> address mapping. So bookkeeping data is "specific" in the above sense to each use case. So I think it can be represented by more objects, assuming that not all objects generate more bookkeeping data. For example, when minting a new Coin, one gets a treasury capability object and a coin metadata object (which here represent the bookkeeping data). The treasury capability contains the total supply and the coin metadata contains the decimals, the symbol and other such static data. These could be stored in the issuing account's vault. The advantage of using objects as bookkeping data is that there would be a standardized representation (e.g. every Non-fungible assets I find generally difficult to discuss in this context, because they are so generic. This is one of the motivations of introducing objects, so that instead of a generic representation, we have (more) concrete ones. Object ID
I agree that an asset/object's vault key must remain stable. In the original post I described a high-level approach for deriving such IDs, but I now think it could be simpler. The idea is that object IDs are generated "by the protocol". The properties of this should be:
The object ID does not authenticate the object, but that's fine I think, because objects are created and destroyed in the controlled environment of the TX kernel and are already authenticated via the asset vault in accounts and the assets hash in notes. Moreover, if the ID would authenticate the object it would change when the object changes, so the stability of the ID is important.
This ID doesn't prevent issuing "duplicate" assets in the sense that an issuer could issue two objects of type
With these IDs we could not query the vault for an existing Object procedures
This seems like an important point and I agree that's probably how it would work. If objects are stored in vaults then we can only directly support two words of data (the Smt key and value) per object. The key would be taken up by the object ID. We can use the value of the leaf by making an indirection and:
SMT Layout: Sequential Hash Layout: This comes with trade-offs:
Procedure Capabilities
Yeah, that would be very powerful. In Sui, for example, an object can be defined to have or not to have a I imagine we could do something similar by specifying on object's somewhere (ID or bookkeeping data) whether it has such abilities or not. Or, as you mentioned, it could be done with something like FPI. While technically possible, it seems tricky for a client to figure out what data an object will require from an account, so that it can load the right data into the advice provider. This depends on how much flexibility we need here. The abilities would be protocol-defined, so fairly static, while the FPI mechanism would allow for permissionless extension, which keeps the protocol simpler and is more powerful, but also may be more tricky to use. |
Beta Was this translation helpful? Give feedback.
-
|
In discussing the approach from #1271 with others, I think some things did not become clear so I want to try and clarify some of these. Here is an overview of the current approach, depicting the three "components" involved in creating a treasury capability and token asset.
Here we're executing a transaction against some user's account, which is the "native account". It calls out to the protocol-deployed Miden Account (via foreign procedure invocation), providing the standard functionality of token minting. It's called the Miden Account because it is protocol-owned and provides standard functionality needed in Miden, such as defining a standard token type. And then there's the transaction kernel, which exposes generic asset management APIs such as One of the things that wasn't clear is why we need the "Miden Account". Why can't we write the "create treasury" or "mint token" procedures as a library and run it from the native account directly? To illustrate further, suppose we have this type in Rust: pub struct Token {
amount: u64
}Because amount is not public, the field cannot be read or written to outside of the module it is declared in. This mechanism is what we're trying to get for assets as well, so the issuer of an asset can define exactly what can be done with a Pure MASM libraryLet's entertain the option of using a pure MASM library for this, though. To restrict the set of allowed procedures of an asset we could store the hash of the MASM library instead of the issuer as part of its bookkeeping data. The tx kernel could then check whether a mutation operation originates from one of the procedures in this library. The main problem with this is that the library hash is part of the globally unique identifier of the asset. E.g. if the library hash is Maybe there is a middle-ground here. Can we use an account ID as the asset issuer and use it to retrieve its account code which is then used as the library for asset operations? This is similar to FPI, but could perhaps be optimized to avoid context switching into the foreign account. Instead the tx kernel gets the calling procedure's hash using the Asset Faucet CallOne core issue we want to solve with asset programmability is to restrict transferability. One alternative idea from @Dominik1999 was (please correct me if I'm misrepresenting the idea) to specify a MAST root in the faucet account of the asset. When an asset is moved to/from an account it is checked if that root is This does solve the problem of restricting transferability. Being able to modify an asset on a transfer is also useful functionality, and we could enable this by making the signature of the called procedure look something like General ProgrammabilityOne of the downsides I see with this is that this solution is somewhat limited in its functionality but simple, which is good. Having a more general programmable asset model still comes with some advantages. For example, say we want to issue a token of flavor POL from account A and we want account B to be able to issue more such tokens. Right now, we could go with at least these two ways:
If we had programmable assets, faucet account A could send a capability asset that represents the ability to issue tokens (e.g. the treasury cap) to account B. Account B can issue more tokens using the treasury cap (e.g. This example shows that such general programmability can be a really good fit for the edge architecture of Miden. In such an architecture, a design where state lives in individual accounts rather than being public and shared is ideal because one doesn't have to solve the shared state problem in the first place. It also enables that functionality privately and is much lighter on network resources. Some other examples where this distribution of capabilities could be powerful:
Relationship to atomic composabilityThis asset model is most powerful if there is atomic composability, which Miden does not have at this time or perhaps won't ever have. The reason is that, at least in block chains with atomic composability such as Sui, such capability objects are often used when calling into foreign smart contracts. E.g. to update the So one question I'm asking myself is whether this asset model is useful enough without atomic composability and useful enough within Miden's architecture. |
Beta Was this translation helpful? Give feedback.
-
|
I've been thinking about an alternative design to the current (static) asset model that achieves the following:
I think that conceptually the below proposal sits somewhere between Philipp's user-defined objects (most flexible) and the current static asset model (not flexible and very coupled to the kernel). Notably, unless I missed something (quite likely!) it should lend itself to a significantly simpler solution that we could probably pull off in a few weeks. To illustrate how such generic assets could work, consider the proposed new approach for how an account would mint an asset and add it to the note's vault:
The vault key is just
Some MASM pseudo-code for the above: Now when we add or remove assets from notes (here The issuer MUST have procedures with the following signatures: and can define whatever logic they want: I think very similar logic could apply across the other dimensions:
Major implications and changes needed:
|
Beta Was this translation helpful? Give feedback.
-
|
I was thinking in a similar direction recently and the following can be seen as an extension of what you proposed and filling out some details. MotivationI now think that the full flexibility of user-defined objects with full programmability is not an ideal fit for the overall actor-based architecture we have. I think the point about this being most useful in an architecture that has atomic composability still stands (see above). Also, adding this flexibility (and complexity) makes it less clear whether the programmability of accounts, note or assets should be used to achieve an outcome. For instance, we have P2IDE which implements timelocking, but with the full flexibility of user-defined objects we could also define a Instead, I think a better fit might be for just the data in assets to be customizable, while the behavior stays with code defined in accounts and notes. This is pretty much what Marti proposed:
As an example, consider a struct StakedEth {
issuer_id: AccountId,
staked_at: BlockNumber,
amount: u64
}This can already be done without user-defined assets, because this information can be stored in an account's storage. The advantage of making this an asset itself is that it becomes tradable (it's basically a liquidity pool token) without needing a transaction executed against the staking account itself. I think this is a big architectural win because it allows for more parallelization, i.e. less congestion on the staking account. I think this fits perfectly into Miden's edge architecture as it pushes more data to the edge, and thus allows more logic to be done at the edge too (e.g. through FPI). Asset InterfaceRecap for what we need: Assets are stored in asset vaults, which are sparse merkle trees with a vault key ( The first point sounds like a restriction but is also a UX feature. In Sui for instance, it is normal to have multiple This feature makes user-defined assets quite tricky, because users have to provide the
The value in the asset vault could either stay the asset itself, become the root of the asset SMT (with a very low depth, ideally customizable), or some other form of commitment, and the tx kernel would treat assets opaquely only via their vault key + encoded representation. The actual data would be in the advice provider and would have to be verified against the SMT root when accessed. In Masm, we'd probably have to always pass around these two as So, to allow users to define the exact structure of an asset, they have to adhere to an interface, quite similar to what Marti proposed already. This is a slightly different way of doing it. The main invariant that needs to be upheld is that assets with the same vault key must be mergeable and splittable. This interface perhaps look like (using Rust instead of MASM for simplicity): pub type AssetId = [Felt; 2];
trait Asset {
/// The identifier of the asset type issued by this account.
///
/// A single account can issue multiple assets and these must be uniquely identified by this ID.
const TYPE_ID: u8;
/// Returns the ID of the issuing account.
fn issuer_id(&self) -> AccountId;
/// Must return a unique identifier for an asset issued by this account.
///
/// Must be stable throughout the lifetime of the asset.
///
/// - Two assets with the same asset ID must be mergeable and splittable.
/// - If an asset type is not mergeable, the asset IDs of its instances must be unique.
fn asset_id(&self) -> AssetId;
/// Merges two instances of the same asset into one.
///
/// This method is only called when self and other have a matching account ID and asset ID (= vault key).
/// other is never identical to self (basically pointer to self != pointer to other, though it can be equal),
/// i.e. an asset is never merged with itself.
///
/// Must return `None` when merging is not supported.
fn merge(self, other: Self) -> Self;
/// Splits an asset into two instances.
///
/// This method is only called when self and other have a matching account ID and asset ID (= vault key).
/// other is never identical to self (basically pointer to self != pointer to other, though it can be equal),
/// i.e. an asset is never merged with itself.
///
/// `other` is split out of self and and the new self is returned.
///
/// For instance, if self is a fungible asset with amount 50, and other has amount 30,
/// then an asset with amount 20 is returned.
fn split(self, other: &Self) -> Self;
/// Encodes the asset into a Word.
///
/// This can either be done by serializing the asset itself as a `Word` if space permits, or
/// otherwise construct a commitment like a sequential hash or the root of an SMT.
fn encode(&self) -> Word;
}
/// Returns the key that identifies the asset in the asset vault.
///
/// This logic is implemented by the tx kernel and can only be influenced by users through the
/// return values of the account_id and asset_id methods.
fn vault_key<ASSET: Asset>(asset: ASSET) -> AssetVaultKey {
let issuer_id = asset.issuer_id();
let asset_id = asset.asset_id();
let mut key = Word::empty();
key[0] = asset_id[0];
key[1] = asset_id[1];
// Use the lower 8 bits of the account ID suffix to encode the type of the asset within this account.
key[2] = Felt::try_from(issuer_id.suffix().as_int() | ASSET::TYPE_ID as u64).expect("should be valid");
key[3] = issuer_id.prefix().as_felt();
AssetVaultKey::new(key)
}So, we basically have:
Standard coinAs Marti also mentioned it would be good to provide a standard token/coin/fungible asset so users do not have to reinvent the wheel for the basic use case. So, miden standards could define a pub struct Coin {
issuer_id: AccountId,
amount: Felt
}
impl Asset for Coin {
const TYPE_ID: u8 = 0;
fn issuer_id(&self) -> AccountId {
self.issuer_id
}
fn asset_id(&self) -> AssetId {
// All coins of the same faucet are mergable/splittable, and so their asset ID should be the same.
[Felt::ZERO; 2]
}
fn merge(self, other: Self) -> Self {
Self {
issuer_id: self.issuer_id,
amount: self.amount + other.amount
}
}
fn split(self, other: &Self) -> Self {
if other.amount > self.amount {
panic!("self does not contain enough to split out other");
}
Self {
issuer_id: self.issuer_id,
amount: self.amount - other.amount
}
}
fn encode(&self) -> Word {
Word::from([self.amount, Felt::ZERO, Felt::ZERO, Felt::ZERO])
}
}Staked CoinLet's also consider the earlier struct StakedEth {
issuer_id: AccountId,
/// The block at which the provided amount was staked. Used to calculate the reward amount.
staked_at: BlockNumber,
amount: Felt,
}
impl Asset for StakedEth {
// Suppose this is the second asset type issued by an account.
const TYPE_ID: u8 = 1;
fn issuer_id(&self) -> AccountId {
self.issuer_id
}
fn asset_id(&self) -> AssetId {
let mut asset_id = [Felt::ZERO; 2];
// Two StakedEths are mergeable if their staked_at blocks are the same.
// Therefore the asset ID is the staked_at block number itself.
asset_id[1] = Felt::from(self.staked_at.as_u32());
asset_id
}
// The tx kernel guarantees that only assets with the same vault key are attempted to be
// merged (or splitted), and so we don't need to check that `staked_at` matches, because we
// set up the asset ID in the correct way.
fn merge(self, other: Self) -> Self {
Self {
issuer_id: self.issuer_id,
staked_at: self.staked_at,
amount: self.amount + other.amount
}
}
fn split(self, other: &Self) -> Self {
if other.amount > self.amount {
panic!("self does not contain enough to split out other");
}
Some(Self {
issuer_id: self.issuer_id,
staked_at: self.staked_at,
amount: self.amount - other.amount
})
}
// Technically this would fit into a word, but this is an (inefficient) example for how assets could be
// encoded that do not fit into a word.
fn encode(&self) -> Word {
let mut smt = Smt::new();
// Field 0 is the amount.
smt.insert(
Word::from([0, 0, 0, 0u32]),
Word::from([self.amount, Felt::ZERO, Felt::ZERO, Felt::ZERO]),
);
// Field 1 is the staked_at block number.
smt.insert(
Word::from([0, 0, 0, 1u32]),
Word::from([self.staked_at.as_u32().into(), Felt::ZERO, Felt::ZERO, Felt::ZERO]),
);
smt.root()
}
}Non-Fungible AssetFinally, a non-fungible asset example: struct GenericNFT {
issuer_id: AccountId,
// Two felts generated deterministically from something like
// hash(BLOCK_HASH | ACCOUNT_COMMITMENT | [0, 0, 0, counter]) at asset creation time. Should
// ensure every asset has a unique asset ID.
asset_id: AssetId,
// The raw data the NFT commits to. This assumes the data is not really useful to be accessed on-chain.
data: Vec<u8>
}
impl Asset for GenericNft {
const TYPE_ID: u8 = 2;
fn issuer_id(&self) -> AccountId {
self.issuer_id
}
fn asset_id(&self) -> AssetId {
self.asset_id
}
fn merge(self, other: Self) -> Self {
panic!("this asset type cannot be merged and the method should never be called");
}
fn split(self, other: &Self) -> Self {
panic!("this asset type cannot be splitted and the method should never be called");
}
fn encode(&self) -> Word {
Hasher::hash(self.data)
}
}Asset CreationCurrently, we have the Similarly, there'd be a Pattern: Permissionless transferThe ability to define custom data in assets allows for "permissionless transfers". This is what I mentioned in the initial To be clear, this only argues for custom data in assets generally, not necessarily that it's necessary for this amount of data to go beyond one word, though it will almost certainly be beneficial in certain cases to have more than one word of space available. Pattern: CapabilityThe ability to define multiple assets per account allows for the capability pattern. That is, an asset can represent a capability, like the right to vote, change a name -> ID mapping in a name service, or mint tokens. The latter could work by calling into a foreign account Open Questions
CapabilitiesRegarding capabilities I also cannot think of any other major ones other than transfer restriction. So one thing we need is for asset issuers to be able to define one or more hooks that are automatically called when the asset is transferred (or on some other event, though I can't think of another one).
I'm thinking just "asset added to note/account" should be good enough, because asset preservation rules force an asset that is added to the tx input vault to be added to one of these two eventually. I haven't explored this in the above at all, but this could conceptually be optional methods on the |
Beta Was this translation helpful? Give feedback.
-
|
At the offsite, we discussed various approaches to "programmable assets" which combine different aspects of @mmagician's and @PhilippGackstatter proposals above. The outcome was 3 different approaches varying in their complexity of implementation and flexibility that they would add to the protocol. Below is a quick summary of these approaches - @mmagician (and others) please correct if anything is wrong/missing. Approach 1This is the simplest approach needed to support something like "compliant private stablecoins". This approach does not change the current representation of assets - we still have fungible and non-fungible assets as we have now. But, a fungible asset issuer (i.e., a fungible faucet) can define "callbacks" which would be called when a fungible asset issued from this faucet is to be added or removed from an account's vault. These callbacks would act as predicates that would specify whether a given action is permitted. This would allow enforcing such things as blocklists for fungible asset transfers - i.e., if the callbacks return an error, the asset could not be added to or removed form an account. The main benefit of this approach is that it would be pretty simple to implement. The main drawback is that it probably wouldn't allow us to support much more beyond blocklists or something very similar. Approach 2This builds on the first approach but makes fungible assets more flexible. That is, callbacks would be used not as simple predicates to check whether an asset can be added/removed from the vault, but also to execute fungible asset merging and splitting logic. This would allow defining more complex fungible/semi-fungible assets. The main drawbacks here are:
The main benefit is that this approach keeps asset representations in a single word, and thus, is still relatively easy to implement. Approach 3This is the most flexible approach that is more along the lines of the discussion between @mmagician and @PhilippGackstatter. In this approach, we no longer differentiate between fungible and non-fungible assets - though, there are still two types of assets simple and complex (this is temporary naming which we can/should change). All assets are defined using 6 field elements (encoded as 2 words) such that:
The main difference between simple and complex assets is how the assets are stored in the asset vault:
The faucets would still be expected to provide the logic for adding/removing assets from the vault. Using Rust, the interfaces of these procedures would look something like: impl MyFaucet {
/// Builds a value that needs to be inserted into the asset vault resulting from adding
/// the provided asset data to the vault.
fn build_merged_value(
account_id: AccountId, // ID of the account to which we are adding the asset
vault: &AssetVault, // reference to the vault of the target account
asset: AssetData, // data of the asset we are adding
) -> Word {
// here, we'd be able to read the current value of the asset from the vault
// modify it as needed based on the asset data, and then return the new value.
//
// - For fungible assets the logic here could be as returning current_amount + new_amount
// - For NFTs this could be reading the current SMT root from the vault, and adding
// the new asset to the SMT, and the returning the root of the new SMT
//
// we can perform a number of checks here
// - check if the account is on some blocklist.
// - check if the vault contains some other assets.
}
/// Builds a value that needs to be inserted into the asset vault resulting from removing
/// the provided asset data from the vault.
fn build_split_value(
account_id: AccountId, // ID of the account from which we are removing the asset
vault: &AssetVault, // reference to the vault of the target account
asset: AssetData, // data of the asset we are removing
) -> Word {
...
}
}Another way to think about this is is that asset vault kind of becomes like "storage" where the storage logic is defined by the asset issuer. For "simple" assets, the issuer gets 32 bytes of storage (i.e., a word), for complex assets, the issuer gets a full SMT worth of storage. This approach is very flexible, but it is also the one that would require the most effort to implement. Main challenges are:
One somewhat annoying thing is that we can't allocate more than 4 field elements of data for asset values, which means that assets that require, say, 64 bytes to represent cannot be represented natively - but i'm not sure there is a way to get around this. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, you need two EC points, one is the "ephemeral public key" point and the other is the blinded message point, hence only one of the points carries the "payload". |
Beta Was this translation helpful? Give feedback.
-
One example that comes to mind is an asset where an account is allowed to transfer some amount per day (or some other duration), but not more (optionally, unless they have some special permission). We cannot define this using simple fungible assets. Using the programmable asset approach, for each asset, we could store the following in the vault: Then, on every merge, the faucet logic would be able to check if we are transferring more than allowed per Another type of asset we cannot represent with simple fungible assets is a private yield-bearing asset. For example, something like USDC where people get yield just for holding it. I haven't fully thought it through, but with programmable assets, we could represent the asset as: Then, on every merge, we'd be able to update There are probably many other examples, these are just the two that came to mind first. |
Beta Was this translation helpful? Give feedback.
-
I think if we allow asset data to be "simple" or "complex" (complex, in this case, meaning more than a single word), then this would address the issue. We could start with "simple" assets now, and enable "complex" ones further down the road.
I'm not sure I followed this part: I think we'd still need just the merge/split procedures and these would be guaranteed to be called on every asset addition/removal from the vault. Or is the issue that the callback won't be able to identify all assets in the vault issued by the same faucet?
Yes, that would work too - though, currently, I believe, we don't allow foreign accounts to make callbacks back to the native account (but I don't think that's a fundamental limitation). |
Beta Was this translation helpful? Give feedback.
-
I imagined fn merge(self, other: Self) -> Self;And so when
Additionally, for assets where the asset ID does not match (like non-fungible assets), That's why I thought we'd need separate It does seem generally useful if either the
The double-tree model enables this directly and in the flat model, I think this could be done via the hook defined as |
Beta Was this translation helpful? Give feedback.
-
|
Just to ensure
USDC doesn't give you yield just for holding it. And no other stablecoin does (to my knowledge). Holding the coin is not an economic activity and cannot generate yield. I think it is super important to align what we build on real use cases before we build it. But I also don't know which standards and coin-types are used most. I think @onurinanc can help here. Does it help with the decision if we come up with a list? |
Beta Was this translation helpful? Give feedback.
-
From an implementation perspective, the encrypted token is a great example for the double-tree. I think Penumbra’s current usage mainly turns a public token into a shielded token to make it usable as a privacy token. But since we can already have naturally private tokens on Miden, I’m not sure this would add any extra value from a privacy perspective.
I believe there is no issue issue with exchange-rate–based tokens since (I don’t think it makes sense to merge based on the exchange rate, since it can change every second, even every millisecond) we can already merge by I think a private yield-bearing stablecoin is a very fitting example here. The idea is that users hold a stablecoin and are earning a small return over time. This already exists in many banks as well, where you get an interest rate just for holding a regular currency such as USD/EURO. There are already non-private versions of this use-case in Ethereum.
These two versions can be implemented using Approach 3. There is also a version of this implemented via an exchange rate: "syrupUSDC". But when we look at it, the current rate is around $1.14 (functionally it behaves like a yield-bearing stablecoin, but visually it no longer looks like a stablecoin). In other words, it is implemented like a simple coin using an exchange-rate. However, I don't think every token issuer desire to implement it with a similar approach. That’s why I think enabling both styles of implementation is the right approach if we want more variation and flexibility. @Dominik1999 @mmagician I have created a table below to compare the use cases with approach 1 & approach 3.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks @onurinanc, this is super helpful. Two follow-up questions (I hope here is the right place):
|
Beta Was this translation helpful? Give feedback.
-
|
It seems like Tempo is building in the mechanism for direct token rewards into their TIP-20 standard. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Motivation
The current asset model in Miden supports fungible and non-fungible assets, which are a way for users to represent value and ownership on-chain. This model couples the transaction kernel to these specific asset types as it handles construction, modification, and destruction of these assets. I think this coupling is undesirable as it makes the protocol hardcoded to those two asset types and makes extension from users impossible.
A more generic and decoupled approach would be to adopt an object-based model, where asset types are represented as user-defined objects defined outside the kernel but managed by it. The kernel would operate on these objects as opaque entities, focusing solely on object management rather than specific asset logic. This change would make the programming model more adaptable and better at handling diverse use cases. At the same time it would make the transaction kernel and protocol at large agnostic to the concrete assets/objects that are represented.
Idea
The basic idea is to have the transaction kernel manage objects. An object represents value or ownership, just like assets, but is user-defined. The details of each object would be implemented outside the kernel, keeping the kernel decoupled. In this model the kernel would only know about objects as black boxes and offer generic methods for creating, setting and getting fields as well as destroying them.
To illustrate this further, here are a few bullet points to hopefully get the idea across. I might be missing some details of how the current asset model has evolved and whether some of its limitations are byproducts of constraints I don't know about. I might even be thinking incorrectly about the asset model. It's intended both as a proposal but also as a way to learn more about the design choices that led to the current model in case I have misunderstandings.
I'll try to explain what I mean in more detail with an example. Let's say we want to represent a fungible asset issued by a faucet in this object model.
miden_stdlibrary (i.e. aMastForest) which is published as a package on-chain. It could contain amiden_std::Cointype to represent what are now fungible assets.0to differentiate between different object types from the same package.miden_std::Coinobjects have different IDs.miden_std::Coincan only be modified throughmiden_std::Coin::*procedures.Here is a more concrete visual example for how issuing a new type of
Coinmight work, which builds on the proposed VM component model.In this example, a user wants to issue a
Coinof theExampleflavor, i.e. a type they defined. To do so, they execute a transaction against their own account whose code package isuser_package. Here, every package is run in a separate VM component whose ID is the package ID (assuming that's feasible). When the account callsmiden_std::Coin::new, it passes a pre-existingExampleobject (just to keep this simple) from its vault andmiden_std::Coin::newwould verify that the issuer of thisuser_package::Exampleobject is the calling component, i.e. that the issuer account ID and the component ID are equal. This might still require something like thecallerinstruction. This is something only theCoin::newprocedure would do. ACoin::get_amountprocedure could be executed by any caller as it does not require any kind of authentication.In the second step,
kernel::create_objectwould create a newCoinobject whose issuer is set to the component ID ofmiden_stdwhich is the same as themiden_stdpackage ID. So more generally, this allows objects of typepackage_id::Typeto be created/modified/destroyed only by procedures that are defined in the package with IDpackage_id.The
Coinobject would store in one of its fields that it is of flavorExample. Then, twoCoin<Example>objects could be merged into one by aCoin::mergeprocedure, but it would fail if called onCoin<Example>andCoin<OtherType>.The
Coinobject is returned to the control of the user account component and it can choose to store it in its vault or transfer it to a note via a call to another kernel procedure.I hope this covers a rough, high level idea of this approach.
Advantages
NameObject { name: Word }type which represents ownership over a name and the capability to update it.StakedExampleobject which represents a receipt for having stakedCoin<Example>and represents the capability to unstake and retrieve the staked coins.Cointype there could be aTreasuryCapabilityobject type which gives whoever owns it, the right to increase or decrease the supply of aCoin<T>. Burning the object would make the supply verifiably fixed. This is the kind of stuff we could technically have with the asset model as well, by introducing a "fungible faucet treasury capability", but we wouldn't realistically do it because it would be a manual extension of the protocol. With an object based model this would be comparatively easy.CoinandTreasuryCapability).NameObjectas a non-fungible asset, which must be hashed first to verify it is the actual pre-image. This must be done for every user-defined asset in the current model, iiuc.NameObjectrather than a name object which is hashed into aNonFungibleAsset. E.g. a name service could describe in its API docs that to change the ID to which a name points, aNameObjectmust be provided to prove ownership over it rather thanNonFungibleAsset, which is less clear.miden_stdand the kernel can evolve independently over time.NonFungibleAssetobject, that works the same as the current one, i.e. it commits to something. In the future, new object types could be defined without having to upgrade the protocol.Drawbacks
Inspiration
The above is an idea for an object-based model on Miden, replacing the current asset model. It is inspired by Sui Move's object-based programming model. I personally really enjoyed using their object model as a developer and think that Miden could benefit from something similar, so the above is an adaptation to hopefully fit into Miden's architecture. Here is a link to Sui's
Cointype to get an idea of what methods could be possible and how different object types could be used together.Conclusion
There are probably many details I haven't though of, as this would be a pretty big change. I would be interested if anyone sees the merits in something like this, especially from a developer perspective and if we should explore this further. Thanks for taking the time to read and I would be happy to receive feedback on this!
Beta Was this translation helpful? Give feedback.
All reactions