Open Dominik1999 opened 6 months ago
I would separate creating a new account with custom code and updating code in an account into two separate issues.
As a user, I want to create accounts with custom code using the Miden client. I want to use a CLI command like
miden-client account new <type, e.g., basic-mutable> custom <PATH_TO_DIRECTORY/FILE_NAME>
Whereas in the CLI expects in
one *.masm
file.
This may not be sufficient as besides the code we may need to provide additional data. For example, for basic wallet, we also need to define initial state of the storage (to store the public key for the account). So, we probably need to come up with a more comprehensive approach here to describe not only the MASM code that is needed for the account, but also how the initial state of the storage is to be constructed.
I would separate creating a new account with custom code and updating code in an account into two separate issues.
As a user, I want to create accounts with custom code using the Miden client. I want to use a CLI command like
miden-client account new <type, e.g., basic-mutable> custom <PATH_TO_DIRECTORY/FILE_NAME>
Whereas in the CLI expects in
one *.masm
file.This may not be sufficient as besides the code we may need to provide additional data. For example, for basic wallet, we also need to define initial state of the storage (to store the public key for the account). So, we probably need to come up with a more comprehensive approach here to describe not only the MASM code that is needed for the account, but also how the initial state of the storage is to be constructed.
This is a very good point. Let us use this issue to come up with a solution. We could have a text file
[storage]
slots: [(1 : "{pub_key}")]
[code]
account_code:
"
use miden::account
begin
exec.account::get_id
end
"
I think we may need to have something a bit more sophisticated than this. For example, in the above example it is not clear how the pub key is to be generated (e.g., for which signature scheme) and what the type of the storage slot would be.
In general, we need to come up with some kind of account package format. This will also be related to the compiler as the compiler (or at least the Miden SDK part of it) would need to output the full account package which contains not only the code but also the description of the expected storage structure.
cc @greenhat and @bitwalker
Are those two separate questions?
For example, in web3.js the users simply provides a JSON with the contract data in byte code. So we could use a similar method to create accounts with custom code.
Then, we could think in our SDK about a method how to compile an account (including its code and storage and keys) into that format.
(or is that what you meant with your last comment?)
one question could be how to inject a custom account (or smart contract) into the Miden client to be deployed on the blockchain.
I believe we already have this (via importing .mac
files into the client). Basically, as long as we can serialize an account into a .mac
file, the client should be able to import it.
another question could be how to create the custom smart contract, including the public key
This is the main question, I think. And then maybe this is not an issue for the client but for miden-base
? i.e., how to create a .mac
file for custom account.
Can we already import .mac
files into the client? If so, we can close this issue and open one in miden-base
.
We can also use the Playground to create custom accounts for builder's testnet @gubloon.
It is indeed possible to import *.mac
files, where each file is a serialized AccountData
instance
I would probably still keep this issue open for now. It might be good to provide an ability through the client to create custom accounts - even if that's just pass-through functionality for miden base.
The only add-on here would be to show the account code. We could add a CLI command, such as ... account show code or something similar.
@Dominik1999 just in case this is already possible with miden-client account show <ACCOUNT_ID> -c
. It also accepts -k
(keys), -v
(vault) and -s
(storage)
also, regarding the Importing custom code into accounts
section. Is the idea to create a new account (from the set of account types we already have) and override its code (while preserving the storage layout and vault). All that before uploading the account to the node. Is that different to importing an account with its .mac
file? I think the use case would be covered that way and in any case we can provide a command to generate the mac file
Sorry, I didn't see your response @mFragaBA
So the general idea is to be able to write arbitrary smart contracts and deploy them using the Miden client.
The problem is the storage layout when creating custom accounts, as described here https://github.com/0xPolygonMiden/miden-base/issues/550.
We have a solution now here https://github.com/0xPolygonMiden/miden-base/issues/667
+++ Updated Issue to summarize the discussion +++
Custom account code allows for general smart contracts
Currently, we only allow users to create accounts with standardized code (basic wallet and faucet). We want users to be able to create accounts with custom code and deploy them on Miden using the Miden client. This is the equivalent of deploying Ethereum smart contracts, and it will widen the space for use cases as users can define their account interfaces.
Importing accounts with custom code into the client
Importing accounts into the Miden client using
... account import <file_name>.mac
is already possible. If the account was created with custom code, importing it already works.The only add-on here would be to show the account code. We could add a CLI command, such as
... account show code
or something similar.This issue in miden-base is related https://github.com/0xPolygonMiden/miden-base/issues/550
Importing custom code into accounts
I also want to be able to import MASM code into an account. This is related to https://github.com/0xPolygonMiden/miden-client/issues/220. I want to use
... account new <ACCOUNT TYPE> code <PATH/TO/file_name>.masm
. Then, I want the client to read my custom account code.masm
file. Finally, I want to deploy this account, so I need to execute the first transaction against it and send the data to the Miden Node.Reading in a
.masm
file for account code is not the same as creating a full account from scratch. The user might also want to initialize custom storage or a custom auth scheme. However,AccountStorage
initialization can be done the same way we create accounts in theBasicWallet
. The storage layout would only contain 254 slots and all slot types areStorageSlotType::Value
. Slot0
and256
are reserved for the public key and theLayout
. But this is already done automatically.After initialization, the client should somehow deploy that contract by executing a transaction against it.