Multisig for miden-lib
#1216
Replies: 7 comments 7 replies
-
|
A few questions:
The approach of signing data off-chain makes more sense to me, although there might be use cases where posting signed data on-chain is beneficial. Multi-signature Account Wallet Rough Draft OutlineThis is a rough outline of how a Miden multisig account could be created:
Each owner could sign the hash of the note they want to create or consume. The JSON structure would look like this: {
"proposed_note": {
"RECIPIENT": "0x123",
"note_execution_hint": "0",
"note_type": "1",
"tag": "0x123",
"expiration_time": "1741883656"
},
"proposed_tx": [
"note_hash"
],
"owner_signature": [
"sig1",
"sig2",
"sigN"
]
}Owners would circulate this JSON, each signing the Once The A similar approach would be taken for a procedure that would consume notes. Or the logic could be combined into a single state transition function that would take in input and output notes. With this approach, the multisig can be a private account, and any owner (or even someone who is not an owner) can submit a transaction to the multisig. With this method the multisig could create P2ID, P2IDR, and SWAP notes. This approach is currently feasable, as long as it is relatively straight forward to get the public key of a signature in the MidenVM. Signing the account delta of the multisigAnother idea which @bobbinth and @Dominik1999 mentioned which would add a very strong security feature would be for the owners to sign the account delta of the multisig in addition to the hash of all the notes that are created / consumed. This would assure that for any state change the owners of the multisig would have to explicitly sign the account delta of the multisig. However, currently it is not possible to get the account delta hash of an account at the end of a transaction. The only thing that signing the account delta hash doesn't secure against (and why signing it may be redundant) is that it doesn't check to whom an asset was sent by the multisig. Say Alice & Bob sign the account delta hash of their multisig, if Alice & Bob agree to send 1 BTC to Charlie, theoretically the account delta hash wouldn't be able to prevent Bob swapping out the output note to send 1 BTC to Eve (in a simple example where only the hash of the acccount delta is used). This is why I think maybe it might be redundant to sign the hash of the account delta since signing the hash of the input / output notes of the multisig is sufficient to prove that quorum was reached for a state transition of the multisig. |
Beta Was this translation helpful? Give feedback.
-
|
Assuming we are talking about a basic multisig here (e.g., We'd need to create a new account authentication method - e.g., something like
We's also need to create a new account component which would contain the authentication procedure - something like Another thing we'd need is to have a way to execute a transaction up to the point when the signatures need to be verified. This is needed to generate a message for the signers to sign. The message itself could be a combination of input/output note hashes and initial/final account state hashes (kind of what we do for the simple Executing transactions in such a way is kind of possible now, but it would be super clunky. So, we should think how to add this functionality to the Once we have a message to sign, we could send it around as a part of the structure described by @partylikeits1983. Basically, the coordinator would send this structure to the signers, collect the signatures from them, and then execute the transaction from start to finish (which would also verify the signatures). |
Beta Was this translation helpful? Give feedback.
-
Nice approach overall. We should be able to generalize this to sign a message consisting of the input notes, output notes and account delta. This is discussed in #1198 and the message structure is summarized in task 2 of #1198 (comment). Then we should be able to generalize your approach to sign a generic transaction instead of creating a specific note, but maybe that was your intention anyway. For simplicity, I think adding an off-chain multi sig like this first is best. Weighted MultisigAs an idea, instead of implementing a k of n scheme, we could go with a weight/threshold approach. The basic idea is that a multisig consists of some signers Examples:
This is just an idea. Whether it warrants the slightly higher complexity depends on the use cases and we could also start with a simpler scheme. Here are some resources on this:
In-Account multi sigWhat I mean by "in-account" is to coordinate the multi sig over an account on-chain (presumably a public one). That would not require off-chain communication channels. One possible approach is, following Dominik's suggestion, to create an account with a storage layout like this:
For this example, assume two signers with weight 1 and threshold 2. That account now has two exported procedures for authentication:
This is essentially access control to ensure that individual signers can only modify the account by expressing their approval to certain transactions. Anything else requires a multi-sig, including updating the threshold or the public keys. An alternative to implementing this access control in one account is to split this up into two accounts. One "signature aggregator account" aggregate the signatures using a similar approach as
The |
Beta Was this translation helpful? Give feedback.
-
|
@VAIBHAVJINDAL3012 thanks for today's call. As discussed, as a first step, we should create a table of features that Safe has on the EVM in one column and features that we will support in the other. We will also add some features, like privacy, that do not exist on the EVM yet. Another feature we could add is rate limiting. We can use that for our initial design. The goal is to create a PoC (including a frontend) until end of July. |
Beta Was this translation helpful? Give feedback.
-
|
Proposal: Threshold-Based Multisig Account (Private, Off-Chain Coordination) The design is guided by the following assumptions:
💡 Design Summary
|
Beta Was this translation helpful? Give feedback.
-
No, I am talking about the private notes, which are shared to all the parties off chain through some offchain mechanism.
Yes, Agree with your point. I was of the assumption that note creation cost will be very less, as proving is done by the client itself. So I didn't think of the note cost.
I was thinking of using the gmail rail, as it is the most used, so very less friction for users.
I have written the masm file for this. Putting it in modified auth component will work, but I agree we need account_delta. |
Beta Was this translation helpful? Give feedback.
-
Yes, Make sense
Yes, account_delta would cover all the edge cases which we might have with other approaches. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Feature description
Add a multi-sig contract to
miden-libOne of Miden's core use cases will be private, compliant DeFi. For example, VCs or whales could anonymously hold and trade their assets on Miden OTC. For most DeFi use cases, especially for VCs, whales, and institutional use cases, we need a good multisig. We should have a standard implementation of a basic multi-sig that can be used to build prototypes or even as a blueprint for teams like Gnosis Safe to start.
The Design is not clear yet
It is not clear what the best design would be. I have some ideas of how this could work, but I want to use this issue to align on a design. Assume we want to create a multi-sig contract (as an account component) that requires n/m signatures.
Storing the public keys in a
StorageMapToday, the
authsmart contract assumes a public key on slot0(see https://github.com/0xPolygonMiden/miden-base/blob/cf708732f17b2c62b744dc37edd3dd028bf21435/crates/miden-lib/asm/miden/contracts/auth/basic.masm#L9). For multi-sigs, instead of a single public key, we can store aStorageMapand add several keys to it.Signing the account delta
Next, one initiator could create a message
Mthat reflects the account delta after the proposed change. I think @PhilippGackstatter already knows how this could be created and signed outside the Miden VM.This message,
M,could now be stored on-chain in anotherStorageSlotor even passed around off-chain. If we choose to store the messageMon-chain, we need to allow storage of the message even with only one signature. There might be potential attack vectors here.Next, other signers could obtain that message
Meither on-chain or off-chain and sign it with their key locally. This process can be repeated untilnout ofmis achieved.Execute the transaction
The last signer would inject
Mthat is signed withndifferent signatures into the transaction and the multi-sig contract needs to check the signature against the stored public keys in slot0similarly to how we do it in our basic auth contract.Ideally, the transacting account would inject which signing parties signed as
TransactionArgsto make the contract more efficient.Next steps: start discussing different designs
Why is this feature needed?
No response
Beta Was this translation helpful? Give feedback.
All reactions