@ocap/client 1.25.4 → 1.25.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (68) hide show
  1. package/dist/report.html +1 -1
  2. package/docs/api-reference-client-methods.ja.md +229 -0
  3. package/docs/api-reference-client-methods.zh-TW.md +229 -0
  4. package/docs/api-reference-client-methods.zh.md +27 -27
  5. package/docs/api-reference-data-types.ja.md +482 -0
  6. package/docs/api-reference-data-types.zh-TW.md +482 -0
  7. package/docs/api-reference-data-types.zh.md +14 -14
  8. package/docs/api-reference-low-level-api.ja.md +228 -0
  9. package/docs/api-reference-low-level-api.zh-TW.md +228 -0
  10. package/docs/api-reference-low-level-api.zh.md +39 -39
  11. package/docs/api-reference-query-mutation-methods.ja.md +814 -0
  12. package/docs/api-reference-query-mutation-methods.zh-TW.md +814 -0
  13. package/docs/api-reference-query-mutation-methods.zh.md +158 -158
  14. package/docs/api-reference-transaction-helpers.ja.md +649 -0
  15. package/docs/api-reference-transaction-helpers.zh-TW.md +649 -0
  16. package/docs/api-reference-transaction-helpers.zh.md +112 -112
  17. package/docs/api-reference.ja.md +23 -0
  18. package/docs/api-reference.zh-TW.md +23 -0
  19. package/docs/api-reference.zh.md +6 -6
  20. package/docs/core-concepts-client-architecture.ja.md +102 -0
  21. package/docs/core-concepts-client-architecture.zh-TW.md +102 -0
  22. package/docs/core-concepts-client-architecture.zh.md +21 -21
  23. package/docs/core-concepts-event-subscriptions.ja.md +123 -0
  24. package/docs/core-concepts-event-subscriptions.zh-TW.md +123 -0
  25. package/docs/core-concepts-event-subscriptions.zh.md +22 -22
  26. package/docs/core-concepts-gas-payment.ja.md +111 -0
  27. package/docs/core-concepts-gas-payment.zh-TW.md +111 -0
  28. package/docs/core-concepts-gas-payment.zh.md +30 -30
  29. package/docs/core-concepts-transaction-lifecycle.ja.md +183 -0
  30. package/docs/core-concepts-transaction-lifecycle.zh-TW.md +183 -0
  31. package/docs/core-concepts-transaction-lifecycle.zh.md +51 -51
  32. package/docs/core-concepts.ja.md +22 -0
  33. package/docs/core-concepts.zh-TW.md +22 -0
  34. package/docs/core-concepts.zh.md +6 -6
  35. package/docs/getting-started-basic-usage.ja.md +87 -0
  36. package/docs/getting-started-basic-usage.zh-TW.md +87 -0
  37. package/docs/getting-started-basic-usage.zh.md +17 -17
  38. package/docs/getting-started-installation.ja.md +60 -0
  39. package/docs/getting-started-installation.zh-TW.md +60 -0
  40. package/docs/getting-started-installation.zh.md +14 -14
  41. package/docs/getting-started.ja.md +16 -0
  42. package/docs/getting-started.zh-TW.md +16 -0
  43. package/docs/getting-started.zh.md +6 -5
  44. package/docs/how-to-guides-delegate-permissions.ja.md +167 -0
  45. package/docs/how-to-guides-delegate-permissions.zh-TW.md +167 -0
  46. package/docs/how-to-guides-delegate-permissions.zh.md +27 -28
  47. package/docs/how-to-guides-manage-accounts.ja.md +73 -0
  48. package/docs/how-to-guides-manage-accounts.zh-TW.md +73 -0
  49. package/docs/how-to-guides-manage-accounts.zh.md +14 -14
  50. package/docs/how-to-guides-manage-assets.ja.md +255 -0
  51. package/docs/how-to-guides-manage-assets.zh-TW.md +255 -0
  52. package/docs/how-to-guides-manage-assets.zh.md +60 -60
  53. package/docs/how-to-guides-manage-tokens.ja.md +179 -0
  54. package/docs/how-to-guides-manage-tokens.zh-TW.md +179 -0
  55. package/docs/how-to-guides-manage-tokens.zh.md +52 -52
  56. package/docs/how-to-guides-stake-tokens-and-assets.ja.md +205 -0
  57. package/docs/how-to-guides-stake-tokens-and-assets.zh-TW.md +205 -0
  58. package/docs/how-to-guides-stake-tokens-and-assets.zh.md +44 -44
  59. package/docs/how-to-guides-transfer-tokens-and-nfts.ja.md +179 -0
  60. package/docs/how-to-guides-transfer-tokens-and-nfts.zh-TW.md +179 -0
  61. package/docs/how-to-guides-transfer-tokens-and-nfts.zh.md +47 -47
  62. package/docs/how-to-guides.ja.md +27 -0
  63. package/docs/how-to-guides.zh-TW.md +27 -0
  64. package/docs/how-to-guides.zh.md +11 -11
  65. package/docs/overview.ja.md +70 -0
  66. package/docs/overview.zh-TW.md +70 -0
  67. package/docs/overview.zh.md +8 -8
  68. package/package.json +14 -14
