@ocap/client 1.25.6 → 1.26.0

package/docs/core-concepts-gas-payment.zh-TW.md

@@ -1,26 +1,26 @@
 # Gas 支付
 
-在大多數區塊鏈系統中，每筆交易都需要發起人支付一筆費用，通常稱為「gas」。對於可能沒有原生貨幣來支付這些費用的新使用者來說，這可能是一個重大的障礙。OCAP Client 引入了 Gas 支付功能，允許應用程式開發者贊助這些費用，為其使用者創造無縫的「無 gas」體驗。
+在大多數區塊鏈系統中，每筆交易都需要由發起人支付一筆費用，通常稱為「Gas」。對於可能沒有原生貨幣來支付這些費用的新使用者來說，這可能是一個重大的障礙。OCAP Client 引入了 Gas 支付功能，允許應用程式開發者贊助這些費用，為其使用者創造無縫的「免 Gas」體驗。
 
-這個強大的功能使 dApps 能夠將 gas 的複雜性抽離，從而改善使用者引導流程和應用程式的整體可用性。
+這個強大的功能使 dApp 能夠將 Gas 的複雜性抽象化，從而改善使用者引導流程和整體應用程式的可用性。
 
-## 運作原理
+## 運作方式
 
-Gas 支付機制是透過標準的 HTTP 標頭實現的。當您在您的客戶端實例上配置一個 gas 支付者錢包時，客戶端會自動將兩個特殊的標頭附加到它發送到區塊鏈節點的每個 `sendTx` 變異中：
+Gas 支付機制是透過標準的 HTTP 標頭來實現的。當您在客戶端實例上設定 Gas 支付者錢包時，客戶端會自動將兩個特殊的標頭附加到它發送給區塊鏈節點的每個 `sendTx` 變更中：
 
-- `x-gas-payer-pk`：將支付 gas 費用的錢包的公鑰。
-- `x-gas-payer-sig`：由 gas 支付者的私鑰簽署的 JSON Web Token (JWT)。此權杖包含交易的雜湊值，作為贊助商為該特定交易支付費用的可驗證授權。
+- `x-gas-payer-pk`：將支付 Gas 費用的錢包的公鑰。
+- `x-gas-payer-sig`：由 Gas 支付者私鑰簽署的 JSON Web Token (JWT)。此權杖包含交易的雜湊值，作為贊助者為該特定交易支付費用的可驗證授權。
 
-當區塊鏈節點收到交易時，它會執行兩項關鍵的驗證：
+當區塊鏈節點收到交易時，它會執行兩項關鍵驗證：
 
-1. 它會驗證使用者在交易本身上的簽名。
-2. 它會根據交易雜湊值，驗證標頭中 gas 支付者的簽名。
+1. 驗證交易本身的使用者簽名。
+2. 根據交易雜湊值驗證標頭中的 Gas 支付者簽名。
 
-如果兩個簽名都有效，交易將以使用者的權限執行，但相應的 gas 費用會從 gas 支付者的帳戶餘額中扣除。
+如果兩個簽名都有效，交易將在使用者授權下執行，但相應的 Gas 費用會從 Gas 支付者的帳戶餘額中扣除。
 
 ### 工作流程圖
 
-下圖說明了從交易發起到執行的整個 gas 支付流程：
+下圖說明了從交易發起到執行的整個 Gas 支付流程：
 
 ```d2 Gas 支付工作流程 icon=mdi:gas-station
 direction: down
@@ -45,17 +45,17 @@ Blockchain-Node: {
 }
 
 User-App -> OCAP-Client: "1. 使用者發起交易"
-OCAP-Client -> OCAP-Client: "2. 使用使用者錢包\n準備並簽署交易"
-Gas-Payer-Wallet -> OCAP-Client: "3. 為 gas 簽署交易雜湊"
+OCAP-Client -> OCAP-Client: "2. 使用使用者錢包準備並簽署交易"
+Gas-Payer-Wallet -> OCAP-Client: "3. 簽署交易雜湊值以支付 Gas"
 OCAP-Client -> Blockchain-Node: "4. 發送交易 + Gas 支付者標頭"
 Blockchain-Node -> Blockchain-Node: "5. 驗證雙方簽名"
 Blockchain-Node: "6. 執行交易"
-Blockchain-Node -> Gas-Payer-Wallet: "7. 扣除 gas 費用"
+Blockchain-Node -> Gas-Payer-Wallet: "7. 扣除 Gas 費用"
 ```
 
 ## 使用範例
 
