[aip-55] Generalize Transaction Authentication and Support Arbitrary K-of-N MultiKey Accounts #263

davidiw · 2023-10-16T23:28:15Z

No description provided.

hariria · 2023-10-16T23:37:13Z

aips/aip-55.md

+---
+aip: 55
+title: Generalize Transaction Authentication and Support Arbitrary K-of-N MultiKey Accounts
+author: davidiw, hariri


hariria :)

aips/aip-55.md

hariria

Looks good!

alinush · 2023-10-17T22:39:16Z

aips/aip-55.md

+## Summary
+
+Transactions submitted to Aptos contain a `RawTransaction` and a `TransactionAuthenticator`. The `TransactionAuthenticator` authorizes the execution of the transaction by the set of senders or approvers of the accounts within the transaction. The `TransactionAuthenticator` contains a mixture of general purpose authenticators like fee payer and multiagent but also some very specific types for single sender transactions such as Ed25519, MultiEd25519, and Secp256k1. Thus adding a new cryptographic proof for authorizing a transaction requires a new `TransactionAuthenticator` and `AccountAuthenticator` variant to support both the single and multiparty transaction authenticaton.
+


I never had time to understand this: why do we have both TransactionAuthenticator and AccountAuthenticator?

alinush · 2023-10-17T22:44:27Z

aips/aip-55.md

+
+## Alternative solutions
+
+This work could have focused purely on multi-key solutions that work across the board. This would have eliminated the optimization for single-sender applications. Doing so increases the burden for creating adding cryptographic algorithms for authorization.


Typo: "creating adding" should have been just "adding"?

alinush · 2023-10-17T22:46:06Z

aips/aip-55.md