@@ -0,0 +1,183 @@
1
+ # トランザクションのライフサイクル
2
+
3
+ トークンの転送やアセットの作成など、ブロックチェーンの状態を変更するすべてのアクションは、トランザクションを通じて実行されます。トランザクションのライフサイクルを理解することは、OCAP Clientを使用してアプリケーションを構築するための基本です。このプロセスには、準備、エンコード、署名、送信の4つの主要なステージが含まれます。
4
+
5
+ OCAP Clientは、最大限の制御のためにこれらのステップを個別に実行するか、利便性のためにそれらを組み合わせた高レベルのヘルパーを使用することができる、柔軟なメソッドセットを提供します。
6
+
7
+ このガイドでは、各ステージを分解し、単一署名と複数署名の両方のワークフローを説明します。
8
+
9
+ ## ライフサイクルの概要
10
+
11
+ 以下の図は、準備からブロックチェーンへの最終的な送信までのトランザクションの完全な流れを示しています。
12
+
13
+ ```d2 Transaction Lifecycle Diagram
14
+ direction: down
15
+
16
+ Start: {
17
+ label: "1. Itxの準備"
18
+ shape: oval
19
+ }
20
+
21
+ Encode-Tx: {
22
+ label: "2. トランザクションのエンコード\n(encode<Type>Tx)"
23
+ shape: rectangle
24
+ }
25
+
26
+ Sign-Tx: {
27
+ label: "3. トランザクションの署名"
28
+ shape: diamond
29
+ }
30
+
31
+ Single-Sign: {
32
+ label: "単一署名\n(sign<Type>Tx)"
33
+ shape: rectangle
34
+ }
35
+
36
+ Multi-Sign-Flow: {
37
+ label: "複数署名"
38
+ shape: rectangle
39
+
40
+ Multi-Sign-1: {
41
+ label: "署名者1\n(multiSign<Type>Tx)"
42
+ }
43
+
44
+ Multi-Sign-2: {
45
+ label: "署名者2\n(multiSign<Type>Tx)"
46
+ }
47
+
48
+ Multi-Sign-N: {
49
+ label: "..."
50
+ }
51
+
52
+ Multi-Sign-1 -> Multi-Sign-2: "署名済みTXを渡す"
53
+ Multi-Sign-2 -> Multi-Sign-N: "署名済みTXを渡す"
54
+ }
55
+
56
+ Send-Tx: {
57
+ label: "4. トランザクションの送信\n(send<Type>Tx)"
58
+ shape: rectangle
59
+ }
60
+
61
+ End: {
62
+ label: "トランザクションハッシュ"
63
+ shape: oval
64
+ }
65
+
66
+ Start -> Encode-Tx
67
+ Encode-Tx -> Sign-Tx
68
+ Sign-Tx -> Single-Sign: "単一署名者"
69
+ Sign-Tx -> Multi-Sign-Flow: "複数署名者"
70
+ Single-Sign -> Send-Tx
71
+ Multi-Sign-Flow -> Send-Tx
72
+ Send-Tx -> End
73
+ ```
74
+
75
+ ## ステージ1:準備(`itx`の作成)
76
+
77
+ すべてのトランザクションは`itx`(内部トランザクション)から始まります。これは、実行したいアクションの特定のデータを含むプレーンなJavaScriptオブジェクトです。例えば、転送`itx`には受信者のアドレスと金額が含まれます。
78
+
79
+ ```javascript Preparing the itx icon=logos:javascript
80
+ // 転送トランザクションのコアデータ
81
+ const itx = {
82
+ to: 'z2C8j81aL2oXpA5t42s2h4g9o8p1k6m3n7b', // 受信者のアドレス
83
+ value: await client.fromTokenToUnit(10), // 送信する量、チェーンの基本単位に変換済み
84
+ };
85
+ ```
86
+
87
+ ## ステージ2:エンコード
88
+
89
+ エンコードは、`itx`と他のメタデータを、暗号学的に署名できる標準化されたバイナリ形式に変換します。クライアントは、各トランザクションタイプに対して`encode{TxType}Tx`メソッド(例:`encodeTransferV2Tx`)を提供します。
90
+
91
+ このステージで、クライアントは自動的に必須のメタデータを追加します。
92
+
93
+ * **`from`**:送信者のアドレス、提供されたウォレットから導出されます。
94
+ * **`chainId`**:ターゲットブロックチェーンの識別子、自動的に取得されます。
95
+ * **`nonce`**:リプレイ攻撃を防ぐためのユニークな番号で、デフォルトは現在のタイムスタンプ(`Date.now()`)です。
96
+ * **`pk`**:送信者のウォレットの公開鍵。
97
+
98
+ エンコード関数は、完全なトランザクションオブジェクトと、署名に使用されるシリアライズされたデータの`Buffer`の両方を返します。
99
+
100
+ ```javascript Encoding the Transaction icon=logos:javascript
101
+ const { object: encodedTx, buffer: txBuffer } = await client.encodeTransferV2Tx({
102
+ tx: { itx },
103
+ wallet: senderWallet,
104
+ });
105
+
106
+ console.log('エンコードされたTXオブジェクト:', encodedTx);
107
+ console.log('署名されるバッファ:', txBuffer);
108
+ ```
109
+
110
+ ## ステージ3:署名
111
+
112
+ 署名はアカウントの所有権を証明し、トランザクションを承認します。このプロセスは単一署名と複数署名のワークフローで異なります。
113
+
114
+ ### 単一署名ワークフロー
115
+
116
+ これは最も一般的なシナリオで、単一のユーザーがトランザクションに署名します。`sign{TxType}Tx`メソッドは、エンコードされたトランザクションを受け取り、ユーザーの秘密鍵でバイナリバッファに署名し、`signature`フィールドに値を設定します。
117
+
118
+ ```javascript Signing with a Single Signature icon=logos:javascript
119
+ const signedTx = await client.signTransferV2Tx({
120
+ tx: encodedTx, // エンコードステップからのオブジェクト
121
+ wallet: senderWallet,
122
+ });
123
+
124
+ console.log('署名:', signedTx.signature);
125
+ ```
126
+
127
+ ### 複数署名ワークフロー
128
+
129
+ 複数署名(マルチシグ)トランザクションは、複数の関係者からの承認が必要です。これは一般的にアトミックスワップや共有アカウントで使用されます。プロセスは順次実行されます。
130
+
131
+ 1. **準備**:初期トランザクションは、必要なすべての署名者を定義する`signaturesList`と共に作成されます。
132
+ 2. **順次署名**:トランザクションは署名者から次の署名者へと渡されます。各署名者は対応する`multiSign{TxType}Tx`メソッドを使用して自身の署名を追加します。
133
+
134
+ 内部的に、`multiSign`メソッドは、署名のためにトランザクションをエンコードする前に既存のすべての署名を一時的に削除することで、各関係者が全く同じトランザクションダイジェストに署名することを保証します。
135
+
136
+ 以下は、二者がアセットを交換する`ExchangeTx`の例です。
137
+
138
+ ```javascript Multi-Signature Signing Example icon=logos:javascript
139
+ // ステップ1:Alice(オファー側)が交換トランザクションを準備し、署名します。
140
+ const txFromAlice = await client.prepareExchange({
141
+ offerToken: 10,
142
+ demandToken: 20,
143
+ receiver: bobWallet.address,
144
+ wallet: aliceWallet,
145
+ });
146
+
147
+ // ステップ2:トランザクションがBobに送信されます。
148
+ // Bob(要求側)が署名を追加して最終化します。
149
+ const txFromBob = await client.finalizeExchange({
150
+ tx: txFromAlice, // Aliceによって署名されたトランザクション
151
+ wallet: bobWallet,
152
+ });
153
+
154
+ console.log('Aliceの署名:', txFromBob.signaturesList[0].signature);
155
+ console.log('Bobの署名:', txFromBob.signaturesList[1].signature);
156
+ ```
157
+
158
+ ## ステージ4:送信
159
+
160
+ トランザクションが完全に署名されると、処理のためにブロックチェーンノードに送信できます。`send{TxType}Tx`メソッドがこの最終ステップを処理します。
161
+
162
+ 便宜上、ウォレットと未署名のトランザクションを提供すれば、これらのメソッドは署名ステップを暗黙的に実行することもできます。メソッドは、送信が成功するとトランザクションハッシュで解決されるプロミスを返します。
163
+
164
+ ```javascript Sending the Signed Transaction icon=logos:javascript
165
+ // 事前に署名されたトランザクションを使用
166
+ const hash = await client.sendTransferV2Tx({ tx: signedTx, wallet: senderWallet });
167
+
168
+ // または、sendメソッドに署名を自動的に処理させる
169
+ const hash2 = await client.sendTransferV2Tx({
170
+ tx: { itx }, // 内部トランザクションのみ
171
+ wallet: senderWallet,
172
+ });
173
+
174
+ console.log('トランザクション送信完了! ハッシュ:', hash);
175
+ ```
176
+
177
+ `commit: true`オプションを含めることで、プロミスが解決される前に、トランザクションが完全に確認され、ブロックに含まれるまでクライアントを待機させることもできます。
178
+
179
+ ## まとめ
180
+
181
+ トランザクションのライフサイクルは、ブロックチェーンと対話するための堅牢で柔軟なフレームワークを提供します。プロセスを準備、エンコード、署名、送信という明確なステージに分けることで、OCAP Clientは開発者にトランザクション作成に対するきめ細かな制御を提供すると同時に、一般的なユースケースのためのシンプルで高レベルなヘルパーも提供します。
182
+
183
+ トランザクション手数料の処理方法についての詳細は、[ガス支払い](./core-concepts-gas-payment.md)ガイドを参照してください。利用可能なさまざまなクライアントタイプを理解するには、[クライアントアーキテクチャ](./core-concepts-client-architecture.md)ドキュメントを参照してください。
@@ -0,0 +1,183 @@
1
+ # 交易生命週期
2
+
3
+ 每個修改區塊鏈狀態的動作,例如轉移代幣或創建資產,都是透過交易來執行的。理解交易的生命週期是使用 OCAP Client 建立應用程式的基礎。此過程涉及四個主要階段:準備、編碼、簽署和發送。
4
+
5
+ OCAP Client 提供了一套靈活的方法,讓您可以為了最大程度的控制而單獨執行這些步驟,或者為了方便而使用將它們組合在一起的高階輔助函式。
6
+
7
+ 本指南將分解每個階段,並說明單簽和多簽的工作流程。
8
+
9
+ ## 生命週期總覽
10
+
11
+ 下圖說明了一筆交易從準備到最終提交至區塊鏈的完整過程。
12
+
13
+ ```d2 交易生命週期圖
14
+ direction: down
15
+
16
+ Start: {
17
+ label: "1. 準備 Itx"
18
+ shape: oval
19
+ }
20
+
21
+ Encode-Tx: {
22
+ label: "2. 編碼交易\n(encode<Type>Tx)"
23
+ shape: rectangle
24
+ }
25
+
26
+ Sign-Tx: {
27
+ label: "3. 簽署交易"
28
+ shape: diamond
29
+ }
30
+
31
+ Single-Sign: {
32
+ label: "單一簽名\n(sign<Type>Tx)"
33
+ shape: rectangle
34
+ }
35
+
36
+ Multi-Sign-Flow: {
37
+ label: "多重簽名"
38
+ shape: rectangle
39
+
40
+ Multi-Sign-1: {
41
+ label: "簽署者 1\n(multiSign<Type>Tx)"
42
+ }
43
+
44
+ Multi-Sign-2: {
45
+ label: "簽署者 2\n(multiSign<Type>Tx)"
46
+ }
47
+
48
+ Multi-Sign-N: {
49
+ label: "..."
50
+ }
51
+
52
+ Multi-Sign-1 -> Multi-Sign-2: "傳遞已簽署的 TX"
53
+ Multi-Sign-2 -> Multi-Sign-N: "傳遞已簽署的 TX"
54
+ }
55
+
56
+ Send-Tx: {
57
+ label: "4. 發送交易\n(send<Type>Tx)"
58
+ shape: rectangle
59
+ }
60
+
61
+ End: {
62
+ label: "交易雜湊值"
63
+ shape: oval
64
+ }
65
+
66
+ Start -> Encode-Tx
67
+ Encode-Tx -> Sign-Tx
68
+ Sign-Tx -> Single-Sign: "單一簽署者"
69
+ Sign-Tx -> Multi-Sign-Flow: "多重簽署者"
70
+ Single-Sign -> Send-Tx
71
+ Multi-Sign-Flow -> Send-Tx
72
+ Send-Tx -> End
73
+ ```
74
+
75
+ ## 階段 1:準備 (建立 `itx`)
76
+
77
+ 每筆交易都始於一個 `itx` (內部交易)。這是一個純粹的 JavaScript 物件,其中包含您想要執行的動作的具體資料。例如,一筆轉帳 `itx` 會包含收款人的地址和金額。
78
+
79
+ ```javascript 準備 itx icon=logos:javascript
80
+ // 我們轉帳交易的核心資料
81
+ const itx = {
82
+ to: 'z2C8j81aL2oXpA5t42s2h4g9o8p1k6m3n7b', // 收款人地址
83
+ value: await client.fromTokenToUnit(10), // 要發送的金額,已轉換為鏈上的基本單位
84
+ };
85
+ ```
86
+
87
+ ## 階段 2:編碼
88
+
89
+ 編碼會將 `itx` 和其他元資料轉換為一個標準化的二進位格式,以便進行密碼學簽署。客戶端為每種交易類型提供了一個 `encode{TxType}Tx` 方法(例如 `encodeTransferV2Tx`)。
90
+
91
+ 在此階段,客戶端會自動添加必要的元資料:
92
+
93
+ * **`from`**:發送者的地址,從提供的錢包中派生。
94
+ * **`chainId`**:目標區塊鏈的識別碼,會自動擷取。
95
+ * **`nonce`**:一個唯一的數字,用以防止重放攻擊,預設為當前時間戳 (`Date.now()`)。
96
+ * **`pk`**:發送者錢包的公鑰。
97
+
98
+ 編碼函式會回傳完整的交易物件和序列化資料的 `Buffer`,後者用於簽署。
99
+
100
+ ```javascript 編碼交易 icon=logos:javascript
101
+ const { object: encodedTx, buffer: txBuffer } = await client.encodeTransferV2Tx({
102
+ tx: { itx },
103
+ wallet: senderWallet,
104
+ });
105
+
106
+ console.log('編碼後的 TX 物件:', encodedTx);
107
+ console.log('待簽署的 Buffer:', txBuffer);
108
+ ```
109
+
110
+ ## 階段 3:簽署
111
+
112
+ 簽署證明了帳戶的所有權並授權該交易。單簽和多簽工作流程的過程有所不同。
113
+
114
+ ### 單簽工作流程
115
+
116
+ 這是最常見的情境,即單一使用者簽署一筆交易。`sign{TxType}Tx` 方法會接收編碼後的交易,使用者的私鑰簽署二進位緩衝區,並填入 `signature` 欄位。
117
+
118
+ ```javascript 使用單一簽名進行簽署 icon=logos:javascript
119
+ const signedTx = await client.signTransferV2Tx({
120
+ tx: encodedTx, // 來自編碼步驟的物件
121
+ wallet: senderWallet,
122
+ });
123
+
124
+ console.log('簽名:', signedTx.signature);
125
+ ```
126
+
127
+ ### 多簽工作流程
128
+
129
+ 多重簽名 (multisig) 交易需要多方批准。這通常用於原子交換或共享帳戶。此過程是循序的:
130
+
131
+ 1. **準備**:初始交易會與一個定義了所有必要簽署者的 `signaturesList` 一同建立。
132
+ 2. **循序簽署**:交易會從一個簽署者傳遞到下一個。每個簽署者都使用對應的 `multiSign{TxType}Tx` 方法來添加他們的簽名。
133
+
134
+ 在內部,`multiSign` 方法會透過在編碼交易以供簽署前,暫時移除所有現有簽名,來確保各方簽署的是完全相同的交易摘要。
135
+
136
+ 以下是一個 `ExchangeTx` 的範例,其中兩方交換資產。
137
+
138
+ ```javascript 多重簽名範例 icon=logos:javascript
139
+ // 步驟 1:Alice (要約方) 準備並簽署交換交易。
140
+ const txFromAlice = await client.prepareExchange({
141
+ offerToken: 10,
142
+ demandToken: 20,
143
+ receiver: bobWallet.address,
144
+ wallet: aliceWallet,
145
+ });
146
+
147
+ // 步驟 2:交易被發送給 Bob。
148
+ // Bob (承諾方) 添加他的簽名以完成交易。
149
+ const txFromBob = await client.finalizeExchange({
150
+ tx: txFromAlice, // 由 Alice 簽署的交易
151
+ wallet: bobWallet,
152
+ });
153
+
154
+ console.log('Alice 的簽名:', txFromBob.signaturesList[0].signature);
155
+ console.log('Bob 的簽名:', txFromBob.signaturesList[1].signature);
156
+ ```
157
+
158
+ ## 階段 4:發送
159
+
160
+ 一旦交易完全簽署,就可以將其發送到區塊鏈節點進行處理。`send{TxType}Tx` 方法負責處理這最後一步。
161
+
162
+ 為了方便起見,如果您提供一個錢包和一筆未簽署的交易,這些方法也可以隱式地執行簽署步驟。此方法會回傳一個 promise,在成功提交後,該 promise 會解析並回傳交易雜湊值。
163
+
164
+ ```javascript 發送已簽署的交易 icon=logos:javascript
165
+ // 使用預先簽署的交易
166
+ const hash = await client.sendTransferV2Tx({ tx: signedTx, wallet: senderWallet });
167
+
168
+ // 或者,讓發送方法自動處理簽署
169
+ const hash2 = await client.sendTransferV2Tx({
170
+ tx: { itx }, // 僅有內部交易
171
+ wallet: senderWallet,
172
+ });
173
+
174
+ console.log('交易已發送!雜湊值:', hash);
175
+ ```
176
+
177
+ 您也可以包含一個 `commit: true` 選項,使客戶端等到交易完全確認並被包含在一個區塊中後,才解析該 promise。
178
+
179
+ ## 總結
180
+
181
+ 交易生命週期提供了一個穩健且靈活的框架,用於與區塊鏈互動。透過將過程分解為不同的階段——準備、編碼、簽署和發送——OCAP Client 為開發者提供了對交易創建的精細控制,同時也為常見用例提供了簡單的高階輔助函式。
182
+
183
+ 有關交易手續費如何處理的更多詳情,請參閱 [Gas 費用支付](./core-concepts-gas-payment.md) 指南。要了解可用的不同客戶端類型,請參閱 [客戶端架構](./core-concepts-client-architecture.md) 文件。
@@ -1,72 +1,72 @@
1
1
  # 交易生命周期