-要啟用無 gas 交易，您只需為贊助帳戶創建一個錢包實例，並使用 `setGasPayer` 方法在客戶端上設定它。
+若要啟用免 Gas 交易，您只需為贊助帳戶建立一個錢包實例，並使用 `setGasPayer` 方法將其設定在客戶端上。
 
 ```javascript Gas 支付者設定與使用 icon=logos:javascript
 import Client from '@ocap/client';
@@ -64,7 +64,7 @@ import Wallet, { fromRandom } from '@ocap/wallet';
 // 1. 初始化客戶端以連接到 Beta 鏈
 const client = new Client('https://beta.abtnetwork.io/api');
 
-// 2. 為 gas 支付者（您的應用程式錢包）創建一個錢包
+// 2. 為 Gas 支付者（您的應用程式錢包）建立一個錢包
 // 此錢包必須有足夠的原生代幣（TBA）來支付交易費用。
 // 您可以從水龍頭獲取測試代幣：https://faucet.abtnetwork.io/
 const gasPayerWallet = Wallet.fromJSON({
@@ -73,39 +73,39 @@ const gasPayerWallet = Wallet.fromJSON({
   address: '...your_sponsor_address...',
 });
 
-// 3. 在客戶端實例上設定 gas 支付者
+// 3. 在客戶端實例上設定 Gas 支付者
 client.setGasPayer(gasPayerWallet);
 
-// 4. 為終端使用者創建一個錢包。
+// 4. 為終端使用者建立一個錢包。
 const userWallet = fromRandom();
 
-// 5. 使用使用者的錢包發送一筆交易。
-// 該交易由使用者簽署，但 gas 費用由 gasPayerWallet 支付。
+// 5. 使用使用者的錢包發送交易。
+// 該交易由使用者簽署，但 Gas 費用由 gasPayerWallet 支付。
 async function performGaslessTransaction() {
   try {
-    // 注意：雖然新帳戶在收到第一筆傳入交易時會在鏈上創建，
-    // 但它必須先存在於鏈上，才能*發送*交易。
+    // 注意：雖然新帳戶在收到第一筆入帳交易時會在鏈上建立，
+    // 但它必須先存在於鏈上才能 *發送* 交易。
     // 您可以透過從水龍頭向其發送少量代幣來進行初始化。
 
-    const receiverAddress = 'z1...'; // 一個有效的收款人地址
+    const receiverAddress = 'z1...'; // 一個有效的接收者地址
     const hash = await client.transfer({
       to: receiverAddress,
       tokens: [{ value: '0.1' }], // 發送 0.1 TBA
       wallet: userWallet,
     });
 
-    console.log('無 gas 交易成功。雜湊值：', hash);
-    console.log(`在區塊鏈瀏覽器上查看：https://beta.abtnetwork.io/explorer/txs/${hash}`);
+    console.log('Gasless transaction successful. Hash:', hash);
+    console.log(`Review on explorer: https://beta.abtnetwork.io/explorer/txs/${hash}`);
   } catch (error) {
-    console.error('交易失敗：', error);
+    console.error('Transaction failed:', error);
   }
 }
 
 performGaslessTransaction();
 ```
 
-在此範例中，`userWallet` 即使原生代幣餘額為零，也可以成功發送交易，因為 `gasPayerWallet` 支付了費用。這創造了一種順暢的體驗，特別是對於加入您應用程式的新使用者。
+在此範例中，即使 `userWallet` 的原生代幣餘額為零，它也可以成功發送交易，因為 `gasPayerWallet` 支付了費用。這創造了一種無摩擦的體驗，特別是對於加入您應用程式的新使用者而言。
 
 ---
 
-要了解交易從創建到最終確定的完整過程，請參閱 [交易生命週期](./core-concepts-transaction-lifecycle.md) 文件。
+若要了解交易從建立到最終確認的完整過程，請參閱 [交易生命週期](./core-concepts-transaction-lifecycle.md) 文件。

package/docs/core-concepts-gas-payment.zh.md

@@ -1,28 +1,28 @@
-# Gas 支付
+# Gas 费支付
 
-在大多数区块链系统中，每笔交易都需要发起者支付一笔费用，通常称为“gas”。对于没有原生货币来支付这些费用的新用户来说，这可能是一个巨大的障碍。OCAP Client 引入了 Gas 支付功能，允许应用程序开发者代付这些费用，从而为用户创造无缝的、“无 gas”体验。
+在大多数区块链系统中，每笔交易都需要发起者支付一笔费用，通常称为“Gas 费”。对于可能没有原生货币来支付这些费用的新用户来说，这可能是一个巨大的障碍。OCAP 客户端引入了 Gas 费支付功能，允许应用开发者代付这些费用，从而为他们的用户创造无缝的“无 Gas 费”体验。
 
-这一强大功能使 dApp 能够屏蔽 gas 的复杂性，从而改善用户引导流程和应用的整体易用性。
+这一强大功能使 dApp 能够将 Gas 费的复杂性抽象出来，从而改善用户入门体验和应用的整体可用性。
 
 ## 工作原理
 
-gas 支付机制通过标准的 HTTP 标头实现。当您在客户端实例上配置 gas 代付方钱包时，客户端会自动将两个特殊的标头附加到它发送给区块链节点的每个 `sendTx` mutation 请求中：
+Gas 费支付机制通过标准的 HTTP 标头实现。当您在客户端实例上配置一个 Gas 费支付方钱包时，客户端会自动将两个特殊的标头附加到它发送给区块链节点的每个 `sendTx` 变更请求中：
 
-- `x-gas-payer-pk`：将支付 gas 费用的钱包的公钥。
-- `x-gas-payer-sig`：由 gas 代付方私钥签名的 JSON Web Token (JWT)。此令牌包含交易的哈希值，作为代付方为该特定交易支付费用的可验证授权。
+- `x-gas-payer-pk`：将支付 Gas 费的钱包的公钥。
+- `x-gas-payer-sig`：由 Gas 费支付方私钥签名的 JSON Web Token (JWT)。此令牌包含交易的哈希值，作为支付方为该特定交易支付费用的可验证授权。
 
-当区块链节点收到交易时，它会执行两项关键验证：
+当区块链节点收到交易时，它会执行两个关键验证：
 
-1. 验证用户在交易本身的签名。
-2. 根据交易哈希验证标头中 gas 代付方的签名。
+1. 验证用户在交易本身上的签名。
+2. 根据交易哈希验证标头中 Gas 费支付方的签名。
 
-如果两个签名都有效，交易将在用户的授权下执行，但相应的 gas 费用将从 gas 代付方的账户余额中扣除。
+如果两个签名都有效，交易将在用户的授权下执行，但相应的 Gas 费将从 Gas 费支付方的账户余额中扣除。
 
 ### 工作流程图
 
-下图说明了从交易发起 Gas 支付到执行的整个流程：
+下图说明了从交易发起 Gas 费支付到执行的完整流程：
 
-```d2 Gas 支付工作流 icon=mdi:gas-station
+```d2 Gas 费支付工作流程 icon=mdi:gas-station
 direction: down
 
 User-App: {
@@ -31,12 +31,12 @@ User-App: {
 }
 
 Gas-Payer-Wallet: {
-  label: "Gas 代付方钱包\n(应用后端的钱包)"
+  label: "Gas 费支付方钱包\n（应用后端钱包）"
   shape: cylinder
 }
 
 OCAP-Client: {
-  label: "OCAP Client 实例"
+  label: "OCAP 客户端实例"
 }
 
 Blockchain-Node: {
@@ -46,66 +46,66 @@ Blockchain-Node: {
 
 User-App -> OCAP-Client: "1. 用户发起交易"
 OCAP-Client -> OCAP-Client: "2. 使用用户钱包\n准备并签署交易"
-Gas-Payer-Wallet -> OCAP-Client: "3. 为 gas 签署交易哈希"
-OCAP-Client -> Blockchain-Node: "4. 发送交易 + Gas 代付方标头"
+Gas-Payer-Wallet -> OCAP-Client: "3. 为 Gas 费签署交易哈希"
+OCAP-Client -> Blockchain-Node: "4. 发送交易及 Gas 费支付方标头"
 Blockchain-Node -> Blockchain-Node: "5. 验证双方签名"
 Blockchain-Node: "6. 执行交易"
-Blockchain-Node -> Gas-Payer-Wallet: "7. 扣除 gas 费用"
+Blockchain-Node -> Gas-Payer-Wallet: "7. 扣除 Gas 费"
 ```
 
