feat(aa): TEMP PR in preparation for beta #8807
Draft
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
…ve_authenticator (#8138) # Description of change - Added `MoveAuthenticator` new variant for `GenericSignature` that implements `AuthenticatorTrait` trait. - new protocol variable `max_auth_gas` has been provided and set as 1000000000. - openrpc and protocol snapshots have been updated. ## Links to any relevant issues Fixes #8118 . ## How the change has been tested Check snapshots - `cargo insta review`
#8179) # Description of change - Added new types that represent `AuthContext` and `MoveAuthenticatorDigest`. - AuthContext contains `MoveAuthenticatorDigest` and tx_inputs, tx_commands(ProgrammableTransaction content) Comparing to `TransactionDigest` only covers for the TransactionData part,`MoveAuthenticatorDigest ` only covers for the `GenericSignature` part and it is only needed during the `authenticate()` execution ## Links to any relevant issues Fixes #8164 . ## How the change has been tested Check snapshots - `cargo insta review`
# Description of change A new function has been added to `Executor` that implements smart account transaction verification by calling the related Move authenticator. It is intended to be called during the processing of a smart account transaction to unlock the corresponding smart account and allow the transaction to be executed. This function is integrated in the following PR: #8167 ## Links to any relevant issues fixes #8119 --------- Co-authored-by: Mirko Zichichi <[email protected]>
# Description of change Introduced `programmable_transaction.move` and `auth_context.move` in the framework, in order to represent these types in Move. Closes #8122 Closes #8165 ## How the change has been tested `programmable_transaction_tests` has been tested using `iota move test` ### Release Notes --------- Co-authored-by: miker83z <[email protected]>
…ema (#8167) # Description of change Integrated the `Executor:: validate_transaction` function implemented in the following PR: #8131 ## Links to any relevant issues fixes #8120 --------- Co-authored-by: Mirko Zichichi <[email protected]>
# Description of change Introduce create_auth_info_v1 native functions. This function provides the capability of creating an AuthenticatorInfoV1 pointing to a desired authenticate function. The gas costs for the native function haven't been identified yet. Tracking issue: #8433 The native function is not yet tested or integrated into the testing frameworks. Tracking issue: #8416 The possibility of enabling the use of private `authenticate` function will be investigated here: #8215 ## Links to any relevant issues fixes #8117 fixes #8216 ## How the change has been tested The `create_auth_info_v1` feature hasn't been tested yet, but the verifier was in a separate PR. ### Release Notes - [x] Protocol: Introduce new move native function create_auth_info_v1 and create_auth_info_self_v1 with its gas costs. - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API:
…asic abstracted IOTA account (#8250) # Description of change A new Move type has been introduced: ``` public struct IOTAccount has key { id: UID, } ``` What can we do with the introduced account: - Create an IOTAccount instance. - Use account dynamic fields. - Rotate the public key handled by the IOTAccount struct. - Use basic authenticator functions. ## Links to any relevant issues Fixes #8238 . --------- Co-authored-by: Istvan Davorin Acs <[email protected]> Co-authored-by: Valerii Reutov <[email protected]>
# Description of change Now the AuthenticatorInfoV1 is constructed on the Move side, instead of the Rust side. This way we avoid the BSC conversion issue we had before. Native function `create_auth_info_v1_impl` was also renamed to `check_auth_info` as that is exactly what it does. Checks if everything is correct, but it does not construct the AuthenticatorInfoV1. ## Links to any relevant issues fixes #8528 ## How the change has been tested Not tested. ### Release Notes - [x] Protocol: `create_auth_info_v1_cost_base` changed to `check_auth_info_v1_cost_base` - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API:
# Description of change Fixed `AuthenticatorInfoV1` dynamic field ID generation when validating an account object. ## Links to any relevant issues fixes #8545 --------- Co-authored-by: Mirko Zichichi <[email protected]> Co-authored-by: miker83z <[email protected]>
# Description of change
Fixed the following issue:
```
ErrorObject { code: ServerError(-32002), message: "Transaction execution failed due to issues with transaction inputs, please review the errors and try again:\n- Failed to execute the Move authenticator, reason: \"ExecutionError: ExecutionError { inner: ExecutionErrorInner { kind: CommandArgumentError { arg_idx: 2, kind: InvalidUsageOfPureArg }, source: Some(\\\"Non-primitive argument at index 2. If it is an object, it must be populated by an object\\\"), command: Some(0) } }\".", data: None }.
```
It is a temporary fix; the solution will be refactored to align with the
`TxContext` approach.
## Links to any relevant issues
fixes #8545
…8577) # Description of change Given that the `AuthContext` Move representation makes use of the `TypeName`, i.e., the string representation of the type, its serializer was implemented to support the conversion from `TypeInput` to `TypeName`. ## Links to any relevant issues Fixes #8455 issue 3 ## 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 ### Release Notes - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API:
# Description of change This example shows how to create an abstracted account and send a TX through it using a Move-based Ed25519 authentication. Here’s what it does step by step: 1. **Setup** **IMPORTANT**: this example needs to run a local network with a faucet manually (see instructions below for the exact command) * Connects to a local IOTA network using `IotaClientBuilder`. * Initializes an in-memory keystore and imports a test account from a fixed mnemonic. * Requests test tokens (faucet) for the sender. 3. **Create an IOTAccount** * Publishes the **IOTAccount Move package** (which uses an Account Abstraction logic) to the network. * Uses the published package to create a new `IOTAccount` shared object. * Requests faucet tokens for the new account. 4. **Build a Simple Transaction** * Prepares a sample PTB (`iota_account_simple_tx`) that calls `iota_account::add_field` with dummy values. * Uses the `IOTAccount` as the sender. 5. **Sign & Authenticate** * Signs the transaction data with the `IOTAccount` owner’s Ed25519 key. * Encodes the signature and wraps it in a `MoveAuthenticator` so it can be verified by the on-chain authenticator in Move. 6. **Execute Transaction** * Submits the signed transaction with the Move-based authenticator to the network. ## Links to any relevant issues Fixes #8538 ## How the change has been tested - start a local network `cargo run --bin iota start --force-regenesis --with-faucet --faucet-amount 100000000000000 --committee-size 2 --epoch-duration-ms 3600000` - `cd docs/examples/rust` - `cargo run --example iotaccount` - The explorer can be helpful (runs only with some browser configurations) https://explorer.iota.org/?network=http%3A%2F%2F127.0.0.1%3A9000
# Description of change This PR contains a `Dynamic Multisig Account` example implementation. ## Links to any relevant issues fixes #8621
…8539) # Description of change Added a number of e2e tests for the `iota-execution/latest/iota-verifier/src/account_auth_verifier.rs`. ## Links to any relevant issues fixes #8414 fixes #8525 ## How the change has been tested - [ ] Basic tests (linting, compilation, formatting, unit/integration tests) - [ ] Patch-specific tests (correctness, functionality coverage) - [x] 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
# Description of change Refactor `iota_account` example to make it more reusable by extracting its construction and protection aspects. `iota_account` has its tests fully reworked, now they should cover 100% all expected behavior. `basic_keyed_account` has been left in the `iota_account` package for now, for simplicity, but in the future we may extract it further. The tests for this module have only been ported with no further modifications. Some of it can/could be simplified, because with the current setup certain scenarios are already forbidden, such as when non-accounts attempt to modify state. ## Links to any relevant issues fixes #8710 ## How the change has been tested - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [ ] 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
|
The latest updates on your projects. Learn more about Vercel for GitHub. 6 Skipped Deployments
|
iota-ci
added
sc-platform
…aa-auth/8116-feature-branch
…aa-auth/8116-feature-branch
) # Description of change This PR adds a new set of e2e tests for the Account Abstraction feature: - create an abstract account - issue a TX using it - issue a sponsored TX using it This is based on an implementation of a Move module that supports basic operations for an Abstract Account (it could be modified later). This is also the base for a series of additional e2e tests in the future. ## Links to any relevant issues Fixes #8670 ## 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
…#8602) # Description of change Implement "Time locked account" example for abstract accounts. This example explores the possibility of utilizing the authentication logic. Each authenticator type can have a number of "reserved" dynamic fields and provide basic functions for attaching, detaching, rotating, checking and borrowing that type. Properly using these functions is the responsibility of the implementer, but given the language restrictions this is a very flexible pattern. ## Links to any relevant issues fixes #8534 ## 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 - [ ] I have checked that new and existing unit tests pass locally with my changes
#8697) # Description of change This package adds plugin-based execution feature to an IOTAccount, enabling a per-pubkey allow-set of callable functions identified as `(package, module, function)`. The authenticate entrypoint implements a dual flow: - Owner flow: if the provided pubkey is the stored owner key, only Ed25519 verification is required (no allow-set or command-count checks). - User flow: otherwise, after Ed25519 verification, the PTB must contain exactly one MoveCall, and that call must be present in the delegated pubkey’s allow-set. ## Links to any relevant issues Fixes #8680 . ## How the change has been tested Run move tests for `function_key` package. `iota move test`
…text` creation (#8881) # Description of change Added a new Move execution mode named `Validation`. It is allowed to use the `iota::auth_context::AuthContext` type only in this execution mode. `iota::auth_context::AuthContext` is added to a transaction parameters list in the same way as it is implemented for `iota::tx_context::TxContext` ## Links to any relevant issues fixes #8845
…er) MoveAuthenticator (#8963) # Description of change 1. Improved `MoveAuthenticator:: verify_claims` implementation by checking the author address. 2. Check a transaction's authenticator amount; allow only one authenticator(sender) until we implement sponsor support. ## Links to any relevant issues fixes #8747
…nsus (#8927) # Description of change This makes so that a move authentication passing pre-consensus (validators sign the TX) and failing post-consensus produces some effects (gas charging). I think starting from `test_abstract_account_post_consensus_failure()` is a good way to understand the logic behind the change. Basically, what is needed, is to make it so that this can happen: 1) Create an AA TX and make the majority of validators to sign it; this means that the Move authentication based on the AA shared object state is CURRENTLY successful. 2) Then, tamper with the AA shared object state by altering the state of the AA shared object (e.g., create and send for execution a second TX that changes a field of the AA shared object). 3) Finally, submit for execution the original certificate, i.e., the one obtained from the signature of the majority of validators. This PR changes the behavior at this step: - before this PR, the TX execution simply didn't go through but just raised a Move authentication error within the iota-core; - whilst, after this PR, the Move authentication error is treated as execution error and thus producing effects; the result is that all input objects are considered when creating the transaction effects and the gas coin is reduced with the authentication computation gas cost execution. This PR also merges input objects in the case of a successful execution. In order to produce effects, the method `authenticate_then_execute_transaction_to_effects()` was added to the execution engine. This new method executes all the steps necessary to create the TransactionEffects after the authentication execution. This means that, after running `authenticate_transaction_inner()` and failing (as well as succeeding), the execution continues with `execute_transaction_to_effects_inner()` in order to finish the job, i.e., creating effects for a failing (or successful) transaction. ## Links to any relevant issues Fixes #8908 ## 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
# Description of change The changes made in this PR are aimed at optimizing the loading of transaction inputs. ## Links to any relevant issues fixes #8849
# Description of change This PR contains a refactoring to avoid gas coins double-check during transaction handling. ## Links to any relevant issues fixes #8847
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Please write a summary of your changes and why you made them.
Links to any relevant issues
Be sure to reference any related issues by adding
fixes #(issue).How the change has been tested