2
2
 
3
- 每一个修改区块链状态的操作,例如转移通证或创建资产,都是通过交易来执行的。理解交易的生命周期是使用 OCAP Client 构建应用程序的基础。该过程涉及四个主要阶段:准备、编码、签名和发送。
3
+ 每一个修改区块链状态的操作,例如转移通证或创建资产,都是通过交易来执行的。理解交易的生命周期是使用 OCAP Client 构建应用的基础。此过程涉及四个主要阶段:准备、编码、签名和发送。
4
4
 
5
- OCAP Client 提供了一套灵活的方法,允许您单独执行这些步骤以实现最大程度的控制,或者使用高级辅助函数将它们组合起来以方便使用。
5
+ OCAP Client 提供了一套灵活的方法,允许您为了最大程度的控制而单独执行这些步骤,或者为了方便而使用将它们组合在一起的高级辅助函数。
6
6
 
7
- 本指南将分解每个阶段,并说明单签名和多重签名工作流。
7
+ 本指南将分解每个阶段,并说明单签名和多签名工作流。
8
8
 
9
- ## 生命周期概述
9
+ ## 生命周期概览
10
10
 
11
11
  下图说明了交易从准备到最终提交至区块链的完整过程。
12
12
 
13
- ```d2 交易生命周期图
13
+ ```d2 Transaction Lifecycle Diagram
14
14
  direction: down