-## 用法示例
+## 使用示例
 
-要启用无 gas 交易，您只需为代付账户创建一个钱包实例，并使用 `setGasPayer` 方法在客户端上进行设置。
+要启用无 Gas 费交易，您只需为代付账户创建一个钱包实例，并使用 `setGasPayer` 方法在客户端上进行设置。
 
-```javascript Gas Payer 设置与使用 icon=logos:javascript
+```javascript Gas 费支付方设置与使用 icon=logos:javascript
 import Client from '@ocap/client';
 import Wallet, { fromRandom } from '@ocap/wallet';
 
 // 1. 初始化客户端以连接到 Beta 链
 const client = new Client('https://beta.abtnetwork.io/api');
 
-// 2. 为 gas 代付方（您的应用程序的钱包）创建一个钱包
+// 2. 为 Gas 费支付方（你的应用钱包）创建一个钱包
 // 此钱包必须有足够的原生代币（TBA）来支付交易费用。
-// 您可以从水龙头获取测试代币：https://faucet.abtnetwork.io/
+// 你可以从水龙头获取测试代币：https://faucet.abtnetwork.io/
 const gasPayerWallet = Wallet.fromJSON({
   sk: '...your_sponsor_secret_key...',
   pk: '...your_sponsor_public_key...',
   address: '...your_sponsor_address...',
 });
 
-// 3. 在客户端实例上设置 gas 代付方
+// 3. 在客户端实例上设置 Gas 费支付方
 client.setGasPayer(gasPayerWallet);
 
 // 4. 为最终用户创建一个钱包。
 const userWallet = fromRandom();
 
