[TSSDKv2][3/n] Account and AuthenticationKey Classes #10210
Merged
Conversation
This file contains 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
0xmigo
requested review from
davidiw,
gregnazario,
heliuchuan,
banool,
0xmaayan,
xbtmatt and
a team
0xmigo
changed the title
gregnazario
reviewed
Sep 26, 2023
There was a problem hiding this comment.
Can we see if we can provide some sort of interfacing that will support multiple signing schemes on the account? That way we can support immediately Ed25519, MultiED25519, and extend to other schemes as well.
We should also look into multiple ways to derive account addresses for things like objects
Comment on lines
41
to
54
| private constructor(args: { privateKey: PrivateKey; address: AccountAddress }) { | ||
| const { privateKey, address } = args; | ||
|
|
||
| // Derive the public key from the private key | ||
| const keyPair = nacl.sign.keyPair.fromSeed(privateKey.toUint8Array().slice(0, 32)); | ||
| this.publicKey = new PublicKey({ hexInput: keyPair.publicKey }); | ||
|
|
||
| this.privateKey = privateKey; | ||
| this.accountAddress = address; | ||
| } |
There was a problem hiding this comment.
This is tied to an Ed25519 key, it should probably take in some interface supporting multiple types of keys. Otherwise, it doesn't support MultiEd25519, secpk etc.
There was a problem hiding this comment.
Updated to args to be an abstract class of PrivateKey
0xmaayan
reviewed
Sep 26, 2023
| } | ||
|
|
||
| /** | ||
| * Creates new account with provided private key |
There was a problem hiding this comment.
maybe?
Suggested change
| * Creates new account with provided private key | |
| * Retrieves an account with provided private key |
as we dont really create a new account
There was a problem hiding this comment.
Hmm, "Retrieves" feels weird to me. I can add a note to indicate - This does not actually creates an account on-chain.
There was a problem hiding this comment.
yea.. well nothing really creates account on chain lol
Maybe something like derive an account from a private key?
There was a problem hiding this comment.
Derive an account - I like it!
0xmigo
force-pushed
the
jin/sdkv2_multi_ed25519
branch
2 times, most recently
from
e313d4b to
7b8aa77
Compare
Base automatically changed from
jin/sdkv2_multi_ed25519
to
jin/sdkv2_ed25519
September 28, 2023 03:27
0xmigo
force-pushed
the
jin/sdkv2_account
branch
from
a538694 to
1e3fc44
Compare
added 6 commits
September 27, 2023 23:19
…abstract. And have all concrete crypto classes to extend from based abstract classes
0xmigo
force-pushed
the
jin/sdkv2_account
branch
2 times, most recently
from
bfcab20 to
84d489a
Compare
0xmigo
force-pushed
the
jin/sdkv2_account
branch
from
84d489a to
f5a97b0
Compare
0xmigo
commented
Sep 28, 2023
| * This method is private because it should only be called by the factory static methods. | ||
| * @returns Account | ||
| */ | ||
| private constructor(args: { privateKey: PrivateKey; address: AccountAddress }) { |
There was a problem hiding this comment.
I am thinking of modifying this to
private constructor(args: { privateKey: PrivateKey; publicKey: PublicKey; address: AccountAddress })
So we don't have to worry about schemes. All properties will just get assigned directly.
There was a problem hiding this comment.
We should probably add a PrivateKey -> PublicKey function on the PrivateKey. The great thing about asymmetrical key cryptography, is the public key should be derivable from the private key.
You will want to add an optional publicKey though for MultiEd25519
There was a problem hiding this comment.
If this is multisig account, then we probably don't have private key and cannot derive the public.
Maybe I will just have a optional privateKey in this case.
private constructor(args: { privateKey?: PrivateKey; publicKey: PublicKey; address: AccountAddress })
gregnazario
approved these changes
Sep 28, 2023
| import { ed25519, multiEd25519PkTestObject } from "./helper"; | ||
|
|
||
| describe("AuthenticationKey", () => { | ||
| it("should create an instance with save the hexinput correctly", () => { |
There was a problem hiding this comment.
Suggested change
| it("should create an instance with save the hexinput correctly", () => { | |
| it("should create an instance with save the hex input correctly", () => { |
|
|
||
| it("should derive an AccountAddress from AuthenticationKey with same string", () => { | ||
| const authKey = new AuthenticationKey({ data: ed25519.authKey }); | ||
| const accountAddress = authKey.derivedAddress(); |
There was a problem hiding this comment.
I know @davidiw changed this in the Rust code to simply accountAddress, though it could be a little debatable, since it doesn't have the same address if it's rotated
There was a problem hiding this comment.
It is accountAddress though... my reading was the derivedAddress was due to it being a portion of the auth key. Mind you, it isn't saying that public key is at that account address, it is just the value computed as an account address. Said another way, I read it more as as_account_address.
| * A private key and public key, associated with the given account | ||
| */ | ||
| readonly publicKey: PublicKey; | ||
| readonly privateKey: PrivateKey; |
There was a problem hiding this comment.
Note the private key doesn't apply to the MultiEd25519.
This is a little weird where we'd probably want the ability to have an account that is either:
- A single key account -> which can sign directly there with the private key
- A non-signable multi-sig account -> which you can verify, but not sign, and won't have a private key.
- Future will have passkeys or other types of accounts, which also may not have all the private information directly.
Additionally, for generated docs, let's try to put the comments above each item individually.
Let's roll with this for right now, but we need to clean this up probably mid next week to ensure there's a way to handle signatures with non single private key accounts.
There was a problem hiding this comment.
Yeah, this was the part where I spent the most time thinking on how to optimize the design, in order to be less confusing and complex.
At the end, I feel like if we want to accommodate all the scenarios, this class might start to get a bit complicate very quickly.
| * This method is private because it should only be called by the factory static methods. | ||
| * @returns Account | ||
| */ | ||
| private constructor(args: { privateKey: PrivateKey; address: AccountAddress }) { |
There was a problem hiding this comment.
We should probably add a PrivateKey -> PublicKey function on the PrivateKey. The great thing about asymmetrical key cryptography, is the public key should be derivable from the private key.
You will want to add an optional publicKey though for MultiEd25519
Comment on lines
+48
to
+50
| // Derive the public key from the private key | ||
| const keyPair = nacl.sign.keyPair.fromSeed(privateKey.toUint8Array().slice(0, 32)); | ||
| this.publicKey = new Ed25519PublicKey({ hexInput: keyPair.publicKey }); |
There was a problem hiding this comment.
Yeah, this is still tied to Ed25519. Can we add the derive function?
Comment on lines
+61
to
+66
| static generate(): Account { | ||
| const keyPair = nacl.sign.keyPair(); | ||
| const privateKey = new Ed25519PrivateKey({ value: keyPair.secretKey.slice(0, 32) }); | ||
| const address = new AccountAddress({ data: Account.authKey({ publicKey: keyPair.publicKey }).toUint8Array() }); | ||
| return new Account({ privateKey, address }); | ||
| } |
There was a problem hiding this comment.
We should probably change this to either generate_ed25519 or we can take in some sort of option that provides a scheme.
There was a problem hiding this comment.
Good one! I think taking in a scheme make sense. And probably default to ed25519 if not provided.
Comment on lines
+68
to
+95
| /** | ||
| * Derives an account with provided private key | ||
| * | ||
| * @param args.privateKey Hex - private key of the account | ||
| * @returns Account | ||
| */ | ||
| static fromPrivateKey(args: { privateKey: HexInput }): Account { | ||
| const privatekeyHex = Hex.fromHexInput({ hexInput: args.privateKey }); | ||
| const keyPair = nacl.sign.keyPair.fromSeed(privatekeyHex.toUint8Array().slice(0, 32)); | ||
| const privateKey = new Ed25519PrivateKey({ value: keyPair.secretKey.slice(0, 32) }); | ||
| const address = new AccountAddress({ data: Account.authKey({ publicKey: keyPair.publicKey }).toUint8Array() }); | ||
| return new Account({ privateKey, address }); | ||
| } | ||
|
|
||
| /** | ||
| * Derives an account with provided private key and address | ||
| * This is intended to be used for account that has it's key rotated | ||
| * | ||
| * @param args.privateKey Hex - private key of the account | ||
| * @param args.address AccountAddress - address of the account | ||
| * @returns Account | ||
| */ | ||
| static fromPrivateKeyAndAddress(args: { privateKey: HexInput; address: AccountAddress }): Account { | ||
| const privatekeyHex = Hex.fromHexInput({ hexInput: args.privateKey }); | ||
| const signingKey = nacl.sign.keyPair.fromSeed(privatekeyHex.toUint8Array().slice(0, 32)); | ||
| const privateKey = new Ed25519PrivateKey({ value: signingKey.secretKey.slice(0, 32) }); | ||
| return new Account({ privateKey, address: args.address }); | ||
| } |
There was a problem hiding this comment.
These can probably be a single one with an optional address (unless we had direct feedback that it was confusing).
Additionally, this would be prime for the derive public key, and all.
Comment on lines
+97
to
+104
| /** | ||
| * Derives an account with bip44 path and mnemonics, | ||
| * | ||
| * @param path. (e.g. m/44'/637'/0'/0'/0') | ||
| * Detailed description: {@link https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki} | ||
| * @param mnemonics. | ||
| * @returns AptosAccount | ||
| */ |
There was a problem hiding this comment.
Should mention this is for ed25519, or we rename it somehow.
Comment on lines
+23
to
+27
| // Scheme identifier for MultiEd25519 signatures used to derive authentication keys for MultiEd25519 public keys | ||
| static readonly MULTI_ED25519_SCHEME: number = 1; | ||
|
|
||
| // Scheme identifier for Ed25519 signatures used to derive authentication key for MultiEd25519 public key | ||
| static readonly ED25519_SCHEME: number = 0; |
There was a problem hiding this comment.
Note that a full list of schemes is here:
aptos-core/types/src/transaction/authenticator.rs
Lines 349 to 365 in c2c8ce3
I'd probably put them in numerical order
There was a problem hiding this comment.
I will add a scheme enum to TS SDK.
Comment on lines
+85
to
+90
| const bytes = new Uint8Array(pubKeyBytes.length + 1); | ||
| bytes.set(pubKeyBytes); | ||
| bytes.set([AuthenticationKey.ED25519_SCHEME], pubKeyBytes.length); | ||
|
|
||
| const hash = sha3Hash.create(); | ||
| hash.update(bytes); |
There was a problem hiding this comment.
Nit, could reduce duplicate code to a separate function with a different scheme, since all auth keys are derived the same way.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
Yeah, I believe many of the Phase 1 stuff are depending on the Account class. Lets get this in. I will have another PR to patch and fix all of the remaining comments. |
❌ Forge suite
|
|
This looks like an unrelated failure. I'm ninja landing this |
Poytr1
pushed a commit
to sentioxyz/aptos-core
that referenced
this pull request
Oct 4, 2023
* Add helper.ts and fixes based on comments * add asymmetric_crypto file which includes all crypto base classes as abstract. And have all concrete crypto classes to extend from based abstract classes * Update crypto classes name to include Ed25519 prefix * fixes based on comments * Add account and auth key classes * update Account class to accept abstract PublicKey and PrivateKey * update methods' comment
Poytr1
added a commit
to sentioxyz/aptos-core
that referenced
this pull request
Oct 4, 2023
* Update system-integrators-guide.md (aptos-labs#10087) The old url file doesn't exist anymore. must be changed to the new one. * [dashboards] sync grafana dashboards * [typo*] (aptos-labs#9912) * [typo*]Update delegation-pool-operations.md * [typo*]Update run-a-fullnode-on-gcp.md * [typo*]Update run-a-fullnode-on-gcp.md * [typo*]Update glossary.md * [Spec] Ensures for stake.move (aptos-labs#9700) * 1 * cannot finish hp * remove some wrong statements * hp1-3 * rewrite hp2 * rewrite hp2 again * hp1-3 * init * fix * fix ensures * fix ensure in the update_sat * fix comment * fix md * fix new comment * update comment * fix indent * fix timeout * fix timeout * fix timeout --------- Co-authored-by: chan-bing <[email protected]> * Update fullnode-source-code-or-docker.md (aptos-labs#9914) * [typo*]Update index.md (aptos-labs#9913) * [typo*]Update index.md * Update index.md --------- Co-authored-by: Christian Sahar <[email protected]> * [link*Update fullnode-source-code-or-docker.md (aptos-labs#9978) * Update aptos-bitvec/src/lib.rs (aptos-labs#10045) There is a mistake in the comment * Update delegation-pool-operations.md (aptos-labs#10171) remove deprecated function * trivial: fix rocksdb property reporter * forge: ability to override resource ask in Rust * [CLI] Add txn stream to local testnet (aptos-labs#10101) * [dashboards] sync grafana dashboards * [TS SDK V2] Add `General` api class (aptos-labs#10185) * add general api queries * add general api queries * [move] make vm clonable * Pass down resolver to MoveVmExt::new() In preparation for caching a warm VM * Move VM warm up into adapter * WarmVmCache * Fix circular dependency * [object] refactor burn/unburn (aptos-labs#9785) * Fix Issue 9717 by breaking critical edges in CFG in move-compiler (v1) (aptos-labs#10064) Fix issue aptos-labs#9717 by breaking critical edges in the CFG in move-compiler (v1). While issue 9717 mentions "inline", this is a red herring as inlining a vector loop just makes it more likely to have a reference parameter on the stack, which leads to a failure to correctly drop dead references in move-compiler/src/cfgir/liveness/mod.rs. I've left the initial test case bug_9717.move and added bug_9717_looponly.move that just has a loop illustrating the problem, along with several variants on the loop (one of them, break2, also exhibiting the problem). Anyway, the failure to properly place the reference drop happens when the constructed CFG has critical edges (edges from a node with multiple outgoing edges to a node with multiple ingoing edges). Such a situation is well-known in compiler literature to make it difficult to place instructions precisely based on certain analyses. Fortunately, this seems to be easily fixed by adding a small pass to add a node on each such critical edge, so that the drop can be placed properly even in the case of a break. Unfortunately, later passes can't deal with the resulting deep expression trees and chains of direct jumps that result in some cases, so I had to fix hlir/translate.rs to reduce stack depth for a given expression, and cfgir/optimize/inline_blocks.rs to properly remove the unneeded jumps. New tests also reveal misplaced warnings/errors about unused variables in the presence of inlining, so that was also fixed. * [Doc] Update build e2e dapp docs (aptos-labs#10165) * Update build e2e dapp docs * update js -> jsx * update * Update developer-docs-site/docs/tutorials/build-e2e-dapp/4-fetch-data-from-chain.md * f * f --------- Co-authored-by: David Wolinsky <[email protected]> * implement memoize high order function (aptos-labs#10110) * [Executor] Metadata and exists support (in Block-STM/executor) (aptos-labs#10170) * [move-vm] Refactor Loader (aptos-labs#9320) * Rename variant * [move-vm] Store ability in runtime type * fixup! [move-vm] Store ability in runtime type * fixup! fixup! [move-vm] Store ability in runtime type * fixup! fixup! fixup! [move-vm] Store ability in runtime type * [move_vm] Split loader into multiple files * [move_vm] Cache struct type for modules * [move_vm] Move depth cache to type cache * [move-vm] Use name to replace type index * [move-vm] Remove function index * [move-vm] Inline functions * [move-vm] Remove cached index from definition * [move-vm] Check cross module linking before loading * [move-vm] Remove global struct cache * [move-vm] Inline struct name to avoid excessive memory allocation * [move-vm] Split function in loader * [move-vm] Split out module cache * [e2e-test] Add randomized test for loader * Fix Lint * [move-vm] Cache signature resolution * [move-vm] Removed unneeded signature token * [move-vm] Arc-ed type argument * Fix Zekun's comments * fixup! [e2e-test] Add randomized test for loader * add comments for the test strategy * Rename struct name * More renaming * Addressing more comments * [consensus] Dedicated channel for proposal buffering and batch process * revert 9ed1da8 (aptos-labs#10256) * update move run to include more params (aptos-labs#9932) * [CLI] Update CLI binary doc site to include openssl3 instruction (aptos-labs#9964) * Update CLI binary doc site to include openssl3 instruction * Update developer-docs-site/docs/tools/aptos-cli/install-cli/download-cli-binaries.md Co-authored-by: Christian Sahar <[email protected]> * Update developer-docs-site/docs/tools/aptos-cli/install-cli/download-cli-binaries.md Co-authored-by: Christian Sahar <[email protected]> --------- Co-authored-by: David Wolinsky <[email protected]> Co-authored-by: Christian Sahar <[email protected]> * [dag] split notifier into Order and Proof Notifier [dag] additional ledger info verification checks [dag] separate out highest committed round provider [dag] introduce a ledger info provider trait * [CLI] Fix faucet component of local testnet without --force-restart (aptos-labs#10214) * Update Docker images (aptos-labs#10208) Co-authored-by: gedigi <[email protected]> * [ts-sdk-v2] Add .npmrc to ensure pnpm lockfile is consistent (aptos-labs#10251) * Update dependabot.yml to disable version update PRs (aptos-labs#10249) * CLI version bump to 2.1.1 (aptos-labs#10272) * Get Drand Move example to compile (aptos-labs#10196) * change names of drand and veiledcoin * drand compiles * drand tests compile * remove diff.txt * add retrieve lottery winner function * Update CLI dry run text (aptos-labs#10273) * add partial transaction queries (aptos-labs#10275) * [TSSDKv2][1/n] add Ed25519 classes (aptos-labs#10157) * add PrivateKey, PublicKey, and Signature classes * Add helper.ts and fixes based on comments * add asymmetric_crypto file which includes all crypto base classes as abstract. And have all concrete crypto classes to extend from based abstract classes * Update crypto classes name to include Ed25519 prefix * [TS SDK V2] Add Indexer account queries (aptos-labs#10216) * implement account indexer queries * add indexer account api queries * address feedback * [TSSDKv2][3/n] Account and AuthenticationKey Classes (aptos-labs#10210) * Add helper.ts and fixes based on comments * add asymmetric_crypto file which includes all crypto base classes as abstract. And have all concrete crypto classes to extend from based abstract classes * Update crypto classes name to include Ed25519 prefix * fixes based on comments * Add account and auth key classes * update Account class to accept abstract PublicKey and PrivateKey * update methods' comment * [ts-sdk-v2] Add getTransactions to the sdk-v2 transaction API (aptos-labs#10288) * Add getTransactions to the sdkv2 transaction API * Update ecosystem/typescript/sdk_v2/src/internal/transaction.ts Co-authored-by: Maayan <[email protected]> * update after merge --------- Co-authored-by: Greg Nazario <[email protected]> Co-authored-by: Maayan <[email protected]> * [aptos-stdlib] Cleanup error codes for divide by 0 * [marketplace-example] Fix royalties edge conditions There were two bugs with royalties and listings. One was that in v1, royalties could have a denominator 0, or be greater than 100% in legacy NFTs. This means that it's possible that payouts don't work correctly, or take more than expected. Now, royalties are bounded to 0-100%. The second issue was that commission was taken after royalties, but didn't consider that royalties could be 100%. Now, royalties are taken first, and commission is taken out of the remainder. This does mean the marketplace may not have any commission if the royalties are set to 100%. * [Spec] Fix spec (aptos-labs#10215) * fix spec * staking_contract spec * [Rust] Upgrade to Rust version 1.72.1 * [Forge][Chaos] remove jitter, make inter-region BW 300 Mbps (aptos-labs#10277) ### Description The changes are based on observations while measuring network performance and reading more into the dataset used. * Jitter: My understanding is that re-ordering of packets should be pretty rare in the real world, while the previous jitter configs would introduce re-ordering quite frequently. Unless we have a strong belief that jitter is present in our networks, we shouldn't mess with this. * Inter-region bitrate: The numbers this was based on are iperf with a single TCP stream. The results correlate strongly with RTT, which suggests that RTT is the limiting factor, so there's no real reason to constrain BW itself. For now, 300 Mbps is as fast as our network stack will go for 100+ ms RTT. * [Forge][PFN] remove epoch changes from some tests (aptos-labs#10278) ### Description This is in an effort to reduce noise in the PFN tests. Epoch changes are an obvious source of noise, although it's unclear how much it contributes to noise difference between runs. To still have coverage of epoch changes, the tests without chaos will still do 5 minute epoch changes. ### Test Plan Run ad-hoc forge run, observe no epoch changes. * [Forge][netbench] split into large and small messages for two region test (aptos-labs#10283) ### Description We found that the throughput for large and small messages is very different with large latencies. We update the test to run with large messages and then split out a small messages test. The large messages are useful for sanity checking the network setup, the small messages is something that we can hopefully improve upon. * [crypto] add secp256k1 support to aptos-crypto Pretty straight forward, but I think our crypto apis are really not great. The amount of traits that should really be compressed down into a single trait for PublicKey, PrivateKey, and Signature. This would make maintaining and adding new libraries so much easier. * [types] Add support for secp256k1 authenticator with this we can now send secp256k1 signed transactions to the blockchain... I'm going to do some code refactoring in authenticators and transactions before resuming the end-to-end testing and the feature gating of this feature. * [openapi] update openapi with secp256k1 * [types] remove AuthenticationKeyPreimage This was adding extra code and adding complexity to what is already a complex space. If we aren't going to use the preimage, we have no need to write the code. We need to be more dilligent about removing this type of unnecessary code from the codebase, because it really impairs our ability to move fast. * [types] remove prefix and rename derived_address on AuthenticationKey * AuthenticationKey and Address are 1:1, so all this code is legacy based upon some weird goal of trying to compress the account address into an insecure size back in Libra. Even the authors of this code have since moved to 32-bytes in their own blockchain. * prefix is never used and removed. * derived_address -> account_address because there's no derivation it is literally 1:1 * [api] end to end test for secp256k1 ecdsa * [features] add secp256k1 ecdsa * [Aptos Data Poller] Improve peer polling logic. * [Aptos Data Client] Update tests for new poller. * [exp] make it work for any upstream repo (aptos-labs#10016) * [indexer-grpc] k6 loadtest (aptos-labs#9493) * [Aptos Data Client] Improve selection for optimistic fetch and subscriptions. * [Aptos Data Client] Add new tests for peer selection logic. * Make InMemoryStateCalculatorV2 work with state sync chunks. (aptos-labs#10263) * [release-builder] Increase lockup before executing proposals Increase the lockup before executing proposals Currently the release flow started consistently failing because we need to increase the lockup This ensures that the lockup is sufficient before executing transactions Test Plan: not sure how to test other than by running against testnet??? Please advise * [Network] Replace RwLock with ArcSwap for trusted peers. * [Network] Reduce lock contention for peer metadata using cache. * replay-verify.yaml not reference workflows by @main * replay-verify: not cancel other sub-jobs on first failure * recalibrate single node benchmark for perf regression aptos-labs#10298 * [move-model] fix internal assertion violation in definition analysis (aptos-labs#10292) Co-authored-by: Aalok Thakkar <[email protected]> * [ts-sdk-v2] Rename endpoint to path in client * [ts-sdk-v2] Rename originMethod to name for API requests * [ts-sdk-v2] Simplify fullnode get requests * [ts-sdk-v2] Make Post requests simpler * [ts-sdk-v2] Update format and lint for SDK This fixes most of the SDK lints except for the pieces around the static functions for deserialize. * [ts-sdk-v2] Fix broken tests * [ts-sdk-v2] Replace "Generic error" * [ts-sdk-v2] Add derivation path invalid test * [ts-sdk-v2] Cleanup Account and crypto for code reuse 1. Allows deriving public key from private key 2. Detaches accounts from Single Ed25519 3. Adds some consistency to input naming * [ts-sdk-v2] Unify authentication key creation * [ts-sdk-v2] Add Authentication Key scheme enum * [ts-sdk-v2] Add ability to derive authkeys from non-key schemes * [ts-sdk-v2] Add docs to AuthenticationKey * [ts-sdk-v2] Cleanup documentation on Ed25519 * [ts-sdk-v2] Add documentation to asymmetric crypto * [ts-sdk-v2] Add docs, cleanup multi-ed25519 * [ts-sdk-v2] Move paginate with cursor to client * [ts-sdk-v2] Cleanup unused lint ignores * [ts-sdk-v2] Authentication key testing and message improvements * [ts-sdk-v2] Rename some client inputs and add documentation * [dag] epoch manager integration; dag is here * [dashboards] sync grafana dashboards * fix WarmVmCache Natives are stateful so must be covered by the WarmVmId. 1. add TimedFeaturesBuilder and convert TimedFeatures to an array of booleans. 2. add SafeNativeBulder::id_bytes() to fix the bug 3. rebuild vm (and hence all the natives) only when the builder id_bytes() change. * use s5cmd for downloading files in replay-verify official aswcli experiencing random crashes * [e2e-tests] Fix compilation error (aptos-labs#10318) * Drop frozen root after make checkpoint. (aptos-labs#10327) * redistribute mainnet replay sub-job ranges * [TS-SDK v2] Updating the `Deserializable` interface and making `Serializable` an abstract class (aptos-labs#10307) * Removing export from Deserializable to facilitate using a static `deserialize` method, fixing error messages in unit tests for multi_ed25519, and changing Serializable to an abstract class that implements `bcsToBytes()`. Removed abstract deserialize from public/private key classes. * Re-adding doc comments * Adding `serialize` and `deserialize` and corresponding unit tests to the AccountAddress class * Fixing multi_ed25519 error messages * Updating doc comments for Deserializable to clarify what its purpose is. * [move unit tests] Run extended checker as part of unit tests (aptos-labs#10309) * [move unit tests] Run extended checker as part of unit tests Closes aptos-labs#9251 This runs the extended checker as part of Aptos unit tests (either our own Rust integrated tests or from the CLI). It uses the same technique as we already used for native extensions specific to Aptos: a hook is defined where additional, move-model based validations can be run. This is hook is then connected to the extended checker when running Aptos tests. The implementation also optimizes the construction of the move model: if that one is already needed by abi generation (which is the default), it is not constructed a 2nd time for the extended checker -- both for the existing build step and the new test step. This should avoid one full additional compilation (source -> bytecode -> model run). * Extended checks until now excluded test code, leading to wrong usage of entry functions and attributes marked as test-only. Because fixing this is a breaking change, this commit adds the behavior to check test code via a new CLI option `--check-test-code`. This flag should eventually become default behavior. Also fixes some reviewer comments. * implement forge links to axiom (aptos-labs#10330) * [gas-calibration][simple] ignore terms with 0-coefficients (aptos-labs#9742) * [indexer][api] update the metrcis for api gateway consumption. (aptos-labs#10322) * [dag] add various counters * [TS-SDK v2] Adding `serializeVector` and `deserializeVector` to SDK v2 (aptos-labs#10347) * Adding `serializeVector` and `deserializeVector` to serializer.ts and deserializer.ts as well as a unit test for each * Adding documentation for each function * Removing redundant line in doc comment * Removing redundant line in deserializer doc comment too * Allow using skip_index_and_usage on state sync code path. (aptos-labs#10303) * [dag] add a few structured logging * jin_fix_ed25519_derive_publickey (aptos-labs#10357) * [ts-sdk-v2] Add MIME types, and convert input types from string to Enum (aptos-labs#10308) * Remove expensive counters (aptos-labs#10188) * [TS SDK V2] Port over transaction types (aptos-labs#10364) * transaction types * address comments * [CLI] Restructure local testnet code (aptos-labs#10252) * [release-builder] Fix increase lockup The previous PR was converting the private key arg to string incorrectly... ED25519 key type has a very silly to_string that returns debug output I suppose this is to prevent dumping the key, but really i think it should just not have a to_string and instead only have a debug method that does the same thing, and a very explicit to hex method so that you dont accidentally dump these. Test Plan: framework upgrade test succeeds, or at least doesnt fail on this error (there is still some underlying flakiness in the forge test itself) * [Sharded-Execution] Fix a race condition while fetching the state values on a shard from a remote stateview (aptos-labs#10320) [Sharded-Execution] Fix a race condition while fetching the state values on a shard from a remote stateview * [SDKv2] derive publickey unit test (aptos-labs#10358) * jin_fix_ed25519_derive_publickey * Add unit test for publicKey() derivate method * [framework] Turn on test-only checking and fix errors (aptos-labs#10368) This turns on running extended checks also on test-only code in the framework unit tests. A few errors discovered this way are fixed. Changes to function declarations in this PR do not effect compatibility because only test-only functions are effected which are stripped before deployment. Related to aptos-labs#10335, but more needs to be done to make this behavior the default. This cannot happen before the next framework release. * Add CI to check for banned CLI deps (aptos-labs#10338) * refactor: replace multiply_then_divide using math64::mul_div (aptos-labs#10047) Co-authored-by: Kevin <[email protected]> * [dag] hardening message verification * [TS SDK V2] Port over account and transaction authenticator, signed transaction type (aptos-labs#10367) * transaction types * address comments * authenticators * previewnet flow in the benchmark (aptos-labs#10305) * [ts sdk-v2] Mini get/post request refactor (aptos-labs#10380) * [Sharded-Execution-GRPC] Add GRPC communication for sharded execution. (aptos-labs#10274) [Sharded-Execution-GRPC] Add GRPC communication for sharded execution In this commit we replace the existing socket based communication (that is message send and message recv) with GRPC. Here we get the basic GRPC reliability. More reliability and better performance to come in subsequent commits * [forge] Fix fullnode override in forge (aptos-labs#10382) ### Description Fixing a mistake made in a previous PR, that made fullnode configs not apply (and overwrite validator configs) ### Test Plan Ran a fullnode test and manually check the config that is logged. * Update delegation-pool-operations.md (aptos-labs#10299) reorganize page * [indexer grpc] update the metrics for usage analysis. (aptos-labs#10383) * Update staking-pool-operations.md (aptos-labs#10300) * Update staking-pool-operations.md reorganize page * Update staking-pool-operations.md add step for owner account * Update staking-pool-operations.md * Update staking-pool-operations.md remove heading --------- Co-authored-by: Christian Sahar <[email protected]> * [Storage][Pruner] Set min_readable_version and metrics. (aptos-labs#10381) * rename enum variants and transaction arguments (aptos-labs#10384) * [indexer grpc] More fields to short connection metric (aptos-labs#10385) * [Tutorials] Replacing the old "Your First NFT" tutorial entry function calls to use aptos_token.move and new indexer queries (aptos-labs#9424) * Overwriting the old your-first-nft tutorial in the docs to replace the 0x3 contract calls with the aptos_token contract calls. Also added corresponding documentation tags to referenced indexer queries and the new token client calls. * Changing simple-aptos-token.py to simple_aptos_token.py and updating the Makefile to include it as an example * Changing `create_token` to `mint_token` in python tutorial and `createToken` in typescript to `mint` * Updating typescript example to work correctly if indexer/fullnode chainId aren't in sync * [Python SDK] Use AccountAddress.from_str_relaxed when parsing addresses from the node API --------- Co-authored-by: rtmtree <[email protected]> Co-authored-by: rustielin <[email protected]> Co-authored-by: Vladislav ~ cryptomolot <[email protected]> Co-authored-by: Zorrot Chen <[email protected]> Co-authored-by: chan-bing <[email protected]> Co-authored-by: Freesson ~ cryptomolot <[email protected]> Co-authored-by: Christian Sahar <[email protected]> Co-authored-by: Jiege <[email protected]> Co-authored-by: michelle-aptos <[email protected]> Co-authored-by: aldenhu <[email protected]> Co-authored-by: Daniel Porteous (dport) <[email protected]> Co-authored-by: Maayan <[email protected]> Co-authored-by: Zekun Li <[email protected]> Co-authored-by: Aaron <[email protected]> Co-authored-by: Brian R. Murphy <[email protected]> Co-authored-by: Oliver He <[email protected]> Co-authored-by: David Wolinsky <[email protected]> Co-authored-by: Rati Gelashvili <[email protected]> Co-authored-by: runtianz <[email protected]> Co-authored-by: Jin <[email protected]> Co-authored-by: Balaji Arun <[email protected]> Co-authored-by: Gerardo Di Giacomo <[email protected]> Co-authored-by: gedigi <[email protected]> Co-authored-by: Greg Nazario <[email protected]> Co-authored-by: Michael Straka <[email protected]> Co-authored-by: Teng Zhang <[email protected]> Co-authored-by: Josh Lind <[email protected]> Co-authored-by: Brian (Sunghoon) Cho <[email protected]> Co-authored-by: Rustie Lin <[email protected]> Co-authored-by: Guoteng Rao <[email protected]> Co-authored-by: Perry Randall <[email protected]> Co-authored-by: igor-aptos <[email protected]> Co-authored-by: aalok-t <[email protected]> Co-authored-by: Aalok Thakkar <[email protected]> Co-authored-by: Matt <[email protected]> Co-authored-by: Wolfgang Grieskamp <[email protected]> Co-authored-by: Christian Theilemann <[email protected]> Co-authored-by: Victor Gao <[email protected]> Co-authored-by: larry-aptos <[email protected]> Co-authored-by: Sital Kedia <[email protected]> Co-authored-by: Manu Dhundi <[email protected]> Co-authored-by: 0xbe1 <[email protected]> Co-authored-by: Kevin <[email protected]>
fEst1ck
pushed a commit
to fEst1ck/aptos-core
that referenced
this pull request
Oct 13, 2023
* Add helper.ts and fixes based on comments * add asymmetric_crypto file which includes all crypto base classes as abstract. And have all concrete crypto classes to extend from based abstract classes * Update crypto classes name to include Ed25519 prefix * fixes based on comments * Add account and auth key classes * update Account class to accept abstract PublicKey and PrivateKey * update methods' comment
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
Note: This is the
3rdstack of the whole work. Previous stack here -> #10186This PR adds the Account and AuthenticationKey classes. Most of the thing stays the same as v1, but with some modification.
PublicKeyandPrivateKeyobjectsVerifyandSignrelies on the method the corresponding keyTest Plan
Run all tests and make sure they all passes