15
15
 
16
16
  Start: {
17
- label: "1. 准备 Itx"
17
+ label: "1. Prepare Itx"
18
18
  shape: oval
19
19
  }
20
20
 
21
21
  Encode-Tx: {
22
- label: "2. 编码交易\n(encode<Type>Tx)"
22
+ label: "2. Encode Transaction\n(encode<Type>Tx)"
23
23
  shape: rectangle
24
24
  }
25
25
 
26
26
  Sign-Tx: {
27
- label: "3. 签署交易"
27
+ label: "3. Sign Transaction"
28
28
  shape: diamond
29
29
  }
30
30
 
31
31
  Single-Sign: {
32
- label: "单一签名\n(sign<Type>Tx)"
32
+ label: "Single Signature\n(sign<Type>Tx)"
33
33
  shape: rectangle
34
34
  }
35
35
 
36
36
  Multi-Sign-Flow: {
37
- label: "多重签名"
37
+ label: "Multi-Signature"
38
38
  shape: rectangle
39
39
 
40
40
  Multi-Sign-1: {
41
- label: "签名者 1\n(multiSign<Type>Tx)"
41
+ label: "Signer 1\n(multiSign<Type>Tx)"
42
42
  }
43
43
 
44
44
  Multi-Sign-2: {
45
- label: "签名者 2\n(multiSign<Type>Tx)"
45
+ label: "Signer 2\n(multiSign<Type>Tx)"
46
46
  }
47
47
 
48
48
  Multi-Sign-N: {
49
49
  label: "..."
50
50
  }
51
51
 
52
- Multi-Sign-1 -> Multi-Sign-2: "传递已签名的交易"
53
- Multi-Sign-2 -> Multi-Sign-N: "传递已签名的交易"
52
+ Multi-Sign-1 -> Multi-Sign-2: "Pass signed TX"
53
+ Multi-Sign-2 -> Multi-Sign-N: "Pass signed TX"
54
54
  }