-// 5. 使用用户的钱包发送一笔交易。
-// 交易由用户签名，但 gas 费用由 gasPayerWallet 支付。
+// 5. 使用用户钱包发送一笔交易。
+// 该交易由用户签名，但 Gas 费由 gasPayerWallet 支付。
 async function performGaslessTransaction() {
   try {
     // 注意：虽然新账户在收到第一笔入账交易时会在链上创建，
     // 但它必须在链上存在才能 *发送* 交易。
-    // 您可以通过从水龙头向其发送少量代币来初始化它。
+    // 你可以通过从水龙头向其发送少量代币来初始化它。
 
-    const receiverAddress = 'z1...'; // 一个有效的接收者地址
+    const receiverAddress = 'z1...'; // 一个有效的接收地址
     const hash = await client.transfer({
       to: receiverAddress,
       tokens: [{ value: '0.1' }], // 发送 0.1 TBA
       wallet: userWallet,
     });
 
-    console.log('无 gas 交易成功。哈希:', hash);
-    console.log(`在浏览器上查看: https://beta.abtnetwork.io/explorer/txs/${hash}`);
+    console.log('Gasless transaction successful. Hash:', hash);
+    console.log(`Review on explorer: https://beta.abtnetwork.io/explorer/txs/${hash}`);
   } catch (error) {
-    console.error('交易失败:', error);
+    console.error('Transaction failed:', error);
   }
 }
 
 performGaslessTransaction();
 ```
 
-在此示例中，`userWallet` 即使原生代币余额为零也能成功发送交易，因为 `gasPayerWallet` 承担了费用。这创造了无摩擦的体验，特别是对于加入您应用程序的新用户而言。
+在此示例中，即使 `userWallet` 的原生代币余额为零，它也可以成功发送交易，因为 `gasPayerWallet` 支付了费用。这创造了一种无摩擦的体验，特别是对于加入您应用的新用户而言。
 
 ---
 
-要了解从创建到最终确认的完整交易过程，请参阅[交易生命周期](./core-concepts-transaction-lifecycle.md)文档。
+要了解交易从创建到最终确认的完整过程，请参阅[交易生命周期](./core-concepts-transaction-lifecycle.md)文档。

package/docs/core-concepts-transaction-lifecycle.ja.md

@@ -1,10 +1,10 @@
 # トランザクションのライフサイクル
 
-トークンの転送やアセットの作成など、ブロックチェーンの状態を変更するすべてのアクションは、トランザクションを通じて実行されます。トランザクションのライフサイクルを理解することは、OCAP Clientを使用してアプリケーションを構築するための基本です。このプロセスには、準備、エンコード、署名、送信の4つの主要なステージが含まれます。
+トークンの転送やアセットの作成など、ブロックチェーンの状態を変更するすべてのアクションは、トランザクションを通じて実行されます。トランザクションのライフサイクルを理解することは、OCAP Client を使用してアプリケーションを構築する上で基本となります。このプロセスには、準備、エンコード、署名、送信という4つの主要な段階が含まれます。
 
-OCAP Clientは、最大限の制御のためにこれらのステップを個別に実行するか、利便性のためにそれらを組み合わせた高レベルのヘルパーを使用することができる、柔軟なメソッドセットを提供します。
+OCAP Client は柔軟なメソッドセットを提供しており、最大限の制御のためにこれらのステップを個別に実行することも、利便性のためにこれらを組み合わせた高レベルのヘルパーを使用することもできます。
 
-このガイドでは、各ステージを分解し、単一署名と複数署名の両方のワークフローを説明します。
+このガイドでは、各段階を詳しく解説し、単一署名と複数署名の両方のワークフローを説明します。
 
 ## ライフサイクルの概要
 
@@ -72,30 +72,30 @@ Multi-Sign-Flow -> Send-Tx
 Send-Tx -> End
 ```
 
-## ステージ1：準備（`itx`の作成）
+## ステージ1: 準備（`itx`の作成）
 
-すべてのトランザクションは`itx`（内部トランザクション）から始まります。これは、実行したいアクションの特定のデータを含むプレーンなJavaScriptオブジェクトです。例えば、転送`itx`には受信者のアドレスと金額が含まれます。
+すべてのトランザクションは `itx` (内部トランザクション) から始まります。これは、実行したいアクションの特定のデータを含むプレーンな JavaScript オブジェクトです。例えば、転送用の `itx` には、受信者のアドレスと金額が含まれます。
 
 ```javascript Preparing the itx icon=logos:javascript
 // 転送トランザクションのコアデータ
 const itx = {
   to: 'z2C8j81aL2oXpA5t42s2h4g9o8p1k6m3n7b', // 受信者のアドレス
-  value: await client.fromTokenToUnit(10),   // 送信する量、チェーンの基本単位に変換済み
+  value: await client.fromTokenToUnit(10),   // 送信する金額、チェーンの基本単位に変換済み
 };
 ```
 
-## ステージ2：エンコード
+## ステージ2: エンコード
 
-エンコードは、`itx`と他のメタデータを、暗号学的に署名できる標準化されたバイナリ形式に変換します。クライアントは、各トランザクションタイプに対して`encode{TxType}Tx`メソッド（例：`encodeTransferV2Tx`）を提供します。
+エンコードは、`itx` とその他のメタデータを、暗号学的に署名可能な標準化されたバイナリ形式に変換します。クライアントは、各トランザクションタイプごとに `encode{TxType}Tx` メソッド（例：`encodeTransferV2Tx`）を提供します。
 
-このステージで、クライアントは自動的に必須のメタデータを追加します。
+この段階で、クライアントは自動的に必須のメタデータを追加します。
 
