feat: Account Abstraction beta #9586
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for GitHub. 6 Skipped Deployments
|
iota-ci
added
sc-platform
miker83z
force-pushed
the
vm-lang/aa-auth/8805-beta-feature-branch
branch
from
1ed444b to
ad3bcf7
Compare
miker83z
force-pushed
the
vm-lang/aa-auth/8805-beta-feature-branch
branch
from
2380306 to
2319e6c
Compare
begonaalvarezd
approved these changes
Jan 19, 2026
polinikita
approved these changes
Jan 19, 2026
kodemartin
approved these changes
Jan 19, 2026
Contributor
Author
|
Currently, the merging is blocked by this issue: #9862 |
This PR cherry picks 2 commits in common to enable authenticator and move view attributes at the move level. Changes: 1. Added a generic FlavoredAttribute which can then allow us to define new attributes within the iota_mode compiler part. 2. Introduces a new protocol feature flag (iota_metadata_module_bytes) to allow the insertion of metadata in the serialized compiled modules (bytecode). This kind of operation was disabled before this PR, with the flag no_extraneous_module_bytes. Instead, iota_metadata_module_bytes allows to fill this metadata field during the execution of build_from_resolution_graph. At the module deserializer level, the only performed check is that metadata have only 1 field and the metadata key is hardcoded. During the execution of the iota-verifier, the metadata value is checked for having well formed metadata struct (later authenticate and view functions checks will be performed here). - [x] Protocol: Added metadata_in_module_bytes flag to allow the insertion of IOTA specific metadata in the serialized compiled modules (bytecode). - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API:
) This PR introduces the creation of a Package Metadata immutable object during a package publishing/upgrade. This allows to use such metadata to create `AuthenticatorInfoV1` instances for accounts. [Internal AA architecture document](https://iotafoundation.atlassian.net/wiki/x/EoBOng). Description: - every time a function uses the `#[authenticator]` annotation, the node’s publish/upgrade execution tries to create a `PackageMetadata` immutable object. - a new set of functions in the `iota-verifier` crate implement the checking of the requirements for a package metadata to be valid; the information for such validation is extracted from the package bytecode (see #9453) - `iota-verifier::verify_authenticate_func_v1` checks the correctness of the declared authenticate() function (that was previously annotated with - once the PackageMetadata immutable object is created, then the framework method `create_auth_info_v1` can be used as the only way to create an `AuthenticatorInfoV1` instance. - the `AuthenticatorInfoV1` struct includes the fields to uniquely identify a function on-chain: package id, module name, function name. - An Account object is an object with a dynamic field being a `AuthenticatorInfoV1`. - Then, to any user-created object, an `AuthenticatorInfoV1` can be “attached“. The only requirement is that the AuthenticatorInfoV1<T> is compatible with T, where T is exactly the type of the object set to become an Account. - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [x] Patch-specific tests (correctness, functionality coverage) - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes - [x] Protocol: Add the publish_package_metadata. This enables the creation of an immutable object at publish/upgrade time when some known attributes (e.g., the authenticator function attribute) are found in the source code. - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API: --------- Co-authored-by: Valerii Reutov <valeriy.reutov@gmail.com> Co-authored-by: Pavlo Botnar <pavlo.botnar@gmail.com>
miker83z
force-pushed
the
vm-lang/aa-auth/8805-beta-feature-branch
branch
from
4091901 to
e1963cf
Compare
…AA transactions (#9492) This part involves the development of a new iota type to represent a new `GenericSignature` variant, that is the `MoveAuthenticator` type, and a execution path to authenticate an Account being the sender of a TX. [Internal AA architecture document](https://iotafoundation.atlassian.net/wiki/x/EoBOng). - The `MoveAuthenticator` type has a unique field which is `call_args`; this is a vector of `CallArg` working similarly to the `ProgrammableTransactionBlock` inputs. - The `MoveAuthenticator` is used to pass the inputs to the move call indicated by the `AuthenticatorInfoV1` found attached to the Account object. - This authentication job is performed by the Validator, which: - checks that the `MoveAuthenticator` is correctly formed - loads `MoveAuthenticator` input objects at a specific version - loads the `AuthenticatorInfoV1` from the account object dynamic field - finally, executes the `authenticate()` function (that has no effects to store) - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [x] Patch-specific tests (correctness, functionality coverage) - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes - [x] Protocol: Add the flag move_auth and the protocol parameter max_auth_gas, which allow to enable the authentication of Abstract Accounts and define the maximum gas budget allowed for the execution of the authentication. - [x] Nodes (Validators and Full nodes): Enable the authentication of Abstract Accounts. - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [x] Rust SDK: Add a new GenericSignature variant named MoveAuthenticator, which allows to authenticate Abstract Accounts. - [ ] REST API: --------- Co-authored-by: Valerii Reutov <valeriy.reutov@gmail.com> Co-authored-by: Pavlo Botnar <pavlo.botnar@gmail.com> Co-authored-by: marc2332 <mespinsanz@gmail.com>
# Description of change Adds the support for creating package metadata in transacitonal test runner. This also adds the `abstract` command, that allows to generate test ptb with Move authenticators. Co-authored-by: Valerii Reutov <valeriy.reutov@gmail.com> Co-authored-by: Pavlo Botnar <pavlo.botnar@gmail.com>
…n and support deny for move authenticators (#9592) The account creation Move API was simplified by removing `AuthenticatorInfoV1CompatibilityProof`. Support `Deny` for Move authenticators on the signing phase. fixes #9459 fixes #8856 - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [x] Patch-specific tests (correctness, functionality coverage) - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes --------- Co-authored-by: Valerii Reutov <valeriy.reutov@gmail.com>
…t Account could be created more easily + aa gas funding (#9604) # Description of change **Added subcommand** is `publish-deps`. A new `publish-deps` subcommand that compiles and publishes support Move modules from a given path. Path can be relative to iota root directory or absolute. It looks like: ``` //# init --addresses test=0x0 --accounts A //# publish-deps --paths crates/iota-adapter-transactional-tests/data/account_abstraction/abstract_account.move //# publish --sender A --dependencies aa ``` **Added subcommand** is `init-abstract-account`. This subcommand creates and funds Abstract Accounts in tests. Wiring between Abstract Accounts and the existing `abstract` subcommand. `Abstract` subcommand is using abstract_accounts collection to get an early created abstract account as a TestAccount instance(gas is included). Example of new subcommand usage: `//# init-abstract-account --sender A --package-metadata object(3,1) --inputs "authenticate" "authenticate_hello_world" --aa-create-fn-path aa::abstract_account::create --aa-type AbstractAccount` ## Links to any relevant issues Fixes #9276 . Fixes #9277 . ## How the change has been tested Run iota-adapter-transactional-tests tests With `cargo simtest`
…ctions and add tests (#9568) # Description of change - Simplify authenticator fn checks and make them similar to an entry function checks, without requiring the function to have the `entry` modifier. - Adds new tests in iota-verifier-transactional-test-runner. ## Links to any relevant issues Fixes #9370 Fixes #9512
# Description of change All the examples in this PR are fixed and ready to be merged. There are a couple of approaches that were used when the examples were created: 1. `Stand-alone accounts`. A package contains the account struct itself as well as the related authentication logic. 2. `IOTAccount`. An example where an account is implemented to be extended with data and the related authentication logic from 3rd-party packages. This example is not finished yet; it requires security rules to be implemented to control access to the internal state. 3. `Extension packages`. Packages where data(a public key, etc.) and the related authenticator logic are implemented in a dedicated module; It makes it possible to reuse such utilities when a new account type is implemented. We need to define an approach(es) that we want to demonstrate to users and categorize the examples in a separate pull request. --------- Co-authored-by: Valerii Reutov <valeriy.reutov@gmail.com>
) Added getters to `AuthenticatorFunctionRefV1`. Added `authenticator_function_tests.move`. fixes #9649
# Description of change Test Abstract Account implemented as immutable object scenarios. A bug was found during implementation, which is related to merging authenticator and the transaction inputs. ## Links to any relevant issues fixes #9516
…ators (#9693) # Description of change New aa tests that use random object have been implemented: `randomness.move` ## Links to any relevant issues Fixed #9583 . ## How the change has been tested Run iota-adapter-transactional-tests tests With `cargo simtest` --------- Co-authored-by: miker83z <mirko.zichichi@iota.org>
Add events to `account.move`. fixes #9650 --------- Co-authored-by: miker83z <mirko.zichichi@iota.org>
…ple (#8959) # Description of change Implement "Account with Spending limit" example for abstract accounts. ## Links to any relevant issues fixes #8651 ## How the change has been tested - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [ ] Patch-specific tests (correctness, functionality coverage) - [ ] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes --------- Co-authored-by: miker83z <mirko.zichichi@iota.org>
# Description of change Rename `new_for_testing` to `new`. ## Links to any relevant issues Closes #9797 ## How the change has been tested - [ ] Basic tests (linting, compilation, formatting, unit/integration tests) - [ ] Patch-specific tests (correctness, functionality coverage) - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] I have checked that new and existing unit tests pass locally with my changes
- Bump protocol version to v19 to prepare merge to develop - Set max_auth_gas to 250_000_000 NANOs - Update snapshots
miker83z
force-pushed
the
vm-lang/aa-auth/8805-beta-feature-branch
branch
2 times, most recently
from
4317a1a to
67d82bb
Compare
Dr-Electron
approved these changes
Jan 26, 2026
Contributor
Dr-Electron
left a comment
Dr-Electron
left a comment
There was a problem hiding this comment.
Approving the examples. Just a comment about gitignore usage and once sentence
Add Account Abstraction support to the CLI. Fixes #9408 - [ ] Basic tests (linting, compilation, formatting, unit/integration tests) - [ ] Patch-specific tests (correctness, functionality coverage) - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] I have checked that new and existing unit tests pass locally with my changes - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [X] CLI: Abstract Account support - `KeyStore` can store account addresses (`StoredKey::Account`) - `iota keytool` can handle account addresses - `iota client add-account` and `iota client sign` commands - `iota client` `--auth-call-args` and `--auth-type-args` options - `iota client ptb` `--auth-call-args` and `--auth-type-args` options - [ ] Rust SDK: - [ ] REST API: --------- Co-authored-by: Thoralf Müller <thoralf.mue@gmail.com>
# Description of change Based on this scenario -> #9371 Receiving objects could be used to make AA TX certificates invalid, even after these were signed by the majority of validators. This PR makes so that any TX trying to receive an object owned by an AA account (i.e., an object having a `AuthenticatorFunctionRef` dynamic field) would abort execution (a validator could still sign the certificate, but the execution makes sure that the received objects will not be received and won't bump the sequence number). This PR also fixes a small issue related to duplicate function names in a package. ## Links to any relevant issues Closes #9371 Fixes #9862 ## How the change has been tested - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [x] Patch-specific tests (correctness, functionality coverage) - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes --------- Co-authored-by: Dkwcs <pavlo.botnar@gmail.com>
miker83z
force-pushed
the
vm-lang/aa-auth/8805-beta-feature-branch
branch
from
67d82bb to
1f3c4ec
Compare
valeriyr
approved these changes
Jan 27, 2026
roman1e2f5p8s
approved these changes
Jan 27, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of change
Enables Account Abstraction core features at the protocol level.
Internal AA architecture document.
Main protocol changes:
feat(move): Add custom attributes feat(move): Add custom attributes #9453
metadata_in_module_bytes).feat(execution): create a package metadata object at publish time feat(execution): create a package metadata object at publish time #9461
#[authenticator]annotation, the node’s publish/upgrade execution tries to create aPackageMetadataimmutable object;iota-verifiercrate implement the checking of the requirements for a package metadata to be valid;create_auth_function_ref_v1can be used as the only way to create anAuthenticatorFunctionRefV1instance.AuthenticatorFunctionRefV1struct includes the fields to uniquely identify a function on-chain: package id, module name, function name.AuthenticatorFunctionRefV1.feat: Add the MoveAuthenticator generic signature variant and enable AA transactions feat: Add the MoveAuthenticator generic signature variant and enable AA transactions #9492
GenericSignaturevariant, that is theMoveAuthenticatortype, and a execution path to authenticate an Account being the sender of a TX.MoveAuthenticatortype has a unique field which iscall_args; this is a vector ofCallArgworking similarly to theProgrammableTransactionBlockinputs.MoveAuthenticatoris used to pass the inputs to the move call indicated by theAuthenticatorFunctionRefV1found attached to the Account object.MoveAuthenticatorinput objects at a specific version; (2) then, executes theauthenticate()function referenced byAuthenticatorFunctionRefV1, having no effects to store to the ledger.