55
55
 
56
56
  Send-Tx: {
57
- label: "4. 发送交易\n(send<Type>Tx)"
57
+ label: "4. Send Transaction\n(send<Type>Tx)"
58
58
  shape: rectangle
59
59
  }
60
60
 
61
61
  End: {
62
- label: "交易哈希"
62
+ label: "Transaction Hash"
63
63
  shape: oval
64
64
  }
65
65
 
66
66
  Start -> Encode-Tx
67
67
  Encode-Tx -> Sign-Tx
68
- Sign-Tx -> Single-Sign: "单一签名者"
69
- Sign-Tx -> Multi-Sign-Flow: "多个签名者"
68
+ Sign-Tx -> Single-Sign: "Single Signer"
69
+ Sign-Tx -> Multi-Sign-Flow: "Multiple Signers"
70
70
  Single-Sign -> Send-Tx
71
71
  Multi-Sign-Flow -> Send-Tx
72
72
  Send-Tx -> End
@@ -74,69 +74,69 @@ Send-Tx -> End
74
74
 
75
75
  ## 阶段 1:准备(创建 `itx`)
76
76
 
77
- 每笔交易都始于一个 `itx`(内部交易)。这是一个纯粹的 JavaScript 对象,包含了您想要执行的操作的具体数据。例如,一笔转账 `itx` 会包含接收者的地址和金额。
77
+ 每笔交易都始于一个 `itx`(内部交易)。这是一个纯粹的 JavaScript 对象,包含了您想要执行的操作的具体数据。例如,一个转账 `itx` 会包含接收方的地址和金额。
78
78
 