-*   **`from`**：送信者のアドレス、提供されたウォレットから導出されます。
-*   **`chainId`**：ターゲットブロックチェーンの識別子、自動的に取得されます。
-*   **`nonce`**：リプレイ攻撃を防ぐためのユニークな番号で、デフォルトは現在のタイムスタンプ（`Date.now()`）です。
-*   **`pk`**：送信者のウォレットの公開鍵。
+*   **`from`**: 送信者のアドレス。提供されたウォレットから派生します。
+*   **`chainId`**: ターゲットブロックチェーンの識別子。自動的に取得されます。
+*   **`nonce`**: リプレイ攻撃を防ぐためのユニークな番号。デフォルトでは現在のタイムスタンプ（`Date.now()`）になります。
+*   **`pk`**: 送信者ウォレットの公開鍵。
 
-エンコード関数は、完全なトランザクションオブジェクトと、署名に使用されるシリアライズされたデータの`Buffer`の両方を返します。
+エンコード関数は、完全なトランザクションオブジェクトと、署名に使用されるシリアライズされたデータの `Buffer` の両方を返します。
 
 ```javascript Encoding the Transaction icon=logos:javascript
 const { object: encodedTx, buffer: txBuffer } = await client.encodeTransferV2Tx({
@@ -103,40 +103,40 @@ const { object: encodedTx, buffer: txBuffer } = await client.encodeTransferV2Tx(
   wallet: senderWallet,
 });
 
-console.log('エンコードされたTXオブジェクト:', encodedTx);
-console.log('署名されるバッファ:', txBuffer);
+console.log('Encoded TX Object:', encodedTx);
+console.log('Buffer to be signed:', txBuffer);
 ```
 
-## ステージ3：署名
+## ステージ3: 署名
 
-署名はアカウントの所有権を証明し、トランザクションを承認します。このプロセスは単一署名と複数署名のワークフローで異なります。
+署名は、アカウントの所有権を証明し、トランザクションを承認するものです。このプロセスは、単一署名と複数署名のワークフローで異なります。
 
 ### 単一署名ワークフロー
 
-これは最も一般的なシナリオで、単一のユーザーがトランザクションに署名します。`sign{TxType}Tx`メソッドは、エンコードされたトランザクションを受け取り、ユーザーの秘密鍵でバイナリバッファに署名し、`signature`フィールドに値を設定します。
+これは、単一のユーザーがトランザクションに署名する、最も一般的なシナリオです。`sign{TxType}Tx` メソッドは、エンコードされたトランザクションを受け取り、ユーザーの秘密鍵でバイナリバッファに署名し、`signature` フィールドに値を設定します。
 
 ```javascript Signing with a Single Signature icon=logos:javascript
 const signedTx = await client.signTransferV2Tx({
-  tx: encodedTx, // エンコードステップからのオブジェクト
+  tx: encodedTx, // エンコードステップで得られたオブジェクト
   wallet: senderWallet,
 });
 
-console.log('署名:', signedTx.signature);
+console.log('Signature:', signedTx.signature);
 ```
 
 ### 複数署名ワークフロー
 
-複数署名（マルチシグ）トランザクションは、複数の関係者からの承認が必要です。これは一般的にアトミックスワップや共有アカウントで使用されます。プロセスは順次実行されます。
+複数署名（マルチシグ）トランザクションは、複数の当事者からの承認を必要とします。これは、アトミックスワップや共有アカウントで一般的に使用されます。プロセスは順次的に行われます。
 
-1.  **準備**：初期トランザクションは、必要なすべての署名者を定義する`signaturesList`と共に作成されます。
-2.  **順次署名**：トランザクションは署名者から次の署名者へと渡されます。各署名者は対応する`multiSign{TxType}Tx`メソッドを使用して自身の署名を追加します。
+1.  **準備**: 最初のトランザクションは、必要なすべての署名者を定義する `signaturesList` とともに作成されます。
+2.  **順次署名**: トランザクションは署名者から次の署名者へと渡されます。各署名者は、対応する `multiSign{TxType}Tx` メソッドを使用して自身の署名を追加します。
 
-内部的に、`multiSign`メソッドは、署名のためにトランザクションをエンコードする前に既存のすべての署名を一時的に削除することで、各関係者が全く同じトランザクションダイジェストに署名することを保証します。
+内部的に、`multiSign` メソッドは、署名のためにトランザクションをエンコードする前に、既存のすべての署名を一時的に取り除くことで、各当事者が全く同じトランザクションダイジェストに署名することを保証します。
 
-以下は、二者がアセットを交換する`ExchangeTx`の例です。
+以下は、2つの当事者がアセットを交換する `ExchangeTx` の例です。
 
 ```javascript Multi-Signature Signing Example icon=logos:javascript
-// ステップ1：Alice（オファー側）が交換トランザクションを準備し、署名します。
+// ステップ1: Alice（オファー側）が交換トランザクションを準備し、署名します。
 const txFromAlice = await client.prepareExchange({
   offerToken: 10,
   demandToken: 20,
@@ -144,40 +144,40 @@ const txFromAlice = await client.prepareExchange({
   wallet: aliceWallet,
 });
 
-// ステップ2：トランザクションがBobに送信されます。
-// Bob（要求側）が署名を追加して最終化します。
+// ステップ2: トランザクションが Bob に送信されます。
+// Bob（デマンド側）が署名を追加して完了させます。
 const txFromBob = await client.finalizeExchange({
-  tx: txFromAlice, // Aliceによって署名されたトランザクション
+  tx: txFromAlice, // Alice によって署名されたトランザクション
   wallet: bobWallet,
 });
 
-console.log('Aliceの署名:', txFromBob.signaturesList[0].signature);
-console.log('Bobの署名:', txFromBob.signaturesList[1].signature);
+console.log('Alice\'s Signature:', txFromBob.signaturesList[0].signature);
+console.log('Bob\'s Signature:', txFromBob.signaturesList[1].signature);
 ```
 
