chore: remove repetitive words

Signed-off-by: welfuture <wellfuture@qq.com>
This commit is contained in:
welfuture 2024-04-20 20:51:34 +08:00
parent 2712dd3f3f
commit 4ba2c84d73
13 changed files with 18 additions and 18 deletions

View File

@ -560,7 +560,7 @@ class AlgoTest(PortalCore):
bal = self.getBalances(client, player.getAddress())
pprint.pprint(bal)
print("upgrading the the guardian set using untrusted account...")
print("upgrading the guardian set using untrusted account...")
upgradeVAA = bytes.fromhex(gt.genGuardianSetUpgrade(gt.guardianPrivKeys, 1, 2, seq, seq))
vaaLogs.append(["guardianUpgrade", upgradeVAA.hex()])
self.submitVAA(upgradeVAA, client, player, self.coreid)

View File

@ -73,7 +73,7 @@ class AlgoTests {
console.log("seq = ", seq);
console.log("XXX upgrading the the guardian set using untrusted account...", seq)
console.log("XXX upgrading the guardian set using untrusted account...", seq)
let upgradeVAA = testLib.genGuardianSetUpgrade(guardianPrivKeys, 0, 1, seq, seq, guardianKeys)
console.log(upgradeVAA)
console.log(parseVAA(hexStringToUint8Array(upgradeVAA)))

View File

@ -71,7 +71,7 @@ When transferring a native token out for the first time, we
When transferring an NFT from a collection on a foreign chain to Aptos, a
corresponding "wrapped" collection is created. The module responsible for this
is [wrapped.move](sources/wrapped.move). The collection name is the the NFT name
is [wrapped.move](sources/wrapped.move). The collection name is the NFT name
field from the transfer VAA. To avoid collisions here, each NFT is minted into a
freshly created creator account, implemented as a resource account.

View File

@ -1,7 +1,7 @@
// This module is for dynamically deploying a module/CoinType on-chain,
// as opposed to submitting a tx from off-chain to publish a module containing the CoinType.
//
// Specifically, we wish to dynamically deploy the the following module
// Specifically, we wish to dynamically deploy the following module
//
// module deployer::coin {
// struct T has key {}

View File

@ -1276,7 +1276,7 @@ fn handle_initiate_transfer_token(
// ongoing transfer in progress here, otherwise we would override
// its state. This could happen if the asset's TransferFrom handler
// sends us an InitiateTransfer message, which would be executed
// before the reply handler due the the depth-first semantics of
// before the reply handler due the depth-first semantics of
// message execution. A simple protection mechanism is to require
// that there's no execution in progress. The reply handler takes
// care of clearing out this temporary storage when done.

View File

@ -1143,7 +1143,7 @@ fn handle_initiate_transfer_token(
// ongoing transfer in progress here, otherwise we would override
// its state. This could happen if the asset's TransferFrom handler
// sends us an InitiateTransfer message, which would be executed
// before the reply handler due the the depth-first semantics of
// before the reply handler due the depth-first semantics of
// message execution. A simple protection mechanism is to require
// that there's no execution in progress. The reply handler takes
// care of clearing out this temporary storage when done.

View File

@ -56,5 +56,5 @@ Currently there is no implementation of a token contract migration function that
## Historical note:
In Aug 2022, an attempt to upgrade the the token contracts was made, but failed due to the gas error:
In Aug 2022, an attempt to upgrade the token contracts was made, but failed due to the gas error:
https://finder.terra.money/classic/tx/FE39E9549770F59E2AAA1C6B0B86DDF36A4C56CED0CFB0CA4C9D4CC9FBE1E5BA. A subsequent upgrade changed the code id of *new* wrapped contracts to 767, but did not perform the migration for old contracts. This means that currently (as of Dec 2023), some wrapped tokens are still on the old code id, and some (the ones deployed after Aug 2022) are on the new code. This discrepancy is fine in the current case, because it only affects the rendering of the token name (https://github.com/wormhole-foundation/wormhole/commit/c832b123fcfb017d55086cb4d71241370ed270c6).

View File

@ -237,7 +237,7 @@ NewContract [32]uint8
## Caveats
### Transfer completion
A user who initiated a transfer should call `completeTransfer` within 24 hours. Guardian Sets are guaranteed to be valid for at least 24 hours. If the user waits longer, it could be that the Guardian Set has changed between the time where the transfer was initiated and the the time the user attempts to redeem the VAA. Let's call the Guardian Set at the time of signing `setA` and the Guardian Set at the time of redeeming on the target chain `setB`.
A user who initiated a transfer should call `completeTransfer` within 24 hours. Guardian Sets are guaranteed to be valid for at least 24 hours. If the user waits longer, it could be that the Guardian Set has changed between the time where the transfer was initiated and the time the user attempts to redeem the VAA. Let's call the Guardian Set at the time of signing `setA` and the Guardian Set at the time of redeeming on the target chain `setB`.
If `setA != setB` and more than 24 hours have passed, there are multiple options for still redeeming the VAA on the target chain:
1. The quorum of Guardians that signed the VAA may still be part of `setB`. In this case, the VAA merely needs to be modified to have the new Guardian Set Index along with any `setA` only guardian signatures removed to make a valid VAA. The updated VAA can then be be redeemed. The typescript sdk includes a [`repairVaa()`](../sdk/js/src/utils/repairVaa.ts) function to perform this automatically.

View File

@ -130,7 +130,7 @@ NewContract [32]uint8
## Caveats
### Transfer completion
A user who initiated a transfer should call `completeTransfer` within 24 hours. Guardian Sets are guaranteed to be valid for at least 24 hours. If the user waits longer, it could be that the Guardian Set has changed between the time where the transfer was initiated and the the time the user attempts to redeem the VAA. Let's call the Guardian Set at the time of signing `setA` and the Guardian Set at the time of redeeming on the target chain `setB`.
A user who initiated a transfer should call `completeTransfer` within 24 hours. Guardian Sets are guaranteed to be valid for at least 24 hours. If the user waits longer, it could be that the Guardian Set has changed between the time where the transfer was initiated and the time the user attempts to redeem the VAA. Let's call the Guardian Set at the time of signing `setA` and the Guardian Set at the time of redeeming on the target chain `setB`.
If `setA != setB` and more than 24 hours have passed, there are multiple options for still redeeming the VAA on the target chain:
1. The quorum of Guardians that signed the VAA may still be part of `setB`. In this case, the VAA merely needs to be modified to have the new Guardian Set Index along with any `setA` only guardian signatures removed to make a valid VAA. The updated VAA can then be be redeemed. The typescript sdk includes a [`repairVaa()`](../sdk/js/src/utils/repairVaa.ts) function to perform this automatically.

View File

@ -12375,7 +12375,7 @@ paths:
bonded shares
multiplied by exchange rate.
description: validators defines the the validators' info of a delegator.
description: validators defines the validators' info of a delegator.
pagination:
type: object
properties:
@ -43408,7 +43408,7 @@ definitions:
exchange rate. Voting power can be calculated as total bonded shares
multiplied by exchange rate.
description: validators defines the the validators' info of a delegator.
description: validators defines the validators' info of a delegator.
pagination:
type: object
properties:

View File

@ -22,7 +22,7 @@ This file tests to make sure that the network can start from genesis, and then c
Prerequesites: Have two nodes running - the tilt guardian validator, and the 'second' wormhole chain node.
This test will register the the public ket of the second node, and then process a governance VAA to switch over the network.
This test will register the public ket of the second node, and then process a governance VAA to switch over the network.
*/

View File

@ -547,7 +547,7 @@ export interface V1Beta1QueryDelegatorUnbondingDelegationsResponse {
Query/DelegatorValidator RPC method.
*/
export interface V1Beta1QueryDelegatorValidatorResponse {
/** validator defines the the validator info. */
/** validator defines the validator info. */
validator?: Stakingv1Beta1Validator;
}
@ -556,7 +556,7 @@ export interface V1Beta1QueryDelegatorValidatorResponse {
Query/DelegatorValidators RPC method.
*/
export interface V1Beta1QueryDelegatorValidatorsResponse {
/** validators defines the the validators' info of a delegator. */
/** validators defines the validators' info of a delegator. */
validators?: Stakingv1Beta1Validator[];
/** pagination defines the pagination in the response. */
@ -616,7 +616,7 @@ export interface V1Beta1QueryValidatorDelegationsResponse {
}
export interface V1Beta1QueryValidatorResponse {
/** validator defines the the validator info. */
/** validator defines the validator info. */
validator?: Stakingv1Beta1Validator;
}

View File

@ -42,7 +42,7 @@ export interface QueryValidatorRequest {
/** QueryValidatorResponse is response type for the Query/Validator RPC method */
export interface QueryValidatorResponse {
/** validator defines the the validator info. */
/** validator defines the validator info. */
validator: Validator | undefined;
}
@ -206,7 +206,7 @@ export interface QueryDelegatorValidatorsRequest {
* Query/DelegatorValidators RPC method.
*/
export interface QueryDelegatorValidatorsResponse {
/** validators defines the the validators' info of a delegator. */
/** validators defines the validators' info of a delegator. */
validators: Validator[];
/** pagination defines the pagination in the response. */
pagination: PageResponse | undefined;
@ -228,7 +228,7 @@ export interface QueryDelegatorValidatorRequest {
* Query/DelegatorValidator RPC method.
*/
export interface QueryDelegatorValidatorResponse {
/** validator defines the the validator info. */
/** validator defines the validator info. */
validator: Validator | undefined;
}