+}
+
+pub struct MultiKeyAuthenticator {
+    public_keys: MultiKey,


You need to define the MultiKey struct.

Also, why not replace MultiKey by a Vec<AnyKey>?

because we use MultiKey in the AuthenticationKey generation, will add context

alinush · 2023-10-17T22:47:32Z

aips/aip-55.md

+
+New cryptographic algorithms can be added by adding an appropriate data structure and verify method under `AnyKey` and `AnySignature`.
+
+The `MultiKeyAuthenticator` supports up to 255 keys and up to 32 signatures, as 32 signatures are the maximum allowed in a single transaction.


Can you clarify why is 32 the maximum? Is it because you assume signatures are, say 32 bytes, so $32 \times 32$ bytes is $960$ bytes which gets close to a potential 1KiB limit in the code?

Also, does this mean in a $t$-out-of-$n$ multikey address cannot have $t > 32$?

it is a legacy component of the code, will clarify

alinush · 2023-10-17T22:49:34Z

aips/aip-55.md

+
+Instead of doing this at an account level, we could have used Multisigv2. In Multisigv2, multiple on-chain accounts share a single account. This is similar to the model here, where multiple keys share the same account. The caveat being that if keys are misplaced in a Multisigv2, the assets within those accounts are lost. Those accounts require minimally gas fees, so there would be inevitable loss.
+
+## Specification


I see nothing mentioned here about how the address (a.k.a., authentication key) of such "multikey" accounts is computed...

alinush

Explain the MultiKey struct
Explain what multikey addresses look like (and how to deal with complications when wallets lose some of the PKs underneath a multikey address and, as a result, are not able to reconstruct the address)
Maybe take the opportunity to explain the difference between TransactionAuthenticator and AccountAuthenticator
Writing is incredibly difficult to follow for me due to poor use of terminology / undefined terms

…K-of-N MultiKey Accounts

davidiw

feedback addressed

davidiw · 2023-10-17T23:54:57Z

aips/aip-55.md

+}
+
+pub struct MultiKeyAuthenticator {
+    public_keys: MultiKey,


because we use MultiKey in the AuthenticationKey generation, will add context

davidiw · 2023-10-18T00:08:37Z

aips/aip-55.md

+
+New cryptographic algorithms can be added by adding an appropriate data structure and verify method under `AnyKey` and `AnySignature`.
+
+The `MultiKeyAuthenticator` supports up to 255 keys and up to 32 signatures, as 32 signatures are the maximum allowed in a single transaction.


it is a legacy component of the code, will clarify

davidiw requested review from alinush, zekun000, sherry-x, movekevin and igor-aptos October 16, 2023 23:28

hariria reviewed Oct 16, 2023

View reviewed changes

hariria reviewed Oct 17, 2023

View reviewed changes

aips/aip-55.md Outdated Show resolved Hide resolved

hariria approved these changes Oct 17, 2023

View reviewed changes

alinush reviewed Oct 17, 2023

View reviewed changes

alinush requested changes Oct 17, 2023

View reviewed changes

[aip-55] Generalize Transaction Authentication and Support Arbitrary …

ef5d69a

…K-of-N MultiKey Accounts

davidiw force-pushed the 55 branch from 556cc2b to ef5d69a Compare October 18, 2023 01:00

davidiw commented Oct 18, 2023

View reviewed changes

thepomeranian approved these changes Oct 18, 2023

View reviewed changes

thepomeranian requested a review from alinush October 18, 2023 22:14

alinush approved these changes Oct 18, 2023

View reviewed changes

davidiw merged commit 3f0541b into main Oct 18, 2023

davidiw deleted the 55 branch October 19, 2023 15:21

0xmaayan mentioned this pull request Oct 20, 2023

Introduce Single Sender transaction authenticator aptos-labs/aptos-ts-sdk#84

Merged

0xmaayan mentioned this pull request Oct 29, 2023

Implement MultiKey authentication key aptos-labs/aptos-ts-sdk#141

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[aip-55] Generalize Transaction Authentication and Support Arbitrary K-of-N MultiKey Accounts #263

[aip-55] Generalize Transaction Authentication and Support Arbitrary K-of-N MultiKey Accounts #263

davidiw commented Oct 16, 2023

hariria Oct 16, 2023

davidiw Oct 17, 2023

hariria left a comment

alinush Oct 17, 2023

alinush Oct 17, 2023

alinush Oct 17, 2023

davidiw Oct 17, 2023

alinush Oct 17, 2023

alinush Oct 17, 2023

davidiw Oct 18, 2023

alinush Oct 17, 2023

alinush left a comment •

edited

Loading

davidiw left a comment

davidiw Oct 17, 2023

davidiw Oct 18, 2023

		## Summary

		Transactions submitted to Aptos contain a `RawTransaction` and a `TransactionAuthenticator`. The `TransactionAuthenticator` authorizes the execution of the transaction by the set of senders or approvers of the accounts within the transaction. The `TransactionAuthenticator` contains a mixture of general purpose authenticators like fee payer and multiagent but also some very specific types for single sender transactions such as Ed25519, MultiEd25519, and Secp256k1. Thus adding a new cryptographic proof for authorizing a transaction requires a new `TransactionAuthenticator` and `AccountAuthenticator` variant to support both the single and multiparty transaction authenticaton.


		## Alternative solutions

		This work could have focused purely on multi-key solutions that work across the board. This would have eliminated the optimization for single-sender applications. Doing so increases the burden for creating adding cryptographic algorithms for authorization.


		New cryptographic algorithms can be added by adding an appropriate data structure and verify method under `AnyKey` and `AnySignature`.

		The `MultiKeyAuthenticator` supports up to 255 keys and up to 32 signatures, as 32 signatures are the maximum allowed in a single transaction.


		Instead of doing this at an account level, we could have used Multisigv2. In Multisigv2, multiple on-chain accounts share a single account. This is similar to the model here, where multiple keys share the same account. The caveat being that if keys are misplaced in a Multisigv2, the assets within those accounts are lost. Those accounts require minimally gas fees, so there would be inevitable loss.

		## Specification

[aip-55] Generalize Transaction Authentication and Support Arbitrary K-of-N MultiKey Accounts #263

[aip-55] Generalize Transaction Authentication and Support Arbitrary K-of-N MultiKey Accounts #263

Conversation

davidiw commented Oct 16, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hariria left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alinush left a comment • edited Loading

Choose a reason for hiding this comment

davidiw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alinush left a comment •

edited

Loading