79
- ```javascript 准备 itx icon=logos:javascript
79
+ ```javascript Preparing the itx icon=logos:javascript
80
80
  // 我们转账交易的核心数据
81
81
  const itx = {
82
- to: 'z2C8j81aL2oXpA5t42s2h4g9o8p1k6m3n7b', // 接收者地址
83
- value: await client.fromTokenToUnit(10), // 发送的金额,已转换为链的基本单位
82
+ to: 'z2C8j81aL2oXpA5t42s2h4g9o8p1k6m3n7b', // 接收方地址
83
+ value: await client.fromTokenToUnit(10), // 要发送的金额,已转换为链的基本单位
84
84
  };
85
85
  ```
86
86
 
87
87
  ## 阶段 2:编码
88
88
 
89
- 编码将 `itx` 和其他元数据转换为一个标准化的二进制格式,以便进行加密签名。客户端为每种交易类型提供了一个 `encode{TxType}Tx` 方法(例如,`encodeTransferV2Tx`)。
89
+ 编码将 `itx` 和其他元数据转换为一种标准化的二进制格式,以便进行加密签名。客户端为每种交易类型提供了一个 `encode{TxType}Tx` 方法(例如,`encodeTransferV2Tx`)。
90
90
 
91
91
  在此阶段,客户端会自动添加必要的元数据:
92
92
 
93
- * **`from`**:发送者的地址,从提供的钱包中派生。
93
+ * **`from`**:发送方地址,从提供的钱包中派生。
94
94
  * **`chainId`**:目标区块链的标识符,自动获取。
95
- * **`nonce`**:一个唯一的数字,用于防止重放攻击,默认为当前时间戳(`Date.now()`)。
96
- * **`pk`**:发送者钱包的公钥。
95
+ * **`nonce`**:一个用于防止重放攻击的唯一数字,默认为当前时间戳(`Date.now()`)。
96
+ * **`pk`**:发送方钱包的公钥。
97
97
 
98
98
  编码函数会返回完整的交易对象和一个序列化数据的 `Buffer`,后者用于签名。
99
99
 
100
- ```javascript 编码交易 icon=logos:javascript
100
+ ```javascript Encoding the Transaction icon=logos:javascript
101
101
  const { object: encodedTx, buffer: txBuffer } = await client.encodeTransferV2Tx({
102
102
  tx: { itx },
103
103
  wallet: senderWallet,
104
104
  });
105
105
 
106
- console.log('编码后的交易对象:', encodedTx);
107
- console.log('待签名的 Buffer:', txBuffer);
106
+ console.log('编码后的交易对象:', encodedTx);
107
+ console.log('待签名的 Buffer', txBuffer);
108
108
  ```
109
109
 
110
110
  ## 阶段 3:签名
111
111
 
112
- 签名证明了账户的所有权并授权了该交易。对于单签名和多重签名工作流,此过程有所不同。
112
+ 签名证明了账户的所有权并授权该交易。单签名和多签名工作流的过程有所不同。
113
113
 
114
114
  ### 单签名工作流
