Add draft for DIP 169: Multi-agent Transactions #159
Conversation
emmazzz
changed the title
Co-authored-by: Bob Wilson <[email protected]>
emmazzz
changed the title
aching
requested review from
aching,
dahliamalkhi,
moeziniaf,
sblackshear and
tzakian
|
|
||
| Previously each transaction can only have one signer, which is the sender of the transaction. In the multi-agent scheme, with the ability to have multiple signers, the transaction can potentially have multiple authenticators from different accounts and of different schemes. An `AccountAuthenticator` serves as the authenticator for one account. And a `TransactionAuthenticator` can contain multiple `AccountAuthenticator`s, as shown in the next subsection. | ||
|
|
||
| Notice that `AccountAuthenticator` has a multi-signature variant `MultiEd25519`. `MultiEd25519` is a signature scheme an account uses to generate signatures. This is different from multi-agent, which is a new type of transaction. |
There was a problem hiding this comment.
Does this mean that an account using MultiEd25519 can't be part of a MultiAgentTransaction?
I don't know much about which accounts use MultiEd25519, though. Is there a reference on that?
There was a problem hiding this comment.
+1. I think it would be useful to explain how to reconcile MultiAgent and MultiEd25519 if one is a sig scheme and another a txn scheme and why they are both variants of TransactionAuthenticator?
There was a problem hiding this comment.
I believe the difference is that MultiAgent does not require to combine signatures off-chain, and the combined signature is a single signature corresponding to a single account
There was a problem hiding this comment.
- https://github.com/diem/dip/blob/main/dips/dip-11.md#authentication-key for more on MultiEd25519. Any account can use this feature
- An account using MultiEd25519 can be part of a MultiAgentTransaction (at least based on my reading of Emma's code in [diem_vm] add support for multi agent transactions diem#7427). But I think we should be careful about opening DDOS attack vectors with this. We already cap the max number of sigs in MultiEd25519 to 32 to prevent an attacker from having too many "free" signature checks. But if we also allow a max of 32 signers in a multi-agent transaction, that's 32 * 32 free signature checks...
Ideally, the addition of the multi-agent feature wouldn't give an attacker any more DDOS power, but I think we will need to tweak the rules/code a bit to ensure that.
There was a problem hiding this comment.
A check has been added to allow no more than 32 signatures. DIP has also been updated to talk about this check in section Additional Checks During Transaction Validation.
|
This is really well written and thoughtful @emmazzz, thanks! |
|
|
||
| Previously each transaction can only have one signer, which is the sender of the transaction. In the multi-agent scheme, with the ability to have multiple signers, the transaction can potentially have multiple authenticators from different accounts and of different schemes. An `AccountAuthenticator` serves as the authenticator for one account. And a `TransactionAuthenticator` can contain multiple `AccountAuthenticator`s, as shown in the next subsection. | ||
|
|
||
| Notice that `AccountAuthenticator` has a multi-signature variant `MultiEd25519`. `MultiEd25519` is a signature scheme an account uses to generate signatures. This is different from multi-agent, which is a new type of transaction. |
There was a problem hiding this comment.
+1. I think it would be useful to explain how to reconcile MultiAgent and MultiEd25519 if one is a sig scheme and another a txn scheme and why they are both variants of TransactionAuthenticator?
Co-authored-by: Fredric Moezinia <[email protected]> Co-authored-by: Avery Ching <[email protected]>
dips/dip-169.md
Outdated
| * Extensibility: In the current scheme, our dual attestation protocol is very specific to travel rule payments. And extending this protocol to dual attestation on a different type of action would require another ad-hoc data format and signature scheme. The multi-agent transaction scheme generalizes this by allowing dual attestation on any action encodable by a Move script without having to define new data formats or signature schemes. | ||
| * Security: Multi-agent scheme closes two security loopholes of our current protocol: | ||
| * Replayability: Since the payee only signs over the payer and the amount of the payment, today the payer can replay the transaction using old payee approvals. In the new scheme, this wouldn’t be possible since the payee has to sign over the sequence number of the transaction as well, disallowing any replay of the transaction. | ||
| * Currency: Today’s protocol does not let the payee commit to the currency type so the payer can reuse a payee approval for payment in one currency for payment in another with the same amount. Again, since the payee has to sign over the entire transaction including the currency type, this scenario would be impossible with the multi-agent scheme. |
There was a problem hiding this comment.
The approval message does not contain the currency, so this is indeed also a problem with the current scheme.
|
|
||
| Previously each transaction can only have one signer, which is the sender of the transaction. In the multi-agent scheme, with the ability to have multiple signers, the transaction can potentially have multiple authenticators from different accounts and of different schemes. An `AccountAuthenticator` serves as the authenticator for one account. And a `TransactionAuthenticator` can contain multiple `AccountAuthenticator`s, as shown in the next subsection. | ||
|
|
||
| Notice that `AccountAuthenticator` has a multi-signature variant `MultiEd25519`. `MultiEd25519` is a signature scheme an account uses to generate signatures. This is different from multi-agent, which is a new type of transaction. |
There was a problem hiding this comment.
I believe the difference is that MultiAgent does not require to combine signatures off-chain, and the combined signature is a single signature corresponding to a single account
|
|
||
|
|
||
|
|
||
| ### Add a New Variant to `TransactionAuthenticator` |
There was a problem hiding this comment.
Add a New Variant or a new field?
There was a problem hiding this comment.
"Variant" is the right technical term for one of the potential values of a sum type like TransactionAuthenticator.
dips/dip-169.md
Outdated
| ## Terminology: | ||
|
|
||
| * Primary signer: This is the account that the transaction is sent from. This account’s sequence number is incremented, and is the account that pays gas. There is precisely one of these for every transaction. | ||
| * Secondary signer: This is any account that participates in a multi-agent transaction that isn’t the primary sender. There can be 0-N of these. The 0 case is a normal transaction today. |
There was a problem hiding this comment.
Did we put a max on N in the code? We do this for multisig and should probably do the same + specify it here. Perhaps we can use the same limit as multisig so that an attacker has the same number of "free" signature checks in each option?
There was a problem hiding this comment.
We don't put a max on N here. Yes we should put a limit same as for multisig. Will work on that.
dips/dip-169.md
Outdated
|
|
||
| * Extensibility: In the current scheme, our dual attestation protocol is very specific to travel rule payments. And extending this protocol to dual attestation on a different type of action would require another ad-hoc data format and signature scheme. The multi-agent transaction scheme generalizes this by allowing dual attestation on any action encodable by a Move script without having to define new data formats or signature schemes. | ||
| * Security: Multi-agent scheme closes two security loopholes of our current protocol: | ||
| * Replayability: Since the payee only signs over the payer and the amount of the payment, today the payer can replay the transaction using old payee approvals. In the new scheme, this wouldn’t be possible since the payee has to sign over the sequence number of the transaction as well, disallowing any replay of the transaction. |
There was a problem hiding this comment.
There is no protection against this. The recipient does not sign the full transaction, only an (amount, sender_address, metdata) approval message. This approval message can be replayed an arbitrary number of times.
dips/dip-169.md
Outdated
| * Extensibility: In the current scheme, our dual attestation protocol is very specific to travel rule payments. And extending this protocol to dual attestation on a different type of action would require another ad-hoc data format and signature scheme. The multi-agent transaction scheme generalizes this by allowing dual attestation on any action encodable by a Move script without having to define new data formats or signature schemes. | ||
| * Security: Multi-agent scheme closes two security loopholes of our current protocol: | ||
| * Replayability: Since the payee only signs over the payer and the amount of the payment, today the payer can replay the transaction using old payee approvals. In the new scheme, this wouldn’t be possible since the payee has to sign over the sequence number of the transaction as well, disallowing any replay of the transaction. | ||
| * Currency: Today’s protocol does not let the payee commit to the currency type so the payer can reuse a payee approval for payment in one currency for payment in another with the same amount. Again, since the payee has to sign over the entire transaction including the currency type, this scenario would be impossible with the multi-agent scheme. |
There was a problem hiding this comment.
The approval message does not contain the currency, so this is indeed also a problem with the current scheme.
|
|
||
| Previously each transaction can only have one signer, which is the sender of the transaction. In the multi-agent scheme, with the ability to have multiple signers, the transaction can potentially have multiple authenticators from different accounts and of different schemes. An `AccountAuthenticator` serves as the authenticator for one account. And a `TransactionAuthenticator` can contain multiple `AccountAuthenticator`s, as shown in the next subsection. | ||
|
|
||
| Notice that `AccountAuthenticator` has a multi-signature variant `MultiEd25519`. `MultiEd25519` is a signature scheme an account uses to generate signatures. This is different from multi-agent, which is a new type of transaction. |
There was a problem hiding this comment.
- https://github.com/diem/dip/blob/main/dips/dip-11.md#authentication-key for more on MultiEd25519. Any account can use this feature
- An account using MultiEd25519 can be part of a MultiAgentTransaction (at least based on my reading of Emma's code in [diem_vm] add support for multi agent transactions diem#7427). But I think we should be careful about opening DDOS attack vectors with this. We already cap the max number of sigs in MultiEd25519 to 32 to prevent an attacker from having too many "free" signature checks. But if we also allow a max of 32 signers in a multi-agent transaction, that's 32 * 32 free signature checks...
Ideally, the addition of the multi-agent feature wouldn't give an attacker any more DDOS power, but I think we will need to tweak the rules/code a bit to ensure that.
|
|
||
|
|
||
|
|
||
| ### Add a New Variant to `TransactionAuthenticator` |
There was a problem hiding this comment.
"Variant" is the right technical term for one of the potential values of a sum type like TransactionAuthenticator.
Co-authored-by: Sam Blackshear <[email protected]> Co-authored-by: dahliamalkhi <[email protected]>
dips/dip-169.md
Outdated
|
|
||
| * Extensibility: In the current scheme, our dual attestation protocol is very specific to travel rule payments. And extending this protocol to dual attestation on a different type of action would require another ad-hoc data format and signature scheme. The multi-agent transaction scheme generalizes this by allowing dual attestation on any action encodable by a Move script without having to define new data formats or signature schemes. | ||
| * Security: Multi-agent scheme closes two security loopholes of our current protocol: | ||
| * Replayability: Since the payee only signs over the payer and the amount of the payment, today the payer can replay the transaction using old payee approvals. In the new scheme, this wouldn’t be possible since the payee has to sign over the sequence number of the transaction as well, disallowing any replay of the transaction. |
There was a problem hiding this comment.
I see. This is not an issue with single-agent transactions, it is a problem with DIP-1 which could be fixed there, right? I would prefer to tone this down and mention the issue with DIP-1.
Here, how about:
The Multi-agent natively leads to robust and secure dual-attestation protocols, since both parties sign the entire transaction.
dips/dip-169.md
Outdated
| * Extensibility: In the current scheme, our dual attestation protocol is very specific to travel rule payments. And extending this protocol to dual attestation on a different type of action would require another ad-hoc data format and signature scheme. The multi-agent transaction scheme generalizes this by allowing dual attestation on any action encodable by a Move script without having to define new data formats or signature schemes. | ||
| * Security: Multi-agent scheme closes two security loopholes of our current protocol: | ||
| * Replayability: Since the payee only signs over the payer and the amount of the payment, today the payer can replay the transaction using old payee approvals. In the new scheme, this wouldn’t be possible since the payee has to sign over the sequence number of the transaction as well, disallowing any replay of the transaction. | ||
| * Currency: Today’s protocol does not let the payee commit to the currency type so the payer can reuse a payee approval for payment in one currency for payment in another with the same amount. Again, since the payee has to sign over the entire transaction including the currency type, this scenario would be impossible with the multi-agent scheme. |
This PR adds draft for DIP 169: muli-agent transactions.
Issue for discussion is here: #169