-## ステージ4：送信
+## ステージ4: 送信
 
-トランザクションが完全に署名されると、処理のためにブロックチェーンノードに送信できます。`send{TxType}Tx`メソッドがこの最終ステップを処理します。
+トランザクションが完全に署名されると、処理のためにブロックチェーンノードに送信できます。`send{TxType}Tx` メソッドがこの最終ステップを処理します。
 
-便宜上、ウォレットと未署名のトランザクションを提供すれば、これらのメソッドは署名ステップを暗黙的に実行することもできます。メソッドは、送信が成功するとトランザクションハッシュで解決されるプロミスを返します。
+利便性のために、これらのメソッドは、ウォレットと未署名のトランザクションを提供した場合、署名ステップを暗黙的に実行することもできます。このメソッドは、送信が成功するとトランザクションハッシュで解決されるプロミスを返します。
 
 ```javascript Sending the Signed Transaction icon=logos:javascript
 // 事前に署名されたトランザクションを使用
 const hash = await client.sendTransferV2Tx({ tx: signedTx, wallet: senderWallet });
 
-// または、sendメソッドに署名を自動的に処理させる
+// または、send メソッドに署名を自動的に処理させる
 const hash2 = await client.sendTransferV2Tx({
   tx: { itx }, // 内部トランザクションのみ
   wallet: senderWallet,
 });
 
-console.log('トランザクション送信完了！ ハッシュ:', hash);
+console.log('Transaction sent! Hash:', hash);
 ```
 
-`commit: true`オプションを含めることで、プロミスが解決される前に、トランザクションが完全に確認され、ブロックに含まれるまでクライアントを待機させることもできます。
+また、`commit: true` オプションを含めることで、プロミスが解決される前に、トランザクションが完全に確認され、ブロックに含まれるまでクライアントを待機させることもできます。
 
 ## まとめ
 
-トランザクションのライフサイクルは、ブロックチェーンと対話するための堅牢で柔軟なフレームワークを提供します。プロセスを準備、エンコード、署名、送信という明確なステージに分けることで、OCAP Clientは開発者にトランザクション作成に対するきめ細かな制御を提供すると同時に、一般的なユースケースのためのシンプルで高レベルなヘルパーも提供します。
+トランザクションのライフサイクルは、ブロックチェーンと対話するための堅牢で柔軟なフレームワークを提供します。プロセスを準備、エンコード、署名、送信という明確な段階に分けることで、OCAP Client は開発者にトランザクション作成に対するきめ細やかな制御を提供すると同時に、一般的なユースケースのためのシンプルで高レベルなヘルパーも提供します。
 
-トランザクション手数料の処理方法についての詳細は、[ガス支払い](./core-concepts-gas-payment.md)ガイドを参照してください。利用可能なさまざまなクライアントタイプを理解するには、[クライアントアーキテクチャ](./core-concepts-client-architecture.md)ドキュメントを参照してください。
+トランザクション手数料の処理方法に関する詳細は、[ガス支払い](./core-concepts-gas-payment.md)ガイドを参照してください。利用可能なさまざまなクライアントタイプを理解するには、[クライアントアーキテクチャ](./core-concepts-client-architecture.md)のドキュメントを参照してください。

package/docs/core-concepts-transaction-lifecycle.zh-TW.md

@@ -1,10 +1,10 @@
 # 交易生命週期
 
-每個修改區塊鏈狀態的動作，例如轉移代幣或創建資產，都是透過交易來執行的。理解交易的生命週期是使用 OCAP Client 建立應用程式的基礎。此過程涉及四個主要階段：準備、編碼、簽署和發送。
+凡是會修改區塊鏈狀態的每個操作，例如轉移代幣或創建資產，都是透過交易來執行的。了解交易的生命週期是使用 OCAP 用戶端建構應用程式的基礎。此過程涉及四個主要階段：準備、編碼、簽署和發送。
 
-OCAP Client 提供了一套靈活的方法，讓您可以為了最大程度的控制而單獨執行這些步驟，或者為了方便而使用將它們組合在一起的高階輔助函式。
+OCAP 用戶端提供了一套彈性的方法，讓您可以為了最大程度的控制而單獨執行這些步驟，或者為了方便而使用將它們結合在一起的高階輔助函式。
 
-本指南將分解每個階段，並說明單簽和多簽的工作流程。
+本指南將分解每個階段，並闡述單一簽章和多重簽章的工作流程。
 
 ## 生命週期總覽
 