115
115
 
116
116
  这是最常见的场景,即单个用户签署一笔交易。`sign{TxType}Tx` 方法接收编码后的交易,使用用户的私钥对二进制缓冲区进行签名,并填充 `signature` 字段。
117
117
 
118
- ```javascript 使用单一签名进行签名 icon=logos:javascript
118
+ ```javascript Signing with a Single Signature icon=logos:javascript
119
119
  const signedTx = await client.signTransferV2Tx({
120
- tx: encodedTx, // 编码步骤中生成的对象
120
+ tx: encodedTx, // 编码步骤中得到的对象
121
121
  wallet: senderWallet,
122
122
  });
123
123
 
124
- console.log('签名:', signedTx.signature);
124
+ console.log('签名:', signedTx.signature);
125
125
  ```
126
126
 
127
- ### 多重签名工作流
127
+ ### 多签名工作流
128
128
 
129
129
  多重签名(multisig)交易需要多方批准。这通常用于原子交换或共享账户。该过程是顺序的:
130
130
 
131
- 1. **准备**:创建初始交易时,带有一个 `signaturesList`,其中定义了所有必需的签名者。
131
+ 1. **准备**:创建初始交易时,需包含一个定义了所有必需签名者的 `signaturesList`。
132
132
  2. **顺序签名**:交易从一个签名者传递到下一个。每个签名者使用相应的 `multiSign{TxType}Tx` 方法添加自己的签名。
133
133
 
134
- 在内部,`multiSign` 方法通过在编码交易以供签名之前临时剥离所有现有签名,来确保各方签署完全相同的交易摘要。
134
+ 在内部,`multiSign` 方法通过在编码交易以进行签名之前临时剥离所有现有签名,来确保各方签署的是完全相同的交易摘要。
135
135
 
136
- 以下是一个 `ExchangeTx` 的示例,其中两方交换资产。
136
+ 以下是一个关于 `ExchangeTx` 的示例,其中两方交换资产。
137
137
 
138
- ```javascript 多重签名示例 icon=logos:javascript
139
- // 步骤 1:Alice(要约方)准备并签署交换交易。
138
+ ```javascript Multi-Signature Signing Example icon=logos:javascript
139
+ // 步骤 1:Alice(报价方)准备并签署交换交易。
140
140
  const txFromAlice = await client.prepareExchange({
141
141
  offerToken: 10,
142
142
  demandToken: 20,
@@ -145,24 +145,24 @@ const txFromAlice = await client.prepareExchange({
145
145
  });
146
146
 
147
147
  // 步骤 2:将交易发送给 Bob。
148
- // Bob(请求方)添加他的签名以最终完成交易。
148
+ // Bob(需求方)添加他的签名以最终完成交易。
149
149
  const txFromBob = await client.finalizeExchange({
150
- tx: txFromAlice, // 由 Alice 签署的交易
150
+ tx: txFromAlice, // 由 Alice 签名的交易
151
151
  wallet: bobWallet,
152
152
  });
153
153
 
154
- console.log('Alice 的签名:', txFromBob.signaturesList[0].signature);
155
- console.log('Bob 的签名:', txFromBob.signaturesList[1].signature);
154
+ console.log('Alice 的签名:', txFromBob.signaturesList[0].signature);
155
+ console.log('Bob 的签名:', txFromBob.signaturesList[1].signature);
156
156
  ```
157
157
 
158
158
  ## 阶段 4:发送
159
159
 
160
- 一旦交易完全签名,就可以将其发送到区块链节点进行处理。`send{TxType}Tx` 方法处理这最后一步。
160
+ 一旦交易被完全签名,就可以发送到区块链节点进行处理。`send{TxType}Tx` 方法处理这最后一步。
161
161
 
162
- 为方便起见,如果您提供一个钱包和一个未签名的交易,这些方法也可以隐式执行签名步骤。该方法返回一个 promise,在成功提交后,该 promise 会解析为交易哈希。
162
+ 为方便起见,如果您提供一个钱包和一个未签名的交易,这些方法也可以隐式执行签名步骤。该方法返回一个 promise,在成功提交后会解析为交易哈希。
163
163
 
164
- ```javascript 发送已签名的交易 icon=logos:javascript
165
- // 使用预先签署的交易
164
+ ```javascript Sending the Signed Transaction icon=logos:javascript
165
+ // 使用预先签名的交易
166
166
  const hash = await client.sendTransferV2Tx({ tx: signedTx, wallet: senderWallet });
167
167
 
168
168
  // 或者,让发送方法自动处理签名
@@ -171,13 +171,13 @@ const hash2 = await client.sendTransferV2Tx({
171
171
  wallet: senderWallet,
172
172
  });
173
173
 