@@ -29,20 +29,20 @@ Sign-Tx: {
 }
 
 Single-Sign: {
-  label: "單一簽名\n(sign<Type>Tx)"
+  label: "單一簽章\n(sign<Type>Tx)"
   shape: rectangle
 }
 
 Multi-Sign-Flow: {
-  label: "多重簽名"
+  label: "多重簽章"
   shape: rectangle
   
   Multi-Sign-1: {
-    label: "簽署者 1\n(multiSign<Type>Tx)"
+    label: "簽署人 1\n(multiSign<Type>Tx)"
   }
   
   Multi-Sign-2: {
-    label: "簽署者 2\n(multiSign<Type>Tx)"
+    label: "簽署人 2\n(multiSign<Type>Tx)"
   }
 
   Multi-Sign-N: {
@@ -65,16 +65,16 @@ End: {
 
 Start -> Encode-Tx
 Encode-Tx -> Sign-Tx
-Sign-Tx -> Single-Sign: "單一簽署者"
-Sign-Tx -> Multi-Sign-Flow: "多重簽署者"
+Sign-Tx -> Single-Sign: "單一簽署人"
+Sign-Tx -> Multi-Sign-Flow: "多個簽署人"
 Single-Sign -> Send-Tx
 Multi-Sign-Flow -> Send-Tx
 Send-Tx -> End
 ```
 
-## 階段 1：準備 (建立 `itx`)
+## 階段 1：準備 (創建 `itx`)
 
-每筆交易都始於一個 `itx` (內部交易)。這是一個純粹的 JavaScript 物件，其中包含您想要執行的動作的具體資料。例如，一筆轉帳 `itx` 會包含收款人的地址和金額。
+每筆交易都始於一個 `itx`（內部交易）。這是一個純 JavaScript 物件，其中包含您想執行操作的特定資料。例如，一個轉帳 `itx` 會包含收款人地址和金額。
 
 ```javascript 準備 itx icon=logos:javascript
 // 我們轉帳交易的核心資料
@@ -86,16 +86,16 @@ const itx = {
 
 ## 階段 2：編碼
 
-編碼會將 `itx` 和其他元資料轉換為一個標準化的二進位格式，以便進行密碼學簽署。客戶端為每種交易類型提供了一個 `encode{TxType}Tx` 方法（例如 `encodeTransferV2Tx`）。
+編碼是將 `itx` 和其他元資料轉換為可進行密碼學簽署的標準化二進位格式。用戶端為每種交易類型提供了一個 `encode{TxType}Tx` 方法（例如 `encodeTransferV2Tx`）。
 
-在此階段，客戶端會自動添加必要的元資料：
+在此階段，用戶端會自動添加必要的元資料：
 
-*   **`from`**：發送者的地址，從提供的錢包中派生。
-*   **`chainId`**：目標區塊鏈的識別碼，會自動擷取。
-*   **`nonce`**：一個唯一的數字，用以防止重放攻擊，預設為當前時間戳 (`Date.now()`)。
-*   **`pk`**：發送者錢包的公鑰。
+*   **`from`**：發送方地址，從提供的錢包中衍生而來。
+*   **`chainId`**：目標區塊鏈的識別碼，會自動獲取。
+*   **`nonce`**：一個用來防止重放攻擊的唯一數字，預設為當前時間戳 (`Date.now()`)。
+*   **`pk`**：發送方錢包的公鑰。
 
-編碼函式會回傳完整的交易物件和序列化資料的 `Buffer`，後者用於簽署。
+編碼函式會返回完整的交易物件和序列化資料的 `Buffer`，後者用於簽署。
 
 ```javascript 編碼交易 icon=logos:javascript
 const { object: encodedTx, buffer: txBuffer } = await client.encodeTransferV2Tx({
@@ -103,40 +103,40 @@ const { object: encodedTx, buffer: txBuffer } = await client.encodeTransferV2Tx(
   wallet: senderWallet,
 });
 
-console.log('編碼後的 TX 物件:', encodedTx);
-console.log('待簽署的 Buffer:', txBuffer);
+console.log('Encoded TX Object:', encodedTx);
+console.log('Buffer to be signed:', txBuffer);
 ```
 
 ## 階段 3：簽署
 
-簽署證明了帳戶的所有權並授權該交易。單簽和多簽工作流程的過程有所不同。
+簽署證明了帳戶的所有權並授權該筆交易。單一簽章和多重簽章工作流程的過程有所不同。
 
-### 單簽工作流程
+### 單一簽章工作流程
 
-這是最常見的情境，即單一使用者簽署一筆交易。`sign{TxType}Tx` 方法會接收編碼後的交易，使用者的私鑰簽署二進位緩衝區，並填入 `signature` 欄位。
+這是最常見的情境，即由單一使用者簽署一筆交易。`sign{TxType}Tx` 方法會接收編碼後的交易，使用者的私鑰簽署二進位緩衝區，並填入 `signature` 欄位。
 
-```javascript 使用單一簽名進行簽署 icon=logos:javascript
+```javascript 使用單一簽章進行簽署 icon=logos:javascript
 const signedTx = await client.signTransferV2Tx({
   tx: encodedTx, // 來自編碼步驟的物件
   wallet: senderWallet,
 });
 
-console.log('簽名:', signedTx.signature);
+console.log('Signature:', signedTx.signature);
 ```
 
-### 多簽工作流程
+### 多重簽章工作流程
 
-多重簽名 (multisig) 交易需要多方批准。這通常用於原子交換或共享帳戶。此過程是循序的：
+多重簽章（multisig）交易需要多方批准。這通常用於原子交換或共享帳戶。這個過程是循序的：
 
-1.  **準備**：初始交易會與一個定義了所有必要簽署者的 `signaturesList` 一同建立。
-2.  **循序簽署**：交易會從一個簽署者傳遞到下一個。每個簽署者都使用對應的 `multiSign{TxType}Tx` 方法來添加他們的簽名。
+1.  **準備**：創建初始交易時，會帶有一個 `signaturesList`，其中定義了所有必要的簽署人。
+2.  **循序簽署**：交易從一個簽署人傳遞給下一個。每個簽署人都會使用對應的 `multiSign{TxType}Tx` 方法來添加自己的簽章。
 
-在內部，`multiSign` 方法會透過在編碼交易以供簽署前，暫時移除所有現有簽名，來確保各方簽署的是完全相同的交易摘要。
+在內部，`multiSign` 方法會透過在編碼交易以進行簽署前，暫時移除所有現有簽章，來確保每一方都簽署完全相同的交易摘要。
 
 以下是一個 `ExchangeTx` 的範例，其中兩方交換資產。
 
-```javascript 多重簽名範例 icon=logos:javascript
-// 步驟 1：Alice (要約方) 準備並簽署交換交易。
+```javascript 多重簽章範例 icon=logos:javascript
+// 步驟 1：Alice（要約人）準備並簽署交換交易。
 const txFromAlice = await client.prepareExchange({
   offerToken: 10,
   demandToken: 20,
@@ -144,22 +144,22 @@ const txFromAlice = await client.prepareExchange({
   wallet: aliceWallet,
 });
 
-// 步驟 2：交易被發送給 Bob。
-// Bob (承諾方) 添加他的簽名以完成交易。
+// 步驟 2：將交易發送給 Bob。
+// Bob（要求人）添加他的簽章以完成交易。
 const txFromBob = await client.finalizeExchange({
   tx: txFromAlice, // 由 Alice 簽署的交易
   wallet: bobWallet,
 });
 
-console.log('Alice 的簽名:', txFromBob.signaturesList[0].signature);
-console.log('Bob 的簽名:', txFromBob.signaturesList[1].signature);
+console.log('Alice\'s Signature:', txFromBob.signaturesList[0].signature);
+console.log('Bob\'s Signature:', txFromBob.signaturesList[1].signature);
 ```
 
 ## 階段 4：發送
 
-一旦交易完全簽署，就可以將其發送到區塊鏈節點進行處理。`send{TxType}Tx` 方法負責處理這最後一步。
+一旦交易被完整簽署，就可以將其發送到區塊鏈節點進行處理。`send{TxType}Tx` 方法處理這最後一步。
 
-為了方便起見，如果您提供一個錢包和一筆未簽署的交易，這些方法也可以隱式地執行簽署步驟。此方法會回傳一個 promise，在成功提交後，該 promise 會解析並回傳交易雜湊值。
+為求方便，如果您提供一個錢包和一筆未簽署的交易，這些方法也可以隱式地執行簽署步驟。該方法會返回一個 promise，在成功提交後，該 promise 會解析並回傳交易雜湊值。
 
 ```javascript 發送已簽署的交易 icon=logos:javascript
 // 使用預先簽署的交易
@@ -167,17 +167,17 @@ const hash = await client.sendTransferV2Tx({ tx: signedTx, wallet: senderWallet
 
 // 或者，讓發送方法自動處理簽署
 const hash2 = await client.sendTransferV2Tx({
-  tx: { itx }, // 僅有內部交易
+  tx: { itx }, // 只需內部交易
   wallet: senderWallet,
 });
 
-console.log('交易已發送！雜湊值:', hash);
+console.log('Transaction sent! Hash:', hash);
 ```
 
-您也可以包含一個 `commit: true` 選項，使客戶端等到交易完全確認並被包含在一個區塊中後，才解析該 promise。
+您也可以加入 `commit: true` 選項，讓用戶端等到交易完全確認並被納入一個區塊後，才解析該 promise。
 
 ## 總結
 
-交易生命週期提供了一個穩健且靈活的框架，用於與區塊鏈互動。透過將過程分解為不同的階段——準備、編碼、簽署和發送——OCAP Client 為開發者提供了對交易創建的精細控制，同時也為常見用例提供了簡單的高階輔助函式。
+交易生命週期為與區塊鏈互動提供了一個穩健而彈性的框架。透過將過程分解為不同的階段——準備、編碼、簽署和發送——OCAP 用戶端為開發者提供了對交易創建的精細控制，同時也為常見用例提供了簡單的高階輔助函式。
 
-有關交易手續費如何處理的更多詳情，請參閱 [Gas 費用支付](./core-concepts-gas-payment.md) 指南。要了解可用的不同客戶端類型，請參閱 [客戶端架構](./core-concepts-client-architecture.md) 文件。
+有關交易費用如何處理的更多詳情，請參閱 [Gas 支付](./core-concepts-gas-payment.md) 指南。要了解可用的不同用戶端類型，請參閱 [用戶端架構](./core-concepts-client-architecture.md) 文件。