174
- console.log('交易已发送!哈希:', hash);
174
+ console.log('交易已发送!哈希:', hash);
175
175
  ```
176
176
 
177
- 您还可以包含一个 `commit: true` 选项,使客户端等待交易完全确认并被包含在一个区块中后,再解析该 promise
177
+ 您还可以包含一个 `commit: true` 选项,让客户端在解析 promise 之前,等待交易被完全确认并包含在区块中。
178
178
 
179
179
  ## 总结
180
180
 
181
- 交易生命周期为与区块链交互提供了一个健壮而灵活的框架。通过将过程分解为不同的阶段——准备、编码、签名和发送——OCAP Client 为开发者提供了对交易创建的精细控制,同时也为常见用例提供了简单的高级辅助函数。
181
+ 交易生命周期为与区块链交互提供了一个强大而灵活的框架。通过将过程分解为准备、编码、签名和发送这几个不同阶段,OCAP Client 为开发者提供了对交易创建的精细控制,同时也为常见用例提供了简单的高级辅助函数。
182
182
 
183
- 有关交易费用处理的更多详细信息,请参阅 [Gas 支付](./core-concepts-gas-payment.md)指南。要了解可用的不同客户端类型,请参阅 [客户端架构](./core-concepts-client-architecture.md) 文档。
183
+ 有关如何处理交易费用的更多详情,请参阅[燃料费支付](./core-concepts-gas-payment.md)指南。要了解可用的不同客户端类型,请参阅[客户端架构](./core-concepts-client-architecture.md)文档。
@@ -0,0 +1,22 @@
1
+ # コアコンセプト
2
+
3
+ このセクションでは、OCAP Client ライブラリを形成する基本原則とアーキテクチャ上の決定について詳しく説明します。これらのコアコンセプトを理解することで、ライブラリの可能性を最大限に引き出し、より効率的なコードを記述し、問題をより効果的にトラブルシューティングできるようになります。
4
+
5
+ [ハウツーガイド](./how-to-guides.md)では特定のタスクのステップバイステップの手順を説明していますが、このセクションではその「方法」の背後にある「理由」を説明します。クライアントの構造、トランザクションが最初から最後までどのように処理されるか、リアルタイムイベントのリッスン方法、そしてガスレスなユーザーエクスペリエンスの作成方法について探ります。
6
+
7
+ <x-cards data-columns="2">
8
+ <x-card data-title="クライアントアーキテクチャ" data-icon="lucide:architecture" data-href="/core-concepts/client-architecture">
9
+ さまざまなクライアント実装(Node、ブラウザ、Lite)について学び、パフォーマンスとバンドルサイズを最適化するために、ご自身の環境に適したものを選択する方法を学びます。
10
+ </x-card>
11
+ <x-card data-title="トランザクションのライフサイクル" data-icon="lucide:refresh-cw" data-href="/core-concepts/transaction-lifecycle">
12
+ 単純な JavaScript オブジェクトからチェーン上で確認済みのブロックになるまでのトランザクションの過程を追い、作成、エンコード、署名、ブロードキャストまでをカバーします。
13
+ </x-card>
14
+ <x-card data-title="イベントサブスクリプション" data-icon="lucide:radio-tower" data-href="/core-concepts/event-subscriptions">
15
+ WebSocket ベースのサブスクリプション機能を使用してリアルタイムのオンチェーンイベントをリッスンし、動的で応答性の高いアプリケーションを実現する方法を発見します。
16
+ </x-card>
17
+ <x-card data-title="ガス支払い" data-icon="lucide:gas-pump" data-href="/core-concepts/gas-payment">
18
+ 指定されたウォレットがユーザーのトランザクション手数料を負担できるようにする強力なガス支払い機能を探索し、シームレスでガスレスな体験を創出します。
19
+ </x-card>
20
+ </x-cards>
21
+
22
+ これらの基礎的なトピックを理解することで、OCAP Client を使用して、堅牢でスケーラブル、かつユーザーフレンドリーなアプリケーションを構築するための準備が整います。
@@ -0,0 +1,22 @@
1
+ # 核心概念
2
+
3
+ 本節深入探討了 OCAP Client 程式庫的基本原則和架構決策。理解這些核心概念將有助於您充分發揮程式庫的潛力,撰寫更有效率的程式碼,並更有效地解決問題。
4
+
5
+ [操作指南](./how-to-guides.md) 提供了特定任務的逐步說明,而本節則解釋了「如何做」背後的「為什麼」。我們將探討客戶端的結構、交易從開始到結束的處理過程、如何監聽即時事件,以及如何創造無 Gas 費的使用者體驗。
6
+
7
+ <x-cards data-columns="2">
8
+ <x-card data-title="客戶端架構" data-icon="lucide:architecture" data-href="/core-concepts/client-architecture">
9
+ 了解不同的客戶端實作(Node、Browser、Lite),以及如何為您的環境選擇合適的實作以優化效能和打包大小。
10
+ </x-card>
11
+ <x-card data-title="交易生命週期" data-icon="lucide:refresh-cw" data-href="/core-concepts/transaction-lifecycle">
12
+ 追蹤一筆交易從簡單的 JavaScript 物件到鏈上確認區塊的完整過程,涵蓋創建、編碼、簽署和廣播。
13
+ </x-card>
14
+ <x-card data-title="事件訂閱" data-icon="lucide:radio-tower" data-href="/core-concepts/event-subscriptions">
15
+ 探索如何使用基於 WebSocket 的訂閱功能來監聽即時的鏈上事件,從而實現動態且響應迅速的應用程式。
16
+ </x-card>
17
+ <x-card data-title="Gas 費支付" data-icon="lucide:gas-pump" data-href="/core-concepts/gas-payment">
18
+ 探索強大的 Gas 費支付功能,該功能允許指定錢包為使用者支付交易費用,創造無縫、無 Gas 費的體驗。
19
+ </x-card>
20
+ </x-cards>
21
+
22
+ 掌握這些基礎主題後,您將能充分準備好使用 OCAP Client 建立穩健、可擴展且使用者友善的應用程式。